20201206-记录一次惊心动魄的误操作(Oracle)

事件回顾：

某月周五晚上，马上下班了，突然手机连续收到多条告警短信，提示我管理的其中一套数据库的DG备库无法连接。
突然想到昨天晚上对DG备库扩容了+DATA磁盘组，本来预计添加30块100G大小的新盘，扩容3000G空间，但是由于粗心大意，错误的多添加了5块旧盘，一共添加了35块盘。
添加完成后检查磁盘容量发现多了5块盘，数据已经在动态平衡了，第一时间想到这5块旧盘有没有问题，查看ASM日志，DB日志没有发现错误，第二天早上检查数据已经动态平衡结束了，DB日志没发现问题。
第一时间连接DG备库，查看数据库实例状态为mount状态，查看DB日志，显示ASM磁盘头损坏，多个数据文件出现大量坏块，+DATA磁盘组自动umount，无法挂载。

环境说明：

OS:AIX 7.1
DB:Oracle 11204 RAC + DG(RAC)

事件原因：

发现昨晚多扩容的5块磁盘，居然是归档所使用的/arch 文件系统盘，DG备库的归档并没有存储在ASM存储中，而是使用的本地文件系统，最终导致归档数据和+DATA磁盘组数据重复写入，数据大面积损坏，数据库宕机。
之前错误的认为已经在使用的磁盘，不会在v$asm_disk中header_status字段显示CANDIDATE，所以之前即使发现了扩容+DATA多加了5块旧盘，也没有想到会是文件系统已经在使用的磁盘，单纯的认为是5块旧的新盘。
由于主库生成归档的频率较低，同时+DATA磁盘组有很多磁盘，所以DG备库坚持了20多小时才宕机。

解决方案：

由于多个数据文件出现大量坏块，ASM磁盘头损坏，针对单个文件进行恢复难度较大，时间较长，所以采取的办法是重建DG备库。
重建DG备库的过程如下：

一：调整主库log_archive_dest_state_2参数，由enable改成defer 。

alter system set log_archive_dest_state_2=defer;

二：将备库/arch 文件系统对应的5块归档盘改成+ASM磁盘组

2.1 清空/arch对应的vg,lv,文件系统信息
2.2 创建新的+ARCH磁盘组，添加这5块磁盘

三：重建备库+DATA磁盘组数据

删除+DATA磁盘组，新建+DATA磁盘组，添加磁盘。
注意：删除磁盘组之前，先将参数文件拷贝出来，便于DG备库的搭建。

create pfile='/tmp/xxxpfile.ora' from spfile;

四：修改备库pfile参数文件，修改备库归档位置

将归档位置由/arch改成+ARCH

五：启动备库为mount状态，恢复DG同步关系

此时备库+ARCH磁盘组可以正常接收主库传来的归档文件。

六：禁用备库删除归档计划

为了避免在备库恢复期间归档完整，先禁用备库删除归档计划

七：恢复主库最新的控制文件，传到备库端，备库重新启动到mount状态

八：主库进行全备

主库全备大小2T，备份时间约2小时。

九：恢复DG备库

备库通过备份软件进行rman全库恢复。
restore和recover指定到全备份完成前最后一个SCN号。
主备库物理位置距离约50KM，恢复了2T多数据，耗时6个多小时。

十：全库恢复完成后，恢复主库最新的控制文件，传到备库端，备库重新启动到mount状态

十一：备库启动mrp进程，应用最新的日志

十二：备库取消mrp，启动open状态，再次启动mrp进程

十三：检查redo log file和standby log file大小和状态

十四：修改备库spfile位置

之前spfile在另一个小磁盘组里，为了方便管理，将spfile迁移到了另一个磁盘组内
14.1 修改pfile中记录的spfile位置
14.2 修改OCR中记录的spfile位置

srvctl config database -d cjcdb
srvctl modify database -d cjcdb -p '+DATA/cjcdb/spfile/spfilecjcdb.ora'

十五：注册新磁盘组位置+ARCH

srvctl注册新归档磁盘组位置

srvctl config database -d cjcdb
srvctl modify database -db cjcdb -diskgroup "DATA,ARCH,OTHER"

十六：清理旧磁盘组信息

旧的磁盘组已经删除了，清空信息

$ srvctl disable diskgroup -diskgroup dgroup1 -node "mynode1,mynode2"
$ srvctl remove diskgroup -diskgroup diskgroup_name -force

十七：crsctl查看实例状态不对，手动刷新实例状态

shutdown immediate
startup
srvctl stop database -d dbname -o immediate
srvctl start instance -d dbname -i instance_name1 -o open
srvctl start database -d dbname -o open

十八：启用修改并测试自动删除归档计划

18.1 自动删除脚本里归档目录由/arch改成了+ARCH

十九：resize tempfile (20M 到 30G)

备库创建完成后,tempfile文件大小只有20M，修改为和主库保持一致

select * from dba_temp_files;
alter database tempfile '' resize 30G;

二十:启动备库监控

备库出问题后，定位到原因后，解决问题的同时，临时将备库监控取消了，待备库完成恢复后，在启动对备库的监控。

反思：

虽然此次误操作发生在DG备库，没有对生产系统造成任何影响，但由于主库是一套非常核心的数据库，如果此次事件发生在主库而不是备库，后果会非常严重。
出现此次事故根本原因是对备库操作不够重视，从而导致关键性操作粗心大意。
根据墨菲定律，凡事如果有出错的可能，在将来的某一天一定会出错。
所以要做出改变，改变心态，改变安全意识，改操作规范等。