我的Oracle資料庫是去年11月份安裝的,然後安裝好之後配置了一下,那個時候是正常的,沒有什麼問題,但是後來我就一直沒有用自己本地的Oracle,使用的PL/SQL一直連的是同事的機子,然後今天突然想在自己的機子上做些測試,PL/SQL居然一直連不上,提示了下面這個錯誤。
提示ORA-03113:通訊通道的檔案結尾進程 ID :0會話 ID:0 序號:0
之後就是一系列的度娘Google論壇等等折騰,折騰了良久,終究是給解決了。
解決方案:
第一步:
C:\Users\Administrator> sqlplus / as sysdbaSQL> shutdown abort;SQL> startup mount;SQL> show parameter background_dump_dest;NAME TYPE VALUE------------------------------------ ----------- ------------------------------background_dump_dest string E:\app\Administrator\diag\rdbms\crm\crm\trace
我們可以看到上面的這個路徑,E:\app\Administrator\diag\rdbms\crm\crm\trace
這個目錄的作用:
它指定在 Oracle 操作過程中為後台進程 (LGWR,DBW n 等等) 寫入追蹤檔案的路徑名(目錄或磁碟)。它還定義記錄著重要事件和訊息的資料庫預警檔案的位置。
我們進入該路徑(E:\app\Administrator\diag\rdbms\crm\crm\trace),找到alert_oracle.log,使用記事本開啟之後(注意:如果該記錄檔比較大的話 系統有可能會卡住,無響應,需要稍等一會兒)可見檔案記錄錯誤如下:
從這裡我們發現了問題的根源:“
ORA-19815: 警告: db_recovery_file_dest_size 位元組 (共 4102029312 位元組) 已使用100.00%, 尚有 0 位元組可用。” 是db_recovery_file_dest_size也叫歸檔日誌空間不足導致的,既然找到問題的根源,那解決起來也就容易了。
解決途徑
空間小,那擺在我們面前辦法就是,一個是將空間設定大點,另一個就是將多餘的檔案刪除掉即可,那麼我們就將這兩個辦法都使用一下。
第二步:
——–通過命令視窗:設定歸檔日誌空間的大小
SQL> select * from v$recovery_file_dest;SQL> alter system set db_recovery_file_dest_size=10737418240; ---這裡是改為10G。SQL> alter database open;SQL> exit;
第三步:
——–刪除歸檔日誌
C:\Users\Administrator> rman target /; -- 進入rman工具視窗RMAN> crosscheck archivelog all; -- 運行這個命令可以把無效的expired的archivelog標出來。RMAN> delete expired archivelog all; -- 直接全部刪除到期的歸檔日誌。RMAN> delete noprompt archivelog until time "sysdate -3"; -- 也可以直接用一個指定的日期來刪除。
到這裡就徹底ok了。接下來重新開啟資料庫:正常使用。
注意:
在刪除歸檔檔案中有一點要注意,通過命令視窗顯示顯示歸檔檔案都在E:\app\Administrator\flash_recovery_area\CRM\ARCHIVELOG 下,但是我們不能手工在作業系統中直接把這些檔案刪除掉,這是因為在controlfile中記錄著每一個archivelog的相關資訊,當我們在OS中刪除這些檔案後,我們的controlfile中仍然記錄著這些archivelog的資訊,因此在Oracle的OEM管理器中還會存在這些日誌。因為當我們手工清除archive目錄下的檔案後,這些記錄並沒有被我們從controlfile中清除掉,也就是oracle並不知道這些檔案已經不存在了。所以還是要通過命令視窗去執行刪除這些檔案的命令。
備忘:
歸檔日誌其實是為了方便我們在恢複資料庫時使用的,但是有時候這些歸檔日誌有時確實會給我們帶來一點點的小麻煩,所以這些歸檔日誌還是需要我們去注意的。
原文地址:http://www.2cto.com/database/201308/235338.html