今天的話題包括：
12.2中ADG的性能與診斷
ADG上部署列式存儲
DG跨平臺遷移
DG數據恢復
DG的歸檔管理
12.2中ADG的性能與診斷
在Oracle 12.2中，ADG有許多驚人的改進，通過ADG standby數據庫的性能數據收集和診斷、快照standby數據庫的應用，以及實時的數據庫操作監控的實現，能夠根據用戶需求相協調來提高DBA效率，從而為業務應用程序提供更好的服務質量。
遠程AWR
ADG standby數據庫的AWR快照稱為遠程快照。稱為目標的數據庫節點負責存儲從遠程ADG standby數據庫節點（稱為源）收集的快照。目標可以是ADG主數據庫或非ADG數據庫。如果目標是ADG主數據庫，則它也是源數據庫，其快照是本地快照。
可以使用AWR報告，Oracle數據庫導入和導出功能以及用戶定義的查詢來訪問存儲在目標上的快照數據或AWR數據。自動數據庫診斷監視器（ADDM）應用程序可以使用AWR數據來分析任何數據庫性能相關的問題。
支持SQL Tuning Advisor
允許DBA將primary數據庫工作負載的調優卸載到ADG standby數據庫，並在ADG 自身上調整ADG SQL工作負載。當將primary數據庫工作負載的SQL調整卸載到ADG standby數據庫時，SQL調整過程從primary數據庫啟動，但是調整過程在ADG standby數據庫上遠程執行，並且結果將寫回primary數據庫數據庫。調整ADG工作負載時，整個SQL調整過程在ADG standby數據庫上本地執行，同時保持數據庫為read-only狀態。這是通過從primary數據庫的DBlink接收集所需的信息並將任何數據庫狀態更改（例如SQL配置文件實現）寫回primary數據庫來實現的。在primary數據庫上實施的SQL配置文件建議將使用redo應用機制應用於ADG standby數據庫。
更多新特性請點擊：
Oracle 12.2新特性掌上手冊 - 第六卷 ADG的性能與診斷
ADG上部署列式存儲
我們命中註定要失去所愛之人，不然我們怎麼知道，他們在我們生命中有多重要？from《返老還童》
在Active Data Guard上部署列式存儲，可以選在在主庫、備庫或者兩者同時部署列式存儲。當在主備庫上同時部署了列式存儲的時候，可以在兩個庫上對相同或者不同的對象集做操作，如果是操作不同的對象集，那就相當於增加了In-Memory的存儲大小。
有三種配置方式：
在主備庫上部署同樣的In-Memory
只在standby 庫上部署列存儲
主庫IN-MEMORY和備庫IN-MEMORY存儲不同對象
第三種優點是可以在每個數據庫中運行不同的工作負載。 例如，HR應用程序在主數據庫中運行報告，而銷售歷史記錄應用程序在備用數據庫中運行報告。 因此，兩個數據庫都沒有承擔分析報告的全部負載。
在以上三種典型的配置中，將會創建三種服務：僅備用，僅主用、主用和備用三種服務。 例如，如果需要主實例中最近一個月的銷售事實表數據，而備用實例中存儲前一個月的銷售數據。 則需要在兩個實例中填充維度表。 對於每個銷售分區，可以使用INMEMORY ... DISTRIBUTE FOR SERVICE指定備用或主要服務。 對於每個維度表，指定包括主數據庫實例和備用數據庫實例的服務。
更多詳情點擊：
【12.2新特性】在Oracle Active Data Guard上部署列式存儲
跨平臺遷移
在Oracle數據庫之中，實現跨平臺遷移一直是一項較為複雜的任務。Oracle的DataGuard技術一直在進步，不僅僅作為容災，在數據遷移中也承擔了重要的使命。
自10g開始，Oracle的DG開始有限度的支持跨平臺的DataGuard環境搭建，從而簡化數據遷移的過程，現在從AIX遷移至Solaris Sparc平臺已經發布了成功的實施過程。
具體實現過程請點擊：
DataGuard對跨平臺數據遷移的支持
DG恢復
DG中主庫的歸檔日誌成功傳輸到備庫後，在本地備份失敗，並出現RMAN-06004，RMAN-20003報錯，如何應對請查看DG恢復遭遇RMAN-06004，RMAN-20003後
DG歸檔管理
在11g裡面，隨著ASM、RAC、Data Guard（包括Active Data Guard）的成熟，使用RAC+ASM+Data Guard越來越成為一種可靠的、維護簡單、穩定的高可用性和容災保護方案。這篇文章談談如何管理Oracle 11g Data Guard環境中的歸檔日誌。
歸檔日誌是重要的，備份恢復需要它，而Data Guard也需要它。在早期版本的Data Guard環境中，常常面臨著歸檔日誌管理問題,，但11g做了很多改進，使得我們使用和維護更加方便。
在Data Guard環境裡面，對歸檔日誌管理需要達到以下幾個方面的要求或者說是需求：
主庫使用快速恢復區(fast recovery area)，在RAC中，毫無疑問快速恢復區最好是置放在ASM上。
為快速恢復區指定合適的空間。首先我們需要預估一個合理的歸檔保留時間長。比如由於備份系統問題或Data Guard備庫問題、維護等，需要歸檔保留的時間長度。假設是24小時，再評估一下在歸檔量最大的24小時之內，會有多少量的歸檔？一般來說是在批量數據處理的時候歸檔量最大，假設這24小時之內歸檔最大為200G。注意對於RAC來說是所有節點在這24小時的歸檔量之和。最後為快速恢復區指定需要的空間量，比通過參數db_recovery_file_dest_size指定快速恢復區的大小。這裡同樣假設快速恢復區們存放歸檔日誌。
在備庫上指定快速恢復區以及為快速恢復區指定合適的大小，主要原因：切換成為主庫後歸檔日誌容量；如果主庫歸檔容量壓力大，備庫能否存儲更多的歸檔日誌以便可以通過備庫來備份歸檔日誌。
對主庫和備份使用RMAN配置歸檔刪除策略：CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
相關推薦
