我們的文章會在微信公眾號IT民工的龍馬人生和博客網站( www.htz.pw )同步更新 ，歡迎關注收藏，也歡迎大家轉載，但是請在文章開始地方標註文章出處，謝謝！
由於博客中有大量代碼，通過頁面瀏覽效果更佳。

本章將深入探討ORA-01555的四種核心觸發場景，為每種場景提供兩個詳細的案例分析，並附上針對性的優化建議，助你從根源上解決問題。

2.1 場景一：長事務與長查詢

場景描述：
這是ORA-01555最經典的誘因。當一個查詢的持續時間（Query Duration）超過了UNDO數據的保留時間，或者在查詢期間有大量的DML操作，導致查詢啓動時所需的數據“前映像”（before-image）在UNDO中被覆蓋，錯誤便會發生。

案例1：報表查詢與批量更新衝突

• 背景： 某電商平台在每天凌晨2點運行一個銷售額統計報表，該報表需要全表掃描訂單表（ORDERS），耗時約1.5小時。同時，另一個批量任務在2:30開始更新前一天的訂單狀態，涉及數十萬行數據。
• 問題： 報表任務在運行到一半時，頻繁報出ORA-01555錯誤。
• 分析： 報表查詢開始後，批量更新任務產生了大量的UNDO數據，迅速佔用了UNDO表空間。由於UNDO空間有限，為了給新的DML操作騰出空間，Oracle覆蓋了報表查詢所需要的部分舊版本數據。
• 解決：
  1. 時間窗口調整： 將批量更新任務調整到報表任務執行完畢後的4點再開始，錯開時間窗口。
  2. SQL優化： 優化報表SQL，利用分區表特性只掃描最近的分區，並將全表掃描改為索引掃描，查詢時間縮短至20分鐘，大大降低了風險。

案例2（新增）：應用層遊標處理不當

• 背景： 一個Java應用需要從一個大表（TRANSACTIONS）中導出數據。開發人員使用了CURSOR FOR LOOP的方式，在循環體內部對每一條查詢出的記錄進行復雜的業務邏輯處理和網絡I/O操作，然後才fetch下一條。
• 問題： 程序運行幾分鐘後，總是拋出ORA-01555異常。開發人員很困惑，因為單條SQL在客户端執行很快。
• 分析： 這個問題的根源在於遊標打開（open cursor）和數據提取（fetch data）之間的時間間隔太長。open cursor時查詢的快照就已確定，但由於循環體內處理耗時，導致整個fetch過程被拉長到數分鐘。在此期間，其他事務對TRANSACTIONS表的修改覆蓋了遊標所依賴的UNDO數據。
• 解決：
  1. 修改代碼邏輯： 建議開發人員調整代碼，先將查詢結果一次性或分批次fetch到一個集合（如ArrayList）中，完全關閉數據庫遊標後，再對內存中的數據進行業務處理。
  2. 分批處理： 如果數據量過大無法全部加載到內存，則採用分批查詢的方式，例如每次查詢10000條記錄進行處理，處理完再查詢下一批。

優化建議

1. SQL調優是第一要務：
   • 通過索引、分區、並行查詢等手段，盡一切可能縮短查詢的執行時間。查詢運行得越快，其受DML影響的“窗口期”就越短。
2. 優化應用邏輯：
   • 杜絕“取一條，處理一條”的慢速循環模式。 應該先快速獲取數據，再進行業務處理。
   • 避免在循環中提交（COMMIT in a loop）。 這會導致UNDO槽位被快速回收，極易引發ORA-01555。
3. 合理調度任務：
   • 將長時間運行的查詢（如報表、數據抽取）與高頻DML操作（如批量更新、數據加載）的時間窗口錯開，儘量安排在系統負載低的深夜執行。
4. 拆分大事務：
   • 對於需要更新或刪除大量數據的操作，應分解為多個小事務，分批提交，避免產生一個巨大的、長時間佔有UNDO空間的事務。

2.2 場景二：UNDO空間不足

場景描述：
當UNDO表空間的大小不足以容納所有事務所產生的UNDO數據，並且無法滿足UNDO_RETENTION參數設定的保留時間時，Oracle會為了保證新事務的執行而“犧牲”已提交但未過期的UNDO數據，這個過程稱為“竊取”（Steal）。

案例3：UNDO表空間固定大小導致的問題

• 背景： 某金融企業的數據庫UNDO表空間被配置為固定大小（例如20GB），且數據文件未開啓AUTOEXTEND。UNDO_RETENTION設置為3600秒（1小時）。
• 問題： 在一次月末結算期間，由於DML操作量劇增，即使查詢的執行時間遠小於1小時，也頻繁出現ORA-01555。
• 分析： 通過查詢V$UNDOSTAT，發現UNXPSTEALCNT（未過期UNDO塊被竊取的次數）列的值在問題發生的時間段內持續大於0。這明確表明，儘管UNDO_RETENTION要求保留1小時，但由於空間嚴重不足，Oracle被迫竊取了這些本應被保留的UNDO塊，導致查詢失敗。
• 解決：
  1. 緊急擴容： 立即為UNDO表空間增加一個新的數據文件，並開啓AUTOEXTEND，緩解了當時的壓力。
  2. 容量規劃： 事後通過分析V$UNDOSTAT中的UNDOBLKS（使用的UNDO塊數）和高峯期業務量，重新規劃了UNDO表空間的大小，將其擴容至50GB，並保留AUTOEXTEND作為保險。

案例4（新增）：UNDO_RETENTION保證（Guarantee）引發的空間問題

• 背景： DBA為了徹底解決ORA-01555問題，為UNDO表空間開啓了RETENTION GUARANTEE選項。
• 問題： 一段時間後，數據庫中所有的DML操作（INSERT/UPDATE/DELETE）全部掛起，最終失敗，並報錯ORA-30036: unable to extend segment by 8 in undo tablespace 'UNDOTBS1'。
• 分析： RETENTION GUARANTEE是一個“雙刃劍”。它強制Oracle必須滿足UNDO_RETENTION的保留時間，絕不允許“竊取”未過期的UNDO。當UNDO表空間被寫滿，同時又存在一個長時間運行的查詢（或僅僅是UNDO_RETENTION時間未到），導致所有UNDO塊都無法被重用時，新的DML操作就無法獲取到UNDO空間，從而導致數據庫“暫停”DML。
• 解決：
  1. 緊急處理： 臨時關閉RETENTION GUARANTEE (ALTER TABLESPACE undotbs1 RETENTION NOGUARANTEE;)，讓DML操作可以繼續。
  2. 根本解決： 重新評估並大幅增加UNDO表空間的大小，確保其容量足以在GUARANTEE模式下支撐最長查詢和高峯DML。通常，不建議輕易開啓GUARANTEE，除非你對UNDO容量有十足的把握。

優化建議

1. 科學估算UNDO容量：
   • 使用V$UNDOSTAT的歷史數據來估算UNDO空間需求。一個簡單的公式是：所需空間 = (UNDOKBLKS * BLOCK_SIZE) + (MAXQUERYLEN * UNDO_RATE)。其中UNDO_RATE是每秒產生的UNDO量。
2. 明智地使用AUTOEXTEND：
   • 在生產環境中，為UNDO數據文件開啓AUTOEXTEND是一個很好的保險策略，可以應對突發的DML洪峯。但必須設置一個合理的MAXSIZE，防止其無限制增長，耗盡磁盤空間。
3. 理解UNDO_RETENTION：
   • UNDO_RETENTION只是一個“目標”而非“承諾”（除非開啓GUARANTEE）。它的有效性完全取決於是否有足夠的空閒UNDO空間。因此，保障空間比單純調大這個參數更重要。
4. 建立監控告警：
   • 對UNDO表空間的使用率設置監控（例如超過85%告警）。
   • 對V$UNDOSTAT中的UNXPSTEALCNT和NOSPACEERRCNT（空間不足錯誤數）設置監控，一旦這些值大於0，就意味着UNDO配置存在問題。

2.3 場景三：併發DML與查詢衝突

場景描述：
在高併發系統中，即使單個查詢和DML操作都很快，但大量的併發操作在同一時間爭搶和回收UNDO資源，也會導致某些查詢“不幸地”踩到剛被回收的UNDO塊上，從而引發ORA-01555。

案例5：報表查詢與批量刪除衝突

• 背景： 某保險公司在月底進行數據歸檔時，需要批量刪除數百萬條歷史保單。與此同時，財務部門會運行多個報表查詢來統計當月的業績。
• 問題： 財務報表查詢頻繁失敗，報ORA-01555。
• 分析： 批量刪除操作是一個巨大的事務，產生了海量的UNDO信息。雖然報表查詢本身不慢，但它運行期間，刪除事務持續進行，導致UNDO空間被迅速消耗和覆蓋。
• 解決：
  1. 任務調度： 將批量刪除任務調整到所有報表查詢結束後的深夜執行。
  2. DML優化： 將刪除操作改為分批提交，例如每刪除10萬條數據就COMMIT一次，減小了單個事務對UNDO的衝擊。

案例6（新增）：ETL過程中的高頻COMMIT

• 背景： 一個ETL（數據抽取、轉換、加載）作業，每從源系統抽取一條數據，經過轉換後插入到目標表，然後立刻執行一次COMMIT。同時，一個BI儀表盤每分鐘都會刷新，查詢這個目標表。
• 問題： BI儀表盤的查詢間歇性地報ORA-01555。
• 分析： 這種“循環內提交”（COMMIT in a loop）的設計是性能殺手，也是ORA-01555的温牀。每一次COMMIT都使得該事務所使用的UNDO塊可以被立即重用。對於BI這種持續運行的查詢來説，它所依賴的UNDO數據在這種高頻回收的模式下極易丟失。
• 解決：
  1. 優化ETL作業： 修改ETL邏輯，改為批量處理。例如，每處理10000條數據後，再執行一次COMMIT。這大大降低了COMMIT的頻率，延長了UNDO塊的生命週期。
  2. 使用物化視圖： 為BI儀表盤創建一個物化視圖（Materialized View），讓查詢直接訪問物化視圖。ETL作業完成後，再刷新物化視圖。這樣就將查詢和DML操作完全分離開來。

優化建議

1. 隔離工作負載：
   • 儘可能將OLTP（在線事務處理）和DSS（決策支持系統，如報表查詢）分離開。最佳實踐是使用讀寫分離架構，例如在備庫（Standby Database）上執行報表查詢。
2. 優化提交策略：
   • 堅決避免“循環內提交”。這不僅性能低下，還會給UNDO管理帶來巨大壓力。應遵循“批量處理，一次提交”的原則。
3. 利用數據庫特性：
   • 對於讀多寫少的場景，可以考慮使用物化視圖來固化查詢結果，避免查詢與DML的直接衝突。
   • 在某些場景下，為查詢設置更高的事務隔離級別（如SERIALIZABLE）或使用FLASHBACK QUERY，但需注意這可能帶來的性能開銷。

2.4 場景四：LOB字段相關問題

場景描述：
LOB（大對象）字段的UNDO管理機制與普通數據類型不同。它不完全使用UNDO表空間，而是有自己的一套基於PCTVERSION或RETENTION的機制。配置不當或對LOB的頻繁更新，是LOB相關ORA-01555的根源。

案例7：LOB字段更新導致快照丟失

• 背景： 某內容管理系統將文章正文存儲在CLOB字段中，該字段默認使用PCTVERSION 10（即LOB段空間的10%用於保存舊版本）。編輯人員頻繁地對熱門文章進行修改和保存。
• 問題： 在前台查詢文章列表（包含部分正文預覽）的長輪詢請求中，偶爾出現ORA-01555。
• 分析： PCTVERSION 10意味着只有10%的LOB段空間用來存放“前映像”。對於頻繁更新的熱門文章，這部分空間很快被用完，舊版本的LOB數據被覆蓋，導致長查詢無法獲得一致性讀。
• 解決：
  1. 調整LOB參數： 將該LOB字段的存儲參數修改為RETENTION，使其版本保留策略與UNDO_RETENTION參數對齊，提供了更長的版本保留時間。

     ALTER TABLE articles MODIFY LOB (content) (RETENTION);
     

  2. 如果仍有問題，可以考慮增加PCTVERSION的值，例如PCTVERSION 20，但這會消耗更多磁盤空間。

案例8（新增）：RETENTION在MSSM表空間下失效

• 背景： 一個文檔管理系統將文件存儲在BLOB字段中，並配置了RETENTION。但是，DBA在創建存放LOB的表空間時，錯誤地選擇了手動段空間管理（Manual Segment Space Management, MSSM）。
• 問題： 儘管UNDO_RETENTION設置得很高，但查詢LOB表時仍然頻繁出現ORA-01555，伴隨ORA-22924（snapshot too old）。
• 分析： 這是一個非常隱蔽的陷阱。根據Oracle官方文檔（如1555説明.txt中引用的Note 800386.1），當LOB段位於MSSM表空間時，RETENTION參數會被靜默地忽略。這意味着LOB的版本保留根本沒有生效。
• 解決：
  1. 遷移LOB段： 創建一個新的、使用自動段空間管理（Automatic Segment Space Management, ASSM）的表空間。
  2. 使用ALTER TABLE ... MOVE LOB ... STORE AS ... (TABLESPACE ...)命令，將出問題的LOB段遷移到新的ASSM表空間中。遷移後，RETENTION參數便能正常工作。

優化建議

1. 選擇正確的LOB版本管理策略：

   • RETENTION：推薦用於AUM（自動UNDO管理）環境，它將LOB的版本保留與UNDO_RETENTION掛鈎，更易於管理。
   • PCTVERSION：一種更直接的基於空間的控制方式。在LOB更新極度頻繁的場景下，有時調大PCTVERSION比依賴RETENTION效果更直接，但需要精確估算空間。

2. 必須使用ASSM表空間：

   • 存放LOB段的表空間必須使用ASSM，這是RETENTION生效的前提。創建表空間時請務必指定SEGMENT SPACE MANAGEMENT AUTO。

3. 優化LOB操作：

   • Oracle官方建議，對LOB的UPDATE操作對UNDO機制的壓力最大。應儘量將業務邏輯優化為DELETE後INSERT，或者減少對LOB列的不必要更新。

4. 保證LOB表空間充足：

   • 用於版本控制的LOB數據會直接消耗LOB段所在表空間的空間。必須確保該表空間有足夠的預留空間來保存舊版本。

   ------------------作者介紹-----------------------
   姓名：黃廷忠
   現就職：Oracle中國高級服務團隊
   曾就職：OceanBase、雲和恩墨、東方龍馬等
   電話、微信、QQ：18081072613
   個人博客: (http://www.htz.pw)
   CSDN地址: (https://blog.csdn.net/wwwhtzpw)
   博客園地址: (https://www.cnblogs.com/www-htz-pw)