<<转>>
Overview :
Oracle database is currently the most commonly used large-scale database system in the industry. I encountered an ORA-00257 error (insufficient space error) in an actual project. By searching for information, most of them said that this was due to too many archived logs, which took up All the remaining space on the hard disk can be solved by simply deleting the log or increasing the storage space. But I found on Oracle 10g that there is still a lot of storage space, but this error is also reported. It turned out to be a new feature in Oracle 10g, caused by the management of Flash Recovery. 1. Software and hardware environment server HP Proliant DL580G4 (Intel Xeon 3.16GHz/4GB/ 72.8*4/RAID4) operating system Red Flag DC Server release 5.0 (Trinity) for x86-64 Linux database Oracle 10.2.0.1.0 2. Problem phenomenon The database system has been in trial operation for more than half a month, and an ORA-00257 error occurred during data update after connecting to the database on the evening of July 24, as shown in the figure below.
|
It prompts an archive error. By looking for the ORACLE error code, it is interpreted that the hard disk space is insufficient, and the archive log needs to be deleted to increase the space. However, the available space of the server is 200GB, and currently only about 10GB is used. Why is this? 3. Diagnosis process : 1) Check the archive log of ORACLE database
| [root@hrmsdb /]# cd /oracle/flash_recovery_area/HKCHR/archivelog [root@hrmsdb archivelog]# ls 2006_07_04 2006_07_13 2006_07_17 2006_07_20 2006_07_23 2006_07_11 2006_07_14 2006_07_18 2006_07_21 2006_07_24 2006_07_12 2006_07_15 2006_07_19 2006_07_22 2006_07_25 [root@hrmsdb archivelog]# cd 2006_07_25 [root@hrmsdb 2006_07_25]# ls [root@hrmsdb 2006_07_25]# cd ../2006_07_24 [root@hrmsdb 2006_07_24]# ls o1_mf_1_92_2d933vgb_.arc o1_mf_1_96_2d954ns7_.arc o1_mf_1_98_2d969d5h_.arc o1_mf_1_95_2d9537cs_.arc o1_mf_1_97_2d956km0_.arc |
It means that the database archiving process has been normal until the problem occurs.
2) View the database REDOLOG situation
| [oracle@hrmsdb ~]$ sqlplus /nolog SQL*Plus: Release 10.2.0.1.0 - Production on 星期二 7月 25 10:44:18 2006 Copyright (c) 1982, 2005, Oracle. All rights reserved. SQL> connect / as sysdba 已连接。 SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ---------- ---------- ---------- ---------- ---------- --- --------------------------------------- -------------- 1 1 101 52428800 1 NO CURRENT 3621973 24-7月 -06 2 1 99 52428800 1 NO INACTIVE 3600145 24-7月 -06 3 1 100 52428800 1 NO INACTIVE 3611932 24-7月 -06 |
It is found that the ARC status is NO, indicating that the system cannot automatically archive.
3) Manually switch the log
| SQL> alter system switch logfile; alter system switch logfile * Error on line 1: |
ORA-01013: 用户请求取消当前的操作
在等待长时间没反应后，中断操作，手工切换日志没有成功。
4）查看Oracle数据库后台归档服务进程
| [oracle@hrmsdb ~]$ ps -ef|grep oracle oracle 4601 1 0 Jul11 ? 00:00:04 /oracle/product/10.2.0/db_1/bin/ tnslsnr LISTENER -inherit oracle 5025 1 0 Jul11 ? 00:00:00 /usr/bin/ssh-agent -s oracle 20923 1 0 Jul24 ? 00:00:01 ora_pmon_hkchr oracle 20925 1 0 Jul24 ? 00:00:00 ora_psp0_hkchr oracle 20927 1 0 Jul24 ? 00:00:00 ora_mman_hkchr oracle 20929 1 0 Jul24 ? 00:00:01 ora_dbw0_hkchr oracle 20931 1 0 Jul24 ? 00:01:07 ora_lgwr_hkchr oracle 20933 1 0 Jul24 ? 00:00:05 ora_ckpt_hkchr oracle 20935 1 0 Jul24 ? 00:00:01 ora_smon_hkchr oracle 20937 1 0 Jul24 ? 00:00:00 ora_reco_hkchr oracle 20939 1 0 Jul24 ? 00:00:00 ora_cjq0_hkchr oracle 20941 1 0 Jul24 ? 00:00:01 ora_mmon_hkchr oracle 20943 1 0 Jul24 ? 00:00:05 ora_mmnl_hkchr oracle 20945 1 0 Jul24 ? 00:00:00 ora_d000_hkchr oracle 20947 1 0 Jul24 ? 00:00:00 ora_s000_hkchr oracle 20953 1 0 Jul24 ? 00:09:41 ora_arc0_hkchr oracle 20955 1 1 Jul24 ? 00:10:29 ora_arc1_hkchr oracle 20959 1 0 Jul24 ? 00:00:00 ora_qmnc_hkchr oracle 20967 1 0 Jul24 ? 00:00:00 ora_q000_hkchr oracle 20969 1 0 Jul24 ? 00:00:00 ora_q001_hkchr oracle 21715 1 0 Jul24 ? 00:00:19 oraclehkchr (LOCAL=NO) oracle 21765 1 0 Jul24 ? 00:00:00 ora_j000_hkchr oracle 21816 1 0 Jul24 ? 00:00:00 ora_j001_hkchr oracle 21832 1 0 Jul24 ? 00:00:00 ora_j002_hkchr oracle 21839 1 0 Jul24 ? 00:00:00 ora_j003_hkchr oracle 21859 1 0 Jul24 ? 00:00:00 ora_j004_hkchr oracle 21861 1 0 Jul24 ? 00:00:00 ora_j005_hkchr oracle 21886 1 0 Jul24 ? 00:00:00 ora_j006_hkchr oracle 21888 1 0 Jul24 ? 00:00:00 ora_j007_hkchr root 23187 23186 0 10:39 ? 00:00:00 login -- oracle oracle 23188 23187 0 10:39 pts/0 00:00:00 -bash oracle 23216 23188 0 10:39 pts/0 00:00:00 sqlplus oracle 23217 23216 0 10:39 ? 00:00:00 oraclehkchr (DESCRIPTION=(LOCAL= YES)(ADDRESS=(PROTOCOL=beq))) root 23224 23223 0 10:40 ? 00:00:00 login -- oracle oracle 23225 23224 0 10:40 pts/1 00:00:00 -bash oracle 23310 23225 0 10:46 pts/1 00:00:00 ps -ef oracle 23311 23225 0 10:46 pts/1 00:00:00 grep oracle [oracle@hrmsdb ~]$ 后台进程都正常运行。 |
5）查看FLASH_RECOVERY_AREA空间使用情况
| [root@hrmsdb /]# cd /oracle [root@hrmsdb oracle]# ls admin flash_recovery_area oraInventory product [root@hrmsdb oracle]# du -a -k flash_recovery_area 4 flash_recovery_area/HKCHR/onlinelog 42456 flash_recovery_area/HKCHR/archivelog/2006_07_15/o1_mf_1_74_2cj1h1jz_.arc ………………. 42448 flash_recovery_area/HKCHR/archivelog/2006_07_14/o1_mf_1_68_2cfzwwvt_.arc 512560 flash_recovery_area/HKCHR/archivelog/2006_07_14 1469224 flash_recovery_area/HKCHR/archivelog 6988 flash_recovery_area/HKCHR/backupset/2006_07_04/o1_mf_ncsnf_TAG20060704T1 74229_2bng1o0b_.bkp 876916 flash_recovery_area/HKCHR/backupset/2006_07_04/o1_mf_nnndf_TAG20060704T1 74229_2bng0cx4_.bkp 883908 flash_recovery_area/HKCHR/backupset/2006_07_04 883912 flash_recovery_area/HKCHR/backupset 2353144 flash_recovery_area/HKCHR 2353148 flash_recovery_area [root@hrmsdb oracle]# FLASH_RECOVERY_AREA空间使用了2.35GB |
6）查看FLASH_RECOVERY_AREA空间中各部分使用情况
| SQL> select * from v$recovery_file_dest; NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES ------------------------------------------------------------------------------------------------------------------ /oracle/flash_recovery_area 2147483648 2134212608 0 35 SQL> select * from v$flash_recovery_area_usage; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- ---------------- -------------- -------------- ------------- CONTROLFILE 0 0 0 ONLINELOG 0 0 0 ARCHIVELOG 69.97 0 40 BACKUPPIECE 30.01 0 2 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0 已选择6行。 |
发现ARCHIVELOG占近70％，BACKUPPIRCR占了30％，这样FLASH_RECOVERY_AREA空间的空间已经被完全占据了。
4、解决过程
根据数据库目前可用存储空间为200GB、FLASH_RECOVERY_AREA空间为2GB的实际情况，把FLASH_RECOVERY_AREA的空间修改为20GB。
| SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20g; 系统已更改。 SQL> select * from v$recovery_file_dest; ------------------------------------------------------- ---------- ----------------------------------- NAME SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES ----------- ---------- ----------------- ------------- -------------- ---------- ---------- ------------ /oracle/flash_recovery_area 2.1475E+10 2264587776 0 38 |
这时再查看日志的状态，发现REDO LOG处于正常的归档状态。
| SQL> select * from v$log; GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME ---------- ---------- ---------- ---------- ---------- --- -------------------------------------------- -------------- 1 1 101 52428800 1 YES ACTIVE 3621973 24-7月 -06 2 1 102 52428800 1 NO CURRENT 3650399 25-7月 -06 3 1 100 52428800 1 YES INACTIVE 3611932 24-7月 -06 SQL> select * from v$flash_recovery_area_usage; FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES ------------ ------------------ ------------------------- --------------- CONTROLFILE 0 0 0 ONLINELOG 0 0 0 ARCHIVELOG 7.6 0 43 BACKUPPIECE 4.21 0 2 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0 6 rows are selected. SQL> |
5. Summary
The reasons for this failure are caused by two simultaneous occurrences:
One is that the Flash_Recovery_Area space is relatively small by default, only 2GB, which is easy
to use up; Because the backup software is not running, the archived logs are not deleted in time.
From this troubleshooting process, we can draw lessons:
·The physical space management method of Oracle 10g database has changed from that of previous Oracle, and additional restrictions have been placed on the Flash_Recovery_Area space where archived logs are located; ·The database system administrator should The Oracle database archives logs and the operating status of the backup software are regularly checked to detect and deal with possible failures in advance.