Oracle Metalink支援筆記實戰避坑指南：STATSPACK安裝、手動升級與詞長變更的血淚教訓

依賴官方文檔與Metalink筆記解決問題，成功率常不足100%。本文以三個真實案例揭示「完整指南」的缺漏，並給出應對策略。

案例一：STATSPACK安裝導致DBMS_UTILITY包體失效

舊版執行spcreate.sql會調用spcusr.sql進而載入dbmsjob腳本，若系統已存在DBMS_JOB會產生衝突，導致大量物件失效。utlrp.sql重編譯無法修復DBMS_UTILITY包體。Metalink筆記149113.1六年後才建議註釋掉spcusr.sql中調用dbmsjob的代碼。10g版spcusr已移除該調用。

案例二：10g手動升級檢查清單遺漏關鍵步驟

筆記316889.1「手動升級到10gR2完整檢查清單」遺漏兩點：

1. 未公開Bug會刪除XML DB佔位表，升級腳本執行前必須手動刪除，否則導致不可恢復錯誤。早期版本僅提及「執行升級腳本後會刪除一表」，未標註已知問題。
2. 時區資料錯誤資訊標註「僅10gR1存在」，實則10gR2仍存在，且步驟5至今仍殘留錯誤標註與缺失句號。

案例三：32/64位詞長變更的隱藏陷阱

執行utlirp.sql重編譯所有物件後提示成功，實際上SYS表STATUS欄位被設為6，utlrp.sql並未真正被調用。所有PL/SQL處於失效狀態，需手動重編譯。

核心問題：知識傳遞斷層

Oracle支援機制缺乏將客戶回饋修正進文檔的閉環。SR關閉邏輯優先於知識庫更新，導致已知錯誤長期殘留。

DBA應對策略

• 將「無意識資料變更」轉為「服務變更事件」：在論壇要求分析師修正相關筆記。
• 交叉驗證：對照多版本文檔、社群討論、補丁說明。
• 建立內部知識庫：記錄每次踩坑與解法，形成團隊資產。

電影《死亡地帶》台詞道盡心聲：「你知道了，是不是，你一定知道了」——有人明知文檔有誤卻不發聲。DBA唯有自救，構建可信知識體系。