自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

Oracle 10g默認(rèn)歸檔路徑在閃回區(qū)的2G空間大小限制問題

數(shù)據(jù)庫 Oracle
本文我們主要介紹了由于Oracle 10g默認(rèn)歸檔路徑在閃回區(qū)的2G空間大小限制而導(dǎo)致的問題的分析及其解決方案,希望能夠?qū)δ兴鶐椭?/div>

Oracle 10g默認(rèn)歸檔路徑在閃回區(qū)的2G空間大小限制問題是本文我們主要要介紹的內(nèi)容,接下來我們就通過一個實際的例子來開始介紹。實例使這樣的,在為客戶解決問題時,打開數(shù)據(jù)解壓縮后一看,他們還是用的Oracle 815版本的(他們exp導(dǎo)出時,帶了導(dǎo)出日志,從導(dǎo)出日志中看出來是oracle 815版本的),不過沒有關(guān)系,低版本的exp是可以用高版本的imp導(dǎo)入到高版本數(shù)據(jù)庫中的。

一看是導(dǎo)入還很正常,導(dǎo)入到其中某個表的時候,突然就不動了。一開始我還沒有弄明白怎么回事。后來,無意中看到了計算機(jī)管理--事件查看器中,有很多報錯信息:

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

 

我這才發(fā)現(xiàn),問題出在了歸檔上了。

又看了alert_oracle.log文件,也有很多這個報錯信息。到這里,這個問題給了我一個教訓(xùn):與oracle有關(guān)的操作,只要有問題,肯定會向alert_oracle.log文件寫入日志的,就看你有沒有意識去看這個日志文件了。

網(wǎng)上查看資料得知:Oracle 10g在默認(rèn)情況下,歸檔日志是保存在閃回恢復(fù)區(qū)的(對于我的來說是:E:/oracle/product/10.2.0/flash_recovery_area/ORACLE/ARCHIVELOG),如果你建庫的時候用的默認(rèn)設(shè)置,閃回恢復(fù)區(qū)應(yīng)該是2G,空間被占滿了以后就無法再歸檔了。

此時,我從sqlplus  open database,有提示:

  1. Microsoft Windows XP [版本 5.1.2600]  
  2. (C) 版權(quán)所有 1985-2001 Microsoft Corp.  
  3. C:/Documents and Settings/Administrator>sqlplus / as sysdba  
  4. SQL*Plus: Release 10.2.0.1.0 - Production on 星期三 11月 26 17:58:22 2008  
  5. Copyright (c) 1982, 2005, Oracle.  All rights reserved.  
  6. 連接到:  
  7. Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production  
  8. With the Partitioning, OLAP and Data Mining options  
  9. SQL> select open_mode from v$database;  
  10. OPEN_MODE  
  11. ----------  
  12. MOUNTED  
  13. SQL> alter database open;  
  14. alter database open  
  15. *  
  16. 第 1 行出現(xiàn)錯誤:  
  17. ORA-16014: 日志 1 的序列號 317 未歸檔, 沒有可用的目的地  
  18. ORA-00312: 聯(lián)機(jī)日志 1 線程 1:  
  19. 'E:/ORACLE/PRODUCT/10.2.0/ORADATA/ORACLE/REDO01.LOG'  
  20. SQL> 

 

那怎么解決這個問題呢?網(wǎng)上的高手也給出了不少方法(以下的方法為轉(zhuǎn)載,原文地址:http://yaanzy.itpub.net/post/1263/286285  ):

解決方法:

1.將歸檔設(shè)置到其他目錄,修改alter system set log_archive_dest = 其他路徑。

2.轉(zhuǎn)移或者刪除閃回恢復(fù)區(qū)里的歸檔日志。

3.增大閃回恢復(fù)區(qū)。

 

  1. ALTER SYSTEM SET db_recovery_file_dest_size=4g scope=both

 

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

 

  1. SQL> show parameter db_recovery_file_dest_size;  
  2. NAME                                 TYPE        VALUE  
  3. ------------------------------------ ----------- ------------------------------  
  4. db_recovery_file_dest_size           big integer 2G  
  5. SQL> alter system set db_recovery_file_dest_size=3G;  
  6. 系統(tǒng)已更改。  
  7. SQL> alter database open;  
  8. 數(shù)據(jù)庫已更改。  
  9. SQL> show parameter db_recovery_file_dest_size;  
  10. NAME                                 TYPE        VALUE  
  11. ------------------------------------ ----------- ------------------------------  
  12. db_recovery_file_dest_size           big integer 3G  
  13. SQL> 

 

值得注意的是,我執(zhí)行完畢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這個文件的修改時間,就是我執(zhí)行alter system set db_recovery_file_dest_size=3G; 這就更證明,此更改馬上就生效了。

如果將歸檔路徑下的可用空間擴(kuò)充到了3G,也就是在原來2G的基礎(chǔ)上又加了1G.  oracle database下新形成的歸檔日志,實際上是用的這個新增的1G的空間。也許會有人提出疑問,“那我把原來已經(jīng)形成的2G歸檔日志刪除掉,oracle database不就能用3G了么?”其實不是這樣,雖然在物理空間上,已經(jīng)刪除了2G,但是動態(tài)性能視圖(v$recovery_file_dest)并沒有釋放此這2g空間,可以使用select * from v$recovery_file_dest 查詢出來。

若你不從動態(tài)性能視圖里刪除這2G的空間,oracle database會認(rèn)為這2G依然被占用。若是有個大的事物提交,并有頻繁的日志切換,1G的空間馬上就被用完,到時候你的alert_oracle.log就有錯誤出現(xiàn),比如:

  1. ORA-19815: WARNING: db_recovery_file_dest_size of 3221225472 bytes is 100.00% used, and has 0 remaining bytes available.  
  2. *** 2008-11-28 10:05:13.375  
  3. ************************************************************************  
  4. You have following choices to free up space from flash recovery area:  
  5. 1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,  
  6.    then consider changing RMAN ARCHIVELOG DELETION POLICY.  
  7. 2. Back up files to tertiary device such as tape using RMAN  
  8.    BACKUP RECOVERY AREA command.  
  9. 3. Add disk space and increase db_recovery_file_dest_size parameter to  
  10.    reflect the new space.  
  11. 4. Delete unnecessary files using RMAN DELETE command. If an operating  
  12.    system command was used to delete files, then use RMAN CROSSCHECK and  
  13.    DELETE EXPIRED commands.  
  14. ************************************************************************  
  15. ORA-19809: limit exceeded for recovery files  
  16. ORA-19804: cannot reclaim 47715840 bytes disk space from 3221225472 limit  
  17. *** 2008-11-28 10:05:13.406 60680 kcrr.c  
  18. 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' 

 

解決以上問題,就需要刪除掉動態(tài)性能視圖中的已占用空間的信息。按照eygle大師在http://www.eygle.com/archives/2005/03/oracle10gecieif.html 一文中的方法,是用rman來刪除這些信息。所用到的rman命令如下:

1.是RMAN>  crosscheck archivelog all;--此命令的含義是檢查所有歸檔日志的狀態(tài),并把遺失的標(biāo)記為expired,也就是說,expired 表示已經(jīng)被操作系統(tǒng)中被刪除的歸檔日志。

2.是delete expired archivelog all; --此命令的含義是刪除expired的歸檔日志。

關(guān)于Oracle 10g默認(rèn)歸檔路徑在閃回區(qū)的2G空間大小限制問題的相關(guān)知識就介紹到這里了,希望本次的介紹能夠?qū)δ兴斋@!

【編輯推薦】

  1. Oracle數(shù)據(jù)庫學(xué)習(xí)筆記之表的聯(lián)合查詢
  2. Oracle數(shù)據(jù)庫RMAN不完全恢復(fù)之基于SCN恢復(fù)
  3. Oracle數(shù)據(jù)庫RMAN不完全恢復(fù)之基于時間恢復(fù)
  4. Oracle C#實現(xiàn)Oracle Text全文檢索的簡單例子
  5. Oracle數(shù)據(jù)庫RMAN不完全恢復(fù)之基于日志序列號恢復(fù)
責(zé)任編輯:趙鵬 來源: CSDN博客轉(zhuǎn)載
相關(guān)推薦

2010-04-14 16:09:51

Oracle 10g歸

2010-04-07 17:27:38

Oracle 11g

2011-08-09 13:14:37

Oracle 10g數(shù)據(jù)庫閃回

2011-08-29 13:40:12

Oracle 10g創(chuàng)建表空間

2009-09-07 09:03:47

VMWare安裝Ora

2011-08-23 14:23:25

Oracle 10g內(nèi)系統(tǒng)全局區(qū)

2010-03-30 19:31:25

Oracle 10g

2011-05-13 11:21:51

linuxoracle 10g安裝

2009-07-10 11:21:08

MyEclipse 6連接Oracle

2010-04-14 14:40:32

Oracle 10g

2010-04-30 17:50:25

2011-03-25 16:10:58

oraclenagios

2010-05-05 15:58:34

Oracle 10g

2010-04-15 12:43:06

Oracle數(shù)據(jù)庫

2009-04-27 13:26:41

Oracle 10gRAC鏈接錯誤

2009-11-19 10:32:41

Oracle 10g服

2011-08-24 14:21:44

Oracle 10gUNDO表空間

2011-08-30 15:28:33

Oracle 10g表

2011-03-29 09:56:48

Oracle數(shù)據(jù)庫10SQL

2010-04-29 17:13:51

Oracle 10g
點贊
收藏

51CTO技術(shù)棧公眾號