oracle笔记

今天oracle服务器上真是经历了腥风血雨，杀的我是片甲不留啊，我先将问题描述一下，

之前的机房需要搬迁，于是学长在我不知情的情况下，把我一直在维护的oracle服务器断电，搬走，在新的机房他们安装完之后

学长告诉我，oracle数据用不了了

我远程登录oracle服务器，

SQL> startup
ORA-01081: cannot start already-running ORACLE - shut it down first
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
ORA-01110: data file 5: '/mnt/sdb/orcldata/iebddata1.dbf'

这个错误我之前没遇见过，大概意思是无法锁定识别数据文件，数据文件地址就是我之前表空间的存储文件

我查看了/mnt/sdb，发现里面的文件竟然全部没有了，没错，就是total=0！！！！！！

我当时就懵了，恶意删除肯定不会有的，只能说是在搬迁的过程中，可能出现了断电导致服务器硬盘挂载出现故障

可我当时没想到这一点啊，再加上之前学长说他备份了全部数据文件，我接下来的解决方法全部是顺着用备份来恢复

这就导致了接下来的连锁反应，一发不可收拾

我的思路，既然表空间没有了，那就新建一个表空间，再将数据导进去嘛（虽然我还不知道怎么导进去，毕竟将近600G的数据啊）

于是我按照这个思路进行下去，首先解决 无法开启数据库的问题

SQL> select status from v$instance;

STATUS ------------------------ MOUNTED

数据库状态一直保留在mounted，就是说无法打开，因为无法定位datafile

所以我就百度，网上说将出现问题的datafile进行offline

SQL>alter database datafile 5 offline drop;

我把所有无法定位的datafile都进行了offline，直到所有的datafile都搞定之后

我再alter database open

这次终于成功了，查看

SQL> select username,default_tablespace from user_users;

USERNAME ------------------------------------------------------------ DEFAULT_TABLESPACE ------------------------------------------------------------ SYS SYSTEM

这次是终于将数据库打开了，然后我就利用之前的数据库普通用户aaa登录

他的默认表空间还是之前的ttt，我想之前的表空间都不见了，这个默认表空间也就没什么意义了，我就把这个表空间删除了（最后想了想，自己真是手贱啊）

然后我在/mnt/sdb建了个新的文件夹orcldata，然后又建了新的表空间，将该表空间设置成aaa的默认表空间，中间出现了下面的问题，设置权限就解决了

ERROR at line 1:
ORA-01119: error in creating database file '/mnt/sdb/orcldata/iebddata1.dbf'
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied（将orcldata文件夹权限设置成chmod 777 -R 即可解决）

 

因为数据量比较大，我就需要扩展表空间，于是我就往表空间里添加新的datafile，这就出现问题，

SQL> alter tablespace iebd add datafile '/mnt/sdb/orcldata/iebddata2.dbf'
  2  size 30g autoextend on next 100m maxsize 31g;
alter tablespace iebd add datafile '/mnt/sdb/orcldata/iebddata2.dbf'
*
ERROR at line 1:
ORA-19502: write error on file "/mnt/sdb/orcldata/iebddata2.dbf", blockno
525696 (blocksize=8192)
ORA-27072: File I/O error
Linux-x86_64 Error: 9: Bad file descriptor
Additional information: 4
Additional information: 525696
Additional information: 458752

意思就是sdb空间不足，我想这不可能啊，明明有3T的空间，怎么就不够了，于是我df -h

[oracle@db-oracle-1 ~]$ df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   50G   43G  4.1G  92% /
tmpfs                          16G   72K   16G   1% /dev/shm
/dev/sda1                     485M   40M  421M   9% /boot
/dev/mapper/VolGroup-lv_home   50G  2.4G   45G   6% /home

发现没有sdb，怎么会没有呢，那我表空间在哪？于是我先向表空间增加一个G的datafile，

[oracle@db-oracle-1 ~]$ df -h
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/VolGroup-lv_root   50G   44G  3.1G  94% /
tmpfs                          16G   72K   16G   1% /dev/shm
/dev/sda1                     485M   40M  421M   9% /boot
/dev/mapper/VolGroup-lv_home   50G  2.4G   45G   6% /home

ok，这次终于知道了，sdb在VolGroup-lv内，我找了学长，他说硬盘压根就没有挂载上，他帮我把硬盘重新挂载，好吧，之前表空间的数据没有丢失，还在，这次我真正歇菜了，原先的表空间没有了

留着的dbf文件也难以恢复，于是我只能先做好两手准备，继续建立一个新的表空间，同时着手利用dbf文件进行恢复吧

哎！

 

我知道了最终的原因，是因为centos上每次重启都要重新挂载，这直接导致我没有识别    啊啊啊啊啊啊啊，于是做了开机重启自动挂载，都是丢人，错误都是我自己造成的。。。