半自動化搭建Data Guard的想法和實踐(二)
關於半自動化搭建Data Guard,自己花了一些時間,總算是把這件事情繼續推進了一下,還是再囉嗦一句,為什麼不自動化,因為安全。主庫就是主庫,任何變更都要手工檢查稽核,自動化的工作在備庫和中控端來完成。我希望自己的指令碼能夠只知道主庫的IP,不用一次又一次連過去配置和檢查,當然要完成自動化還是半自動化,有些網友也提醒的極是,那就是規範和標準。
預先條件:
1.目前的設計是基於11.2.0.4的版本,當然這個很容易定製,在此是作為一個基本的標準,作為環境的初始化和Data Guard對的搭建的基線。
2.預設主庫是開啟了DG Broker,即dg_broker_start=true,這個是DG Broker配置的必備要求,為什麼要這麼配置,因為這個工具確實很方便實用,強烈推薦。
3.資料庫主庫啟用了spfile,這個是DG Broker的一個基本要求,而且本身spfile也是提倡使用的。
而一套主庫環境和另外一臺未知的伺服器要搭建Data Guard環境,還是有很多的依賴條件。這些細節之處不檢查,後期的工作就無從開展,所以自己在寫指令碼的過程中越來越意識到這些的重要性,因為在後期的指令碼中驗證再詳細再完整,這些預先條件不滿足,最後還是無功而返,所以我們可以考慮一個統一的檢查指令碼來評估,可以就pass,失敗就failed.
大體列舉了一些檢查項,如下:
主備軟體版本一致
主庫IP確為主庫
主庫沒有其他的資料庫例項
備庫沒有其它的資料庫例項
主備庫的磁碟空間情況
主備庫的作業系統檢查
是否已存在其他備庫,已存在備庫是否為ADG,備庫的compatible
主備庫的CPU資源
主備庫的核心引數情況
主庫是否啟用spfile(需要判斷是否滿足DG Broker的要求)
主庫是否開啟DG Broker
主備ORACLE_HOME一致
主庫啟用歸檔模式
主庫DG Broker啟用
有些可能還需要進一步確認和整理,但是這個指令碼是搭建的基礎,這些條件可以設定一個閾值,比如主備庫的CPU資源,不能差太多,主庫64c,備庫8c這種是需要提前判斷出來的。主備庫的版本不同這些也是需要提前發現的。
而實現的指令碼需要配置一個檔案autodg.cnf
export db_name=statdb1
export pri_db_unique_name=statdb1
export pri_db_ip_addr=10.127.133.9
export std_db_unique_name=statdb2
export std_db_ip_addr=10.127.133.4
標示主備庫的資訊即可。
指令碼的執行效果如下,先實現了一部分功能,是中控端的操作,剩下的就是主庫端,備庫端了。
10.127.133.9
NAME DATABASE_ROLE OPEN_MODE
--------- ---------------- --------------------
STATDB1 PRIMARY READ WRITE
Databases:
statdb1 - Primary database
statdb3 - Physical standby database
NAME VALUE
------------------------------ --------------------------------------------------
db_file_name_convert
db_name statdb1
db_unique_name statdb1
dg_broker_start TRUE
local_listener statdb1
log_file_name_convert
standby_file_management AUTO
.
RAC LOG_MODE INST_ID INSTANCE_NA HOST_NAME VERSION STATUS STARTUP_TIME
----- ---------- ---------- ----------- --------------- --------------- -------- ---------------------
NO ARCHIVELOG 1 statdb1 statdb1.test.com 11.2.0.3.0 OPEN 07:06:10 23-DEC-13
,PRIMARY
.
ORACLE_HOME is:/U01/app/oracle/product/11.2.3/db_1
statdb1 - Primary database SCN:712764:CURRENT
.
statdb1 - Physical standby database
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
HOST = 10.127.133.9
PORT = 1521
SERVICE_NAME = statdb1
BACKUP ORACLE LEVEL CONF FILES ...DONE
.
Run below scripts to open firewall
./open_firewall.sh 10.127.133.9 1521 10.127.133.4
./open_firewall.sh 10.127.133.4 1521 10.127.133.9
這個過程會從主庫抓取配置檔案的資訊,然後在中控端做變更和補充,複製到備庫端。
指令碼的內容比較長,可能涉及若干個檔案,我近幾天提供一個下載的連結,感興趣可以下載試用。
預先條件:
1.目前的設計是基於11.2.0.4的版本,當然這個很容易定製,在此是作為一個基本的標準,作為環境的初始化和Data Guard對的搭建的基線。
2.預設主庫是開啟了DG Broker,即dg_broker_start=true,這個是DG Broker配置的必備要求,為什麼要這麼配置,因為這個工具確實很方便實用,強烈推薦。
3.資料庫主庫啟用了spfile,這個是DG Broker的一個基本要求,而且本身spfile也是提倡使用的。
而一套主庫環境和另外一臺未知的伺服器要搭建Data Guard環境,還是有很多的依賴條件。這些細節之處不檢查,後期的工作就無從開展,所以自己在寫指令碼的過程中越來越意識到這些的重要性,因為在後期的指令碼中驗證再詳細再完整,這些預先條件不滿足,最後還是無功而返,所以我們可以考慮一個統一的檢查指令碼來評估,可以就pass,失敗就failed.
大體列舉了一些檢查項,如下:
主備軟體版本一致
主庫IP確為主庫
主庫沒有其他的資料庫例項
備庫沒有其它的資料庫例項
主備庫的磁碟空間情況
主備庫的作業系統檢查
是否已存在其他備庫,已存在備庫是否為ADG,備庫的compatible
主備庫的CPU資源
主備庫的核心引數情況
主庫是否啟用spfile(需要判斷是否滿足DG Broker的要求)
主庫是否開啟DG Broker
主備ORACLE_HOME一致
主庫啟用歸檔模式
主庫DG Broker啟用
有些可能還需要進一步確認和整理,但是這個指令碼是搭建的基礎,這些條件可以設定一個閾值,比如主備庫的CPU資源,不能差太多,主庫64c,備庫8c這種是需要提前判斷出來的。主備庫的版本不同這些也是需要提前發現的。
而實現的指令碼需要配置一個檔案autodg.cnf
export db_name=statdb1
export pri_db_unique_name=statdb1
export pri_db_ip_addr=10.127.133.9
export std_db_unique_name=statdb2
export std_db_ip_addr=10.127.133.4
標示主備庫的資訊即可。
指令碼的執行效果如下,先實現了一部分功能,是中控端的操作,剩下的就是主庫端,備庫端了。
10.127.133.9
NAME DATABASE_ROLE OPEN_MODE
--------- ---------------- --------------------
STATDB1 PRIMARY READ WRITE
Databases:
statdb1 - Primary database
statdb3 - Physical standby database
NAME VALUE
------------------------------ --------------------------------------------------
db_file_name_convert
db_name statdb1
db_unique_name statdb1
dg_broker_start TRUE
local_listener statdb1
log_file_name_convert
standby_file_management AUTO
.
RAC LOG_MODE INST_ID INSTANCE_NA HOST_NAME VERSION STATUS STARTUP_TIME
----- ---------- ---------- ----------- --------------- --------------- -------- ---------------------
NO ARCHIVELOG 1 statdb1 statdb1.test.com 11.2.0.3.0 OPEN 07:06:10 23-DEC-13
,PRIMARY
.
ORACLE_HOME is:/U01/app/oracle/product/11.2.3/db_1
statdb1 - Primary database SCN:712764:CURRENT
.
statdb1 - Physical standby database
Intended State: APPLY-ON
Transport Lag: 0 seconds
Apply Lag: 0 seconds
HOST = 10.127.133.9
PORT = 1521
SERVICE_NAME = statdb1
BACKUP ORACLE LEVEL CONF FILES ...DONE
.
Run below scripts to open firewall
./open_firewall.sh 10.127.133.9 1521 10.127.133.4
./open_firewall.sh 10.127.133.4 1521 10.127.133.9
這個過程會從主庫抓取配置檔案的資訊,然後在中控端做變更和補充,複製到備庫端。
指令碼的內容比較長,可能涉及若干個檔案,我近幾天提供一個下載的連結,感興趣可以下載試用。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/23718752/viewspace-2122879/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 半自動化搭建Data Guard的想法和實踐(一)
- 半自動化搭建Data Guard的想法和實踐(四)
- 半自動化搭建Data Guard的想法和實踐(三)
- 容災半自動化的實現思路(二)
- Data Guard故障自動切換的想法(r11筆記第40天)筆記
- Data guard搭建
- Data Guard Broker系列之二:Data Guard Broker配置實戰
- 單機搭建Data Guard
- Data Guard實現故障自動切換(二)(r11筆記第39天)筆記
- DATA GUARD部署模式——DATA GUARD概念和管理模式
- 【DG】Data Guard搭建(physical standby)
- RedHat搭建物理Data GuardRedhat
- 搭建Active Data Guard環境
- 介紹ORACLE DATA GUARD——DATA GUARD概念和管理Oracle
- 容災半自動化的實現思路(一)
- [Data Guard]Oracle10g Data Guard學習筆記(二)Oracle筆記
- 容災技術Data Guard搭建
- Data Guard搭建困境突圍(一)
- Oracle RAC + Data Guard 環境搭建Oracle
- gulp 前端自動化實踐前端
- 半抄半寫的自動化-知識儲備
- 自動化測試的最佳實踐
- Oracle10g Data Guard (Standby) 理論與實踐Oracle
- 利用Python實現微信半自動化操作!Python
- Oracle 12c Data Guard搭建(一)Oracle
- 搭建邏輯Data Guard 12c
- 半自動化運維之動態新增資料檔案(二)運維
- API自動化測試實踐API
- Oracle Data Guard和Broker概述Oracle
- Oracle10g Data Guard (Standby) 理論與實踐 2Oracle
- Data guard 配置之搭建物理備庫
- 《QTP自動化測試實踐》要出第二版了!QT
- 介面自動化實戰之框架搭建框架
- 【ASK_ORACLE】Oracle Data Guard(二)物理備庫的概念和優勢Oracle
- Webpack自動化構建實踐指南Web
- fastlane 自動化打包工具實踐AST
- 自動化測試實踐總結
- 前端自動化混沌測試實踐前端