最近被utlrp.sql坑慘了
因爲公司的腳本是要交付出去的東西，需要經常執行，反覆驗證，供多個局點使用，而之前看中了utlrp.sql多線程編譯無效對象的機制，圖省事，就在腳本中使用了它，非常信任Oracle官方提供的腳本。
殊不知它有很多坑！
比如，如果你的SGA設置太小了，它就會執行失敗，並報錯。
而由於安裝實例時，SGA是可以配置的，而又沒有標準，所以測試運維他們在安裝環境的時候，這個值都沒有統一，有的配的大，有的配的小，而公司裏環境又多，所以不可能保證每個實例的SGA都設置的足夠大。
最近遇到幾個環境的，執行utlrp.sql卡死了，查看trace日誌，發現了報分配shared_pool失敗等類似的錯誤。之後把SGA改到4G才能順利執行。
再比如，如果你對sys用戶的SESSIONS_PER_USER做了限制，則它可能會卡死，查看oracle進程的CPU使用率爲100%。
由於安全是公司的紅線，對安全要求非常嚴格。所以對數據庫中的用戶賬戶的profile相關參數做了嚴格的限制，就比如管理員相關賬號的profile的SESSION_PER_USER參數，被設置成了10，結果導致執行的utlrp.sql時卡死，查看trace日誌，發現一直在報exceeded SESSIONS_PER_USER limit的錯誤。
最後果斷不能在這種要交付出去的腳本中執行utlrp.sql，改成使用spool生成普通的alter語句來重新編譯無效對象的方式，以提高腳本的穩定性。