亚洲中字慕日产2020,大陆极品少妇内射AAAAAA,无码av大香线蕉伊人久久,久久精品国产亚洲av麻豆网站

資訊專(zhuān)欄INFORMATION COLUMN

DG不同步問(wèn)題

IT那活兒 / 3451人閱讀
DG不同步問(wèn)題

點(diǎn)擊上方“IT那活兒”，關(guān)注后了解更多內(nèi)容，不管什么活兒，干就完了！??！


Dg主要進(jìn)程介紹

RFS: 在備庫(kù)上啟用的進(jìn)程，遠(yuǎn)程文件服務(wù)器，接受重做日志（redo log 和 arch log）；
LNSn：本地網(wǎng)絡(luò)服務(wù)，復(fù)制傳送 redo 日志；
MRP: 管理恢復(fù)進(jìn)程，如果是物理 DG ，用于對(duì) redo log 做 recovery；
LSP: 邏輯備用進(jìn)程，在邏輯 DG,將從 redo log 中抽取的 sql 進(jìn)行應(yīng)用。


主備磁盤(pán)大小不一致
主庫(kù)加表空間，導(dǎo)致備庫(kù)無(wú)法添加

1. 由于主備磁盤(pán)大小不一致的時(shí)候，當(dāng)主庫(kù)磁盤(pán)還有空間，備庫(kù)磁盤(pán)沒(méi)有空間時(shí)，主庫(kù)加表空間，而參數(shù)db_file_name_convert轉(zhuǎn)換到備庫(kù)，備庫(kù)無(wú)法增加數(shù)據(jù)文件就會(huì)報(bào)錯(cuò)，錯(cuò)誤將如下圖所示：
這種情況是可避免的，所以建議給主庫(kù)添加表空間時(shí)，關(guān)注下備庫(kù)的磁盤(pán)使用情況，或者保證主備磁盤(pán)大小一致。
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（當(dāng)開(kāi)啟OEM時(shí)）
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單實(shí)例）
1）處理方法：對(duì)備庫(kù)的ASM磁盤(pán)進(jìn)行擴(kuò)容，與主庫(kù)追平。
2）解決方法實(shí)例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;
檢查是否需要恢復(fù)文件：
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
確認(rèn)主庫(kù)數(shù)據(jù)文件：
SQL> select file#,name from v$datafile where file# in (5,6);

FILE# NAME
---------- ------------------------------------------------------------------
5 /oradata/lmis/LMIS01.dbf
6 /oradata/lmis/LMIS02.dbf
識(shí)別在（備庫(kù)）中創(chuàng)建的虛擬文件名：
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
檢查沒(méi)有運(yùn)行MRP，并且在待機(jī)狀態(tài)下創(chuàng)建文件后可以啟用：
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.
檢查虛擬文件是否被修復(fù)：
SQL> select * from v$recover_file where error like %FILE%;

no rows selected
啟用STANDBY_FILE_MANAGEMENT為AUTO并啟動(dòng)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.
創(chuàng)建文件后，MRP將開(kāi)始在備用數(shù)據(jù)庫(kù)上應(yīng)用存檔。
檢查主備庫(kù)歸檔應(yīng)用情況：
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;
主庫(kù)實(shí)例歸檔日志信息：
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM 
V$ARCHIVED_LOG ORDER BY SEQUENCE#;
備庫(kù)實(shí)例歸檔日志信息：
SQL> SELECT SEQUENCE#, FIRST_TIME, NEXT_TIME, APPLIED FROM 
V$ARCHIVED_LOG ORDER BY SEQUENCE#;



oracle關(guān)閉mrp進(jìn)程卡死

案例：DG備庫(kù)報(bào)錯(cuò)ORA-600[2619]致使mrp進(jìn)程異常終止

告警日志發(fā)現(xiàn)有報(bào)錯(cuò)ORA-600[2619]，并因此導(dǎo)致mrp進(jìn)程異常終止，這是什么原因?qū)е碌哪兀话鉕RA-600都為oracle數(shù)據(jù)庫(kù)一些內(nèi)部錯(cuò)誤。
接下來(lái)分析下過(guò)程：
1. 由于之前有做過(guò)清理歸檔的動(dòng)作，因?yàn)橹案婢夸浛臻g滿；
2. 嘗試手工拉起mrp進(jìn)程，發(fā)現(xiàn)不成功，嘗試應(yīng)用日志時(shí)同樣是報(bào)錯(cuò)ORA-600[2619]；
3. 通過(guò)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. 結(jié)合之前空間滿的事實(shí)，懷疑是否該歸檔文件也存在尚未完全寫(xiě)入到磁盤(pán)的情況；
5. 主備庫(kù)比對(duì)這個(gè)歸檔日志的大小，發(fā)現(xiàn)大小是一致的；
6. 通過(guò)md5sum比對(duì)主備庫(kù)該歸檔日志，發(fā)現(xiàn)md5不一樣，這說(shuō)明該歸檔文件還是存在差異；
7. 將備庫(kù)的這個(gè)歸檔文件mv重命名備份，然后將主庫(kù)的這個(gè)歸檔文件重新拷貝到備庫(kù)，重新比對(duì)數(shù)據(jù)文件確認(rèn)一致；
8. 再次嘗試?yán)餸rp進(jìn)程，發(fā)現(xiàn)不再報(bào)錯(cuò)，解決問(wèn)題。
總結(jié)：在這種情況下，是由于備用站點(diǎn)的歸檔日志磁盤(pán)空間用完了，導(dǎo)致歸檔日志沒(méi)有完全寫(xiě)入磁盤(pán)。當(dāng)應(yīng)用歸檔日志時(shí)，這會(huì)導(dǎo)致 ORA-600[2619]。

DataGuard 歸檔無(wú)法同步

oracle 啟動(dòng)mrp進(jìn)程,DataGuard MRP進(jìn)程crash：ORA-01111

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

no rows selected
不存在GAP，手動(dòng)啟動(dòng)MRP進(jìn)程，仍無(wú)法啟動(dòng)查看告警日志，找到關(guān)鍵內(nèi)容如下：
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)
可以看到數(shù)據(jù)庫(kù)嘗試啟動(dòng)MRP進(jìn)程，但后臺(tái)進(jìn)行介質(zhì)恢復(fù)時(shí)，被錯(cuò)誤1111碼終端(即ORA-01111)，ORA-01111提示數(shù)據(jù)文件12是未知的。
而后續(xù)的ORA-01110報(bào)錯(cuò)顯示該數(shù)據(jù)文件的位置應(yīng)該是$ORACLE_HOME/UNNAMED00012文件。
實(shí)際在該路徑下是查找不到該文件的：
find /u01/oracle/product/11.2.0.3.0/dbs/ -name UNNAMED00012
那么問(wèn)題就來(lái)了，為什么數(shù)據(jù)庫(kù)需要找到該文件進(jìn)行恢復(fù)？
DG的備庫(kù)是通過(guò)歸檔日志進(jìn)行恢復(fù)的。
在歸檔獲取正確的情況下，會(huì)把主庫(kù)的對(duì)數(shù)據(jù)的更新內(nèi)容都傳遞到備庫(kù)進(jìn)行應(yīng)用。也就是說(shuō)上面報(bào)錯(cuò)在于，主庫(kù)傳過(guò)來(lái)一條更新記錄，對(duì)于備庫(kù)是無(wú)法判斷的。
通過(guò)網(wǎng)上查找相關(guān)答案，發(fā)現(xiàn)原來(lái)當(dāng)主庫(kù)異常宕機(jī)重啟之后，數(shù)據(jù)庫(kù)會(huì)進(jìn)行自動(dòng)恢復(fù)，也就是Instance Recovery，這部分缺失的數(shù)據(jù)被記錄再Redo之中，在異常關(guān)閉后，傳輸?shù)絺鋷?kù)的歸檔中并不包含這部分內(nèi)容，而主庫(kù)通過(guò)一個(gè)臨時(shí)的數(shù)據(jù)文件(UNNAMED命名方式)恢復(fù)后，這部分被恢復(fù)的記錄在后續(xù)的歸檔中被傳輸?shù)絺鋷?kù)，當(dāng)備庫(kù)恢復(fù)到這個(gè)歸檔時(shí)，備庫(kù)無(wú)法自動(dòng)去創(chuàng)建這個(gè)UNNAMED臨時(shí)數(shù)據(jù)文件。
解決方法：
停止備庫(kù)歸檔應(yīng)用(實(shí)際已停止，非必要)，同步歸檔將備庫(kù)歸檔自動(dòng)管理該為手動(dòng)，手工創(chuàng)建該數(shù)據(jù)文件，啟動(dòng)歸檔應(yīng)用進(jìn)程，將歸檔管理由手動(dòng)轉(zhuǎn)自動(dòng)。
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
告警日志已經(jīng)說(shuō)明歸檔已經(jīng)正常應(yīng)用了，也可以查看一下V$MANAGED_STANDBY視圖,確認(rèn)一下MRP進(jìn)程是否啟用。


主備不同步

主備不同步，備庫(kù)歸檔丟失


由于某種原因，可能導(dǎo)致備庫(kù)的歸檔丟失，這需要我們手動(dòng)來(lái)進(jìn)行處理。
示例問(wèn)題描述：
備庫(kù)的歸檔日志沒(méi)有增加，一直等待一個(gè)。
1. 查詢問(wèn)題：
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. 解決問(wèn)題：
需要查看主庫(kù)存不存在歸檔日志，分兩種情況討論：
1）如果存在的話拷貝到備庫(kù)然后手工注冊(cè)；
Scp到備庫(kù)后，備庫(kù)注冊(cè)alter database register logfile XXX；
2）如果不存在的話生成基于SCN的備份集。
查看備庫(kù)最小的scn號(hào)：
select to_char(current_scn) from v$database;
select min(checkpoint_change#) from v$datafile;
select min(checkpoint_change#) from v$datafile_header;
比對(duì)最小的scn，然后再備庫(kù)生成基于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 傳輸?shù)絺鋷?kù)上，備庫(kù)恢復(fù)備份集：
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;
重新開(kāi)啟實(shí)時(shí)應(yīng)用歸檔：
alter database recover managed standby database disconnect from session using current logfile;



文章總結(jié)

當(dāng)dg出現(xiàn)主備不同步時(shí)，首先查看日志看由于什么問(wèn)題導(dǎo)致的，之后看是由于主備斷了同步，mrp進(jìn)程斷掉還是由于磁盤(pán)空間不夠?qū)е碌模饕幕謴?fù)方法為當(dāng)主庫(kù)是否存在歸檔：
若主庫(kù)存在歸檔可直接拷過(guò)去注冊(cè)應(yīng)用即可；
若主庫(kù)不存在歸檔，則需要基于scn號(hào)的增量恢復(fù)。


本文作者：李曉紅

本文來(lái)源：IT那活兒（上海新炬王翦團(tuán)隊(duì)）

文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請(qǐng)注明本文地址：http://www.ezyhdfw.cn/yun/129653.html

相關(guān)文章

  • DG備庫(kù)讀寫(xiě)測(cè)試方案

    DG備庫(kù)讀寫(xiě)測(cè)試方案 img{ display:block; margin:0 auto !important; width:100%; } body{ width:75%; margin:0...

    IT那活兒 評(píng)論0 收藏856

  • DBASK問(wèn)答集萃（2）

    摘要：新晉技術(shù)專(zhuān)家下面是墨天輪部分新晉的技術(shù)專(zhuān)家。大家可以點(diǎn)擊往期閱讀墨天輪技術(shù)專(zhuān)家邀請(qǐng)函了解詳情，申請(qǐng)成為我們的技術(shù)專(zhuān)家，加入專(zhuān)家團(tuán)隊(duì)，與我們一起創(chuàng)建一個(gè)開(kāi)放互助的數(shù)據(jù)庫(kù)技術(shù)社區(qū)。新關(guān)聯(lián)公眾號(hào)墨天輪是一個(gè)開(kāi)放互助的數(shù)據(jù)庫(kù)技術(shù)社區(qū)。 引言 近期我們?cè)贒BASK小程序增加了數(shù)據(jù)庫(kù) MongoDB、Redis、 Elasticsearch、DB2、Weblogic 等新的的專(zhuān)題欄目和一些新的技術(shù)...

    liuchengxu 評(píng)論0 收藏0

發(fā)表評(píng)論

0條評(píng)論

最新活動(dòng)
閱讀需要支付1元查看
<