standby实例丢失online log文件的处理

今天在公司处理一个case,通过从生产standby库主机向测试库所在主机复制磁盘的方式导库,主机磁盘复制ok后起库的过程都是自动化脚本的方式进行的,因为测试库与生产库sid不同,文件路径不同,这里的主要工作就是rename file,以及重建控制文件以测试库sid重命名数据库,并open  read wirte供用户使用。脚本跑完后我看了脚本输出日志,大概扫了下,发现了在rename  log file 的时候,有几个文件rename失败,并且一系列的初始化脚本运行失败,报错如下:

ERROR at line 1:
ORA-16000: database open for read-only access
ORA-06512: at "SYS.DBMS_REGISTRY_SYS", line 619

检查了下,确实数据库是read only打开的。问题一个个来,先处理rename失败的问题。发现磁盘复制过来后对应的日志group的文件不在了,并且目录整个消失。尝试了集中方法:drop logfile group提示无法确定文件状态,找不到文件;clear logfile group提示permission deny。既然没权限,那就好办,把权限问题解决了应该就ok,如下列出了部分缺失的logfile  group#以及member。

  9   /xxxx/t0pufda/log/fra/RPUFDA/onlinelog/o1_mf_9_c5x9j02v_.log

这里是主机上的目录结构   

xxxxxx:t0pufda > cd log

xxxxxx:t0pufda > pwd

/xxxxx/t0pufda/log

xxxxxx:t0pufda >ls

xxxxxx:t0pufda >

可以看到,缺失了从log以下的目录结构,于是乎,手动创建了目录,fra/RPUFDA/onlinelog,并且授权给dba用户。重新尝试clear仍然失败,无权限。看了下db_recovery_file_dest参数值,

SQL> show parameter db_recovery

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /xxxx/t0pufda/log
db_recovery_file_dest_size           big integer 150G
SQL> 

发现只到了log这一层,而log这个目录是root用户创建的,并且只有root自己有权限。到这里似乎明白了,尽管已经存在了fra目录,oracle仍然会在 db_recovery_file_dest参数指向的目录位置尝试创建自己的目录结构。所以接下来就好办了,修改 db_recovery_file_dest参数值,使之指向dba用户有权限操作的目录。修改后指向了/xxxx/t0pufda/log/fra目录,重新clear,正常无报错。可以看到,oracle在fra目录下创建了自己的目录结构  db_uniquename/onlinelog/logfilename.log

下面就是shutdown,nomount,alter database mount standby database,alter database activate standby database,alter database open。检查open_mode为read write。case处理完毕。

你可能感兴趣的:(oracle)