| 月底有一套RAC要上線了 |
| 但ORACLE_HOME或者GRID_HOME是越長越大 |
| 70GB的專屬空間,總共用掉了86% |
| 其實我心裡有數 |
| 所以就開了case給Global Support |
| 上述就是support的分析 |
| 資料當然是我送上去的 |
| 我怎會不知道有這個狀況 |
| 但我想知道的是 |
| 到底能不能清掉它釋放空間 |
| 我想support應該沒有實務上管理RAC的經驗 |
| 我是從他建議閱讀的文件中 |
| 再去找到550522.1 |
| 才總算有個可行的解法 |
| 可用的描述如下 |
| Additionally, further cleanup of the $ORACLE_HOME/.patch_storage is possible if there are directories from patches applied to previous versions. This can be done manually as follows: |
| 1. run command: |
| $ opatch lsinventory |
| 2. Remove all the sub-directories from $ORACLE_HOME/.patch_storage that are not present in the list of installed patches. Directory names would be prefaced with the patchid for example: |
| 13343438_<timestamp> |
如果它有列在opatch lsinventory裡頭
就把它留在$ORACLE_HOME/.patch_storage裡
其它的目錄我的做法是搬到另外的filesystem
搬完之後, 使用率剩50%
其實Oracle開發團隊這樣設計
是為了當你補釘失敗時
可以從備出來的library回復(rollback)
也有可能你上了補釘後
產生能不良的系統影響
一時間解不了
當然也只能rollback走回原狀
只是我們打補釘的用意
是為了增加系統穩定性
結果反而造成了維護上的困擾
不過...至少現在我找到了解法