本帖最后由 yuanqk 于 2018-8-11 20:28 編輯

真實(shí)案例，記錄一下，都是小白，非常理解小白在遇到問題時(shí)的無奈，希望能幫助到一些人。過程非常簡單，主要是處理問題的思路。

1、早上收到告警，說備庫有15個(gè)歸檔沒有同步，我們的告警還是非常low的那種，只能告訴你有幾個(gè)歸檔沒同步，具體原因不知道。(這也是我后續(xù)需要調(diào)整的)

2、檢查具體原因，登錄主庫，查看dest狀態(tài)，確實(shí)是有問題，不能創(chuàng)建歸檔日志了。

SQL> select status,gap_status,error from v$archive_dest_status;

STATUS? ?? ?? ?? ?? ?? ?? ? GAP_STATUS? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?ERROR

--------------------------- ------------------------------------------------------------------------ ------------------------------------------

VALID

ERROR? ?? ?? ?? ?? ?? ?? ???RESOLVABLE GAP? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ???ORA-00270: error creating archive log

3、登錄備庫，檢查alert日志，看到db_recovery_file_dest_size使用率100%

Creating archive destination file : /opt/app/oracle/oradata/xxxxxx/o1_mf_1_2990_%u_.arc (1176113 blocks)

Sat Aug 11 13:02:50 2018

Errors in file /u01/app/oracle/diag/rdbms/xxxxxxxxxxx/trace/xxxxxx_rfs_20130.trc:

ORA-19815: WARNING: db_recovery_file_dest_size of 101295421440 bytes is 100.00% used, and has 0 remaining bytes available.

4、從現(xiàn)象上看問題很簡單，調(diào)整這個(gè)目錄大小就行了，調(diào)整之后看歸檔文件，缺少的也都同步過來了

ALTER SYSTEM SET db_recovery_file_dest_size='300G' SCOPE=BOTH;

5、看似很ok，啟動應(yīng)用進(jìn)程吧，結(jié)果啟動后又報(bào)了一個(gè)錯(cuò)

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE??DISCONNECT FROM SESSION;

ORA-01186: file 50 failed verification tests

ORA-01157: cannot identify/lock data file 50 - see DBWR trace file

ORA-01111: name for data file 50 is unknown - rename to correct file

ORA-01110: data file 50: '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00050'

File 50 not verified due to error ORA-01157

MRP0: Background Media Recovery terminated with error 1111

6、這個(gè)報(bào)錯(cuò)也很簡單，就是主備庫數(shù)據(jù)文件路徑不一致，而且在db_file_name_convert中也沒有設(shè)置，這時(shí)就檢查一下主庫的數(shù)據(jù)文件路徑，和備庫的db_file_name_convert參數(shù)

結(jié)果確實(shí)是缺少了一個(gè)映射關(guān)系。

7、處理上面的問題，先到主庫查看下file_id為50的數(shù)據(jù)文件信息，然后在備庫執(zhí)行下面的命令處理：

alter system set standby_file_management='MANUAL' SCOPE=MEMORY;

alter database create datafile '/u01/app/oracle/product/11.2.0/db_1/dbs/UNNAMED00050' as '備庫數(shù)據(jù)文件存放路徑/主庫查詢出來的數(shù)據(jù)文件名稱.dbf';

alter system set standby_file_management='AUTO' SCOPE=MEMORY;

8、在檢查主庫file_id為50的數(shù)據(jù)文件信息時(shí)，發(fā)現(xiàn)是8月3號創(chuàng)建的，那就是說8月3號這套dg就出問題了，當(dāng)時(shí)心里一萬個(gè)草擬馬在奔騰(哎，我也不是圣人，正在醫(yī)院掛號，突然回來替別人擦屁股)

檢查一下備庫日志應(yīng)用情況，確定在2907的歸檔斷了，再檢查下歸檔目錄，發(fā)現(xiàn)歸檔還全部都在。。。

2904 03-AUG-18? ?? ? 03-AUG-18? ?? ? YES

2905 03-AUG-18? ?? ? 03-AUG-18? ?? ? YES

2906 03-AUG-18? ?? ? 03-AUG-18? ?? ? YES

2907 03-AUG-18? ?? ? 03-AUG-18? ?? ? NO

2908 03-AUG-18? ?? ? 03-AUG-18? ?? ? NO

2909 03-AUG-18? ?? ? 03-AUG-18? ?? ? NO

9、確認(rèn)問題都解決后啟動恢復(fù)進(jìn)程，慢慢恢復(fù)吧，反正又每人急著用，結(jié)果又報(bào)錯(cuò)了

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE??DISCONNECT FROM SESSION;

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE??DISCONNECT FROM SESSION

*

ERROR at line 1:

ORA-01153: an incompatible media recovery is active

10、這個(gè)錯(cuò)誤第一次遇到，查了官方文檔也沒明白。嘗試關(guān)閉應(yīng)用進(jìn)程，再啟用還是一樣報(bào)錯(cuò)

SQL> alter database recover managed standby database cancel;

alter database recover managed standby database cancel

*

ERROR at line 1:

ORA-16136: Managed Standby Recovery not active

11、不知道怎么回事，嘗試recover automatic standby database竟然成功了(這樣一個(gè)一個(gè)歸檔去追很慢，可以考慮使用增量恢復(fù))

alter database recover automatic standby database;

12、恢復(fù)完成后，啟動應(yīng)用進(jìn)程

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE??DISCONNECT FROM SESSION;

13、最后別忘了修改db_file_name_convert和log_file_name_convert參數(shù)，這2個(gè)參數(shù)需要重啟數(shù)據(jù)庫。

總結(jié)

以上是生活随笔為你收集整理的oracle数据同步异常,案例：DataGuard同步异常问题处理记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。