Oracle程序員面試分類模擬20簡答題1.

什么是高水位?如何回收表的高水位?正確答案：Oracle數(shù)據(jù)庫通過跟蹤段中的塊狀態(tài)來管理空間。高水位標記(HighWarterMark，HWM)是（江南博哥）段中的一個點，超過該點的數(shù)據(jù)塊是未格式化和未使用過的。HWM的信息儲存在段頭(SegmentHeader，第一個區(qū)的第一個塊就稱為段頭)，在段空間是手動管理方式時(MSSM)，Oracle是通過Freelist(一個單向鏈表)來管理段內(nèi)的空間分配，此時只有HWM的說法；在段空間是自動管理方式(ASSM)時，Oracle是通過BITMAP來管理段內(nèi)的空間分配，此時Oracle引入了LHWM。(LowHWM，低高水位)的概念。在MSSM中，當數(shù)據(jù)插入以后，如果是插入到新的數(shù)據(jù)塊中，那么數(shù)據(jù)塊就會被自動格式化等待數(shù)據(jù)訪問；而在ASSM中，數(shù)據(jù)插入到新的數(shù)據(jù)塊以后，數(shù)據(jù)塊并沒有被格式化，而是在第一次訪問這個數(shù)據(jù)塊的時候才格式化這個塊。所以此時又需要一條水位線，用來標示已經(jīng)被格式化的塊，這條水位線就稱為LHWM。LHWM之下的所有塊都是已格式化的，要么包含數(shù)據(jù)或以前曾包含數(shù)據(jù)。一般來說，LHWM肯定是低于等于HWM的。在一個ASSM段中的每個數(shù)據(jù)塊處于以下狀態(tài)之一：

1)在HWM之上，這些塊是未分配、未格式化的，且從未使用過。

2)在HWM之下，這些塊處于以下狀態(tài)之一：

①已分配，但當前未格式化且未使用。

②已分配、已格式化且包含數(shù)據(jù)。

③已分配、已格式化且為空，因為數(shù)據(jù)已被刪除。

LHWM在全表掃描中非常重要。因為HWM之下的塊只在被使用時才格式化，所以可能還有一些塊是未被格式化的。因此，數(shù)據(jù)庫讀取位圖塊，以獲取LHWM的位置。數(shù)據(jù)庫讀取LHWM之下的所有塊，因為它們是已格式化的，然后僅仔細讀取位于LHWM和HWM之間的已格式化塊，避開未格式化的塊。所以，Oracle對表進行全表掃描時是掃描了HWM下的所有格式化了的塊。當HWM與LHWM之間的塊填滿時，HWM向右推進，而LHWM相應推進到舊的HWM的位置。數(shù)據(jù)庫不斷插入數(shù)據(jù)，隨著時間的推移，HWM繼續(xù)向右推進，而LHWM總尾隨其后。除非DBA手動重建、截斷或縮小該對象，否則HWM從不倒退。

當使用DELETE刪除表記錄時，HWM并不會下降，隨之導致的是全表掃描的實際開銷并沒有任何減少。例如，首先新建一張空表，大小占用64K，然后插入數(shù)據(jù)直到表大小變?yōu)?0G，此時使用DELETE刪除所有的數(shù)據(jù)并且提交，這個時候查詢表的大小的時候依然是50G，這就是因為表的高水位沒有釋放的緣故，而在這時如果使用“SELECT*FROMTABLE_NAME;”語句來查詢數(shù)據(jù)的話，那么查詢過程就會很慢，因為Oracle要執(zhí)行全表掃描，從HWM下所有的格式化了的塊都得去掃描，直到50G的所有塊全部掃描完畢。曾遇到一個同事使用DELETE刪除了一個很大的分區(qū)表，然后執(zhí)行SELECT查詢很久都沒有結(jié)果，以為是數(shù)據(jù)庫暫停運行了，其實這個問題是由于高水位的緣故。所以，表執(zhí)行了TRUNCATE操作，再次SELECT的時候就可以很快返回結(jié)果了。

當用直接路徑插入行時[例如，通過直接加載插入(用APPEND提示插入)或通過SQL*Loader直接路徑1，數(shù)據(jù)塊直接置于HWM之上，HWM下面的空間就浪費掉了。

釋放表的高水位通常有如下幾種辦法：

1)對表進行MOVE操作：ALTERTABLETABLE_NAMEMOVE;。若表上存在索引，則記得重建索引。

2)對表進行SHRINKSPACE操作：ALTERTABLETABLE_NAMESHRINKSPACE;。注意，在執(zhí)行該指令之前必須開啟行移動：ALTERTABLETABLE_NAMEENABLEROWMOVEMENT;。該方法的優(yōu)點是：在碎片整理結(jié)束后，表上相關(guān)的索引仍然有效，缺點是會產(chǎn)生大量的Undo和Redo。

3)復制要保留的數(shù)據(jù)到臨時表T，DROP原表，然后RENAME臨時表T為原表。

4)exp/imp或expdp/impdp重構(gòu)表。

5)若表中沒有數(shù)據(jù)則直接使用TRUNCATE來釋放高水位。

如何找出系統(tǒng)中哪些表擁有高水位呢?這里給出兩種辦法，①比較表的行數(shù)和表的大小關(guān)系。如果行數(shù)為0，而表的當前占用大小減去初始化時的大小(INITIAL_EXTENT)后依然很大，那么說明該表有高水位。②行數(shù)和塊數(shù)的比率，即查看一個塊可以存儲多少行數(shù)據(jù)。如果一個塊存儲的行數(shù)少于5行甚至更少，那么說明有高水位。注意，這兩種方法都不是十分準確，需要再對查詢結(jié)果進行篩選。另外，在查詢表的高水位時，首先需要分析表，以得到最準確的統(tǒng)計信息。

2.

若臨時表空間使用率過高有什么調(diào)優(yōu)思路?正確答案：臨時表空間是Oracle數(shù)據(jù)庫的重要組成部分，尤其是對于大型的頻繁操作，如創(chuàng)建索引、排序等都需要在臨時表空間完成來減少內(nèi)存的開銷。當然對于查詢性能要求較高的操作應盡可能地避免在磁盤上完成這些操作。

當SQL語句中使用了諸如ORDERBY、GROUPBY子句時，Oracle服務器就需要對所選取的數(shù)據(jù)進行排序，這時如果排序的數(shù)據(jù)量很大，那么內(nèi)存的排序區(qū)(在PGA中)就可能裝不下，所以，Oracle服務器就需要把一些中間的排序結(jié)果寫到磁盤上，即臨時表空間中。當用戶的SQL語句中經(jīng)常有大規(guī)模的多重排序而內(nèi)存的排序區(qū)不夠時，使用臨時表空間就可以改進數(shù)據(jù)庫的效率。

臨時表空間可以被多個用戶共享，它不能包含任何永久對象。臨時表空間中的排序段是在實例啟動后當有第一個排序操作時創(chuàng)建的，排序段在需要時可以通過分配EXTENTS來擴展并一直可以擴展到大于或等于在該實例上所運行的所有排序活動的總和。

若臨時表空間占用過大，首先，要去檢查是什么會話占用了臨時表空間，具體占用了多少，臨時段的具體類型是什么。通過查詢視圖GV$SORT_USAGE(GV$SORT_USAGE和GV$TEMPSEG_USAGE查詢的結(jié)果是一致的)和GV$SESSION可以獲取到臨時表空間的占用情況和臨時段的類型等信息。視圖GV$SORT_USAGE中的SEGTYPE列的不同的值所代表的含義如下：

1)SORT：SQL排序使用的臨時段，包括ORDERBY、GROUPBY、DISTINCT、窗口函數(shù)(WINDOWFUNCTION，如ROLLUP)、合并查詢(UNION、INTERSECT、MINUS)、索引的創(chuàng)建(CREATE)和重建(REBUILD)、ANALYZE分析表等產(chǎn)生的排序。

2)DATA：臨時表(GLOBALTEMPORARYTABLE)存儲數(shù)據(jù)使用的段。

3)INDEX：臨時表上建的索引使用的段。

4)HASH：HASH算法，如HASH連接所使用的臨時段。

5)LOB_DATA和LOB_INDEX：臨時LOB使用的臨時段。

根據(jù)上述的段類型，說明TEMP表空間大體可以分為4類占用：①SQL語句排序。②HashJoin占用。③臨時表、臨時表上的索引占用。④LOB對象占用。

在找到了哪些會話占用臨時表空間過大后，分析這些會話，確保會話異常或SQL異常后，接著就可以將這些會話清理掉，如下：

最后，可以執(zhí)行臨時表空間的回收操作：

另外，還可以使用診斷事件來清理臨時段。首先，確定TEMP表空間的TS#，如下：

然后，設(shè)置診斷事件來執(zhí)行清理操作：

其中，LEVEL后的值為TS#+1。在以上例子中，TEMP表空間的TS#為3，所以TS#+1=4。如果想清除所有表空間的臨時段，那么TS#設(shè)置為2147483647。

3.

什么是SQL實時監(jiān)控?正確答案：在Oracle11g中，V$SESSION視圖增加了一些新的字段，這其中包括SQL_EXEC_START和SQL_EXEC_ID，這兩個字段實際上代表了Oracle11g的一個新特性：實時的SQL監(jiān)控(RealTimeSQLMonitoring)。

在Oracle11g中，當SQL并行執(zhí)行時，會立即被實時監(jiān)控到，或者當SQL單進程運行時，若消耗超過5s的CPU或I/O時間，則它也會被監(jiān)控到。另外，若使用/*+monitor*/提示的SQL語句，則也會被強制監(jiān)控到。若使用/*+no_monitor*/提示的SQL語句則不會被監(jiān)控到。監(jiān)控數(shù)據(jù)被記錄在V$SQL_MONITOR視圖中，當然也可以通過Oracle11g新增的包DBMS_MONITOR來主動對SQL執(zhí)行監(jiān)控部署。

V$SQL_MONITOR這個視圖還記錄了SQL的CPU_TIME以及BUFFER_GETS等重要信息，對于診斷SQL性能問題具有極大的幫助。結(jié)合V$SQL_MONITOR視圖與V$SQL_PLAN_MONITOR視圖可以進一步查詢SQL的執(zhí)行計劃等信息。聯(lián)合一些其他視圖，如V$ACTIVE_SESSION_HISTORY、V$SESSION、V$SESSION_LONGOPS、V$SQL、V$SQL_PLAN等，可以獲得關(guān)于SQL的更多信息。

V$SQL_MONITOR收集的信息每秒刷新一次，接近實時。當SQL執(zhí)行完畢，信息并不會立即從V$SQL_MONITOR中刪除，至少會保留1min。V$SQL_PLAN_MONITOR視圖中的執(zhí)行計劃信息也是每秒更新一次，當SQL執(zhí)行完畢，它們同樣至少被保留1min。

實時SQL監(jiān)控需要STATISTICS_LEVEL初始化參數(shù)設(shè)置為TYPICAL或ALL。同時CONTROL_MANAGEMENT_PACK_ACCESS參數(shù)必須是DIAGNOSTIC+TUNING(默認設(shè)置)。

可以使用如下的SQL獲取文本格式的SQL報告：

在有外網(wǎng)的情況下，可以通過如下的腳本獲取HTML格式的報告：

實時SQL監(jiān)視通過HTML查看其峪視報告時，具有更好的圖形化的展示效果，它是基于Flash的基礎(chǔ)進行展現(xiàn)，動態(tài)、圖形畫，讓SQL的執(zhí)行過程直觀地展示出來。如果監(jiān)視的SQL語句發(fā)現(xiàn)具有全表掃描等執(zhí)行計劃的特征，或者CPU時間和I/O時間比較長，那么可以與SQL調(diào)優(yōu)顧問接合起來，不但能獲知性能瓶頸，而且能獲得Oracle推薦的優(yōu)化策略。

4.

如何查找邏輯讀、物理讀、執(zhí)行次數(shù)和解析次數(shù)最多以及執(zhí)行時間最長的SQL語句呢?如何查找或監(jiān)控效率低下的SQL語句?正確答案：效率低下的SQL一般是執(zhí)行時間較長的SQL語句，可以通過如下幾種方式來監(jiān)控分析：

1)當前系統(tǒng)的SQL可以通過監(jiān)控V$SQL_MONITOR、V$SESSION視圖來實現(xiàn)，記錄執(zhí)行時間較長的SQL語句。對于歷史SQL可以通過分析DBA_HIST_SQLSTAT視圖。

2)分析現(xiàn)有的系統(tǒng)中的執(zhí)行計劃，重點檢查驅(qū)動表與被驅(qū)動表順序、表連接算法、排序是否有索引、索引使用。

3)分析AWR、ASH和ADDM。

4)通過OEM中性能監(jiān)控的捕獲執(zhí)行時間5s以上的SQL程序。

5)通過GV$SQLAREA視圖來分析。

5.

如何查找最近1min內(nèi)，最消耗CPU的SQL語句及會話信息?正確答案：最消耗CPU的SQL語句可以根據(jù)V$ACTIVE_SESSION_HISTORY視圖來獲取，取“SESSION_STATE='ONCPU'”，若查詢最消耗I/O的SQL語句則可以取“WAIT_CLASS='USERI/O'”。

6.

V$SESSION_LONGOPS視圖的作用是什么?正確答案：在Oracle11g之前的版本，長時間運行的SQL可以通過監(jiān)控V$SESSION_LONGOPS來觀察，當某個操作執(zhí)行時間超過6s時，就會被記錄在V$SESSION_LONGOPS中，通?？梢员O(jiān)控到全表掃描、全索引掃描、哈希連接、并行查詢等操作。

7.

如何有效地刪除一個大表(即表的EXTENT數(shù)很多)?正確答案：一個有很多EXTENT(100k+)的表，如果只是簡單地用DROPTABLE的話，那么會大量消耗CPU(在DMT管理下，Oracle要對FET$、UET$數(shù)據(jù)字典進行操作)，可能會用上幾天的時間，較好的方法是分多次刪除EXTENT，以減輕這種消耗：

8.

什么是熱塊?正確答案：當一個會話需要訪問一個數(shù)據(jù)塊，而這個數(shù)據(jù)塊正在被另一個用戶從磁盤讀取到內(nèi)存中或者這個數(shù)據(jù)塊正在被另一個會話修改時，當前的會話就需要等待，就會產(chǎn)生一個bufferbusywaits等待，也伴隨著Latch爭用。如果太多的會話去訪問相同的數(shù)據(jù)塊，那么會導致長時間的bufferbusywaits等待，通常表現(xiàn)形式為CPU使用率很高，但吞吐量很低。造成熱塊的原因可能是數(shù)據(jù)庫設(shè)置或者重復執(zhí)行的SQL語句頻繁訪問一些相同的數(shù)據(jù)塊。熱塊產(chǎn)生的原因不盡相同，按照數(shù)據(jù)塊的類型，可以分成表數(shù)據(jù)塊、索引數(shù)據(jù)塊、索引根數(shù)據(jù)塊、文件頭數(shù)據(jù)塊和數(shù)據(jù)塊自身的爭用，不同熱塊類型處理的方式是不同的。下面給出找到熱塊的SQL語句：

9.

數(shù)據(jù)庫運行很慢，如何解決?正確答案：導致數(shù)據(jù)庫運行很慢的原因非常多，例如可能是開發(fā)人員SQL語句寫的不好導致執(zhí)行性能比較差。所以，碰到這類問題，不能給出一個非常精確的答案，但是可以按照如下的步驟去檢測排除：

1)top或topas查看系統(tǒng)的CPU利用率是否正常，找到最耗費資源的Oracle進程，然后進入數(shù)據(jù)庫查詢相關(guān)的會話，找到SQL語句再進行具體分析。如果CPU正常，那么就很可能是由于開發(fā)人員寫的SQL語句不好，導致SQL執(zhí)行時間過長，因此，開發(fā)人員誤認為是數(shù)據(jù)庫運行緩慢。

2)進入數(shù)據(jù)庫查看等待事件是否正常，SQL語句如下：

例如，結(jié)果如下：

那么，在這里就應該著重解決logfilesync這個等待事件。

10.

什么是ORA-01555錯誤?正確答案：(1)Undo的作用

Undo主要有以下幾個作用：

1)事務回滾(RollbackTransaction)。當一個事務修改表中數(shù)據(jù)的時候，該數(shù)據(jù)修改前的值(即前鏡像，BeforeImage)會被存放在Undo段中，當用戶回滾事務(ROLLBACK)時，Oracle將會利用在數(shù)據(jù)塊ITL槽中記錄的Undo塊地址(UndoBlockAddress，Uba)，然后找到相應的Undo塊，接著利用其中的Undo數(shù)據(jù)(即前鏡像)來將修改的數(shù)據(jù)恢復到原來的值，從而實現(xiàn)對事務所做的改變進行回滾。

2)事務恢復(TransactionRecovery)。實例恢復(InstanceRecovery)的第一階段稱為前滾(RollingForward)或者緩存恢復(CacheRecovery)，第二階段稱為回滾(RollingBack)或者事務恢復。前滾和回滾是Oracle數(shù)據(jù)庫實例發(fā)生意外崩潰，重新啟動的時候，由SMON進行的自動恢復的過程。所謂的前滾是應用Redo來恢復BufferCache的數(shù)據(jù)，將BufferCache恢復到Crash之前狀態(tài)，所以此時BufferCache中既有崩潰時已經(jīng)提交但還沒有寫入數(shù)據(jù)文件的臟塊，還有事務被突然終止而導致的既沒有提交又沒有回滾的事務的臟塊(也就是沒有COMMIT，但是DBWn已經(jīng)將改變的數(shù)據(jù)刷新到底層磁盤)。前滾完成之后就可以確保聯(lián)機Redo日志中所有已提交的事務操作的數(shù)據(jù)寫回到數(shù)據(jù)文件中。接下來，前滾之后，任何未提交的更改必須被撤銷，而回滾是在數(shù)據(jù)庫做完前滾操作后并打開數(shù)據(jù)庫的情況下完成的，SMON會利用Llndo信息將未提交的事務全部進行回滾。具體來說，SMON進程在完成前滾后，查看Undo段頭(Undo段的第1個數(shù)據(jù)塊)記錄的事務表(每個事務在使用Undo塊時，首先要在該Undo塊所在的Undo段頭記錄一個條目，該條目里記錄了該事務相關(guān)的信息，其中包括是否提交等)，將其中既沒有提交也沒有回滾，而是在實例崩潰時被異常終止的事務全部回滾。

3)提供一致性讀(ConsistentRead)。Oracle是一個多用戶系統(tǒng)，當一個會話開始讀取數(shù)據(jù)還未結(jié)束讀取之前，可能會有其他會話修改了該會話將要讀取的數(shù)據(jù)。如果會話讀取到修改后的數(shù)據(jù)，那么就會造成數(shù)據(jù)的不一致，出現(xiàn)了臟讀(DirtyRead)。所以，一致性讀是相對于臟讀而言的。在Oracle中，一致性讀是通過Undo來實現(xiàn)的，一致性讀就是為了保證數(shù)據(jù)的一致性。在一般情況下，普通查詢都是一致性讀。

舉例來說，假設(shè)某個表T中有1萬條記錄，獲取所有記錄需要15min時間。當前時間為9點整，某用戶A發(fā)出一條查詢語句：“SELECT*FROMT;”，該語句在9點15分時執(zhí)行完畢。當用戶A執(zhí)行該SQL語句到9點10分的時候，另外一個用戶B發(fā)出了一條DELETE命令，將T表中的最后一條記錄刪除并提交了。那么到9點15分時，A用戶將返回多少條記錄?如果返回9999條記錄，那么說明發(fā)生了臟讀；如果仍然返回1萬條記錄，那么說明發(fā)生了一致性讀。很明顯，在9點鐘那個時間點發(fā)出查詢語句時，表T中確實有1萬條記錄，只不過由于I/O的相對較慢，所以才會花15min完成所有記錄的檢索。對于Oracle數(shù)據(jù)庫來說，必須提供一致性讀，并且該一致性讀是在沒有阻塞用戶的DML操作的前提下實現(xiàn)的。

那么Undo數(shù)據(jù)是如何實現(xiàn)一致性讀的呢?在Oracle數(shù)據(jù)庫中的BufferCache中的數(shù)據(jù)塊上都會有最后一次修改數(shù)據(jù)塊時的SCN。如果一個事務需要修改數(shù)據(jù)塊中數(shù)據(jù)，那么會先在回滾段中保存一份修改前數(shù)據(jù)和SCN的數(shù)據(jù)塊，然后再更新BufferCache中的數(shù)據(jù)塊的數(shù)據(jù)及其SCN，并標識其為“臟”數(shù)據(jù)。當其他進程讀取數(shù)據(jù)塊時，會先比較數(shù)據(jù)塊上的SCN和自己發(fā)出SQL語句時刻的SCN，分為以下兩種情況：

①如果該數(shù)據(jù)塊頭部的ITL槽上記錄的SCN大于自己查詢時刻的SCN，那么表示該塊被更新過，此時就要借助Undo塊了。在該數(shù)據(jù)塊頭部的ITL槽上記錄了對應的Undo塊的地址(Uba)，根據(jù)Uba就可以找到對應的Undo塊。如果發(fā)現(xiàn)該Undo塊的ITL槽的SCN號也較大，證明該Undo塊也不可用，那么需要在該塊的ITL糟上繼續(xù)尋找上一個Undo塊地址，層層遞歸，最終找到SCN號比發(fā)出查詢的SCN號小的Undo塊，將該Undo塊中的被修改前的數(shù)據(jù)取出，從而構(gòu)建出發(fā)出SQL語句時刻的數(shù)據(jù)塊內(nèi)容，這樣的數(shù)據(jù)塊稱為CR(ConsistentRead)塊。但是在查找的過程中，可能會發(fā)現(xiàn)當前Undo塊里記錄的ITL槽的SCN號比上一個Undo塊里記錄的SCN號還要大。這種情況說明由于事務被提交或回滾，導致當前找到的Undo塊里的數(shù)據(jù)已經(jīng)被其他事務覆蓋了，于是就無法再找出小于等于發(fā)出查詢時的那個時間點的SCN號，這時Oracle就會拋出一個非常經(jīng)典的錯誤—ORA-1555，也就是snapshottooold(快照過舊)的錯誤。對于DELETE來說，其Undo信息就是INSERT，也就是說該構(gòu)建出來的CR塊中就插入了被刪除的那條記錄。

②如果數(shù)據(jù)塊頭部的ITL槽(事務槽)上記錄的SCN小于等于自己查詢時刻的SCN，那么分為兩種情況：第一，若被查詢的塊上沒有活動的事務，則表示該塊沒有被更新過，是可用的，可以直接讀取該數(shù)據(jù)塊上的數(shù)據(jù)；第二，若被查詢的塊上有活動的事務，則需要找Undo的前鏡像數(shù)據(jù)。

4)實現(xiàn)閃回功能。閃回功能中的閃回查詢(FlashbackQuery)、閃回版本查詢(FlashbackVersionQuery)、閃回事務查詢(FlashbackTransactionQuery)和閃回表(FlashbackTABLE)都是基于Undo表空間中的回滾信息實現(xiàn)的。

(2)Undo段存儲的內(nèi)容

Redo中只會記錄少量信息，這些信息足以重演事務；同樣Undo中也只記錄精簡信息，這些信息足以撤銷事務。具體來說：

1)對于INSERT操作，回滾段只需要記錄插入記錄的ROWID，如果回退，那么只需將該記錄根據(jù)ROWID刪除即可。

2)對于UPDATE操作，回滾段只需要記錄被更新字段的舊值即可(前鏡像)，回退時通過舊值覆蓋新值即可完成回滾。

3)對于DELETE操作，Oracle則必須記錄整行的數(shù)據(jù)，在回滾時，Oracle通過一個反向操作恢復刪除的數(shù)據(jù)。

總結(jié)一下：對于相同數(shù)據(jù)量的數(shù)據(jù)操作，通常INSERT產(chǎn)生最少的Undo，UPDATE產(chǎn)生的Undo居中，而DELETE操作產(chǎn)生的Undo最多。所以，當一個大的DELETE操作失敗或者回滾，總是需要很長的時間，并且會有大量的Redo生成。所以通常在進行大規(guī)模數(shù)據(jù)刪除操作時，推薦通過分批刪除分次提交，以減少對于回滾段的占用和沖擊。

(3)塊清除

塊清除(BlockCleanout)是指清除存儲在數(shù)據(jù)塊頭部與鎖相關(guān)的信息，其實質(zhì)是在清除塊上的事務信息，包括數(shù)據(jù)的行級鎖和ITL信息(包括提交標志、SCN等)，塊清除不需要生成Redo日志。Oracle的塊清除有兩種：快速塊清除(FastCommitCleanout)和延時塊清除(DelayedBlockCleanout)。

通過命令“altersystemdumpundoheader'回滾段名稱';”可以將Undo段頭信息dump出來，可以很明顯地看到事務表(TRNTBL)信息，其中，狀態(tài)(state)為10代表活動事務，狀態(tài)(state)為9表示INACTIVE。Dba列表示該事務對應的UndoBlockDba地址。每個事務處理只分配給一個Undo段，一個Undo段可以同時服務多個事務處理。

在提交事務的時候，如果被修改過的數(shù)據(jù)塊仍然在BufferCache之中，那么Oracle可以清除ITL信息，這稱為快速塊清除(FastBlockCleanout)，也稱為提交清除(FastCommitCleanout)?？焖賶K清除還有一個限制，當修改的塊數(shù)量超過BufferCache約10%，則對超出部分不再進行快速塊清除。

在提交事務的時候，如果被修改過的數(shù)據(jù)塊已經(jīng)被寫回到數(shù)據(jù)文件上(或大量修改超出BufferCache的10%的部分)，再次讀出該數(shù)據(jù)塊進行修改，顯然成本過于高昂，對于這種情況，Oracle選擇延遲塊清除(DelayedBlockCleanout)，即在提交的時候只會清理UndoSegmentHeader中的事務表信息，而DataBlock上的事務標志不會清除，等到下一次訪問該Block時再來清除ITL鎖定信息，這就是延遲塊清除。Oracle通過延遲塊清除來提高數(shù)據(jù)庫性能，加快提交操作。如果Oracle不對塊完成這種延遲清除，那么COMMIT的處理可能會很長，COMMIT必須重新訪問每一個塊，可能還要從磁盤將塊再次讀入內(nèi)存。在一個OLTP系統(tǒng)中，可能很少看到這種情況發(fā)生，因為OLTP系統(tǒng)的特點是事務都很短小，只會影響為數(shù)不多的一些塊。

如果執(zhí)行一個大的INSERT、UPDATE或DELETE，會影響數(shù)據(jù)庫中的許多塊，那么就有可能在此之后，第一個“接觸”塊的查詢會做延遲塊清除，從而生成Redo日志，所以，SELECT語句也有可能會產(chǎn)生Redo日志。

因此，建議在批量加載了數(shù)據(jù)后，通過運行DBMS_STATS實用程序來收集統(tǒng)計信息，就能自然地完成塊清除工作。Oracle提供了一個內(nèi)部事件(10203事件)可以用來跟蹤數(shù)據(jù)庫的塊清除操作，可以通過以下命令設(shè)置：

(4)Undo表空間

Undo信息存儲在Undo段中，Undo段又存儲在Undo表空間中。Undo表空間僅用于Undo段(在Undo表空間中不能創(chuàng)建其他段類型，例如表、索引等)，只能與單個實例相關(guān)聯(lián)。在任意指定時間，一個給定的實例只能有一個表空間是當前可寫Undo表空間。Undo表空間是永久的、本地管理的表空間(具有自動區(qū)分配)，它們由數(shù)據(jù)庫自動進行管理。

Redo和Undo可以從以下幾個方面進行區(qū)分，見表。

OracleUndo段中區(qū)有幾種狀態(tài)(DBA_UNDO_EXTENTS的STATUS列)：ACTIVE、EXPIRED和UNEXPIRED：

1)ACTIVE表示事物還在活動，該值對應的Undo段的DBA_ROLLBACK_SEGS.STATUS一定是ONLINE狀態(tài)，一旦沒有活動的事務在使用Undo段，那么對應的Undo段就變成OFFLINE狀態(tài)。ACTIVE狀態(tài)的Undo區(qū)不會被覆蓋。

2)EXPIRED表示事務已經(jīng)提交且超過了UNDO_RETENTION指定時間，該狀態(tài)可以被覆蓋使用。

3)UNEXPIRED表示事務已經(jīng)提交但是還沒有超過UNDO_RETENTION指定時間，該狀態(tài)可以被覆蓋使用。

關(guān)于Undo表空間有如下幾個參數(shù)：

1)UNDO_RETENTION。參數(shù)指定已提交的Undo信息要保留多長時間(單位為秒)，默認為900s(即15min)。但足該值不是絕對的，也就是說，如果有其他事務需要Undo空間，而Undo空間出現(xiàn)不足時，這些信息仍然會被覆蓋。只有當表空間設(shè)置為GUARANTEE時，才能確保已提交的數(shù)據(jù)保留UNDO_RETENTION參數(shù)設(shè)置的時間。RETENTIONGUARANTEE是表空間屬性而不是初始化參數(shù)，此屬性只可使用SQL命令行語句來更改。通過更改Undo表空間來保證保留時間的語法是：

將有保留時間保證的還原表空間返回到其常規(guī)設(shè)置，請使用以下命令：

查詢保留時間狀態(tài)：

如果設(shè)置UNDO_RETENTION為0，那么Oracle啟用自動調(diào)整UNDO_RETENTION(autotuningofundo_retention)以滿足最長運行查詢的需要，在告警日志文件中可以看到如下信息：

可以通過設(shè)置“"_undo_autotune"=FALSE”來顯式地關(guān)閉自動調(diào)整UNDO_RETENTION功能。

2)UNDO_MANAGEMENT。參數(shù)用于指定Undo數(shù)據(jù)的管理方式，分為自動Undo管理(AUM，AutomaticUndoManagement)和手動Undo管理(MUM，ManualUndoManagement)。如果要使用AUM，那么必須設(shè)置為AUTO；如果要使用MUM，那么必須設(shè)置為MANUAL。在使用AUM時，Oracle會使用Undo表空間管理Undo數(shù)據(jù)；在使用MUM時，Oracle會使用回滾段管理Undo數(shù)據(jù)。需要注意的是，在使用AUM時，如果沒有配置初始化參數(shù)UNDO_TABLESPACE，那么Oracle會自動選擇第一個可用的Undo表空間存放Undo數(shù)據(jù)，如果沒有可用的Undo表空間，那么Oracle會使用SYSTEM回滾段存放Undo記錄，并在告警文件中記錄警告。

3)UNDO_TABLESPACE。在使用AUM時，該參數(shù)用于指定實例所要使用的Undo表空間。在RAC結(jié)構(gòu)中，因為一個Undo表空間不能由多個實例同時使用，所以必須為每個實例配置一個獨立的Undo表空間。

(5)系統(tǒng)回滾段(SystemRollbackSegment)

SYSTEM回滾段創(chuàng)建在系統(tǒng)表空間中，當手工創(chuàng)建數(shù)據(jù)庫后，在創(chuàng)建普通回滾段之前必須首先創(chuàng)建系統(tǒng)回滾段。但正常情況下，系統(tǒng)回滾段主要用于兩個方面：一是系統(tǒng)事務，另一個就是延遲回滾段(DeferredRollbackSegment)。

(6)ORA-01555

在告警日志中記錄的ORA-01555(snapshottooold，快照過舊)報錯信息與下條信息類似：