10gDataguard最大效能模式後期維護文件
資料庫採用.
Primary database (Oracle 10g)
IP:172.16.75.35
INSTANCE_NAME=ora1
Standby database (Oracle 10g)
IP:172.16.75.30
INSTANCE_NAME=ora2
資料庫採用Oracle 10g版本.Dataguard採用最大效能模式.
Primary database (Oracle 10g)
IP:172.16.75.35
INSTANCE_NAME=ora1
Standby database (Oracle 10g)
IP:172.16.75.30
INSTANCE_NAME=ora2
第一部分 日常維護
一 正確開啟主資料庫和從資料庫
1 主資料庫端: IP:172.16.75.35
SQL> STARTUP MOUNT;
SQL> ALTER DATABASE ARCHIVELOG;
SQL> ALTER DATABASE OPEN;
2 從資料庫端: IP:172.16.75.30
SQL> STARTUP MOUNT;
啟動從資料庫日誌傳送程式
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
二 正確關閉主資料庫和從資料庫
1 從資料庫端: IP:172.16.75.30
停止日至傳送程式
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
關閉從資料庫
SQL>SHUTDOWN IMMEDIATE;
2 主資料庫端 IP:172.16.75.35
SQL>SHUTDOWN IMMEDIATE;
三 從資料庫Read-Only模式開啟
當前主資料庫正常OPEN狀態
從資料庫處於日誌傳送狀態.
1 在從資料庫停止日誌傳送
SQL> recover managed standby database cancel;
2 從資料庫Read-only模式開啟
SQL> alter database open read only;
3 從資料庫回到日誌傳送模式
SQL> recover managed standby database disconnect from session;
Media recovery complete.
SQL> select status from v$instance;
STATUS
------------
MOUNTED
四 日誌傳送狀態監控
1 主資料庫察看當前日誌狀況
SQL> select sequence#,status from v$log;
SEQUENCE# STATUS
---------- ----------------
51 ACTIVE
52 CURRENT
50 INACTIVE
2 從資料庫端察看RFS(Remote File Service)接收日誌情況和MRP應用日誌同步主資料庫情況
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS
2 FROM V$MANAGED_STANDBY;
PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS
--------- ------------ ---------- ---------- ---------- ----------
ARCH CONNECTED 0 0 0 0
ARCH CONNECTED 0 0 0 0
RFS RECEIVING 0 0 0 0
MRP0 WAIT_FOR_LOG 1 52 0 0
RFS RECEIVING 0 0 0 0
可以看到從資料庫MPR0正等待SEQUENCE#為52的redo.
3 察看從資料庫是否和主資料庫同步
SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ#
2 FROM V$ARCHIVE_DEST_STATUS;
ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#
---------------- ------------- --------------- ------------
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
0 0 0 0
1 51 1 50
11 rows selected.
可以看到從資料庫已經將SEQUENCE#51的日誌歸檔,已經將SEQUENCE#50的redo應用到從資料庫.
由於已經將SEQUENCE#51的日誌歸檔,所以SEQUENCE#51以前的資料不會丟失.
4 察看從資料庫已經歸檔的redo
SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#,
2 NEXT_CHANGE# FROM V$ARCHIVED_LOG;
REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
------- ------- ---------- ---------- ------------- ------------
SRMN SRMN 1 37 572907 573346
RFS ARCH 1 38 573346 573538
RFS ARCH 1 39 573538 573623
RFS ARCH 1 40 573623 573627
RFS ARCH 1 41 573627 574326
RFS ARCH 1 42 574326 574480
RFS ARCH 1 43 574480 590971
RFS ARCH 1 44 590971 593948
RFS FGRD 1 45 593948 595131
RFS FGRD 1 46 595131 595471
FGRD FGRD 1 46 595131 595471
REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
------- ------- ---------- ---------- ------------- ------------
RFS ARCH 1 47 595471 595731
RFS ARCH 1 48 595731 601476
RFS ARCH 1 49 601476 601532
RFS ARCH 1 50 601532 606932
RFS ARCH 1 51 606932 607256
16 rows selected.
5 察看從資料庫已經應用的redo
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#
2 FROM V$LOG_HISTORY;
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 1 366852 368222
1 2 368222 369590
1 3 369590 371071
1 4 371071 372388
1 5 372388 376781
1 6 376781 397744
1 7 397744 407738
1 8 407738 413035
1 9 413035 413037
1 10 413037 413039
1 11 413039 413098
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 12 413098 428161
1 13 428161 444373
1 14 444373 457815
1 15 457815 463016
1 16 463016 476931
1 17 476931 492919
1 18 492919 505086
1 19 505086 520683
1 20 520683 530241
1 21 530241 545619
1 22 545619 549203
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 23 549203 552403
1 24 552403 553230
1 25 553230 553398
1 26 553398 553695
1 27 553695 554327
1 28 554327 557569
1 29 557569 561279
1 30 561279 561385
1 31 561385 566069
1 32 566069 566825
1 33 566825 570683
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 34 570683 571627
1 35 571627 571867
1 36 571867 572907
1 37 572907 573346
1 38 573346 573538
1 39 573538 573623
1 40 573623 573627
1 41 573627 574326
1 42 574326 574480
1 43 574480 590971
1 44 590971 593948
THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ---------- ------------- ------------
1 45 593948 595131
1 46 595131 595471
1 47 595471 595731
1 48 595731 601476
1 49 601476 601532
1 50 601532 606932
1 51 606932 607256
可以看到從資料庫已經將SEQUENCE#為51的歸檔檔案應用到從資料庫.
6 察看從資料庫接收,應用redo資料過程.
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;
MESSAGE
--------------------------------------------------------------------------------
ARC0: Archival started
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Archival started
ARC1: Becoming the heartbeat ARCH
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[1]: Assigned to RFS process 19740
RFS[1]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
Attempt to start background Managed Standby Recovery process
MESSAGE
--------------------------------------------------------------------------------
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Clearing online redo logfile 7 /oraguard/redo1/redo_7_1.log
Clearing online redo logfile 7 complete
Media Recovery Waiting for thread 1 sequence 47
RFS[1]: No standby redo logfiles created
Redo Shipping Client Connected as PUBLIC
-- Connected User is Valid
RFS[2]: Assigned to RFS process 19746
RFS[2]: Identified database type as 'physical standby'
Primary database is in MAXIMUM PERFORMANCE mode
MESSAGE
--------------------------------------------------------------------------------
Committing creation of archivelog '/arch/1_47_552308270.arc'
Media Recovery Log /arch/1_47_552308270.arc
Media Recovery Waiting for thread 1 sequence 48
MRP0: Background Media Recovery cancelled with status 16037
MRP0: Background Media Recovery process shutdown
Managed Standby Recovery Canceled
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 48
RFS[1]: No standby redo logfiles created
MESSAGE
--------------------------------------------------------------------------------
Committing creation of archivelog '/arch/1_48_552308270.arc'
Media Recovery Log /arch/1_48_552308270.arc
Media Recovery Waiting for thread 1 sequence 49
RFS[1]: No standby redo logfiles created
Committing creation of archivelog '/arch/1_49_552308270.arc'
Media Recovery Log /arch/1_49_552308270.arc
Media Recovery Waiting for thread 1 sequence 50
RFS[1]: No standby redo logfiles created
Committing creation of archivelog '/arch/1_50_552308270.arc'
Media Recovery Log /arch/1_50_552308270.arc
Media Recovery Waiting for thread 1 sequence 51
MESSAGE
--------------------------------------------------------------------------------
RFS[1]: No standby redo logfiles created
Committing creation of archivelog '/arch/1_51_552308270.arc'
Media Recovery Log /arch/1_51_552308270.arc
Media Recovery Waiting for thread 1 sequence 52
可以看到RFS接收到sequence#為51的歸檔檔案並存至從資料庫歸檔目錄/arch/1_51_552308270.arc.
Oracle自動應用檔案/arch/1_51_552308270.arc進行從資料庫與主資料庫同步
Oracle繼續等待主資料庫sequence 52的歸檔檔案
五 從資料庫歸檔目錄維護 IP:172.16.75.30
1 找到從資料庫歸檔目錄
SQL> show parameter log_archive_dest_1
NAME TYPE
------------------------------------ --------------------------------
VALUE
------------------------------
log_archive_dest_1 string
LOCATION=/arch
VALID_FOR=(ALL_LOGFILES,ALL_RO
LES)
DB_UNIQUE_NAME=ora2
log_archive_dest_10 string
2 維護策略
每週2,4,7刪除已經應用的歸檔檔案
具體參見附錄二
第二部分 主資料庫正常切換
一 人工干預主資料庫正常切換
1 在主資料庫端檢驗資料庫可切換狀態 IP:172.16.75.35
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
1 row selected
SWITCHOVER_STATUS:TO STANDBY表示可以正常切換.
如果SWITCHOVER_STATUS的值為SESSIONS ACTIVE,表示當前有會話處於ACTIVE狀態
2 開始主資料庫正常切換 IP:172.16.75.35
如果SWITCHOVER_STATUS的值為TO STANDBY 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;
如果SWITCHOVER_STATUS的值為SESSIONS ACTIVE 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
成功執行這個命令後，主資料庫被修改為從資料庫
3 重啟先前的主資料庫 IP:172.16.75.35
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
4 在從資料庫端驗證可切換狀態 IP:172.16.75.30
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected
5 將目標從資料庫轉換為主資料庫 IP:172.16.75.30
如果SWITCHOVER_STATUS的值為TO STANDBY 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
如果SWITCHOVER_STATUS的值為SESSIONS ACTIVE 則:
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
成功執行這個命令後，從資料庫被修改為主資料庫
6 重啟目標從資料庫 IP:172.16.75.30
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP;
7 先前主資料庫啟動日誌傳送程式 IP:172.16.75.35
SQL> alter database recover managed standby database disconnect;
總結: 這樣主資料庫的一次正常切換完成.切換後的狀態,原先的主資料庫(35)變為從資料庫,原先的從資料庫(30)變為主資料庫.
二 透過執行指令碼實現主資料庫正常切換
1 主資料庫切換為從資料庫
在172.16.75.35上執行指令碼
/admin/dataGuard/switchover/primary_to_standby.sh
2 從資料庫切換為主資料庫
在172.16.75.30上執行指令碼
/admin/dataGuard/switchover/standby_to_primary.sh
指令碼1成功執行後,再執行指令碼2,不能同時執行兩個指令碼.
經過這次切換後原來的主資料庫(35)變為從資料庫,原先的從資料庫(30)變為主資料並且OPEN對應用提供服務.
3 復原最初狀態
即: 恢復35為主資料庫,30為從資料庫
在172.16.75.30上執行指令碼
/admin/dataGuard/switchover/primary_to_standby.sh
成功完成後
在172.16.75.35上執行指令碼
/admin/dataGuard/switchover/standby_to_primary.sh
第三部分 主資料庫災難切換
一 人工干預主資料庫災難切換
二 透過執行指令碼實現主資料庫災難切換
附:
一 有選擇察看redo傳送與應用情況
select message from v$dataguard_status
where message_num>&message_num;
二 從資料庫歸檔目錄維護指令碼
在crontab 中定製每日執行removeCommand.sh即可。
流程:每日11:50PM執行removeCommand.sh
假設今日2005-04-05 則刪除04-04和04-03兩日已應用歸檔日誌.保留今日已應用歸檔日誌
[oracle@db_gurid admin]$ crontab -l
50 23 * * * sh /oraguard/admin/removeCommand.sh>>removeArch.log
##################
[oracle@db_gurid admin]$ cat removeCommand.sh
#!/bin/sh
export ORACLE_BASE=/ora10g/app
export ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1
export ORACLE_SID=ora2
cd /oraguard/admin
$ORACLE_HOME/bin/sqlplus /nolog<
@/oraguard/admin/removeArch.sql
EOF
chmod +x /oraguard/admin/removeArch.sh
/oraguard/admin/removeArch.sh>>removeArch2.log
##################
[oracle@db_gurid admin]$ cat removeArch.sql
set feed off
set heading off
set echo off
spool removeArch.sh
select 'rm '||name from v$archived_log where applied='YES' and completion_time>trunc(sysdate-3) and completion_time
###############
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/76065/viewspace-795687/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 企業網站後期如何維護？網站
- 10g DG保護模式的切換：從最大效能到最大可用模式
- 最大效能保護，最大資料保護，最大可用性，LGWR, ARCH大資料
- 面試題庫（長期維護）面試題
- 網站優化到後期該如何更好的維護排名？網站優化
- 最大效能模式DATAGUARD 搭建 及SWITCH模式
- 10gR2最大保護模式DataGuard建立模式
- 建立DATAGUARD最大保護模式-測試手記模式
- 開發資料大全（個人整理，長期維護）
- 0gR2最大保護模式DataGuard建立 (轉載)模式
- Data Guard的三種保護模式（摘自官方文件）模式
- DedeCMS織夢文件關鍵詞維護中設定詞語重疊後出錯的修改方法
- 引數配置 -- 最大效能模式 dataguard 不影響Production DB .模式
- IT職場：TPM是如何確定裝置維護週期的？
- 長期維護嵌入式 Linux 核心變得容易Linux
- UVA 11078 Open Credit System（掃描 維護最大值）
- 修改陣列【並查集維護集合的最大值、連續數字的最大值】陣列並查集
- TensorFlow 官方文件中文版釋出啦（持續維護）
- 資訊系統資料維護的週期和頻率
- 修改維護模式導致ebs頁面打不開模式
- 多維分析的後臺效能優化手段優化
- 瞭解和使用kfed維護ASM後設資料ASM
- 需要簡單修改 python 第三方庫原始碼，後期怎樣進行升級維護Python原始碼
- ELK運維文件運維
- 資料維護和基礎架構維護-有感架構
- OCR維護命令
- RAC維護命令
- mysql 管理維護MySql
- 系統維護
- RAC維護工具
- QTP測試指令碼的維護 - 使用Update執行模式和Maintenance執行模式QT指令碼模式AINaN
- 如何刪除word文件密碼保護 解除word文件保護密碼密碼
- SpringBoot整合Swagger2，再也不用維護介面文件了！Spring BootSwagger
- OCR/Vote disk 維護操作: (新增/刪除/替換/移動) (文件 ID 1674859.1)
- 【DataGuard】不能沒有你，我的Standby ——Oracle DataGuard最大保護模式 故障實驗Oracle模式
- 保護模式模式
- 後端思維之資料庫效能優化方案後端資料庫優化
- oracle維護服務 oracle解決方案 oracle售後服務Oracle