每天日誌上T的環境用duplicate做DG的注意事項
前提條件
1、資料庫總量上5T
2、每天online redo總量上T,online redo的目錄1.1T
3、每天23:00增量備份,第二天凌晨2:00備份完成,備份指令碼對應歸檔日誌是PLUS ARCHIVELOG DELETE ALL INPUT
4、rman設定對於archivelog是CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY
5、使用duplicate target database for standby from active database
6、duplicate過程大概需要16小時
最重要的一個知識點
使用duplicate搭建DG,duplicate完成後, dg備庫需要同步的歸檔日誌起始於duplicate開始的那個時間點
歸檔日誌沒有刪除的情況下,每次PLUS ARCHIVELOG都會備份一次,即一個歸檔日誌可以被備份多次
考慮的問題1
因duplicate需要16小時,dg備庫需要同步的歸檔日誌起始於duplicate開始的那個時間點,所以duplicate完成後需要16小時前的歸檔日誌進行同步,24小時內會備份一次並清除已經備份的,duplicate時間16小於清理週期24,可以獲得這些歸檔日誌
考慮的問題2
假如14:00 開始做duplicate,晚上23:00開始執行備份,這樣14:00到23:00就是9小時,小於16小時,無法獲得16小時前的歸檔日誌了,DG就無法同步,是不是就做不了呢?不是的,因為主庫設定了CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY。
考慮的問題3
繼續上面問題2,因為備份於23:00開始,第二天2:00結束,那不就是日誌的保留時間在第二天的2:00到第三天的06:00,也就是保留時間超過28小時,這不就是超過了保留的極限24小時,容易把磁碟撐爆?不用擔心,可以在第二天晚上23:00執行備份後,因為主庫設定了CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON STANDBY導致歸檔日誌不會刪除,此時可以手工刪除14:00之前的歸檔日誌,保留14:00之後的就可以。
以上三個問題,得出結論
只要duplicate for standby from active database的時間長度小於日誌必須清理的時間週期即可,如上duplicate為16小時,日誌清理週期為24小時
實踐過程
1、第一天14:00開始執行duplicate,此刻主資料庫的歸檔日誌序列號為416005,此時歸檔日誌目錄空間為500G(因前一天23:00開始備份到下一天凌晨2:00備份完成,所以資料起始於第一天凌晨2:00至第一天14:00)
2、第二天凌晨2:00主庫備份完畢,此刻主資料庫的歸檔日誌序列號為419005,此時歸檔日誌目錄空間為900G(第一天凌晨2:00至第二天凌晨2:00的)
3、第二天凌晨2:05,順序執行如下,執行完後,此時歸檔日誌目錄空間為400G(第一天14:00至第二天凌晨2:00的)
RMAN> list backup of archivelog sequence between 416000 and 416005;
確保這些歸檔日誌都在備份裡面,都在備份裡面了的話,再執行下面
RMAN> delete force archivelog until SEQUENCE 416000;
4、第二天凌晨6:00,duplicate完成,此時歸檔日誌目錄空間為550G(第一天14:00至第二天6:00的),此時歸檔日誌起始於第一天14:00前幾分鐘的416001,啟用DG備庫應用日誌,備庫開始使用第一個歸檔日誌416005
5、第二天早上10:00,DG同步得差不多了,此時主資料庫的歸檔日誌目錄為700G(第一天14:00至第二天10:00的),此時再順序執行如下,執行後,歸檔日誌目錄空間為300G(第二天2:00至第二天10:00的)
RMAN> list backup of archivelog sequence between 419000 and 419005;
確保這些歸檔日誌都在備份裡面,都在備份裡面了的話,再執行下面
RMAN> delete force archivelog until SEQUENCE 419000;
其實在上面第1、2步之間,可以單獨執行一次歸檔日誌的備份,即14:30執行一次歸檔日誌備份,到15:30歸檔日誌備份結束後,再手工刪除13:30之前的歸檔日誌即可。當然13:00至14:00的歸檔日誌晚上23:00時還會再備份一次,備份兩次沒有關係。只要保證duplicate完成後DG需要的歸檔日誌沒有刪除即可,DG需要的歸檔日誌就是起始於duplicate開始時刻點即起始於14:00的歸檔日誌。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30126024/viewspace-2168405/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- DG-duplicate操作注意事項(各種報錯應對方法)
- 【DG】在Linux平臺上搭建單例項的dataguard--duplicateLinux單例
- 做SAP freelancer 的幾個注意事項
- DG:11.2.0.4 RAC線上duplicate恢復DG
- jmeter做分散式壓測時的注意事項JMeter分散式
- GO 中的 defer 有哪些注意事項?上Go
- 開發及上線中的注意事項
- Oracle使用*的注意事項Oracle
- 換工作的注意事項
- Laravel 專案上線的一些注意事項Laravel
- SQL 語句的注意事項SQL
- C++ queue的注意事項C++
- 整合環信IM SDK及使用注意事項
- php大檔案上傳注意事項PHP
- 使用ProForm的useRef()物件的注意事項ORM物件
- 每週的第一天日期
- @Lombok注意事項Lombok
- RandomAccessFile注意事項randomMac
- 畫PCB板時的注意事項
- 說點JSON使用的注意事項JSON
- 伺服器配置的注意事項伺服器
- 使用MyBatis的注意事項有哪些MyBatis
- 使用Vue.js的注意事項Vue.js
- 使用HTTP的三個注意事項HTTP
- Python匯入包的注意事項Python
- Python eval的用法及注意事項Python
- 刷題時需要的注意事項
- 異常-異常的注意事項
- 關於 interface{} 會有啥注意事項?上
- 直流負載箱的安全事項和注意事項有哪些?負載
- 低程式碼開發平臺選型的注意事項(上)
- 線上問診app開發的好處與注意事項APP
- DG環境下打補丁
- WPF新建viewModel例項化成員的注意事項View
- [爬坑日誌1]寫查詢的mysql一些小注意事項MySql
- Go 中修改切片副本的注意事項Go
- 資料網格的注意事項 - Kineret
- ip代理軟體的使用注意事項