親身經歷oracle 10g預設的歸檔路徑（在閃回區）的2g大小限制

今天給客戶測試問題，讓客戶把資料發過來了。解壓縮後一看，他們還是用的oracle 815版本的(他們exp匯出時，帶了匯出日誌，從匯出日誌中看出來是oracle 815版本的)，不過沒有關係，低版本的exp是可以用高版本的imp匯入到高版本資料庫中的。一看是匯入還很正常，匯入到其中某個表的時候，突然就不動了。一開始我還沒有弄明白怎末回事。後來，無意中看到了 計算機管理--事件檢視器中 ，有很多報錯資訊：

Archive process error: ORA-16038: log 1 sequence# 317 cannot be archived
ORA-19809: limit exceeded for recovery files
ORA-00312: online log 1 thread 1: 'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORACLE\REDO01.LOG'

我這才發現，問題出在了歸檔上了。

又看了alert_oracle.log檔案，也有很多這個報錯資訊。到這裡，這個問題給了我一個教訓：與oracle有關的操作，只要有問題，肯定會向alert_oracle.log檔案寫入日誌的，就看你有沒有意識去看這個日誌檔案了。

.去 google.com搜了點資料，這才恍然大悟：
 oracle10g在預設情況下，歸檔日誌是儲存在閃回恢復區的（對於我的來說是：E:\oracle\product\10.2.0\flash_recovery_area\ORACLE\ARCHIVELOG），如果你建庫的時候用的預設設定，
閃回恢復區應該是2G，空間被佔滿了以後就無法再歸檔了。

此時。我從sqlplus  open database ,有提示：

Microsoft Windows XP [版本 5.1.2600]
(C) 版權所有 1985-2001 Microsoft Corp.

C:\Documents and Settings\Administrator>sqlplus / as sysdba

SQL*Plus: Release 10.2.0.1.0 - Production on 星期三 11月 26 17:58:22 2008

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

連線到:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

SQL> alter database open;
alter database open
*
第 1 行出現錯誤:
ORA-16014: 日誌 1 的序列號 317 未歸檔, 沒有可用的目的地
ORA-00312: 聯機日誌 1 執行緒 1:
'E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORACLE\REDO01.LOG'

SQL>

/*-------------------------完畢------------------------*/

 

那怎麼解決這個問題呢？網上的高手也給出了不少方法（以下的方法為轉載，原文地址 菩提老祖的部落格http://yaanzy.itpub.net/post/1263/286285  ）：

解決方法：

1.將歸檔設定到其他目錄，修改alter system set log_archive_dest = 其他路徑

2.轉移或者刪除閃回恢復區裡的歸檔日誌。

3.增大閃回恢復區。
ALTER SYSTEM SET db_recovery_file_dest_size=4g scope=both;

我的處理方法是採用第3種方法,下邊是我的操作過程：

SQL> show parameter db_recovery_file_dest_size;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size           big integer 2G
SQL> alter system set db_recovery_file_dest_size=3G;

系統已更改。

SQL> alter database open;

資料庫已更改。

SQL> show parameter db_recovery_file_dest_size;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest_size           big integer 3G
SQL>

 

/*-------------------------完畢------------------------*/

值得注意的是，我執行完畢alter system set db_recovery_file_dest_size=3G;後，馬上又去show parameter db_recovery_file_dest_size;此時顯示的是3g了，不是原來的2g了。從另外一個方面來說：E:\oracle\product\10.2.0\db_1\dbs\SPFILEORACLE.ORA這個檔案的修改時間，就是我執行alter system set db_recovery_file_dest_size=3G; 這就更證明，此更改馬上就生效了。

值得注意的是，將歸檔路徑下的可用空間擴充到了3G,也就是在原來2G的基礎上又加了1G.  oracle database下新形成的歸檔日誌，實際上是用的這個新增的1G的空間。也許會有人提出疑問，“那我把原來已經形成的2G歸檔日誌刪除掉，oracle database不就能用3G了麼？”其實不是這樣，雖然在物理空間上，已經刪除了2G,但是動態效能檢視（v$recovery_file_dest)並沒有釋放此這2g空間，可以使用select * from v$recovery_file_dest 查詢出來。若你不從動態效能檢視裡刪除這2G的空間，oracle database會認為這2G依然被佔用。若是有個大的事物提交，並有頻繁的日誌切換，1G的空間馬上就被用完，到時候你的alert_oracle.log就有錯誤出現，比如，
ORA-19815: WARNING: db_recovery_file_dest_size of 3221225472 bytes is 100.00% used, and has 0 remaining bytes available.
*** 2008-11-28 10:05:13.375
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.
************************************************************************
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 47715840 bytes disk space from 3221225472 limit
*** 2008-11-28 10:05:13.406 60680 kcrr.c
ARC0: Error 19809 Creating archive log file to 'E:\ORACLE\PRODUCT\10.2.0\FLASH_RECOVERY_AREA\ORACLE\ARCHIVELOG\2008_11_28\O1_MF_1_344_%U_.ARC'

解決以上問題，就需要刪除掉動態效能檢視中的已佔用空間的資訊。按照eygle大師在  一文中的方法，是用rman來刪除這些資訊。所用到的rman命令如下：

1.是RMAN>  crosscheck archivelog all;--此命令的含義是檢查所有歸檔日誌的狀態，並把遺失的標記為expired，也就是說，expired 表示已經被作業系統中被刪除的歸檔日誌。
2.是delete expired archivelog all; --此命令的含義是刪除expired的歸檔日誌。