Oracle 11G DataGuard ORA-16086問題修復詳細過程
1，問題描述，standby從庫沒有應用redo日誌
Tue Jul 22 09:05:07 2014
RFS[8852]: Assigned to RFS process 12956
RFS[8852]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 09:05:09 2014
RFS[8853]: Assigned to RFS process 12958
RFS[8853]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8853]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_12958.trc:
ORA-16086: Redo data cannot be written to the standby redo log
Tue Jul 22 09:11:07 2014
RFS[8854]: Assigned to RFS process 12976
RFS[8854]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 09:11:07 2014
RFS[8855]: Assigned to RFS process 12978
RFS[8855]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8855]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_12978.trc:
ORA-16086: Redo data cannot be written to the standby redo log
2，在從庫檢視redo日誌資訊
SQL> show parameter log_file_name_convert;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_file_name_convert string /home/oradata/powerdes, /home/
oradata/powerdes
SQL>
SQL>
SQL> select group#,member from v$logfile;
GROUP#
----------
MEMBER
--------------------------------------------------------------------------------
3
/home/oradata/powerdes/redo03.log
2
/home/oradata/powerdes/redo02.log
1
/home/oradata/powerdes/redo01.log
SQL> select GROUP#,FIRST_CHANGE#,SEQUENCE#,STATUS from v$log;
GROUP# FIRST_CHANGE# SEQUENCE# STATUS
---------- ------------- ---------- ----------------
1 1.0533E+10 23999 CLEARING_CURRENT
2 1.0533E+10 23997 CLEARING
3 1.0533E+10 23998 CLEARING
SQL>
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 CLEARING
2 50 1 CLEARING_CURRENT
3 50 1 CLEARING
SQL>
先暫停redo log日誌：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
執行更新日誌操作：
alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
SQL> alter database clear logfile group 1;
alter database clear logfile group 1
*
ERROR at line 1:
ORA-01156: recovery or flashback in progress may need access to files
報錯是因為MFS程式鎖定日誌了，所以需要先停應用再更新日誌操作
alter database recover managed standby database cancel;
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database clear logfile group 2;
Database altered.
SQL> alter database clear logfile group 3;
Database altered.
SQL>
然後再執行redo應用
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
檢視redo應用情況
SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
都是NO
3，重建redo log
再檢視下看一下現在的redo log狀態
select group#,bytes/1024/1024,members,status from v$log;
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 UNUSED
2 50 1 CLEARING
3 50 1 CLEARING_CURRENT
redo log損壞，但是clear不管用，因為是備庫 read-only不讓切換日誌
重建redo日誌檔案，先停redo應用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
alter database add logfile group 4 ('/home/oradata/powerdes/redo04.log') size 50M;
alter database add logfile group 5 ('/home/oradata/powerdes/redo05.log') size 50M;
alter database add logfile group 6 ('/home/oradata/powerdes/redo06.log') size 50M;
日誌管理是自動的，所以不能操作，要先設定成手動管理的
SQL> alter system set standby_file_management='manual';
System altered.
SQL> alter database add logfile group 4 ('/home/oradata/powerdes/redo04.log') size 50M;
Database altered.
SQL> alter database add logfile group 5 ('/home/oradata/powerdes/redo05.log') size 50M;
Database altered.
SQL> alter database add logfile group 6 ('/home/oradata/powerdes/redo06.log') size 50M;
Database altered.
SQL>
檢視一下日誌狀態
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 CLEARING_CURRENT
2 50 1 CLEARING
3 50 1 CLEARING
4 50 1 UNUSED
5 50 1 UNUSED
6 50 1 UNUSED
6 rows selected.
清空redo日誌組
SQL>
alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
SQL>
alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
Database altered.
SQL>
Database altered.
SQL>
Database altered.
SQL>
檢視redo 日誌組資訊
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 CURRENT
2 50 1 UNUSED
3 50 1 UNUSED
4 50 1 UNUSED
5 50 1 UNUSED
6 50 1 UNUSED
6 rows selected.
alter database drop logfile group 1;
alter database drop logfile group 2;
alter database drop logfile group 3;
SQL>
alter database drop logfile group 1;
alter database drop logfile group 2;
alter database drop logfile group 3;
Database altered.
SQL>
Database altered.
SQL> alter database drop logfile group 3
*
ERROR at line 1:
ORA-01623: log 3 is current log for instance powerdes (thread 1) - cannot drop
ORA-00312: online log 3 thread 1: '/home/oradata/powerdes/redo03.log'
SQL>
4，檢查歸檔檔案是否完整
從庫redo log損壞了的話，只要從庫的歸檔日誌在，還是可以修復的，不用重新做Standy。
從庫上執行check：
SQL> SELECT DISTINCT THREAD#,max(SEQUENCE#) OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;
THREAD# A
---------- ----------
1 23826
SQL>
主庫上執行check：
SQL> SELECT DISTINCT THREAD#,max(SEQUENCE#) OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;
THREAD# A
---------- ----------
1 24022
SQL>
取出primary和standy庫上各執行緒已經歸檔檔案最大序列號，看到兩者不相同，必須將多出的序列號對應的歸檔檔案複製到standy庫。
也就是說主庫從庫的歸檔日誌相差蠻大的。
如何檢視歸檔路徑，最高可用模式的時候 dg會盡力的讓日誌應用到standby
去查一下
SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
從庫：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
no rows selected
SQL>
主庫：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
no rows selected
SQL>
表名從庫的standby log都空的，需要重建standby log。
5，確定歸檔日誌有沒有寫到從庫：
所以用的lgwr程式，用lgwr程式進行傳輸日誌，而其他模式用arch傳輸日誌是等到日誌寫到歸檔的過程中傳輸過去，最近你沒有改過從庫的保護模式吧。
主庫上檢視下redo log的大小：
select GROUP#,BYTES/1024/1024,STATUS from v$log;
SQL> select GROUP#,BYTES/1024/1024,STATUS from v$log;
GROUP# BYTES/1024/1024 STATUS
---------- --------------- ----------------
1 50 CURRENT
2 50 INACTIVE
3 50 ACTIVE
SQL>
確定日誌有沒有寫到從庫：
執行： select name,sequence#,applied from v$archived_log;
NAME
--------------------------------------------------------------------------------
SEQUENCE# APPLIED
---------- ---------
/oracle/app/oracle/flash_recovery_area/archivelog/1_24161_821708334.dbf
24161 NO
/oracle/app/oracle/flash_recovery_area/archivelog/1_24162_821708334.dbf
24162 NO
從庫上歸檔日誌：
NAME
--------------------------------------------------------------------------------
SEQUENCE# APPLIED
---------- ---------
/data/oracle/oradgdata/standby_archive/1_24072_821708334.dbf
24072 NO
2800 rows selected.
看到這裡，從庫上，最後一個日誌是24072，比主庫上的24162要低很多，
再去查下主庫的歸檔日誌路徑：
select name from v$archived_log;找到歸檔日誌路徑/oracle/app/oracle/flash_recovery_area/archivelog/
ll /oracle/app/oracle/flash_recovery_area/archivelog/看到最後一個歸檔日誌是：
-rw-r----- 1 oracle oinstall 2808832 Jul 22 09:24 1_24162_821708334.dbf
-rw-r----- 1 oracle oinstall 3072512 Jul 22 09:30 1_24163_821708334.dbf
再去主庫的歸檔日誌路徑上面check下，是否有從庫最後一個歸檔日誌24072
[oracle@localhost ~]$ ll /oracle/app/oracle/flash_recovery_area/archivelog/*24072*.dbf
-rw-r----- 1 oracle oinstall 1992704 Jul 22 01:00 /oracle/app/oracle/flash_recovery_area/archivelog/1_24072_821708334.dbf
[oracle@localhost ~]$
檢查下主庫從庫的歸檔管理模式
從庫：
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
SQL>
主庫：
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
看到從庫跟主庫不一致，需要手動將從庫上面的MANUAL修改成AUTO。
alter system set standby_file_management='AUTO';
SQL> alter system set standby_file_management='AUTO';
System altered.
SQL>
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
去主庫上檢視一下歸檔日誌的狀態
SQL> show parameter log_archive_dest_state_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string ENABLE
log_archive_dest_state_20 string enable
log_archive_dest_state_21 string enable
log_archive_dest_state_22 string enable
log_archive_dest_state_23 string enable
log_archive_dest_state_24 string enable
log_archive_dest_state_25 string enable
log_archive_dest_state_26 string enable
log_archive_dest_state_27 string enable
log_archive_dest_state_28 string enable
log_archive_dest_state_29 string enable
SQL>
6，檢查alert資訊
因為主庫1點有oracle歸檔日誌，所以去主庫從庫看下alert日誌資訊：
主庫資訊：
ll /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/alert_powerdes.log
Tue Jul 22 01:00:02 2014
ALTER SYSTEM ARCHIVE LOG
Tue Jul 22 01:00:02 2014
Thread 1 advanced to log sequence 24073 (LGWR switch)
Current log# 1 seq# 24073 mem# 0: /home/oradata/powerdes/redo01.log
Archived Log entry 46639 added for thread 1 sequence 24072 ID 0xca2ab4eb dest 1:
Tue Jul 22 01:00:17 2014
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/powerdes_lgwr_15950.trc:
ORA-16086: Redo data cannot be written to the standby redo log
LGWR: Failed to archive log 2 thread 1 sequence 24074 (16086)
Thread 1 advanced to log sequence 24074 (LGWR switch)
Current log# 2 seq# 24074 mem# 0: /home/oradata/powerdes/redo02.log
Tue Jul 22 01:00:19 2014
Archived Log entry 46641 added for thread 1 sequence 24073 ID 0xca2ab4eb dest 1:
Tue Jul 22 01:02:28 2014
backup piece header validation failure for handle /data/oracle/backup/data/ctl_auto/c-3391761643-20140721-00
backup piece header validation failure for handle /data/oracle/backup/data/ctl_auto/c-3391761643-20140721-01
ll /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/alert_powerdes.log
從庫資訊：
Tue Jul 22 01:04:48 2014
RFS[8692]: Assigned to RFS process 10970
RFS[8692]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 01:04:49 2014
RFS[8693]: Assigned to RFS process 10972
RFS[8693]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8693]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_10972.trc:
ORA-16086: Redo data cannot be written to the standby redo log
Tue Jul 22 01:10:48 2014
RFS[8694]: Assigned to RFS process 10989
RFS[8694]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 01:10:51 2014
RFS[8695]: Assigned to RFS process 10992
RFS[8695]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
7，在從庫上操作，還原昨天的logfile組：
先停止redo應用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
然後設定成manual模式
alter system set standby_file_management='MANUAL';
重建redo日誌檔案
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 2 ('/home/oradata/powerdes/redo02.log') size 50M;
alter database drop logfile group 4;
alter database drop logfile group 5;
alter database drop logfile group 6;
SQL> alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M
*
ERROR at line 1:
ORA-01275: Operation ADD LOGFILE is not allowed if standby file management is
automatic.
SQL>
看到報錯，需要去從庫刪除已經存在的redo01和redo02日誌
[oracle@localhost dbs]$ mv /home/oradata/powerdes/redo01.log /home/oradata/powerdes/bak.redo01.log.20140722
[oracle@localhost dbs]$ mv /home/oradata/powerdes/redo02.log /home/oradata/powerdes/bak.redo02.log.20140722
然後再在從庫執行如下還原日誌操作，成功了
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 2 ('/home/oradata/powerdes/redo02.log') size 50M;
alter database drop logfile group 4;
alter database drop logfile group 5;
alter database drop logfile group 6;
去主庫從庫執行，不分先後順序：
alter database add standby logfile group 4 ('/home/oradata/powerdes/redo_dg_01.log') size 50m;
alter database add standby logfile group 5 ('/home/oradata/powerdes/redo_dg_02.log') size 50m;
alter database add standby logfile group 6 ('/home/oradata/powerdes/redo_dg_03.log') size 50m;
執行redo應用：
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
select name,sequence#,applied from v$archived_log;
還是No，沒有被應用成YES。
alter system set standby_file_management='AUTO';
SQL> alter system set standby_file_management='AUTO';
System altered.
SQL>
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
然後再在從庫上面執行redo應用
alter database recover managed standby database disconnect from session;
8，嘗試下關閉再重啟從庫
SHUTDOWN IMMEDIATE;
下面是alert資訊：
再啟動從庫
STARTUP MOUNT;
再應用redo應用
alter database recover managed standby database disconnect from session;
檢視是否有yes
select name,sequence#,applied from v$archived_log;
select sequence#,applied from v$archived_log;
還是NO，沒有被應用
最後執行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
在檢查select sequence#,applied from v$archived_log;還是No，日誌沒有被應用。
檢視歸檔日誌路徑：
select name from v$archived_log;
檢視主庫備份記錄策略：
RMAN> show retention policy;
RMAN configuration parameters for database with db_unique_name PDUNQ are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;
9，從庫上面執行恢復歸檔日誌，這個過程比較慢，耗時比較長
recover automatic standby database ;
SQL> recover automatic standby database ;
ORA-00279: change 10533608939 generated at 07/22/2014 14:00:38 needed for
thread 1
ORA-00289: suggestion :
/data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
ORA-00280: change 10533608939 for thread 1 is in sequence #24178
ORA-00278: log file
'/data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf' no longer needed
for this recovery
ORA-16145: archival for thread# 1 sequence# 24178 in progress
Specify log: {=suggested | filename | AUTO | CANCEL}
ORA-16145: archival for thread# 1 sequence# 24178 in progress
SQL>
如下是alert日誌資訊：
Media Recovery Log /data/oracle/oradgdata/standby_archive/1_24177_821708334.dbf
Tue Jul 22 14:16:58 2014
Media Recovery Log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Tue Jul 22 14:16:59 2014
MRP: Archival for thread 1 sequence 24178 in progress
Standby Managed Recovery operation not detected
Errors with log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_13910.trc:
ORA-16145: archival for thread# 1 sequence# 24178 in progress
Tue Jul 22 14:17:13 2014
ORA-279 signalled during: ALTER DATABASE RECOVER automatic standby database ...
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Tue Jul 22 14:17:13 2014
MRP: Archival for thread 1 sequence 24178 in progress
Standby Managed Recovery operation not detected
Errors with log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_13910.trc:
ORA-16145: archival for thread# 1 sequence# 24178 in progress
ORA-16145 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
ALTER DATABASE RECOVER CANCEL
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER CANCEL
然後啟動redo應用
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
去從庫上檢查日誌是否已經應用成YES
SQL> select sequence#,applied from v$archived_log;
SEQUENCE# APPLIED
---------- ---------
24172 YES
24170 YES
24169 YES
24173 YES
24176 YES
24177 YES
2800 rows selected.
再去主庫上切換下日誌，看下新的24178歸檔日誌是否傳輸過來，是否應用成YES：
alter system switch logfile;
SQL> alter system switch logfile;
System altered.
SQL>
去從庫上面執行檢查
SQL> select sequence#,applied from v$archived_log;
SEQUENCE# APPLIED
---------- ---------
24170 YES
24169 YES
24173 YES
24176 YES
24177 YES
24178 IN-MEMORY
2800 rows selected.
再繼續檢查check下，applied就變成YES了
SEQUENCE# APPLIED
---------- ---------
24170 YES
24169 YES
24173 YES
24176 YES
24177 YES
24178 YES
2800 rows selected.
停止redo應用
alter database recover managed standby database cancel;
再開啟open模式，將從庫開啟供大家查詢資料
alter database open read only;
再起動redo應用
alter database recover managed standby database disconnect from session;
10，總結2個操作：
一是重建了redo log，新增了3組standby log：
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 2 ('/home/oradata/powerdes/redo02.log') size 50M;
alter database drop logfile group 4;
alter database drop logfile group 5;
alter database drop logfile group 6;
alter database add standby logfile group 4 ('/home/oradata/powerdes/redo_dg_01.log') size 50m;
alter database add standby logfile group 5 ('/home/oradata/powerdes/redo_dg_02.log') size 50m;
alter database add standby logfile group 6 ('/home/oradata/powerdes/redo_dg_03.log') size 50m;
二是在從庫上恢復歸檔日誌：
RECOVER AUTOMATIC STANDBY DATABASE ;
Tue Jul 22 09:05:07 2014
RFS[8852]: Assigned to RFS process 12956
RFS[8852]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 09:05:09 2014
RFS[8853]: Assigned to RFS process 12958
RFS[8853]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8853]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_12958.trc:
ORA-16086: Redo data cannot be written to the standby redo log
Tue Jul 22 09:11:07 2014
RFS[8854]: Assigned to RFS process 12976
RFS[8854]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 09:11:07 2014
RFS[8855]: Assigned to RFS process 12978
RFS[8855]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8855]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_12978.trc:
ORA-16086: Redo data cannot be written to the standby redo log
2，在從庫檢視redo日誌資訊
SQL> show parameter log_file_name_convert;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_file_name_convert string /home/oradata/powerdes, /home/
oradata/powerdes
SQL>
SQL>
SQL> select group#,member from v$logfile;
GROUP#
----------
MEMBER
--------------------------------------------------------------------------------
3
/home/oradata/powerdes/redo03.log
2
/home/oradata/powerdes/redo02.log
1
/home/oradata/powerdes/redo01.log
SQL> select GROUP#,FIRST_CHANGE#,SEQUENCE#,STATUS from v$log;
GROUP# FIRST_CHANGE# SEQUENCE# STATUS
---------- ------------- ---------- ----------------
1 1.0533E+10 23999 CLEARING_CURRENT
2 1.0533E+10 23997 CLEARING
3 1.0533E+10 23998 CLEARING
SQL>
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 CLEARING
2 50 1 CLEARING_CURRENT
3 50 1 CLEARING
SQL>
先暫停redo log日誌：
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
執行更新日誌操作：
alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
SQL> alter database clear logfile group 1;
alter database clear logfile group 1
*
ERROR at line 1:
ORA-01156: recovery or flashback in progress may need access to files
報錯是因為MFS程式鎖定日誌了，所以需要先停應用再更新日誌操作
alter database recover managed standby database cancel;
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database clear logfile group 1;
Database altered.
SQL> alter database clear logfile group 2;
Database altered.
SQL> alter database clear logfile group 3;
Database altered.
SQL>
然後再執行redo應用
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
檢視redo應用情況
SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
都是NO
3，重建redo log
再檢視下看一下現在的redo log狀態
select group#,bytes/1024/1024,members,status from v$log;
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 UNUSED
2 50 1 CLEARING
3 50 1 CLEARING_CURRENT
redo log損壞，但是clear不管用，因為是備庫 read-only不讓切換日誌
重建redo日誌檔案，先停redo應用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
alter database add logfile group 4 ('/home/oradata/powerdes/redo04.log') size 50M;
alter database add logfile group 5 ('/home/oradata/powerdes/redo05.log') size 50M;
alter database add logfile group 6 ('/home/oradata/powerdes/redo06.log') size 50M;
日誌管理是自動的，所以不能操作，要先設定成手動管理的
SQL> alter system set standby_file_management='manual';
System altered.
SQL> alter database add logfile group 4 ('/home/oradata/powerdes/redo04.log') size 50M;
Database altered.
SQL> alter database add logfile group 5 ('/home/oradata/powerdes/redo05.log') size 50M;
Database altered.
SQL> alter database add logfile group 6 ('/home/oradata/powerdes/redo06.log') size 50M;
Database altered.
SQL>
檢視一下日誌狀態
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 CLEARING_CURRENT
2 50 1 CLEARING
3 50 1 CLEARING
4 50 1 UNUSED
5 50 1 UNUSED
6 50 1 UNUSED
6 rows selected.
清空redo日誌組
SQL>
alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
SQL>
alter database clear logfile group 1;
alter database clear logfile group 2;
alter database clear logfile group 3;
Database altered.
SQL>
Database altered.
SQL>
Database altered.
SQL>
檢視redo 日誌組資訊
SQL> select group#,bytes/1024/1024,members,status from v$log;
GROUP# BYTES/1024/1024 MEMBERS STATUS
---------- --------------- ---------- ----------------
1 50 1 CURRENT
2 50 1 UNUSED
3 50 1 UNUSED
4 50 1 UNUSED
5 50 1 UNUSED
6 50 1 UNUSED
6 rows selected.
alter database drop logfile group 1;
alter database drop logfile group 2;
alter database drop logfile group 3;
SQL>
alter database drop logfile group 1;
alter database drop logfile group 2;
alter database drop logfile group 3;
Database altered.
SQL>
Database altered.
SQL> alter database drop logfile group 3
*
ERROR at line 1:
ORA-01623: log 3 is current log for instance powerdes (thread 1) - cannot drop
ORA-00312: online log 3 thread 1: '/home/oradata/powerdes/redo03.log'
SQL>
4，檢查歸檔檔案是否完整
從庫redo log損壞了的話，只要從庫的歸檔日誌在，還是可以修復的，不用重新做Standy。
從庫上執行check：
SQL> SELECT DISTINCT THREAD#,max(SEQUENCE#) OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;
THREAD# A
---------- ----------
1 23826
SQL>
主庫上執行check：
SQL> SELECT DISTINCT THREAD#,max(SEQUENCE#) OVER(PARTITION BY THREAD#) A FROM V$ARCHIVED_LOG;
THREAD# A
---------- ----------
1 24022
SQL>
取出primary和standy庫上各執行緒已經歸檔檔案最大序列號，看到兩者不相同，必須將多出的序列號對應的歸檔檔案複製到standy庫。
也就是說主庫從庫的歸檔日誌相差蠻大的。
如何檢視歸檔路徑，最高可用模式的時候 dg會盡力的讓日誌應用到standby
去查一下
SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
從庫：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
no rows selected
SQL>
主庫：
SQL> SELECT GROUP#,THREAD#,SEQUENCE#,ARCHIVED,STATUS FROM V$STANDBY_LOG;
no rows selected
SQL>
表名從庫的standby log都空的，需要重建standby log。
5，確定歸檔日誌有沒有寫到從庫：
所以用的lgwr程式，用lgwr程式進行傳輸日誌，而其他模式用arch傳輸日誌是等到日誌寫到歸檔的過程中傳輸過去，最近你沒有改過從庫的保護模式吧。
主庫上檢視下redo log的大小：
select GROUP#,BYTES/1024/1024,STATUS from v$log;
SQL> select GROUP#,BYTES/1024/1024,STATUS from v$log;
GROUP# BYTES/1024/1024 STATUS
---------- --------------- ----------------
1 50 CURRENT
2 50 INACTIVE
3 50 ACTIVE
SQL>
確定日誌有沒有寫到從庫：
執行： select name,sequence#,applied from v$archived_log;
NAME
--------------------------------------------------------------------------------
SEQUENCE# APPLIED
---------- ---------
/oracle/app/oracle/flash_recovery_area/archivelog/1_24161_821708334.dbf
24161 NO
/oracle/app/oracle/flash_recovery_area/archivelog/1_24162_821708334.dbf
24162 NO
從庫上歸檔日誌：
NAME
--------------------------------------------------------------------------------
SEQUENCE# APPLIED
---------- ---------
/data/oracle/oradgdata/standby_archive/1_24072_821708334.dbf
24072 NO
2800 rows selected.
看到這裡，從庫上，最後一個日誌是24072，比主庫上的24162要低很多，
再去查下主庫的歸檔日誌路徑：
select name from v$archived_log;找到歸檔日誌路徑/oracle/app/oracle/flash_recovery_area/archivelog/
ll /oracle/app/oracle/flash_recovery_area/archivelog/看到最後一個歸檔日誌是：
-rw-r----- 1 oracle oinstall 2808832 Jul 22 09:24 1_24162_821708334.dbf
-rw-r----- 1 oracle oinstall 3072512 Jul 22 09:30 1_24163_821708334.dbf
再去主庫的歸檔日誌路徑上面check下，是否有從庫最後一個歸檔日誌24072
[oracle@localhost ~]$ ll /oracle/app/oracle/flash_recovery_area/archivelog/*24072*.dbf
-rw-r----- 1 oracle oinstall 1992704 Jul 22 01:00 /oracle/app/oracle/flash_recovery_area/archivelog/1_24072_821708334.dbf
[oracle@localhost ~]$
檢查下主庫從庫的歸檔管理模式
從庫：
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
SQL>
主庫：
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
看到從庫跟主庫不一致，需要手動將從庫上面的MANUAL修改成AUTO。
alter system set standby_file_management='AUTO';
SQL> alter system set standby_file_management='AUTO';
System altered.
SQL>
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
去主庫上檢視一下歸檔日誌的狀態
SQL> show parameter log_archive_dest_state_2;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_dest_state_2 string ENABLE
log_archive_dest_state_20 string enable
log_archive_dest_state_21 string enable
log_archive_dest_state_22 string enable
log_archive_dest_state_23 string enable
log_archive_dest_state_24 string enable
log_archive_dest_state_25 string enable
log_archive_dest_state_26 string enable
log_archive_dest_state_27 string enable
log_archive_dest_state_28 string enable
log_archive_dest_state_29 string enable
SQL>
6，檢查alert資訊
因為主庫1點有oracle歸檔日誌，所以去主庫從庫看下alert日誌資訊：
主庫資訊：
ll /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/alert_powerdes.log
Tue Jul 22 01:00:02 2014
ALTER SYSTEM ARCHIVE LOG
Tue Jul 22 01:00:02 2014
Thread 1 advanced to log sequence 24073 (LGWR switch)
Current log# 1 seq# 24073 mem# 0: /home/oradata/powerdes/redo01.log
Archived Log entry 46639 added for thread 1 sequence 24072 ID 0xca2ab4eb dest 1:
Tue Jul 22 01:00:17 2014
Errors in file /oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/powerdes_lgwr_15950.trc:
ORA-16086: Redo data cannot be written to the standby redo log
LGWR: Failed to archive log 2 thread 1 sequence 24074 (16086)
Thread 1 advanced to log sequence 24074 (LGWR switch)
Current log# 2 seq# 24074 mem# 0: /home/oradata/powerdes/redo02.log
Tue Jul 22 01:00:19 2014
Archived Log entry 46641 added for thread 1 sequence 24073 ID 0xca2ab4eb dest 1:
Tue Jul 22 01:02:28 2014
backup piece header validation failure for handle /data/oracle/backup/data/ctl_auto/c-3391761643-20140721-00
backup piece header validation failure for handle /data/oracle/backup/data/ctl_auto/c-3391761643-20140721-01
ll /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/alert_powerdes.log
從庫資訊：
Tue Jul 22 01:04:48 2014
RFS[8692]: Assigned to RFS process 10970
RFS[8692]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 01:04:49 2014
RFS[8693]: Assigned to RFS process 10972
RFS[8693]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
Primary database is in MAXIMUM AVAILABILITY mode
Standby controlfile consistent with primary
Standby controlfile consistent with primary
RFS[8693]: No standby redo logfiles selected (reason:7)
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_rfs_10972.trc:
ORA-16086: Redo data cannot be written to the standby redo log
Tue Jul 22 01:10:48 2014
RFS[8694]: Assigned to RFS process 10989
RFS[8694]: Identified database type as 'physical standby': Client is ARCH pid 16028
Tue Jul 22 01:10:51 2014
RFS[8695]: Assigned to RFS process 10992
RFS[8695]: Identified database type as 'physical standby': Client is LGWR SYNC pid 15950
7，在從庫上操作，還原昨天的logfile組：
先停止redo應用
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
然後設定成manual模式
alter system set standby_file_management='MANUAL';
重建redo日誌檔案
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 2 ('/home/oradata/powerdes/redo02.log') size 50M;
alter database drop logfile group 4;
alter database drop logfile group 5;
alter database drop logfile group 6;
SQL> alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M
*
ERROR at line 1:
ORA-01275: Operation ADD LOGFILE is not allowed if standby file management is
automatic.
SQL>
看到報錯，需要去從庫刪除已經存在的redo01和redo02日誌
[oracle@localhost dbs]$ mv /home/oradata/powerdes/redo01.log /home/oradata/powerdes/bak.redo01.log.20140722
[oracle@localhost dbs]$ mv /home/oradata/powerdes/redo02.log /home/oradata/powerdes/bak.redo02.log.20140722
然後再在從庫執行如下還原日誌操作，成功了
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 2 ('/home/oradata/powerdes/redo02.log') size 50M;
alter database drop logfile group 4;
alter database drop logfile group 5;
alter database drop logfile group 6;
去主庫從庫執行，不分先後順序：
alter database add standby logfile group 4 ('/home/oradata/powerdes/redo_dg_01.log') size 50m;
alter database add standby logfile group 5 ('/home/oradata/powerdes/redo_dg_02.log') size 50m;
alter database add standby logfile group 6 ('/home/oradata/powerdes/redo_dg_03.log') size 50m;
執行redo應用：
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL>
select name,sequence#,applied from v$archived_log;
還是No，沒有被應用成YES。
alter system set standby_file_management='AUTO';
SQL> alter system set standby_file_management='AUTO';
System altered.
SQL>
SQL> show parameter standby_file_management;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
SQL>
然後再在從庫上面執行redo應用
alter database recover managed standby database disconnect from session;
8，嘗試下關閉再重啟從庫
SHUTDOWN IMMEDIATE;
下面是alert資訊：
-
Tue Jul 22 11:04:42 2014
-
MRP0: Background Media Recovery cancelled with status 16037
-
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_13338.trc:
-
ORA-16037: user requested cancel of managed recovery operation
-
Recovery
-
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_13338.trc:
-
ORA-16037: user requested cancel of managed recovery operation
-
Waiting for MRP0 pid 13335 to terminate
-
Tue Jul 22 11:04:44 2014
-
MRP0: Background Media Recovery process shutdown (powerdes)
-
License high water mark = 40
-
ALTER DATABASE CLOSE NORMAL
-
Tue Jul 22 11:04:45 2014
-
SMON: disabling cache recovery
-
Completed: ALTER DATABASE CLOSE NORMAL
-
ALTER DATABASE DISMOUNT
-
Completed: ALTER DATABASE DISMOUNT
-
ARCH: Archival disabled due to shutdown: 1089
-
Shutting down archive processes
-
Archiving is disabled
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting down
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting down
-
Tue Jul 22 11:04:46 2014
-
ARCj: Archival stoppedTue Jul 22 11:04:46 2014
-
ARCH shutting downTue Jul 22 11:04:46 2014
-
-
-
ARCH shutting down
-
-
-
ARCH shutting down
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting downARCi: Archival stopped
-
-
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting down
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting down
-
ARCf: Archival stopped
-
ARCg: Archival stoppedARCh: Archival stopped
-
Tue Jul 22 11:04:46 2014
-
-
-
ARCH shutting downARCe: Archival stopped
-
Tue Jul 22 11:04:46 2014
-
-
-
ARCH shutting downTue Jul 22 11:04:46 2014
-
ARCd: Archival stopped
-
ARCH shutting downTue Jul 22 11:04:46 2014
-
-
-
-
-
ARCc: Archival stoppedTue Jul 22 11:04:46 2014
-
ARCH shutting downARCH shutting down
-
Tue Jul 22 11:04:46 2014
-
-
-
Tue Jul 22 11:04:46 2014
-
-
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting downTue Jul 22 11:04:46 2014
-
ARCH shutting down
-
ARCH shutting downARCa: Archival stopped
-
-
-
ARC9: Archival stopped
-
ARCH shutting down
-
ARC7: Archival stopped
-
-
-
ARCb: Archival stopped
-
ARC6: Archival stoppedARC5: Archival stoppedTue Jul 22 11:04:46 2014
-
-
-
-
-
ARCH shutting downARC8: Archival stopped
-
-
-
ARC4: Archival stopped
-
ARC2: Archival stopped
-
ARC3: Archival stopped
-
Tue Jul 22 11:04:46 2014
-
ARCH shutting down
-
ARC1: Archival stoppedTue Jul 22 11:04:46 2014
-
-
-
ARCH shutting down
-
ARC0: Archival stopped
-
ARCH: Archival disabled due to shutdown: 1089
-
Shutting down archive processes
-
Archiving is disabled
-
Archive process shutdown avoided: 0 active
-
Tue Jul 22 11:04:48 2014
-
Stopping background process VKTM:
-
Tue Jul 22 11:04:50 2014
- Instance shutdown complete
STARTUP MOUNT;
再應用redo應用
alter database recover managed standby database disconnect from session;
檢視是否有yes
select name,sequence#,applied from v$archived_log;
select sequence#,applied from v$archived_log;
還是NO，沒有被應用
最後執行
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
在檢查select sequence#,applied from v$archived_log;還是No，日誌沒有被應用。
檢視歸檔日誌路徑：
select name from v$archived_log;
檢視主庫備份記錄策略：
RMAN> show retention policy;
RMAN configuration parameters for database with db_unique_name PDUNQ are:
CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 15 DAYS;
9，從庫上面執行恢復歸檔日誌，這個過程比較慢，耗時比較長
recover automatic standby database ;
SQL> recover automatic standby database ;
ORA-00279: change 10533608939 generated at 07/22/2014 14:00:38 needed for
thread 1
ORA-00289: suggestion :
/data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
ORA-00280: change 10533608939 for thread 1 is in sequence #24178
ORA-00278: log file
'/data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf' no longer needed
for this recovery
ORA-16145: archival for thread# 1 sequence# 24178 in progress
Specify log: {
ORA-16145: archival for thread# 1 sequence# 24178 in progress
SQL>
如下是alert日誌資訊：
Media Recovery Log /data/oracle/oradgdata/standby_archive/1_24177_821708334.dbf
Tue Jul 22 14:16:58 2014
Media Recovery Log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Tue Jul 22 14:16:59 2014
MRP: Archival for thread 1 sequence 24178 in progress
Standby Managed Recovery operation not detected
Errors with log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_13910.trc:
ORA-16145: archival for thread# 1 sequence# 24178 in progress
Tue Jul 22 14:17:13 2014
ORA-279 signalled during: ALTER DATABASE RECOVER automatic standby database ...
ALTER DATABASE RECOVER CONTINUE DEFAULT
Media Recovery Log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Tue Jul 22 14:17:13 2014
MRP: Archival for thread 1 sequence 24178 in progress
Standby Managed Recovery operation not detected
Errors with log /data/oracle/oradgdata/standby_archive/1_24178_821708334.dbf
Errors in file /oracle/app/oracle/diag/rdbms/pddgunq/powerdes/trace/powerdes_pr00_13910.trc:
ORA-16145: archival for thread# 1 sequence# 24178 in progress
ORA-16145 signalled during: ALTER DATABASE RECOVER CONTINUE DEFAULT ...
ALTER DATABASE RECOVER CANCEL
Media Recovery Canceled
Completed: ALTER DATABASE RECOVER CANCEL
然後啟動redo應用
alter database recover managed standby database disconnect from session;
SQL> alter database recover managed standby database disconnect from session;
Database altered.
去從庫上檢查日誌是否已經應用成YES
SQL> select sequence#,applied from v$archived_log;
SEQUENCE# APPLIED
---------- ---------
24172 YES
24170 YES
24169 YES
24173 YES
24176 YES
24177 YES
2800 rows selected.
再去主庫上切換下日誌，看下新的24178歸檔日誌是否傳輸過來，是否應用成YES：
alter system switch logfile;
SQL> alter system switch logfile;
System altered.
SQL>
去從庫上面執行檢查
SQL> select sequence#,applied from v$archived_log;
SEQUENCE# APPLIED
---------- ---------
24170 YES
24169 YES
24173 YES
24176 YES
24177 YES
24178 IN-MEMORY
2800 rows selected.
再繼續檢查check下，applied就變成YES了
SEQUENCE# APPLIED
---------- ---------
24170 YES
24169 YES
24173 YES
24176 YES
24177 YES
24178 YES
2800 rows selected.
停止redo應用
alter database recover managed standby database cancel;
再開啟open模式，將從庫開啟供大家查詢資料
alter database open read only;
再起動redo應用
alter database recover managed standby database disconnect from session;
10，總結2個操作：
一是重建了redo log，新增了3組standby log：
alter database add logfile group 1 ('/home/oradata/powerdes/redo01.log') size 50M;
alter database add logfile group 2 ('/home/oradata/powerdes/redo02.log') size 50M;
alter database drop logfile group 4;
alter database drop logfile group 5;
alter database drop logfile group 6;
alter database add standby logfile group 4 ('/home/oradata/powerdes/redo_dg_01.log') size 50m;
alter database add standby logfile group 5 ('/home/oradata/powerdes/redo_dg_02.log') size 50m;
alter database add standby logfile group 6 ('/home/oradata/powerdes/redo_dg_03.log') size 50m;
二是在從庫上恢復歸檔日誌：
RECOVER AUTOMATIC STANDBY DATABASE ;
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/26230597/viewspace-1224676/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- Oracle 11G DataGuard重啟詳細過程Oracle
- ORACLE 11G透過SCN做增量備份修復standby庫詳細過程Oracle
- ORACLE 11G通過SCN做增量備份修復standby庫詳細過程Oracle
- oracle 11G RAC 建立詳細過程Oracle
- 【DataGuard】同一臺主機部署Oracle 11g物理Active Data Guard詳細過程Oracle
- ORACLE 11G DataGuard Failover後如何修復standby庫OracleAI
- Linux Oracle 11g Dataguard配置詳細步驟LinuxOracle
- Jtti：如何修復Oracle資料庫執行過程的問題JttiOracle資料庫
- 【DATAGUARD】Oracle Dataguard nologging 塊修復Oracle
- Linux Glibc庫嚴重安全漏洞修復（詳細過程）Linux
- Oracle 11g在RHEL 6.4下的詳細安裝過程Oracle
- 【DATAGUARD 學習】學習DATAGUARD 過程中遇到的問題
- ORACLE 11G 搭建dataguard詳細步驟（所有操作總結）Oracle
- Oracle日常問題-壞塊修復Oracle
- 分散式 | DBLE docker 部署遇到的簡單問題修復過程分散式Docker
- Oracle->Mysql dblink 建立詳細過程OracleMySql
- 原創：oracle 授權的詳細過程Oracle
- Oracle後設資料物件Invalid修復過程Oracle物件
- oracle 的DML命令的詳細處理過程Oracle
- oracle 11.2.0.4 DataGuard Broker配置過程中可能遇到的問題及解決方法Oracle
- Oracle 11g Data Guard搭建過程中問題解決兩例Oracle
- ORACLE中採用rman備份異機恢復資料庫詳細過程Oracle資料庫
- 11g DataGuard通過ABMR自動修復主庫壞塊 - Automatic Block Media RepairBloCAI
- oracle 11g dataguardOracle
- 通過 rman duplicate 配置Oracle 11g Active DataguardOracle
- oracle 11g安裝過程中問題：找不到WFMLRSVCApp.earOracleAPP
- MySQL MHA詳細搭建過程MySql
- Windows Xp修復控制檯詳細用法(轉)Windows
- oracle10g 物理standby dataguard 建立過程Oracle
- ORACLE例項恢復過程詳細分析--使用dump、BBED等多種工具結合分析Oracle
- Oracle 11g存在密碼過期問題Oracle密碼
- Oracle之11g DataGuardOracle
- oracle 11G dataguard配置Oracle
- oracle 11g dataguard 建立Oracle
- Oracle 11g Active DataguardOracle
- 網站漏洞修復之圖片驗證碼的詳細修復方案網站
- oracle 11g result 整理詳細版Oracle
- Oracle分割槽資料問題的分析和修復Oracle