国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

DG不同步問題

IT那活兒 / 3365人閱讀
DG不同步問題

點擊上方“IT那活兒”，關注后了解更多內容，不管什么活兒，干就完了！！！


Dg主要進程介紹

RFS: 在備庫上啟用的進程，遠程文件服務器，接受重做日志（redo log 和 arch log）；
LNSn：本地網絡服務，復制傳送 redo 日志；
MRP: 管理恢復進程，如果是物理 DG ，用于對 redo log 做 recovery；
LSP: 邏輯備用進程，在邏輯 DG,將從 redo log 中抽取的 sql 進行應用。


主備磁盤大小不一致
主庫加表空間，導致備庫無法添加

1. 由于主備磁盤大小不一致的時候，當主庫磁盤還有空間，備庫磁盤沒有空間時，主庫加表空間，而參數db_file_name_convert轉換到備庫，備庫無法增加數據文件就會報錯，錯誤將如下圖所示：
這種情況是可避免的，所以建議給主庫添加表空間時，關注下備庫的磁盤使用情況，或者保證主備磁盤大小一致。
2. Mos給出的兩種情況解決辦法為：
1）when Data Guard setup is managed via sqlplus
Ensure Disk / file system space issue is addressed and then follow this on the standby
sql>alter system set standby_file_management=manual scope=both sid=*;
sql>alter database create datafile
/oracle/app/oracle/product/10.2.0.1/db_1/dbs/UNNAMED00038 as new;
Note:- It assumes that database files are using Oracle Managed File (OMF),
else keyword "new" has to be replaced by actual file name
sql>alter system set standby_file_management=auto scope=both sid=*;
sql>alter database recover managed standby database disconnect from session;
2）when Data Guard setup is managed via Data Guard Broker or OEM（當開啟OEM時）
Ensure Disk / file system space issue is addressed and then follow this on the standby
dgmgrl /
edit database standby db unique name here set property StandbyFileManagement=MANUAL;
exit
sql>alter database create datafile
/oracle/app/oracle/product/10.2.0.1/db_1/dbs/UNNAMED00038 as new;
Note:- It assumes that database files are using Oracle Managed File (OMF),
else keyword "new"has to be replaced by actual file name
dgmgrl /
edit database standby db unique name here set property StandbyFileManagement=AUTO;
edit database standby db unique name here set state=ONLINE;
exit
3. 示例（ASM單實例）
1）處理方法：對備庫的ASM磁盤進行擴容，與主庫追平。
2）解決方法實例2：Mos的解決。
sql>alter system set standby_file_management=manual scope=both sid=*;
sql>alter database create datafile
/oracle/app/oracle/product/10.2.0.1/db_1/dbs/UNNAMED00038 as new;
Note:- It assumes that database files are using Oracle Managed File (OMF),
else keyword "new" has to be replaced by actual file name
sql>alter system set standby_file_management=auto scope=both sid=*;
sql>alter database recover managed standby database disconnect from session;
檢查是否需要恢復文件：
SQL> select * from v$recover_file where error like %FILE%;

FILE# ONLINE ONLINE_ ERROR CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- ---------- -------------------
5 ONLINE ONLINE FILE MISSING 0
6 ONLINE ONLINE FILE MISSING 0
確認主庫數據文件：
SQL> select file#,name from v$datafile where file# in (5,6);

FILE# NAME
---------- ------------------------------------------------------------------
5 /oradata/lmis/LMIS01.dbf
6 /oradata/lmis/LMIS02.dbf
識別在（備庫）中創建的虛擬文件名：
SQL> select file#,name from v$datafile where file# in (5,6);

FILE# NAME
---------- ------------------------------------------------------------------
5 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005
6 /app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006
檢查沒有運行MRP，并且在待機狀態下創建文件后可以啟用：
STANDBY_FILE_MANAGEMENT

SQL> alter system set standby_file_management=manual scope=both;

System altered.

SQL> alter database create datafile/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00005 as /oradata/lmisdbdg/LMIS01.dbf;

Database altered.

SQL> alter database create datafile/app/oracle/product/11.2.4/db_1/dbs/UNNAMED00006 as /oradata/lmisdbdg/LMIS02.dbf;

Database altered.
檢查虛擬文件是否被修復：
SQL> select * from v$recover_file where error like %FILE%;

no rows selected
啟用STANDBY_FILE_MANAGEMENT為AUTO并啟動MRP：
SQL> show parameter standby_file_management

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string MANUAL
SQL> alter system set standby_file_management=AUTO scope=both;
System altered.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered.
創建文件后，MRP將開始在備用數據庫上應用存檔。
檢查主備庫歸檔應用情況：
set linesize 200
set pagesize 999
col status for a10
SELECT DEST_ID,
SEQUENCE#,
APPLIED
FROM v$archived_log
WHERE first_time>sysdate-35
ORDER BY SEQUENCE#,DEST_ID;
主庫實例歸檔日志信息：
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM 
V$ARCHIVED_LOG ORDER BY SEQUENCE#;
備庫實例歸檔日志信息：
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM 
V$ARCHIVED_LOG ORDER BY SEQUENCE#;



oracle關閉mrp進程卡死

案例：DG備庫報錯ORA-600[2619]致使mrp進程異常終止

告警日志發現有報錯ORA-600[2619]，并因此導致mrp進程異常終止，這是什么原因導致的呢，一般ORA-600都為oracle數據庫一些內部錯誤。
接下來分析下過程：
1. 由于之前有做過清理歸檔的動作，因為之前告警目錄空間滿；
2. 嘗試手工拉起mrp進程，發現不成功，嘗試應用日志時同樣是報錯ORA-600[2619]；
3. 通過MOS查詢匹配到：
ORA-600[2619] During Physical Standby Recovery [1138913.1]
ORA-600[2619] is raised due to an invalid next_change# detected in archive log.

In this case, it is caused by the archive log disk space ran out on standby site, causing that archive log not fully written on disk. This lead to ORA-600[2619] when the archive log was applied.
--Mos給出的處理方法：
1）. Clear the disk space where archive log stored on standby site
2）. Copy the problem archive log (eg: 4_77799_650412287.dbf) from the primary site and replace the one on the standby,
then restart Managed Recovery.
Archive log should be applied properly now.
4. 結合之前空間滿的事實，懷疑是否該歸檔文件也存在尚未完全寫入到磁盤的情況；
5. 主備庫比對這個歸檔日志的大小，發現大小是一致的；
6. 通過md5sum比對主備庫該歸檔日志，發現md5不一樣，這說明該歸檔文件還是存在差異；
7. 將備庫的這個歸檔文件mv重命名備份，然后將主庫的這個歸檔文件重新拷貝到備庫，重新比對數據文件確認一致；
8. 再次嘗試拉起mrp進程，發現不再報錯，解決問題。
總結：在這種情況下，是由于備用站點的歸檔日志磁盤空間用完了，導致歸檔日志沒有完全寫入磁盤。當應用歸檔日志時，這會導致 ORA-600[2619]。

DataGuard 歸檔無法同步

oracle 啟動mrp進程,DataGuard MRP進程crash：ORA-01111

DataGuard 歸檔無法同步的情況：
查看主庫LNS進程存在表示，主庫正常向備庫傳送歸檔日志。
但備庫的MRP進程不在，判斷是否存在歸檔的GAP：
SQL> SELECT THREAD#,LOW_SEQUENCE#,HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;

no rows selected
不存在GAP，手動啟動MRP進程，仍無法啟動查看告警日志，找到關鍵內容如下：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSIONAttempt to start background Managed Standby Recovery process (sss)

Thu Oct 09 11:38:58 2021

MRP0 started with pid=30, OS id=102010

MRP0: Background Managed Standby Recovery process started (sss)

started logmerger process

Thu Oct 09 11:39:03 2021

Managed Standby Recovery not using Real Time Apply

MRP0: Background Media Recovery terminated with error 1111

Errors in file /dba/oracle/diag/rdbms/sss/sss/trace/sss_pr00_102070.trc:

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

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

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

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

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

Slave exiting with ORA-1111 exception

Errors in file /dba/oracle/diag/rdbms/sss/sss/trace/sss_pr00_102070.trc:

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

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

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

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

ORA-01110: data file 12: /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012

Recovery Slave PR00 previously exited with exception 1111

MRP0: Background Media Recovery process shutdown (sss)
可以看到數據庫嘗試啟動MRP進程，但后臺進行介質恢復時，被錯誤1111碼終端(即ORA-01111)，ORA-01111提示數據文件12是未知的。
而后續的ORA-01110報錯顯示該數據文件的位置應該是$ORACLE_HOME/UNNAMED00012文件。
實際在該路徑下是查找不到該文件的：
find /u01/oracle/product/11.2.0.3.0/dbs/ -name UNNAMED00012
那么問題就來了，為什么數據庫需要找到該文件進行恢復？
DG的備庫是通過歸檔日志進行恢復的。
在歸檔獲取正確的情況下，會把主庫的對數據的更新內容都傳遞到備庫進行應用。也就是說上面報錯在于，主庫傳過來一條更新記錄，對于備庫是無法判斷的。
通過網上查找相關答案，發現原來當主庫異常宕機重啟之后，數據庫會進行自動恢復，也就是Instance Recovery，這部分缺失的數據被記錄再Redo之中，在異常關閉后，傳輸到備庫的歸檔中并不包含這部分內容，而主庫通過一個臨時的數據文件(UNNAMED命名方式)恢復后，這部分被恢復的記錄在后續的歸檔中被傳輸到備庫，當備庫恢復到這個歸檔時，備庫無法自動去創建這個UNNAMED臨時數據文件。
解決方法：
停止備庫歸檔應用(實際已停止，非必要)，同步歸檔將備庫歸檔自動管理該為手動，手工創建該數據文件，啟動歸檔應用進程，將歸檔管理由手動轉自動。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL SCOPE=MEMEORY;

SQL> ALTER DATABASE CREATE DATAFILE /u01/oracle/product/11.2.0.3.0/dbs/UNNAMED00012 as /u01/oradata/sss/sys07.dbf

SQL> ALTER SYSTEM SET standby_file_management=AUTO SCOPE=MEMORY;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION
到這里查看告警日志：
Attempt to start background Managed Standby Recovery process (sss)

Thu Oct 09 11:41:08 2021

MRP0 started with pid=30, OS id=102513

MRP0: Background Managed Standby Recovery process started (sss)

started logmerger process

Thu Oct 09 11:41:14 2021

Managed Standby Recovery not using Real Time Apply

Parallel Media Recovery started with 24 slaves

Waiting for all non-current ORLs to be archived...

All non-current ORLs have been archived.

Thu Oct 09 11:41:14 2021

Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION

Media Recovery Log /u01/sss/SSS/archivelog/2021_10_03/o1_mf_1_13523_b2wzmf1b_.arc

Thu Oct 09 11:41:36 2021
告警日志已經說明歸檔已經正常應用了，也可以查看一下V$MANAGED_STANDBY視圖,確認一下MRP進程是否啟用。


主備不同步

主備不同步，備庫歸檔丟失


由于某種原因，可能導致備庫的歸檔丟失，這需要我們手動來進行處理。
示例問題描述：
備庫的歸檔日志沒有增加，一直等待一個。
1. 查詢問題：
SQL> SELECT * FROM V$ARCHIVE_GAP;

THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1        6434       6435
SQL>select name ,sequence# from v$archived_log;
NAME SEQUENCE#
-------------------------------------------------------------------------- ------
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6414_1000748999.dbf 6414
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6417_1000748999.dbf 6417
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6420_1000748999.dbf 6420
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6421_1000748999.dbf 6421
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6419_1000748999.dbf 6419
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6418_1000748999.dbf 6418
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6425_1000748999.dbf 6425
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6426_1000748999.dbf 6426
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6423_1000748999.dbf 6423
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6422_1000748999.dbf 6422
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6424_1000748999.dbf 6424

NAME SEQUENCE#
-------------------------------------------------------------------------- ------
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6366_1000748999.dbf 6366
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6427_1000748999.dbf 6427
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6428_1000748999.dbf 6428
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6429_1000748999.dbf 6429
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6509_1000748999.dbf 6509
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6431_1000748999.dbf 6431
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6432_1000748999.dbf 6432
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6430_1000748999.dbf 6430
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6433_1000748999.dbf 6433
/u01/app/oracle/product/11.2.0/db_1/dbs/archivelog/1_6436_1000748999.dbf 6436
2. 解決問題：
需要查看主庫存不存在歸檔日志，分兩種情況討論：
1）如果存在的話拷貝到備庫然后手工注冊；
Scp到備庫后，備庫注冊alter database register logfile XXX；
2）如果不存在的話生成基于SCN的備份集。
查看備庫最小的scn號：
select to_char(current_scn) from v$database;
select min(checkpoint_change#) from v$datafile;
select min(checkpoint_change#) from v$datafile_header;
比對最小的scn，然后再備庫生成基于SCn的備份集：
backup as compressed backupset incremental from scn $MIN  
database format /backup/inc_%d_%T_%s_%p;
backup current controlfile for standby format /backup/inc.ctl;
然后scp 傳輸到備庫上，備庫恢復備份集：
shutdown abort;
startup nomount;
restore standby controlfile from "/backup/inc.ctl";
alter database mount;
catalog start with "/backup/" NOPROMPT;
shutdown immediate;
startup mount;
recover database;
重新開啟實時應用歸檔：
alter database recover managed standby database disconnect from session using current logfile;



文章總結

當dg出現主備不同步時，首先查看日志看由于什么問題導致的，之后看是由于主備斷了同步，mrp進程斷掉還是由于磁盤空間不夠導致的，主要的恢復方法為當主庫是否存在歸檔：
若主庫存在歸檔可直接拷過去注冊應用即可；
若主庫不存在歸檔，則需要基于scn號的增量恢復。


本文作者：李曉紅

本文來源：IT那活兒（上海新炬王翦團隊）

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/129653.html

相關文章

  • DG備庫讀寫測試方案

    DG備庫讀寫測試方案 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin:0...

    IT那活兒 評論0 收藏856

  • DBASK問答集萃（2）

    摘要：新晉技術專家下面是墨天輪部分新晉的技術專家。大家可以點擊往期閱讀墨天輪技術專家邀請函了解詳情，申請成為我們的技術專家，加入專家團隊，與我們一起創建一個開放互助的數據庫技術社區。新關聯公眾號墨天輪是一個開放互助的數據庫技術社區。 引言 近期我們在DBASK小程序增加了數據庫 MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的專題欄目和一些新的技術...

    liuchengxu 評論0 收藏0

發表評論

0條評論

IT那活兒

男|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<