11g adg 環境搭建實施手冊-0824
11g adg 環境搭建實施手冊-0824
2017年8月24日
10:18
################################################################
簡介
從11g 開始oracle提供了一個新功能Active Database Duplication for A standby database來創建配置物理standby 數據庫。
Active Database Duplication for A standby database這個功能主要從一個正在運行的數據庫復制數據文件，控制文件等到一個物理備庫（physical standby database）。
這個功能簡化了創建standby database過程中在主庫備份和備庫恢復的環節，實現了自動拷貝主庫的控制文件，數據文件等到備庫，對比基於備份集的創建standby database
過程中需要手動在主庫備份，然後將備份集拷貝到備庫再手動恢復來說，減少了dba的大量工作。
創建物理standby database過程中的其他環節，如打開主庫的force logging，主庫init參數的修改等，以及備庫開始應用redo log這些環節還需手動來完成的，與以往的創建配置物理standby database 是相同的。
備庫的init參數需要在duplicate命令中指定，沒有特殊指定的，就會默認使用主庫的init參數值。
測試環境
-----------------------------------
主庫：11.2.0.1 單機數據庫，db_unique_name=fpyj，數據文件存放在文件系統
備庫：11.2.0.1 單機數據庫，db_unique_name=fpyjbak，數據文件存放在文件系統
Data Guard保護模式（Protection mode）采用最大性能模式（MAXIMIZE PERFORMANCE）
redo log傳輸采用LGWR進程的異步傳輸方式
##########################################################################
安裝前環境檢查
【要求】
|
1. 主庫和備庫必須是相同版本及位數並且為企業版（Enterprise Edition Release） 2. 主庫和備庫所在的操作系統最好是相同平臺，相同操作系統版本，必須是相同 ENDIAN_FORMAT 的平臺 3. 主庫、備庫必須開啟歸檔模式 4.主庫、備庫 必須啟用force logging功能 |
1. 檢查主庫和備庫數據庫軟件版本
|
SYS(125_9)@fpyj> select * from v$version;
BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production PL/SQL Release 11.2.0.1.0 - Production CORE 11.2.0.1.0 Production TNS for Linux: Version 11.2.0.1.0 - Production NLSRTL Version 11.2.0.1.0 - Production |
2. 檢查操作系統平臺是否兼容
|
SYS(125_9)@fpyj> select * from v$transportable_platform order by endian_format,platform_name;
PLATFORM_ID PLATFORM_NAME ENDIAN_FORMAT ----------- ---------------------------------------- -------------- 6 AIX-Based Systems (64-bit) Big 16 Apple Mac OS Big 3 HP-UX (64-bit) Big 4 HP-UX IA (64-bit) Big 18 IBM Power Based Linux Big 9 IBM zSeries Based Linux Big 1 Solaris[tm] OE (32-bit) Big 2 Solaris[tm] OE (64-bit) Big 21 Apple Mac OS (x86-64) Little 19 HP IA Open VMS Little 15 HP Open VMS Little 5 HP Tru64 UNIX Little 10 Linux IA (32-bit) Little 11 Linux IA (64-bit) Little 13 Linux x86 64-bit Little 7 Microsoft Windows IA (32-bit) Little 8 Microsoft Windows IA (64-bit) Little 12 Microsoft Windows x86 64-bit Little 17 Solaris Operating System (x86) Little 20 Solaris Operating System (x86-64) Little |
3. 檢查主庫是否開啟數據庫歸檔
|
SYS(125_9)@fpyj> select name,log_mode,force_logging from v$database;
NAME LOG_MODE FOR --------- ------------ --- FPYJ ARCHIVELOG YES |
##########################################################################
安裝前環境準備
##########################################################################
1. 打開主庫force logging:
|
SQL> ALTER DATABASE FORCE LOGGING;
查看主庫當前是否為force logging： SQL> select force_logging from v$database; FOR --- YES |
2. 修改主庫的初始化參數如下：
|
LOG_ARCHIVE_CONFIG=‘DG_CONFIG=(fpyj,fpyjbak)‘ --這是本地的歸檔目錄 LOG_ARCHIVE_DEST_1=‘LOCATION=/home/oracle/arch_dir/fpyj VALID_FOR=(all_logfiles,all_roles) db_unique_name=fpyj‘ --這是接收遠程的歸檔目錄 註意 service、db_unique_name LOG_ARCHIVE_DEST_2=‘SERVICE=fpyjbak LGWR SYNC VALID_FOR=(all_logfiles,all_roles) DB_UNIQUE_NAME=fpyj123‘ LOG_ARCHIVE_DEST_STATE_1=ENABLE LOG_ARCHIVE_DEST_STATE_2=ENABLE REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE LOG_ARCHIVE_MAX_PROCESSES=10 |
- 3. 為簡化 rman窗口中的輸入，因此把相應的操作放入 duplicate.sql文件中。然後執行該文件。
|
duplicate target database for standby nofilenamecheck from active database dorecover spfile set db_unique_name=‘fpyjbak‘ set log_archive_dest_1=‘location=/home/oracle/arch_dir/fpyjbak valid_for=(all_logfiles,all_roles) db_unique_name=fpyjbak‘ set log_archive_dest_2=‘service=fpyj sync lgwr valid_for=(online_logfiles,primary_role) db_unique_name=fpyj‘ set standby_file_management=‘auto‘ set fal_server=‘fpyj‘ set fal_client=‘fpyjbak‘ set control_files=‘/u01/app/oracle/oradata/fpyjbak/control01.ctl‘ #set memory_target=‘500m‘ set sga_max_size=‘400m‘ set diagnostic_dest=‘/u01/app/oracle‘ set audit_file_dest=‘/u01/app/oracle/admin/fpyjbak/adump‘ set DB_FILE_NAME_CONVERT=‘/oradata02/fpyj/1107‘,‘/u01/app/oracle/oradata/fpyjbak‘ set LOG_FILE_NAME_CONVERT=‘/oradata02/fpyj‘,‘/u01/app/oracle/oradata/fpyjbak‘ |
4. 在備庫創建 adump 路徑，與參數audit_file_dest的路徑一致
|
$ mkdir -p /u01/app/oracle/admin/fpyjbak/adump |
5. 在備庫創建init參數文件$ORACLE_HOME/dbs/initfpyj123.ora‘，
|
有了這個臨時的init參數文件，我們就可以在duplicate命令運行前將備庫的AUXILIARY實例啟動到nomount狀態，這也是運行duplicate命令的一個必要條件。
initfpyjbak.ora文件只有一行信息： DB_NAME=fpyj |
6. 將密碼文件從主庫服務器拷貝到備庫服務器，並且重命名：
|
$ cp orapwfpyj orapwfpyj123 |
7. 在主庫服務器和備庫服務器, 編輯添加下面信息到$ORACLE_HOME/network/tnsnames.ora
|
FPYJ = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = Oracle11g)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = fpyj) ) )
FPYJ123 = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = Oracle11g)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = fpyj123) ) ) |
8. 在備庫服務器, 添加靜態註冊信息到 $ORACLE_HOME/network/listener.ora文件，
|
這主要是由於AUXILIARY實例啟動到nomount狀態時，listener無法註冊AUXILIARY實例，listener會標誌Auxiliary實例為‘blocked‘狀態，因此duplicate命令就無法通過TNS的方式連接到Auxiliary實例，為了解決這個問題，需要先手動靜態註冊數據庫實例到listener上。 當Data Guard配置完成後，就可以刪除靜態註冊的配置信息。 （本測試使用ASM，因此需要安裝GRID，有效的listener.ora文件是在GRID_HOME下面）
LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = IPC)(KEY = ANYTHING)) (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.113)(PORT = 1521)) ) )
SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = fpyjbak) (ORACLE_HOME = /u01/app/oracle/product/11.2.0/db_1) (SID_NAME = fpyjbak) ) ) |
9. 在備庫服務器，執行duplicate命令前，先啟動AUXILIARY實例到 nomount 狀態：
|
$ export ORACLE_SID=fpyjbak $ sqlplus / as sysdba SQL> startup nomount; |
10. 在備庫測試與AUXILIARY實例的連接和與主庫的連接，如果連接成功，繼續執行下面的步驟，
|
很多時候duplicate命令失敗都是由於連接失敗導致的。 $ sqlplus sys/[email protected] as sysdba $ sqlplus sys/[email protected] as sysdba |
Duplicate.sql 如下：
|
duplicate target database for standby nofilenamecheck from active database dorecover spfile set db_unique_name=‘fpyjbak‘ set log_archive_dest_1=‘location=/home/oracle/arch_dir/fpyjbak valid_for=(all_logfiles,all_roles) db_unique_name=fpyjbak‘ set log_archive_dest_2=‘service=fpyj sync lgwr valid_for=(online_logfiles,primary_role) db_unique_name=fpyj‘ set standby_file_management=‘auto‘ set fal_server=‘fpyj‘ set fal_client=‘fpyjbak‘ set control_files=‘/u01/app/oracle/oradata/fpyjbak/control01.ctl‘ set memory_target=‘500m‘ set sga_max_size=‘400m‘ set diagnostic_dest=‘/u01/app/oracle‘ set audit_file_dest=‘/u01/app/oracle/admin/fpyjbak/adump‘ set DB_FILE_NAME_CONVERT=‘/oradata02/fpyj/1107‘,‘/u01/app/oracle/oradata/fpyjbak‘ set LOG_FILE_NAME_CONVERT=‘/oradata02/fpyj‘,‘/u01/app/oracle/oradata/fpyjbak‘ |
11. 創建備庫
|
在duplicate命令中指定關鍵字‘FOR STANDBY‘和‘FROM ACTIVE DATABASE‘表示從一個active的數據庫來復制創建物理備庫 參數‘DORECOVER‘表示duplicate命令會執行recover動作，否則duplicate命令只執行restore， 備庫與主庫不同的初始化參數，需要在duplicate命令中特殊指定，這樣創建備庫的spfile時就會用指定的值替換主庫的參數值， 主庫與備庫的數據文件的路徑不同，因此設置參數‘DB_FILE_NAME_CONVERT‘
% rman target sys/[email protected] AUXILIARY SYS/[email protected] cmdfile=/home/oracle/scripts/duplicate.sql log=/home/oracle/scripts/duplicate.log |
|
以下是duplicate standby database過程中屏幕的log信息 RMAN> duplicate target database for standby nofilenamecheck 2> from active database 3> dorecover 4> spfile 5> set db_unique_name=‘fpyjbak‘ 6> set log_archive_dest_1=‘location=/home/oracle/arch_dir/fpyjbak valid_for=(all_logfiles,all_roles) db_unique_name=fpyjbak‘ 7> set log_archive_dest_2=‘service=fpyj sync lgwr valid_for=(online_logfiles,primary_role) db_unique_name=fpyj‘ 8> set standby_file_management=‘auto‘ 9> set fal_server=‘fpyj‘ 10> set fal_client=‘fpyjbak‘ 11> set control_files=‘/u01/app/oracle/oradata/fpyjbak/control01.ctl‘ 12> set memory_target=‘500m‘ 13> set sga_max_size=‘400m‘ 14> set diagnostic_dest=‘/u01/app/oracle‘ 15> set audit_file_dest=‘/u01/app/oracle/admin/fpyjbak/adump‘ 16> set DB_FILE_NAME_CONVERT=‘/oradata02/fpyj/1107‘,‘/u01/app/oracle/oradata/fpyjbak‘ 17> set LOG_FILE_NAME_CONVERT=‘/oradata02/fpyj/1107‘,‘/u01/app/oracle/oradata/fpyjbak‘ 18> ; 19> Starting Duplicate Db at 28-AUG-17 using target database control file instead of recovery catalog allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=20 device type=DISK
contents of Memory Script: { backup as copy reuse targetfile ‘/u01/app/oracle/product/11.2.0/db_1/dbs/orapwfpyj‘ auxiliary format ‘/u01/app/oracle/product/11.2.0/db_1/dbs/orapwfpyjbak‘ targetfile ‘/u01/app/oracle/product/11.2.0/db_1/dbs/spfilefpyj.ora‘ auxiliary format ‘/u01/app/oracle/product/11.2.0/db_1/dbs/spfilefpyjbak.ora‘ ; sql clone "alter system set spfile= ‘‘/u01/app/oracle/product/11.2.0/db_1/dbs/spfilefpyjbak.ora‘‘"; } executing Memory Script
Starting backup at 28-AUG-17 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=145 device type=DISK Finished backup at 28-AUG-17
sql statement: alter system set spfile= ‘‘/u01/app/oracle/product/11.2.0/db_1/dbs/spfilefpyjbak.ora‘‘
contents of Memory Script: { sql clone "alter system set db_unique_name = ‘‘fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set log_archive_dest_1 = ‘‘location=/home/oracle/arch_dir/fpyjbak valid_for=(all_logfiles,all_roles) db_unique_name=fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set log_archive_dest_2 = ‘‘service=fpyj sync lgwr valid_for=(online_logfiles,primary_role) db_unique_name=fpyj‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set standby_file_management = ‘‘auto‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set fal_server = ‘‘fpyj‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set fal_client = ‘‘fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set control_files = ‘‘/u01/app/oracle/oradata/fpyjbak/control01.ctl‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set memory_target = 500m comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set sga_max_size = 400m comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set diagnostic_dest = ‘‘/u01/app/oracle‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set audit_file_dest = ‘‘/u01/app/oracle/admin/fpyjbak/adump‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set db_file_name_convert = ‘‘/oradata02/fpyj/1107‘‘, ‘‘/u01/app/oracle/oradata/fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile"; sql clone "alter system set LOG_FILE_NAME_CONVERT = ‘‘/oradata02/fpyj/1107‘‘, ‘‘/u01/app/oracle/oradata/fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile"; shutdown clone immediate; startup clone nomount; } executing Memory Script
sql statement: alter system set db_unique_name = ‘‘fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set log_archive_dest_1 = ‘‘location=/home/oracle/arch_dir/fpyjbak valid_for=(all_logfiles,all_roles) db_unique_name=fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set log_archive_dest_2 = ‘‘service=fpyj sync lgwr valid_for=(online_logfiles,primary_role) db_unique_name=fpyj‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set standby_file_management = ‘‘auto‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set fal_server = ‘‘fpyj‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set fal_client = ‘‘fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set control_files = ‘‘/u01/app/oracle/oradata/fpyjbak/control01.ctl‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set memory_target = 500m comment= ‘‘‘‘ scope=spfile
sql statement: alter system set sga_max_size = 400m comment= ‘‘‘‘ scope=spfile
sql statement: alter system set diagnostic_dest = ‘‘/u01/app/oracle‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set audit_file_dest = ‘‘/u01/app/oracle/admin/fpyjbak/adump‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set db_file_name_convert = ‘‘/oradata02/fpyj/1107‘‘, ‘‘/u01/app/oracle/oradata/fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile
sql statement: alter system set LOG_FILE_NAME_CONVERT = ‘‘/oradata02/fpyj/1107‘‘, ‘‘/u01/app/oracle/oradata/fpyjbak‘‘ comment= ‘‘‘‘ scope=spfile
Oracle instance shut down
connected to auxiliary database (not started) Oracle instance started
Total System Global Area 417546240 bytes
Fixed Size 2213936 bytes Variable Size 209717200 bytes Database Buffers 201326592 bytes Redo Buffers 4288512 bytes
contents of Memory Script: { backup as copy current controlfile for standby auxiliary format ‘/u01/app/oracle/oradata/fpyjbak/control01.ctl‘; } executing Memory Script
Starting backup at 28-AUG-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile copy copying standby control file output file name=/u01/app/oracle/product/11.2.0/db_1/dbs/snapcf_fpyj.f tag=TAG20170828T160822 RECID=27 STAMP=953222903 channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:01 Finished backup at 28-AUG-17
contents of Memory Script: { sql clone ‘alter database mount standby database‘; } executing Memory Script
sql statement: alter database mount standby database Using previous duplicated file /u01/app/oracle/oradata/fpyjbak/system01.dbf for datafile 1 with checkpoint SCN of 1785948 Using previous duplicated file /u01/app/oracle/oradata/fpyjbak/sysaux01.dbf for datafile 2 with checkpoint SCN of 1785992 Using previous duplicated file /u01/app/oracle/oradata/fpyjbak/undotbs01.dbf for datafile 3 with checkpoint SCN of 1786037 Using previous duplicated file /u01/app/oracle/oradata/fpyjbak/users01.dbf for datafile 4 with checkpoint SCN of 1786044 Using previous duplicated file /u01/app/oracle/oradata/fpyjbak/fpyj01.dbf for datafile 5 with checkpoint SCN of 1786030
contents of Memory Script: { set newname for tempfile 1 to "/u01/app/oracle/oradata/fpyjbak/temp01.dbf"; switch clone tempfile all; sql ‘alter system archive log current‘; } executing Memory Script
executing command: SET NEWNAME
renamed tempfile 1 to /u01/app/oracle/oradata/fpyjbak/temp01.dbf in control file
sql statement: alter system archive log current
contents of Memory Script: { backup as copy reuse archivelog like "/home/oracle/arch_dir/fpyj/1_109_927291116.dbf" auxiliary format "/home/oracle/arch_dir/fpyjbak/1_109_927291116.dbf" archivelog like "/home/oracle/arch_dir/fpyj/1_110_927291116.dbf" auxiliary format "/home/oracle/arch_dir/fpyjbak/1_110_927291116.dbf" archivelog like "/home/oracle/arch_dir/fpyj/1_111_927291116.dbf" auxiliary format "/home/oracle/arch_dir/fpyjbak/1_111_927291116.dbf" ; catalog clone archivelog "/home/oracle/arch_dir/fpyjbak/1_109_927291116.dbf"; catalog clone archivelog "/home/oracle/arch_dir/fpyjbak/1_110_927291116.dbf"; catalog clone archivelog "/home/oracle/arch_dir/fpyjbak/1_111_927291116.dbf"; catalog clone datafilecopy "/u01/app/oracle/oradata/fpyjbak/system01.dbf", "/u01/app/oracle/oradata/fpyjbak/sysaux01.dbf", "/u01/app/oracle/oradata/fpyjbak/undotbs01.dbf", "/u01/app/oracle/oradata/fpyjbak/users01.dbf", "/u01/app/oracle/oradata/fpyjbak/fpyj01.dbf"; switch clone datafile 1 to datafilecopy "/u01/app/oracle/oradata/fpyjbak/system01.dbf"; switch clone datafile 2 to datafilecopy "/u01/app/oracle/oradata/fpyjbak/sysaux01.dbf"; switch clone datafile 3 to datafilecopy "/u01/app/oracle/oradata/fpyjbak/undotbs01.dbf"; switch clone datafile 4 to datafilecopy "/u01/app/oracle/oradata/fpyjbak/users01.dbf"; switch clone datafile 5 to datafilecopy "/u01/app/oracle/oradata/fpyjbak/fpyj01.dbf"; } executing Memory Script
Starting backup at 28-AUG-17 using channel ORA_DISK_1 channel ORA_DISK_1: starting archived log copy input archived log thread=1 sequence=109 RECID=153 STAMP=953222648 output file name=/home/oracle/arch_dir/fpyjbak/1_109_927291116.dbf RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting archived log copy input archived log thread=1 sequence=110 RECID=154 STAMP=953222649 output file name=/home/oracle/arch_dir/fpyjbak/1_110_927291116.dbf RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 channel ORA_DISK_1: starting archived log copy input archived log thread=1 sequence=111 RECID=155 STAMP=953222909 output file name=/home/oracle/arch_dir/fpyjbak/1_111_927291116.dbf RECID=0 STAMP=0 channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01 Finished backup at 28-AUG-17
cataloged archived log archived log file name=/home/oracle/arch_dir/fpyjbak/1_109_927291116.dbf RECID=1 STAMP=953222905
cataloged archived log archived log file name=/home/oracle/arch_dir/fpyjbak/1_110_927291116.dbf RECID=2 STAMP=953222905
cataloged archived log archived log file name=/home/oracle/arch_dir/fpyjbak/1_111_927291116.dbf RECID=3 STAMP=953222905
cataloged datafile copy datafile copy file name=/u01/app/oracle/oradata/fpyjbak/system01.dbf RECID=27 STAMP=953222905 cataloged datafile copy datafile copy file name=/u01/app/oracle/oradata/fpyjbak/sysaux01.dbf RECID=28 STAMP=953222905 cataloged datafile copy datafile copy file name=/u01/app/oracle/oradata/fpyjbak/undotbs01.dbf RECID=29 STAMP=953222905 cataloged datafile copy datafile copy file name=/u01/app/oracle/oradata/fpyjbak/users01.dbf RECID=30 STAMP=953222905 cataloged datafile copy datafile copy file name=/u01/app/oracle/oradata/fpyjbak/fpyj01.dbf RECID=31 STAMP=953222905
datafile 1 switched to datafile copy input datafile copy RECID=27 STAMP=953222905 file name=/u01/app/oracle/oradata/fpyjbak/system01.dbf
datafile 2 switched to datafile copy input datafile copy RECID=28 STAMP=953222905 file name=/u01/app/oracle/oradata/fpyjbak/sysaux01.dbf
datafile 3 switched to datafile copy input datafile copy RECID=29 STAMP=953222905 file name=/u01/app/oracle/oradata/fpyjbak/undotbs01.dbf
datafile 4 switched to datafile copy input datafile copy RECID=30 STAMP=953222905 file name=/u01/app/oracle/oradata/fpyjbak/users01.dbf
datafile 5 switched to datafile copy input datafile copy RECID=31 STAMP=953222905 file name=/u01/app/oracle/oradata/fpyjbak/fpyj01.dbf
contents of Memory Script: { set until scn 1788149; recover standby clone database delete archivelog ; } executing Memory Script
executing command: SET until clause
Starting recover at 28-AUG-17 allocated channel: ORA_AUX_DISK_1 channel ORA_AUX_DISK_1: SID=1 device type=DISK
starting media recovery
archived log for thread 1 with sequence 109 is already on disk as file /home/oracle/arch_dir/fpyjbak/1_109_927291116.dbf archived log for thread 1 with sequence 110 is already on disk as file /home/oracle/arch_dir/fpyjbak/1_110_927291116.dbf archived log for thread 1 with sequence 111 is already on disk as file /home/oracle/arch_dir/fpyjbak/1_111_927291116.dbf archived log file name=/home/oracle/arch_dir/fpyjbak/1_109_927291116.dbf thread=1 sequence=109 archived log file name=/home/oracle/arch_dir/fpyjbak/1_110_927291116.dbf thread=1 sequence=110 archived log file name=/home/oracle/arch_dir/fpyjbak/1_111_927291116.dbf thread=1 sequence=111 media recovery complete, elapsed time: 00:00:01 Finished recover at 28-AUG-17 Finished Duplicate Db at 28-AUG-17
Recovery Manager complete. |
以上創建完成了物理standby數據庫(最後的錯誤警告信息可以忽略，我們在後面的附錄1詳細解釋這個錯誤信息)。但是備庫數據庫還沒有開始應用redo log。
12. 創建standby redo log，standby redo log大小等於主庫online redo log大小：
|
SYS(125_13)@fpyjbak> alter database open;
Database altered.
SYS(125_13)@fpyjbak> ALTER DATABASE ADD STANDBY LOGFILE ‘srl1.f‘ SIZE 52428800;
Database altered.
SYS(125_13)@fpyjbak> ALTER DATABASE ADD STANDBY LOGFILE ‘srl2.f‘ SIZE 52428800;
Database altered.
SYS(125_13)@fpyjbak> ALTER DATABASE ADD STANDBY LOGFILE ‘srl3.f‘ SIZE 52428800;
Database altered.
SYS(125_13)@fpyjbak> ALTER DATABASE ADD STANDBY LOGFILE ‘srl4.f‘ SIZE 52428800;
Database altered. |
13. 運行下面的命令開始應用redo log：
|
SYS(14_17)@fpyjbak> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
Database altered. |
以上的全部步驟就配置完成了物理standby數據庫，並且開始應用redo log。
附錄1
----------
|
在創建備庫時最後報出的錯誤警告信息ORA-19527和在MRP開始應用redo log時，alert log中報出下面的錯誤信息：
Errors in file /u01/app/diag/rdbms/orabak/orabak/trace/orabak_mrp0_7644.trc: ORA-00313: open failed for members of log group 1 of thread 1 ORA-00312: online log 1 thread 1: ‘/home/oracle/app/oradata/orcl/redo01.log‘ ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory ..... Errors in file /u01/app/diag/rdbms/orabak/orabak/trace/orabak_mrp0_7644.trc: ORA-19527: physical standby redo log must be renamed ORA-00312: online log 1 thread 1: ‘/home/oracle/app/oradata/orcl/redo01.log‘
以上錯誤的原因： oracle為了加快備庫與主庫switchover的速度，從10.2開始增加了一個增強的功能，就是當MRP啟動時會去清理備庫上online redo log。造成以上2個錯誤有2個原因，第一個是備庫沒有創建online redo log，第二個是備庫沒有設置log_file_name_convert參數。
解決方法： 方法#1：如果不考慮switchover（備庫上不創建online reod log），那麽可以忽略這個錯誤，因為這個錯只是一個提示性的信息，不會影響備庫的MRP的工作。 方法#2：如果考慮switchover，在備庫上創建online reod log，並且設置log_file_name_convert參數： SQL> shutdown immediate; SQL> startup mount; SQL> ALTER DATABASE ADD LOGFILE GROUP 4 (‘+DATA/redo01.log‘) SIZE 52428800; SQL> ALTER DATABASE ADD LOGFILE GROUP 5 (‘+DATA/redo02.log‘) SIZE 52428800; SQL> ALTER DATABASE ADD LOGFILE GROUP 6 (‘+DATA/redo03.log‘) SIZE 52428800; SQL> alter system set log_file_name_convert=‘/home/oracle/app/oradata/orcl‘,‘+data‘ scope=spfile; SQL> shutdown immediate; SQL> startup mount; SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
按照上面方法搭建的dataguard，應用日誌 open read only後，alert中出現如下內容
Error 12154 received logging on to the standby FAL[client, MRP0]: Error 12154 connecting to host for fetching gap sequence
原因分析 這是由於備庫沒有設置 fal_client參數原因造成
解決方法 設置備庫的fal_client參數，例如本示例中 主庫db_unique_name orcl 備庫 db_unique_name orabak 那麽將備庫的fal_client設置為orabak即可 Alter system set fal_client=‘orabak‘ scope=both;
主備庫可用以下SQL檢測log sequence是否一致： SYS(125_15)@fpyjbak> select name,replace(database_role,‘ ‘,‘‘) as database_role,thread,seq from v$database,(select max(sequence#) seq,THREAD# thread from v$log_history group by THREAD#);
NAME DATABASE_ROLE THREAD SEQ --------- ---------------- ---------- ---------- FPYJ PHYSICALSTANDBY 1 100 |
- 驗證dataguard
驗證日誌是否從主庫傳輸過來，最後一個欄位為yes表示日誌已經傳輸過來
|
SYS(14_17)@fpyjbak> set linesize 1000 SYS(14_17)@fpyjbak> set pagesize 1000 SYS(14_17)@fpyjbak> col archived for a10 SYS(14_17)@fpyjbak> col status for 10
SQL> select resetlogs_id,thread#,sequence#,status,archived,applied from v$archived_log;
RESETLOGS_ID THREAD# SEQUENCE# S ARC APPLIED ------------ ---------- ---------- - --- --------- 927291116 1 109 A YES YES 927291116 1 110 A YES YES 927291116 1 111 A YES YES 927291116 1 112 A YES YES 927291116 1 113 A YES YES 927291116 1 114 A YES YES 927291116 1 115 A YES YES 927291116 1 116 A YES YES 927291116 1 117 A YES YES 927291116 1 118 A YES IN-MEMORY |
如果日誌傳輸失敗，請用以下命令查看主備庫日誌傳輸路徑是否valid的
|
set linesize 160 col dest_name for a20 col error for a50 SYS(14_17)@fpyjbak> SELECT RESETLOGS_ID,THREAD#,SEQUENCE#,STATUS,ARCHIVED,APPLIED FROM V$ARCHIVED_LOG;
RESETLOGS_ID THREAD# SEQUENCE# STATUS ARCHIVED APPLIED ------------ ---------- ---------- ---------- ---------- --------- 927291116 1 50 A YES YES |
如果status為其他，則查看是什麽原因導致無法歸檔到備庫，調整完後用以下命令重啟遠程歸檔進程
|
alter system set log_archive_dest_state_2 = ‘defer‘; alter system set log_archive_dest_state_2 = ‘enable‘; |
備庫查看lag 延時，正常所有lag應該接近0或者為0
|
SYS(14_17)@fpyjbak> col name for a30 SYS(14_17)@fpyjbak> col value for a30 SYS(14_17)@fpyjbak> col datum_time for a30 SYS(14_17)@fpyjbak> col TIME_COMPUTED for a20 SYS(14_17)@fpyjbak> set line 160 SYS(14_17)@fpyjbak> select name, value, datum_time, time_computed from v$dataguard_stats;
NAME VALUE DATUM_TIME TIME_COMPUTED ------------------------------ ------------------------------ ------------------------------ -------------------- transport lag 08/24/2017 13:58:32 apply lag 08/24/2017 13:58:32 apply finish time 08/24/2017 13:58:32 estimated startup time 10 08/24/2017 13:58:32 |
查看DataGuard message
|
SYS(14_17)@fpyjbak> set linesize 1000 SYS(14_17)@fpyjbak> set pagesize 1000 SYS(14_17)@fpyjbak> col time1 for a15 SYS(14_17)@fpyjbak> select to_char(timestamp,‘yyyy-mm-dd hh24:mi:ss‘) time1,message from v$dataguard_status order by time1 asc;
TIME1 MESSAGE ------------------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------2017-08-24 13:30:42 ARC0: Archival started 2017-08-24 13:30:42 ARC1: Archival started 2017-08-24 13:30:42 ARC2: Archival started 2017-08-24 13:30:42 ARC1: Becoming the ‘no FAL‘ ARCH 2017-08-24 13:30:42 ARC2: Becoming the heartbeat ARCH 2017-08-24 13:30:43 ARC3: Archival started 2017-08-24 13:32:22 Managed Standby Recovery not using Real Time Apply 2017-08-24 13:32:22 Media Recovery Complete 2017-08-24 13:37:12 Attempt to start background Managed Standby Recovery process 2017-08-24 13:37:12 MRP0: Background Managed Standby Recovery process started 2017-08-24 13:37:17 Managed Standby Recovery starting Real Time Apply 2017-08-24 13:37:17 Media Recovery Waiting for thread 1 sequence 51 |
查看日誌應用狀態
|
SYS(14_17)@fpyj123> select thread#,sequence#,applied from v$archived_log;
THREAD# SEQUENCE# APPLIED ---------- ---------- --------- 1 50 YES |
11g adg 環境搭建實施手冊-0824