作者：dbdream 發布：2016-03-28 18:14 分類：
Oracle,
oracle 10g,
oracle 11g
搶沙發
本文主要分享一對多(一主多備)的DG環境主備切換的案例，我們的一套生產環境，一主四備，其中3個備庫承載着查詢業務，還有一個DG沒有任務業務，由於主庫的存儲性能不給力，公司采購了新的存儲，這個DG就是為了切換到新存儲而搭建的，數據量1.5TB。
本文是在測試環境操作，之前並沒有切換過一對多的DG環境，而且網上基本沒有關於一對多DG環境切換的資料，官方文檔也只是說自己選擇切換到哪個DG，也沒有詳細的介紹和案例。本文測試環境為一主兩備，版本為11.2.0.4.0。
以下是主庫的幾個主要參數的配置信息：
02 |
------------------------------------ ----------- ------------------------------ |
05 |
log_archive_config string dg_config=(orac2,orastd1,orastd2) |
06 |
log_archive_dest_1 string location=/u01/app/oracle/orada |
07 |
ta/arch valid_for=(all_logfile |
08 |
s,all_roles) db_unique_name=or |
10 |
log_archive_dest_2 string service=orastd1 lgwr async val |
11 |
id_for=(online_logfiles,primar |
12 |
y_role) db_unique_name=orastd1 |
13 |
log_archive_dest_3 string service=orastd2 lgwr async val |
14 |
id_for=(online_logfiles,primar |
15 |
y_role) db_unique_name=orastd2 |
以下是ORASTD1備庫的主要參數設置：
02 |
------------------------------------ ----------- ------------------------------ |
03 |
log_archive_config string dg_config=(orac2,orastd1) |
04 |
og_archive_dest_1 string location=/u01/app/oracle/orada |
05 |
ta/arch valid_for=(all_logfile |
06 |
s,all_roles) db_unique_name=or |
08 |
og_archive_dest_2 string service=orac2 lgwr async valid |
09 |
_for=(online_logfiles,primary_ |
10 |
role) db_unique_name=orac2 |
11 |
fal_client string ORASTD1 |
12 |
fal_server string ORAC2 |
以下是ORASTD2備庫的主要參數設置：
02 |
------------------------------------ ----------- ------------------------------ |
03 |
fal_client string ORASTD2 |
04 |
fal_server string ORAC2 |
05 |
log_archive_config string dg_config=(orac2,orastd2) |
06 |
log_archive_dest_1 string location=/u01/app/oracle/orada |
07 |
ta/arch valid_for=(all_logfile |
08 |
s,all_roles) db_unique_name=or |
10 |
log_archive_dest_2 string service=orac2 lgwr async valid |
11 |
_for=(online_logfiles,primary_ |
12 |
role) db_unique_name=orac2 |
在DG切換之前，一定要檢查當前環境是否可以切換，我在做這個測試的時候，因為是剛剛搭建的測試環境，而且搭建時已經測試，所以在切換之前沒有檢查。我之前就做過類似的案例，差點死的很慘，這里簡單說一嘴，那是航天系統的一套數據庫，當時負責人找我去做切換測試，他們的DBA已經離職，離職前寫了一個切換方案，我到客戶機房的時候，客戶給我看了下那個方案，很簡單的方案，只有切換的命令，並沒有檢查的相關信息，我看完方案后，直接提出方案不完成，切換之前需要檢查，因為我是第一次接觸這個數據庫，操作之前必須仔細檢查，萬一掉坑里怎么辦？我在檢查時發現，備庫和主庫之間差了半年多的延遲，而且備庫並沒有接收到這半年來的歸檔，檢查發現，備庫在半年之前，主機重啟，並沒人起備庫的監聽和數據庫，導致主庫的日志傳不到備庫，經檢查發現備庫少了將近三千多個歸檔，短時間很難追得上，還好那個數據庫只有20個GB，我直接選擇重新搭建備庫了，然后順利的進行了主備切換。
在切換時，在主庫上是不可以選擇我要切換到哪個備庫的，這個選擇是在備庫上選擇的，下面進行SWITCHOVER切換。
主庫(ORAC2)：
1 |
SQL> alter database commit to switchover to physical standby with session shutdown; |
切換后，這個數據庫已經備關閉，啟動數據庫，這個數據庫已經變為備庫，啟動MRP進程。
02 |
ORACLE instance started. |
04 |
Total System Global Area 835104768 bytes |
05 |
Fixed Size 2257840 bytes |
06 |
Variable Size 528485456 bytes |
07 |
Database Buffers 301989888 bytes |
08 |
Redo Buffers 2371584 bytes |
12 |
SQL> alter database recover managed standby database using current logfile disconnect from session; |
16 |
SQL> select open_mode from v$database; |
22 |
SQL> select database_role,switchover_status from v$database; |
24 |
DATABASE_ROLE SWITCHOVER_STATUS |
25 |
---------------- -------------------- |
26 |
PHYSICAL STANDBY TO PRIMARY |
將ORAC2數據庫的FAL修為為ORASTD1。
1 |
SQL> alter system set fal_server=ORASTD1; |
主庫切換后，兩個備庫均變為TO PRIMARY狀態，這時就要選擇切換哪個備庫為主庫了。
1 |
SQL> select database_role,switchover_status from v$database; |
3 |
DATABASE_ROLE SWITCHOVER_STATUS |
4 |
---------------- -------------------- |
5 |
PHYSICAL STANDBY TO PRIMARY |
這里選擇ORASTD1這個備庫切換為主庫。
ORASTD1：
1 |
SQL> alter database commit to switchover to primary; |
切換后數據庫變為MOUNT狀態，打開數據庫。
01 |
SQL> select open_mode from v$database; |
07 |
SQL> alter database open; |
11 |
SQL> select database_role,switchover_status from v$database; |
13 |
DATABASE_ROLE SWITCHOVER_STATUS |
14 |
---------------- -------------------- |
因為之前ORASTD1這個備庫的log_archive_config參數並沒有添加ORASTD2這個備庫，現在變成了主庫，需要添加上所有的數據庫。
1 |
SQL> alter system set log_archive_config='dg_config=(orac2,orastd1,orastd2)'; |
切換日志發現，日志並沒有傳到備庫(ORAC2)。
1 |
SQL> alter system switch logfile; |
修改相關的log_archive_dest_state參數，日志可以成功發送到備庫(ORAC2)，備庫(ORAC2)也可以正常應用，備庫(ORAC2)開始和主庫(ORASTD1)同步數據。
1 |
SQL> alter system set log_archive_dest_state_2=enable; |
因為ORASTD2這個數據庫之前的主是ORAC2，現在已經變成了備庫，需要把ORASTD2的主改成ORASTD1。因為ORASTD1並沒有配ORASTD2的參數，需要把ORASTD2添加進來。
1 |
SQL> ALTER SYSTEM SET log_archive_dest_3='service=orastd2 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=orastd2'; |
將當前主庫添加了歸檔到ORASTD2后，還需要將ORASTD2的遠程歸檔信息改為ORASTD1。
ORASTD2:
1 |
SQL> ALTER SYSTEM SET log_archive_dest_2='service=orastd1 lgwr async valid_for=(online_logfiles,primary_role) db_unique_name=orastd1'; |
ORASTD2的FAL信息從ORAC2修改為ORASTD1。
1 |
SQL> alter system set fal_server=ORASTD1; |
此時整個DG切換就已經完成，ORASTD2數據庫無需做其他操作，MRP進程也不需要重新啟動，此時主庫(ORASTD1)切換日志，會成功發送到所有的備庫(ORAC2，ORASTD2)，兩個備庫會直接應用。
ORAC2：
01 |
Completed: alter database recover managed standby database using current logfile disconnect from session |
02 |
Clearing online redo logfile 3 complete |
03 |
Media Recovery Waiting for thread 1 sequence 31 |
05 |
Mon Jan 25 17:49:54 2016 |
06 |
Using STANDBY_ARCHIVE_DEST parameter default value as /u01/app/oracle/oradata/arch |
07 |
RFS[1]: Assigned to RFS process 17703 |
08 |
RFS[1]: Opened log for thread 1 sequence 32 dbid 1800997619 branch 901820147 |
09 |
Archived Log entry 24 added for thread 1 sequence 32 rlc 901820147 ID 0x6b5ca155 dest 2: |
10 |
RFS[1]: Opened log for thread 1 sequence 33 dbid 1800997619 branch 901820147 |
11 |
Archived Log entry 25 added for thread 1 sequence 33 rlc 901820147 ID 0x6b5ca155 dest 2: |
12 |
Mon Jan 25 17:49:54 2016 |
13 |
RFS[2]: Assigned to RFS process 17705 |
14 |
RFS[2]: Opened log for thread 1 sequence 31 dbid 1800997619 branch 901820147 |
15 |
RFS[1]: Opened log for thread 1 sequence 34 dbid 1800997619 branch 901820147 |
16 |
Archived Log entry 26 added for thread 1 sequence 34 rlc 901820147 ID 0x6b5ca155 dest 2: |
17 |
Archived Log entry 27 added for thread 1 sequence 31 rlc 901820147 ID 0x6b5ca155 dest 2: |
18 |
RFS[2]: Selected log 10 for thread 1 sequence 35 dbid 1800997619 branch 901820147 |
19 |
Mon Jan 25 17:49:54 2016 |
20 |
Archived Log entry 28 added for thread 1 sequence 35 ID 0x6b5ca155 dest 1: |
21 |
Mon Jan 25 17:49:55 2016 |
22 |
Primary database is in MAXIMUM PERFORMANCE mode |
23 |
RFS[3]: Assigned to RFS process 17707 |
24 |
RFS[3]: Selected log 10 for thread 1 sequence 36 dbid 1800997619 branch 901820147 |
25 |
Mon Jan 25 17:49:55 2016 |
26 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_31_901820147.dbf |
27 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_32_901820147.dbf |
28 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_33_901820147.dbf |
29 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_34_901820147.dbf |
30 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_35_901820147.dbf |
31 |
Media Recovery Waiting for thread 1 sequence 36 (in transit) |
32 |
Recovery of Online Redo Log: Thread 1 Group 10 Seq 36 Reading mem 0 |
34 |
Mon Jan 25 17:50:19 2016 |
35 |
Expanded controlfile section 11 from 28 to 280 records |
36 |
Requested to grow by 252 records; added 9 blocks of records |
37 |
Archived Log entry 29 added for thread 1 sequence 36 ID 0x6b5ca155 dest 1: |
38 |
Mon Jan 25 17:50:19 2016 |
39 |
Primary database is in MAXIMUM PERFORMANCE mode |
40 |
Mon Jan 25 17:50:19 2016 |
41 |
Media Recovery Waiting for thread 1 sequence 37 |
42 |
RFS[4]: Assigned to RFS process 17713 |
43 |
RFS[4]: Selected log 10 for thread 1 sequence 37 dbid 1800997619 branch 901820147 |
44 |
Recovery of Online Redo Log: Thread 1 Group 10 Seq 37 Reading mem 0 |
46 |
Mon Jan 25 17:51:03 2016 |
47 |
ALTER SYSTEM SET log_archive_dest_state_3='ENABLE' SCOPE=BOTH; |
48 |
Mon Jan 25 17:53:46 2016 |
49 |
Archived Log entry 30 added for thread 1 sequence 37 ID 0x6b5ca155 dest 1: |
50 |
Mon Jan 25 17:53:46 2016 |
51 |
RFS[4]: Selected log 10 for thread 1 sequence 38 dbid 1800997619 branch 901820147 |
52 |
Mon Jan 25 17:53:46 2016 |
53 |
Media Recovery Waiting for thread 1 sequence 38 (in transit) |
54 |
Recovery of Online Redo Log: Thread 1 Group 10 Seq 38 Reading mem 0 |
56 |
RFS[4]: Selected log 11 for thread 1 sequence 39 dbid 1800997619 branch 901820147 |
57 |
Mon Jan 25 17:53:49 2016 |
58 |
Archived Log entry 31 added for thread 1 sequence 38 ID 0x6b5ca155 dest 1: |
59 |
Media Recovery Waiting for thread 1 sequence 39 (in transit) |
60 |
Recovery of Online Redo Log: Thread 1 Group 11 Seq 39 Reading mem 0 |
ORASTD2:
01 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_31_901820147.dbf |
02 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_32_901820147.dbf |
03 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_33_901820147.dbf |
04 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_34_901820147.dbf |
05 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_35_901820147.dbf |
06 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_36_901820147.dbf |
07 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_37_901820147.dbf |
08 |
Media Recovery Waiting for thread 1 sequence 38 |
09 |
RFS[6]: Opened log for thread 1 sequence 38 dbid 1800997619 branch 901820147 |
10 |
Archived Log entry 14 added for thread 1 sequence 38 rlc 901820147 ID 0x6b5ca155 dest 3: |
11 |
Mon Jan 25 23:30:17 2016 |
12 |
Primary database is in MAXIMUM PERFORMANCE mode |
13 |
RFS[8]: Assigned to RFS process 14397 |
14 |
RFS[8]: No standby redo logfiles created for thread 1 |
15 |
RFS[8]: Opened log for thread 1 sequence 39 dbid 1800997619 branch 901820147 |
16 |
Media Recovery Log /u01/app/oracle/oradata/arch/1_38_901820147.dbf |
17 |
Media Recovery Waiting for thread 1 sequence 39 (in transit) |
有些參數可以提前設置好，這樣可以減少切換的時間，比如，選擇切換ORASTD1數據庫，那么可以先停掉ORASTD2數據庫，並修改相關的參數，從ORAC2切換到ORASTD1后，直接起ORASTD2就可以了。
