Oracle RMAN備份為什麼會大量使用temp表空間？

導讀：Oracle Rman不備份temp表空間，為什麼會大量使用temp表空間呢？rman備份datafiles或archivelog files結束時需將rman jobs資訊寫入controfiles中，其中rman jobs的資訊是透過檢視v$rman_status查詢得知，正是v$rman_status查詢消耗了大量的temp表空間，並不是rman程式。透過mos查詢發現當FIXED objects的統計資訊不準確時，可能導致v$rman_status查詢消耗了大量的temp表空間。

1.備份報錯(以mos的case為例分析)

Finished Control File and SPFILE Autobackup at 22-MAR-20
ORA-00604: error occurred at recursive SQL level 1
ORA-01652: unable to extend temp segment by 64 in tablespace TEMP
RMAN-08132: warning: cannot update recovery area reclaimable file list
sql statement: alter system archive log current

2.原因分析：(以提問的形式來分析原因)

--2.1 報錯ORA-01652均在datafiles或archivelog files結束時
問：為什麼rman程式報錯ORA-01652均是在datafiles或archivelog files結束時呢？僅在結束時不會是一個巧合吧？我肯定不信。
答：rman備份datafiles或archivelog files結束時，
透過v$rman_status檢視來查詢rman jobs的progress and status資訊，並寫入controlfile中。
--2.2 v$rman_status導致大量temp space
問：查詢v$rman_status檢視為什麼會導致大量temp space呢？
答：v$rman_status這個檢視的資訊來源於FIXED objects，若FIXED objects的統計資訊不準確，
可能造成大量temp space(排序)或hangs(x$導致各種各樣的latches)

3.解決辦法：

--3.1 第一種情況
問:FIXED objects統計資訊不準確怎麼辦？
答：exec dbms_stats.gather_fixed_objects_stats;
#下面的解決rman備份繞過FIXED objects統計資訊不準確的問題
或者RMAN> sql "alter session set optimizer_mode=RULE"; 
--3.2 第二種情況
問:FIXED objects行資料過大怎麼辦？
答:重啟例項，減少FIXED objects行資料

4.理論依據

--4.1 fixed tables統計資訊不準確會導致performance degradation or hangs，或是導致大量使用TEMP。
Missing or bad statistics on the X$ / fixed tables that can lead to performance degradation or hangs. Various X$ views are protected by latches and as a result can be very expensive to query in large and busy systems.
RMAN, Data Guard, Streams, and Grid Control make heavy usage of the fixed tables through the DBA/V$ views and so can often encounter performance issues.
Another commonly seen symptom is extreme TEMP space usage driven by poor plans against the fixed tables.
參考：Queries from V$BACKUP_PIECE_DETAILS or V$RMAN_STATUS Return Error ORA-01652 (Doc ID 2119607.1)
--4.2 當fixed tables統計資訊不準確導致大量使用TEMP時，可重新收集統計資訊
原因：
SQL> select count(*) from v$rman_status ;
select count(*) from v$rman_status
*
ERROR at line 1:
ORA-01652: unable to extend temp segment by 640 in tablespace TEMP
V$RMAN_STATUS displays the finished and on-going RMAN jobs. For on-going jobs, this view displays progress and status. The jobs which are in progress are stored only in memory while the finished jobs are stored in the controlfile.
原理：
Incorrect statistics on FIXED objects
which resulted in an ineffective execution plan, needed much sort-space.
Multiple waitevents on 'direct path write temp'
解決辦法：
exec dbms_stats.gather_fixed_objects_stats;
If the above doesnot work you can explore Purging just the failing statement/Cursors using dbms_shared_pool.purge
How To Flush an Object Out The Library Cache [SGA] Using The DBMS_SHARED_POOL Package (Doc ID 457309.1)
參考：Rman uses a lot Of Temporary Segments ORA-1652: Unable To Extend Temp Segment (Doc ID 357765.1)
##注意：dbms_stats.gather_fixed_objects_stats這種方法僅僅是收集fixed統計資訊，不會減少fixed objects的行資料。因為fixed objects的行資料是隨著例項的執行逐步增加的，所以你可以採取重啟例項來減少fixed objects的行資料。
--4.3 當fixed tables統計資訊不準確導致大量使用TEMP時，不想收集統計資訊，可透過設定session級最佳化器繞過
問題：
Finished Control File and SPFILE Autobackup at 22-MAR-20
ORA-00604: error occurred at recursive SQL level 1
ORA-01652: unable to extend temp segment by 64 in tablespace TEMP
RMAN-08132: warning: cannot update recovery area reclaimable file list
sql statement: alter system archive log current
原因：
Setting optimizer_mode = ALL_ROWS can cause non-optimized usage Of Temp
解決辦法：
RMAN> sql "alter session set optimizer_mode=RULE";