Oracle 11g Data Guard搭建過程中問題解決兩例

Oracle安裝配置過程中，是與作業系統、儲存、網路密切相關的。特別是在Linux、AIX環境中，配置過程相對複雜，一個環節錯誤可能就會引起後續一系列的問題故障。
 
此外，隨著Oracle版本的變化，相同安裝項目執行的步驟方法有很大變化。比如Data Guard，發展到11g有三種安裝方法，每種方法的配置都有所差異不同。我們很多朋友在安裝過程中，往往不在意版本差異，只是簡單從網路上搜尋一些文章就去實驗使用。網路資源的確豐富了我們解決問題的思路和廣度，但是網路中一些隻言片語、張冠李戴的說法做法，也的確會給我們造成麻煩。
 
本篇記錄了筆者安裝Data Guard過程中遇到的兩個小問題解決方案，記錄下來留待需要的朋友不時之需。

相關參考:

Oracle Data Guard 重要配置參數

基於同一主機配置 Oracle 11g Data Guard

探索Oracle之11g DataGuard

Oracle Data Guard （RAC+DG) 歸檔刪除策略及指令碼

Oracle Data Guard 的角色轉換

Oracle Data Guard的日誌FAL gap問題

Oracle 11g Data Guard Error 16143 Heartbeat failed to connect to standby 處理方法
 

1、環境背景介紹
 
 

使用Oracle 11.2.0.4進行實驗，項目是進行Active Data Guard搭建過程。由於環境條件所限，筆者實現在一台物理機上實現Primary和Standby。
 
 

SQL> select * from v$version;
 
BANNER
 
--------------------------------------------
 
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - Production
 
PL/SQL Release 11.2.0.4.0 - Production
 
CORE    11.2.0.4.0      Production
 
TNS for Linux: Version 11.2.0.4.0 - Production
 
NLSRTL Version 11.2.0.4.0 - Production
 
 

2、/dev/shm過小引起故障
 
 

其他配置過程和官方推薦安裝Active Dataguard方法相同。進行參數配置、密碼檔案建立、Oracle Net檔案配置和Standby端參數檔案建立後，使用RMAN進行duplicate過程，指令碼如下：
 
 

run {
 
  duplicat target database for standby from active database
 
  spfile

    parameter_value_convert 'ora11g','ora11gsy'
 
    set db_unique_name='ora11gsy'
 
    set log_archive_max_processes='5'
 
    set fal_client='ora11gsy'
 
    set fal_server='ora11g'
 
    set standby_file_management='AUTO'
 
    set log_archive_config='dg_config=(ora11g,ora11gsy)'
 
    set log_archive_dest_2='service=ora11g async valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=ora11g';
 
}
 
 

此時primary和standby執行個體都在啟動狀態，運行RMAN串連並執行指令碼。
 
 

[oracle@SimpleLinux dbs]$ rman nocatalog
 
 

Recovery Manager: Release 11.2.0.4.0 - Production on Thu Apr 10 11:21:49 2014
 
Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.
 
 

RMAN> connect target sys/oracle@ora11g
 
 

connected to target database: ORA11G (DBID=4239941846)
 
using target database control file instead of recovery catalog
 
 

RMAN> connect auxiliary sys/oracle@ora11gsy 
 
connected to auxiliary database: ORA11GSY (not mounted)
 
 

執行指令碼：
 
 

RMAN> @cr_phy_standby
 
 

RMAN> run {
 
2>  duplicate target database for standby from active database
 
3>  spfile

4>      parameter_value_convert 'ora11g','ora11gsy'
 
5>      set db_unique_name='ora11gsy'
 
（篇幅原因，有省略……）
 
sql statement: alter system set  log_archive_config =  ''dg_config=(ora11g,ora11gsy)'' comment= '''' scope=spfile
 
 

sql statement: alter system set  log_archive_dest_2 =  ''service=ora11g async valid_for=(ONLINE_LOGFILE,PRIMARY_ROLE) db_unique_name=ora11g'' comment= '''' scope=spfile
 
 

Oracle instance shut down
 
 

connected to auxiliary database (not started)
 
RMAN-00571: ===========================================================
 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
 
RMAN-00571: ===========================================================
 
RMAN-03002: failure of Duplicate Db command at 04/10/2014 11:51:19
 
RMAN-05501: aborting duplication of target database
 
RMAN-03015: error occurred in stored script Memory Script
 
RMAN-04014: startup failed: ORA-00845: MEMORY_TARGET not supported on this system
 
 

duplicate過程報錯，執行失敗。
 
從分析看，應該是Oracle運行和內部共用記憶體配置有關。Linux中的/dev/shm對應tmpfs，也就是臨時共用記憶體結構。當前大小為：
 
 

[root@SimpleLinux ~]# df -lh
 
Filesystem      Size  Used Avail Use% Mounted on
 
/dev/sda2        48G  13G  33G  28% /
 
tmpfs          448M  160M  288M  36% /dev/shm
 
 

當前系統中包括兩個執行個體對象，消耗的共用記憶體要超過一個實力的情況。所以需要調節增大這部分大小。
 
 

[root@SimpleLinux ~]# vi /etc/fstab

 

#
 
# /etc/fstab
 
# Created by anaconda on Wed Mar 12 08:33:33 2014
 
#
 
# Accessible filesystems, by reference, are maintained under '/dev/disk'
 
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
 
#
 
UUID=19248f54-250c-46a0-8e5d-ec26a6a08342 /                      ext4    defaults        1 1
 
UUID=5ce24d42-a713-4b6c-8d9b-0d780346e093 swap                    swap    defaults        0 0
 
tmpfs                  /dev/shm                tmpfs  defaults,size=2G    0 0
 
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
 
sysfs                  /sys                    sysfs  defaults        0 0
 
proc                    /proc                  proc    defaults        0 0
 
~
 
 

在儲存空間允許的情況下，調節tmpfs方法就是在fstab中增加size參數，直接指定大小。
 
 

[root@SimpleLinux ~]# mount /dev/shm
 
[root@SimpleLinux ~]# df -h
 
Filesystem      Size  Used Avail Use% Mounted on
 
/dev/sda2        48G  13G  33G  28% /
 
tmpfs          2.0G    0  2.0G  0% /dev/shm
 
 

再次執行指令碼，依然報錯，但是故障提示變化。
 
 

  startup clone nomount;
 
}
 
executing Memory Script
 
 

sql statement: alter system set  control_files =  ''/u01/app/oradata/ORA11G/controlfile/o1_mf_9mnjwpko_.ctl'', ''/u01/app/fast_recovery_area/ORA11G/controlfile/o1_mf_9mnjwpw2_.ctl'' comment= ''Set by RMAN'' scope=spfile
 
 

Starting backup at 10-APR-14
 
using channel ORA_DISK_1
 
channel ORA_DISK_1: starting datafile copy
 
copying standby control file
 
RMAN-00571: ===========================================================
 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
 
RMAN-00571: =========================================
 
RMAN-03002: failure of Duplicate Db command at 04/10/2014 12:18:19
 
RMAN-05501: aborting duplication of target database
 
RMAN-03015: error occurred in stored script Memory Script
 
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 04/10/2014 12:18:19
 
ORA-17628: Oracle error 19505 returned by remote Oracle server
 
 

RMAN> **end-of-file**

更多詳情見請繼續閱讀下一頁的精彩內容：

1 2 下一頁