您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關(guān)Oracle中閃回區(qū)存儲(chǔ)空間報(bào)ORA-19815問題怎么辦的內(nèi)容。小編覺得挺實(shí)用的,因此分享給大家做個(gè)參考,一起跟隨小編過來看看吧。
查詢Oracle的alert日志是發(fā)現(xiàn)ORA-19815告警日志,具體現(xiàn)象如下:
【現(xiàn)象】
ORA-19815: WARNING: db_recovery_file_dest_size of 214748364800 bytes is 85.22% used, and has 31746169856 remaining bytes available
【分析處理思路】
1、查詢相關(guān)參數(shù)和視圖
(1)查詢db_recovery_file_dest_size和db_recovery_file_dest參數(shù)閃回區(qū)存儲(chǔ)空間確定位置和大小。
(2)查詢v$recovery_file_dest視圖確定db_recovery_file_dest_size的使用情況。
(3)查詢v$flash_recovery_area_usage視圖確定那種文件占用空間。
2、解決方法主要考慮以下三個(gè)方面:
(1)如果db_recovery_file_dest_size 較小,修改db_recovery_file_dest_size 為更大的值。
(2)如果db_recovery_file_dest指定的目錄空間不足,解決辦法:
A、可另指定空間,將源db_recovery_file_dest中的文件拷貝到該空間下;
B、為該目錄新增磁盤空間;
C、將該目錄空間中的文件備份到其他目錄,并進(jìn)行壓縮。
(3)通過RMAN刪除已經(jīng)失效的文件。
【實(shí)際操作】
1、查看db_recovery_file相關(guān)參數(shù)
SQL> show parameter db_recovery NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest string /home/erp_db_rec/db_recovery_d est db_recovery_file_dest_size big integer 200G
[oraprod@erpdb erp_db_rec]$ pwd /home/erp_db_rec [oraprod@erpdb erp_db_rec]$ du -sh db_recovery_dest/ 17G db_recovery_dest/
根據(jù)參數(shù)可以判斷db_recovery_file_dest 指定的目錄足夠大。
2、查看recovery file的使用率
SQL> set linesize 2000 SQL> col name form a40 SQL> col SPACE_LIMIT form 99999999999999 SQL> col SPACE_USED form 99999999999999 SQL> col NUMBER_OF_FILES form 9999 SQL> select rfd.NAME,rfd.SPACE_LIMIT,rfd.SPACE_USED,rfd.SPACE_USED/rfd.SPACE_LIMIT*100 as "Rate(%)",rfd.NUMBER_OF_FILES from v$recovery_file_dest rfd; NAME SPACE_LIMIT SPACE_USED Rate(%) NUMBER_OF_FILES ---------------------------------------- --------------- --------------- ---------- --------------- /home/erp_db_rec/db_recovery_dest 214748364800 183002194944 85.2170377 736
查詢發(fā)現(xiàn)已經(jīng)使用了85.21%了。
3、查詢是哪類文件占用空間
SQL> select file_type, percent_space_used as used, percent_space_reclaimable as reclaimable, number_of_files as "number" from v$flash_recovery_area_usage; FILE_TYPE USED RECLAIMABLE number ----------------------- ---------- ----------- ---------- CONTROL FILE 0 0 0 REDO LOG 0 0 0 ARCHIVED LOG 0 0 0 BACKUP PIECE 85.22 0 736 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0 AUXILIARY DATAFILE COPY 0 0 0
8 rows selected.
通過查詢可知是BACKUP PIECE使用了recovery_file_dest統(tǒng)計(jì)的空間。
由上述查詢可知:對db_recovery_file_dest和備份空間中的文件定期進(jìn)行刪除,但是在數(shù)據(jù)庫層面為進(jìn)行清理,導(dǎo)致v$recovery_file_dest視圖將已刪除的文件統(tǒng)計(jì)在內(nèi)導(dǎo)致,判斷通過RMAN刪除無效的備份集可解決。
4、解決此問題的方法
(1)對backupset進(jìn)行交叉檢查。
RMAN> crosscheck backupset; using channel ORA_DISK_1 crosschecked backup piece: found to be 'EXPIRED' backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/backupset/2017_11_07/o1_mf_annnn_TAG20171107T230006_f03lmq9w_.bkp RECID=1405 STAMP=959468407 crosschecked backup piece: found to be 'EXPIRED' ...... ...... backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/backupset/2017_11_09/o1_mf_annnn_TAG20171109T230007_f08vcrc8_.bkp RECID=1420 STAMP=959641208 crosschecked backup piece: found to be 'EXPIRED' backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/backupset/2017_11_09/o1_mf_annnn_TAG20171109T230007_f08vcrf1_.bkp RECID=1421 STAMP=959641208 crosschecked backup piece: found to be 'EXPIRED' backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/backupset/2017_11_09/o1_mf_annnn_TAG20171109T230007_f08vcrhd_.bkp RECID=1422 STAMP=959641208 crosschecked backup piece: found to be 'EXPIRED' backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/backupset/2017_11_09/o1_mf_annnn_TAG20171109T230932_f08vxdxq_.bkp RECID=1426 STAMP=959641772 ....... backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/backupset/2018_03_22/o1_mf_annnn_TAG20180322T231231_fc7kz019_.bkp RECID=2963 STAMP=971478752 crosschecked backup piece: found to be 'AVAILABLE' backup piece handle=/home/erp_db_rec/db_recovery_dest/PROD/autobackup/2018_03_22/o1_mf_s_971478753_fc7kz217_.bkp RECID=2964 STAMP=971478754 Crosschecked 1510 objects
(2)刪除無效的備份集
RMAN> delete noprompt expired backupset; using channel ORA_DISK_1 ...... backup piece handle=/backup/rman_backup/20180219/level1backup/PROD_2218_1_5asrlg89.20180219 RECID=2573 STAMP=968540425 deleted backup piece backup piece handle=/backup/rman_backup/20180219/level1backup/PROD_2217_1_59srlg89.20180219 RECID=2574 STAMP=968540425 deleted backup piece backup piece handle=/backup/rman_backup/20180219/level1backup/PROD_2219_1_5bsrlg89.20180219 RECID=2575 STAMP=968540426 Deleted 1125 EXPIRED objects
(3)使用v$recovery_file_dest驗(yàn)證使用率
SQL> select rfd.NAME,rfd.SPACE_LIMIT,rfd.SPACE_USED,rfd.SPACE_USED/rfd.SPACE_LIMIT*100 as "Rate(%)",rfd.NUMBER_OF_FILES from v$recovery_file_dest rfd; NAME SPACE_LIMIT SPACE_USED Rate(%) NUMBER_OF_FILES ---------------------------------------- --------------- --------------- ---------- --------------- /home/erp_db_rec/db_recovery_dest 214748364800 18025081856 8.39358282 162
刪除無效的備份集后,空間使用率變成8.39%。
(4)查詢BACKUP PIECE 的使用情況
SQL> select file_type, 2 percent_space_used as used, 3 percent_space_reclaimable as reclaimable, 4 number_of_files as "number" 5 from v$flash_recovery_area_usage; FILE_TYPE USED RECLAIMABLE number ----------------------- ---------- ----------- ---------- CONTROL FILE 0 0 0 REDO LOG 0 0 0 ARCHIVED LOG 0 0 0 BACKUP PIECE 8.39 0 162 IMAGE COPY 0 0 0 FLASHBACK LOG 0 0 0 FOREIGN ARCHIVED LOG 0 0 0 AUXILIARY DATAFILE COPY0 0 0
8 rows selected.
完整解決ORA-19815問題。
感謝各位的閱讀!關(guān)于“Oracle中閃回區(qū)存儲(chǔ)空間報(bào)ORA-19815問題怎么辦”這篇文章就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,讓大家可以學(xué)到更多知識,如果覺得文章不錯(cuò),可以把它分享出去讓更多的人看到吧!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。