記一次Oracle異常二：異常又續，書接上一回
又？我爲什麼會說"又"呢？
上文鏈接在這裏：https://blog.csdn.net/weixin_44868854/article/details/106440395
上回說到，好不容易把半死不活的Oracle給救回來了，然後我就放着不管，當我要做實驗報告的時候，我cao，又崩了！
由於，沒有來得及截圖，就口述一波異常情況吧！
按照常規操作
sqlplus /no log
conn /as sysdba
沒有問題，各種查詢也是可以的
關鍵來了，當我試圖給某個表空間更名的時候，卡住了，就是那種不上不下，什麼反應沒有的卡住。然後我以爲是網絡不行，關掉重啓，甚至把這個docker實例停掉重啓，發現還是無補於事~~~~終於在一頓操作猛如虎之後，我大膽的猜測，我該不會是又掉同一個坑了吧！
當我按照Nomount、mount、open三步驟啓動數據庫的時候，終於，我tm還真是掉同一個坑裏面了，又是隻能啓動到mount狀態！然後果斷查看一下閃回恢復空間flash_recover_arer的使用情況，傻眼了，我上次將原本1G的空間擴展到是5個G，然後我就沒操作過，連select都沒有，中間也就十幾天，它那個空間使用情況就已經去到了99.27%？？？？？（可惱也）
正如我上文所說的，一味退縮是不行的，早晚也會再次出問題！
於是這次我來點硬的，刪除那些日誌文件，從此一了百了。
首先是啓動RMAN，這個是Oracle專門用來進行數據庫備份和恢復的，
再次強調一波，以下操作都是在Linux環境下的
這樣就可以進入RMAN的操作空間；
然後就是連接，命令如下：
connect target sys/sys
#target 後面的其實是用戶和密碼，要指定對象就在密碼後面加’@數據庫對象‘
在RMAN也可以查看一下歸檔日誌情況，命令與sqlplus上一致
list archivelog all
然後就是本文最重要的點了，刪除這些日誌文件
delete archivelog all completed befored 'SYSDATE-7'
這樣就會把七天前的日誌全部刪掉。然後再次查看閃回恢復區的使用情況，回到了0%。這裏就因機而異了，因爲我沒什麼日誌，所以刪7天前跟刪完其實沒有多大區別。
限於我的水平問題，在有些地方上就不作詳細述說，如果是對這種情況有更多的瞭解的話，可以參考下面這條鏈接的大佬寫的博客，關於Oracle數據閃回恢復以及日誌文件相關的操作都有很詳細的分析。
https://www.cnblogs.com/andy6/p/5997410.html
忍一時風平浪靜，退一步越想越氣！當時我就應該把它給刪了的。也順便吐槽一波，在找這個問題的時候，翻了好多博客，都是在說這個問題有三種操作可以解決，然後永遠都是隻列出來擴展那一種而已，然後連續好幾篇都是換了個標題換了個出處的復讀機。真的有時候面向搜索引擎學習也是件蠻痛苦的事情~