我的Oracle數據庫是去年11月份安裝的，然後安裝好之後配置了一下，那個時候是正常的，沒有什麼問題，但是後來我就一直沒有用自己本地的Oracle，使用的PL/SQL一直連的是同事的機子，然後今天突然想在自己的機子上做些測試，PL/SQL居然一直連不上，提示了下面這個錯誤。
提示ORA-03113：通信通道的文件結尾
進程 ID ：0
會話 ID：0 序列號：0之後就是一系列的度娘谷歌論壇等等折騰，折騰了良久，終究是給解決了。
解決方法：
第一步：
C:\Users\Administrator> sqlplus / as sysdba
SQL> 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並不知道這些文件已經不存在了。所以還是要通過命令窗口去執行刪除這些文件的命令。
備註：
歸檔日誌其實是爲了方便我們在恢復數據庫時使用的，但是有時候這些歸檔日誌有時確實會給我們帶來一點點的小麻煩，所以這些歸檔日誌還是需要我們去注意的。
