一次教训，引以为鉴

一次教训，引以为鉴
数据库环境9.2.0.4 RAC两个节点
EMC存储

由于mail报警MIRRORRAC1 SPACE WILL BE USED UP SOON ..
要在裸设备新增数据文件
当时发现我记录的分区表，结合rawdevices表，发现由于在建立数据库初期给数据库预留的分区太少，到这次新增数据文件时
已经没有分区可以用了，必须用fdisk新增一个区，但是由于新增的区不会被OS认出（除非整个lun全部重新划分），
fdisk /dev/sdc 新建立sdc11（1026m），但是用dmesg|grep sdc11查不到，所以要想重新让OS能认，必须重新MOUNT这个区（没有试过），
但是由于sdc下面有很多区被使用了（除非数据库允许down机）。所以只能找其他捷径，因为我建立emc存储时划分了sdi,sdh,sdg没有被
划分（其实sdg已经划分了一个sdg5,问题就出在这），我看到这个sdg5已经在dmesg中可以看到，我看了一下相关的配置（当时建库时
的文档）没有发现使用了sdg5,当时好象也查了/etc/sysconfig/rawdevices也没有发现，在数据库中查了controlfile,redolog,datafile
等均未发现使用了sdg5,所以认为这个sdg5是可以被新增数据文件利用的，但是后来发现问题恰恰出现在这个sdg5,我后来恢复数据库后居然
在/etc/sysconfig/rawdevices中看到这个sdg5。
数据库是在alert中发现 600错误，发现monitor_kp无法访问，但是我在数据库中select count(*) from monitor_kp（其实是走索引的）
可以查到数据，认为数据库不存在问题。后来查看alert日志发现/opt/oracle/admin/oint/udump/oint1_ora_1842.trc文件中有
select * from monitor_kp order by id desc
该数据库读表数据错误。
先以为网站被攻击了，后来我发现可能跟我这次操作有关（这里也是一大过错，对自己过于相信是对的，没有及时去重起数据库，这里大概延时了15分钟）
于是准备重起数据库，shutdown abort时发生错误，ipcrm删除共享段，然后重起过程中就发现只能mount数据库，不能打开数据库，提示
/dbvol1/oradata/oint/appdata1m12.dbf数据文件坏了，然后我将数据库完全恢复起来，做了备份，网站数据库恢复正常。


添加数据文件的过程如下
raw /dev/raw/raw43 /dev/sdg5
/bin/ln -s /dev/raw/raw43 /dbvol1/oradata/oint/offerts03.dbf
chown oracle:oinstall /dbvol1/oradata/oint/offerts03.dbf
alter tablespace OFFERTS add datafile '/dbvol1/oradata/oint/offerts03.dbf' size 1025M;
数据文件添加成功



检查原因过程
1.cat /etc/sysconfig/rawdevices
...
/dev/raw/raw42 /dev/sdg5 --这这里发现了sdg5
...

2.于是我查一下由于被绑定的设备
[root@mirrorrac2 root]# raw -qa
...
/dev/raw/raw42: bound to major 8, minor 101 --原因找出来了，是由于原来就有文件/dbvol1/oradata/oint/appdata1m12.dbf使用了sdg5
/dev/raw/raw43: bound to major 8, minor 101 --我们看到绑定的设备都是101
...

就此可以确认是由于数据文件被覆盖的原因。
当前数据库的状态是数据完全恢复正常，但是两个数据文件公用同一个设备，当前设备的数据是raw42相关联的/dbvol1/oradata/oint/appdata1m12.dbf
而offerts的数据基本没用，过了一会offerts自动从online转换成recover状态，此时，数据库正常可以运行。

第2次恢复过程：
1.于是只能通过将offerts03.dbf从sdg5中分离出来。
利用sdi来保存offerts03.dbf
先在mirror2上建立fdisk /dev/sdi将所有的区建立起来

[root@mirrorrac1 root]# dmesg|grep sdi
Attached scsi disk sdi at scsi3, channel 0, id 0, lun 8
SCSI device sdi: 31457280 512-byte hdwr sectors (16106 MB)
sdi: unknown partition table
此时mirror1还是看不到sdi区
2.
[root@mirrorrac1 root]# blockdev --rereadpt /dev/sdi --同步mirror2的分区
[root@mirrorrac1 root]# dmesg|grep sdi
Attached scsi disk sdi at scsi3, channel 0, id 0, lun 8
SCSI device sdi: 31457280 512-byte hdwr sectors (16106 MB)
sdi: unknown partition table
SCSI device sdi: 31457280 512-byte hdwr sectors (16106 MB)
sdi: sdi1 < sdi5 sdi6 sdi7 sdi8 sdi9 sdi10 sdi11 sdi12 sdi13 sdi14 sdi15 >

--此时可以看到新的分区

3.
在两个节点同时运行绑定裸设备
[root@mirrorrac2 root]# raw /dev/raw/raw43 /dev/sdi5
/dev/raw/raw43: bound to major 8, minor 133
[root@mirrorrac1 root]# raw /dev/raw/raw43 /dev/sdi5
/dev/raw/raw43: bound to major 8, minor 133

4.检查raw绑定正确性，是否有重复绑定
[root@mirrorrac2 root]# raw -qa|awk '{print $7}'|wc -l
63
[root@mirrorrac2 root]# raw -qa|awk '{print $7}'| sort -u | wc -l
63

5.做备份
bash-2.05$ dd if=/dbvol1/oradata/oint/offerts03.dbf of=/mirror_backup/back_datafile/offerts03.dbf.0727 bs=10
49608k count=1
1+0 records in
1+0 records out

6.
SQL> alter database datafile '/dbvol1/oradata/oint/offerts03.dbf' offline;
Database altered.

7.
SQL> recover datafile '/dbvol1/oradata/oint/offerts03.dbf';
ORA-00283: recovery session canceled due to errors
ORA-01110: data file 38: '/dbvol1/oradata/oint/offerts03.dbf'
ORA-01122: database file 38 failed verification check
ORA-01110: data file 38: '/dbvol1/oradata/oint/offerts03.dbf'
ORA-01251: Unknown File Header Version read for file number 38
直接恢复不行

8.
alter database create datafile '/dbvol1/oradata/oint/offerts03.dbf'

9.
SQL> recover datafile '/dbvol1/oradata/oint/offerts03.dbf';
Media recovery complete.
SQL>
SQL>

10.
SQL> alter database datafile '/dbvol1/oradata/oint/offerts03.dbf' online;

Database altered.

11.检查文件状态
select name,status from v$datafile where file# in (37,38)
NAME STATUS
-------------------------------------- -------

/dbvol1/oradata/oint/appdata1m12.dbf ONLINE


/dbvol1/oradata/oint/offerts03.dbf ONLINE


12.检查OFFERTS03数据文件是否正常
SQL> select file#,name from v$datafile where name like '%offerts03.dbf%';
FILE# NAME
---------- --------------------------------------------------
38 /dbvol1/oradata/oint/offerts03.dbf

SQL> select * from dba_extents where file_id = 38;

no rows selected
--现在新增的数据文件没有对象

查看OFFERTS表空间的区大小
SQL> select NEXT_EXTENT/1024 from dba_tablespaces where TABLESPACE_NAME = 'OFFERTS';

NEXT_EXTENT/1024
----------------
32768

--由于OFFERTS有3个文件，那么要建立32M*3以上的表进行测试
SQL> select * from (select segment_name,bytes/1024/1024||'M' from user_segments order by bytes desc) where rownum < 10;

SEGMENT_NAME bytes/1024/1024||'M'
----------------------------------------- --------------------
......
COMPANY 188M
......

SQL> create table fanglf_test nologging tablespace offerts as select * from company;

Table created.

SQL> select segment_name from dba_extents where file_id = 38;

SEGMENT_NAME
--------------------------------------------------------------------------------
FANGLF_TEST
FANGLF_TEST
FANGLF_TEST
--表明该新增的数据文件是好的


13.检查appdata1m12.dbf数据文件是否正常
select file#,name from v$datafile where name like '%appdata1m12.dbf%';
FILE# NAME
---------- --------------------------------------------------
37 /dbvol1/oradata/oint/appdata1m12.dbf


SQL> select rowid from alibaba.COMPANY where DBMS_ROWID.rowid_relative_fno(rowid) = 37 and rownum < 10;

ROWID
------------------
AAACBSAAlAAAIgmAAC
AAACBSAAlAAAIiBAAB
AAACBSAAlAAAIihAAB
AAACBSAAlAAAIihAAC
AAACBSAAlAAAIihAAD
AAACBSAAlAAAIkEAAB
AAACBSAAlAAAIkEAAE
AAACBSAAlAAAIkEAAF
AAACBSAAlAAAIkXAAB

SQL> update alibaba.COMPANY
SET SITE = 'test'
where rowid = 'AAACBSAAlAAAIgmAAC';
2 3
1 row updated.

SQL> commit;

Commit complete.

SQL> update alibaba.COMPANY
SET SITE = '???'
where rowid = 'AAACBSAAlAAAIgmAAC';
2 3
1 row updated. --说明appdata1m12.dbf也没有问题

SQL> commit;
Commit complete.

修改vi /etc/sysconfig/rawdevices（在两个节点）
增加/dev/raw/raw43 /dev/sdi5[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/257699/viewspace-815208/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/257699/viewspace-815208/