ORACLE数据库归档日志满后造成系统宕机的处理方法

归档⽇志空间满和 ORA-03113 解决今天有⼀个⽤户因为归档⽇志空间满，造成数据库宕机。

在alert⾥⾯会看到类似下⾯的内容：1. ORA-19815: 警告: db_recovery_file_dest_size 字节 (共 4294967296 字节) 已使⽤ 100.00%, 尚有 0 字节可⽤。

2. ************************************************************************3. You have following choices to free up space from recovery area:4. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,5. then consider changing RMAN ARCHIVELOG DELETION POLICY.6. Back up files to tertiary device such as tape using RMAN7. BACKUP RECOVERY AREA command.8. Add disk space and increase db_recovery_file_dest_size parameter to9. reflect the new space.10. Delete unnecessary files using RMAN DELETE command. If an operating11. system command was used to delete files, then use RMAN CROSSCHECK and12. DELETE EXPIRED commands这时，如果只是把快速恢复区的归档⽇志删除，启动数据库会报错ORA-03113⽅法之⼀，按照上⾯第8条的提⽰，增加db_recovery_file_dest_size需要把数据库启动到mount状态sql>startup mountsql>system set db_recovery_file_dest_size=8192m题外话：出现这个问题的原因是开启归档⽇志，⽽快速恢复区（Flash Recovery Area）默认安装的时候⼀般只有4096M，所以很容易就满，按照Oracle的建议，⼀般这个区域的⼤⼩是数据库⽂件⼤⼩总和的两倍，所以建议⼤⼩都设置⼤⼀些。

oracle归档日志占满系统存储空间，导致数据库启动失败；存储空间占满导致rman工具无法使用，无法删除过期归档日志。

告警信息：1、 存储空间满，/opt占用率达到100%；2、无法进入数据库操作；3、无法使用rman工具清除过期归档日志。

处理过程1、通过命令检查存储空间被哪个目录占用了，最深查询到第八层目录：du -h --max-depth=8。

查询到/opt/oracle/archivelog有142G这么大，打开看有3000+的dbf文件，通过文件目录结构分析，此为数据库归档文件。

2、删除数据库归档文件。

首先切换oracle用户su – oraclecd /opt/oracle/archivelog执行下面命令删除7天以前的归档日志：find . -xdev -mtime +7 -name "*.dbf" -exec rm -f {} \;3、执行rman逻辑上删除过期日志rmanRMAN> connect target />crosscheck archivelog all;>delete expired archivelog all;>quit4、关闭数据库归档日志：登录数据库：!sqlSQL> shutdown immediate启动了实例，并加载了数据库 SQL> startup mount归档->非归档 SQL> alter database noarchivelog;检查是否成功 SQL> archive log list5、启动数据库，完成。

SQL>alter database open;此后，不再生成归档日志。

建议与总结打开归档日志时，DBA定时清理归档文件，避免再次占满；如不使用，关闭归档日志。

XX项目故障解决库——VER 1.02012年6月文挡名称初稿审核建立日期作者文档修订记录章节编号章节名称修订内容简述修订日期修订前版本号目录1.总统架构 (4)2.故障解决库 (4)3.详细解决方法 (5)3.1.序号1 (5)3.1.1.解决方法 (5)1.总统架构架构图：2.故障解决库序号发生时间故障现象故障原因解决方法详见3.详细解决方法前期预防详见3.详细解决方法解决人联系方式1 2012年10月9日上午11时数据库系统宕机，应用系统停用。

自动备份脚本中，删除归档日志的命令没有添加noprompt参数，需要人工输入YES确认，不能自动执1、备份最近3天的归档日志。

2、删除最近2天归档日志。

3、正常关闭数据库。

4、正常开启数据库。

5、开启相关应用系统。

6、做数据库完全备份。

7、更改自动备份脚本，添监控归档目录空间使用百分比，一旦超过80%开始告警。

select file_type,percent_space_usedasused,percent_space_reclaimable asreclaimable,number_of_files as行，造成存放归档日志的闪回区目录空间使用率积累到100%，引起数据库系统宕机。

加noprompt参数。

测试自动备份脚本。

"number" fromv$flash_recovery_area_usage;3.详细解决方法3.1.序号13.1.1.解决方法1、备份最近3天的归档日志。

# cd /home/db/oracle_backup# mkdir 2012_10_07# mkdir 2012_10_08# mkdir 2012_10_09# su - grider$ asmcmdASMCMD> lsARCVG/DBVG/ASMCMD> cd ARCVGASMCMD> lsJXPAEA/ASMCMD> cd JXPAEAASMCMD> lsARCHIVELOG/CONTROLFILE/ONLINELOG/ASMCMD> cd ARCHIVELOGASMCMD> cd 2012_10_07ASMCMD> cp thread_1_seq_14696.9677.796359843 /home/db/oracle_backup/2012_10_07/ ……2、删除最近2天归档日志。

一个安静的下午，测试环境中一台装有ORACLE数据库的AIX小机因意外断电而导致其上的oracle数据库宕机了。

由于是测试环境，安排了一个工程师过去解决了，具体是这样解决的：首先重启了小机服务器，启动完后，发现oracle所在的/app目录没有mount上。

然后通过smitty fs修复了一下，mount上了app，再接着启动oracle就起来了。

事后搜集了system.txt 系统日志(通过errpt -a获得)和alert_soa.log以及oracle的跟踪日志trc，分析trc日志看到如下：/app/oracle/product/10.2.0/admin/soa/bdump/soa_mmon_307366.trcOracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options ORACLE_HOME = /app/oracle/product/10.2.0System name: AIXNode name: data2Release: 3Version: 5Machine: 00CE993C4C00Instance name: soaRedo thread mounted by this instance: 1Oracle process number: 11Unix process pid: 307366, image: oracle@data2 (MMON)*** 2013-03-01 14:06:10.308*** SERVICE NAME:(SYS$BACKGROUND) 2013-03-01 14:06:10.212*** SESSION ID:(161.1) 2013-03-01 14:06:10.212Hex dump of (file 3, block 49259)Dump of memory from 0x07000000C5934000 to 0x07000000C59360007000000C5934000 06A20000 00C0C06B 0178F614 00000104 [.......k.x......]7000000C5934010 45A30000 010A0025 0000224D 0178F614 [E......%.."M.x..]7000000C5934020 00000000 1F023200 00C0C069 00010003 [......2....i....]又观察另两个文件，发现有较多ORA-1578报错和DISK OPERATION ERROR。

ORACLE 数据库故障解决方案一、引言ORACLE 数据库是一种常用的关系型数据库管理系统，用于存储和管理大量的结构化数据。

然而，在数据库运行过程中，可能会遇到各种故障，如数据库崩溃、数据丢失、性能下降等。

本文将介绍一些常见的ORACLE数据库故障解决方案，以匡助管理员快速恢复数据库的正常运行。

二、数据库崩溃的解决方案1. 数据库崩溃可能由于硬件故障、软件错误、人为操作等原因引起。

当数据库崩溃时，管理员应采取以下步骤进行故障排查和修复：a. 检查数据库日志文件，查找崩溃前的异常信息；b. 尝试重启数据库实例，使用备份恢复数据；c. 如果无法恢复数据，可以考虑使用数据库恢复工具进行修复。

2. 数据丢失的解决方案数据丢失可能由于误删除、磁盘损坏等原因导致。

为了防止数据丢失，管理员应采取以下预防措施：a. 定期备份数据库，并将备份文件存储在安全的位置；b. 使用数据库的日志文件功能，可以实现数据的增量备份；c. 配置RAID技术，提高数据库的容错能力。

3. 性能下降的解决方案当数据库性能下降时，可能会导致用户访问延迟、查询速度变慢等问题。

管理员可以采取以下措施来提高数据库性能：a. 优化数据库的查询语句，使用索引、视图等技术来加速查询；b. 增加硬件资源，如CPU、内存等，提升数据库的处理能力；c. 定期清理数据库，删除不必要的数据和索引，减少数据库的负载。

4. 数据库安全的解决方案数据库安全是保护数据库免受未经授权的访问和数据泄露的重要任务。

管理员应采取以下安全措施来保护数据库：a. 设置强密码策略，要求用户使用复杂的密码，并定期更换密码；b. 限制数据库用户的权限，只赋予其必要的访问权限；c. 定期更新数据库软件和补丁，以修复已知的安全漏洞；d. 使用防火墙和入侵检测系统，监控数据库的网络访问。

三、总结本文介绍了ORACLE数据库常见故障的解决方案，包括数据库崩溃、数据丢失、性能下降和数据库安全等方面。

archive log归档日志文件已满情况的处理ORA-00257: archiver error. Connect internal only, until freed 错误的处理方法1.用sys用户登录SQL> conn sys/oracle as sysdba已连接。

2.看看archiv log所在位置SQL> col name for a30SQL> show parameter archive logNAME TYPE V ALUE------------------------------------ ----------- ------------------------------archive_lag_target integer 0log_archive_config stringlog_archive_dest stringlog_archive_dest_1 string LOCA TION=F:\disk5\offlinelog\mandatory log_archive_dest_10 stringlog_archive_dest_2 string LOCATION=F:\disk7\offlinelog\log_archive_dest_3 string LOCATION=F:\disk3\offlinelog\optional log_archive_dest_4 stringlog_archive_dest_5 string3.一般V ALUE为空时，可以用archive log list;检查一下归档目录和log sequence SQL> archive log list数据库日志模式存档模式自动存档启用存档终点F:\disk3\offlinelog\optional最早的联机日志序列935下一个存档日志序列937当前日志序列9374.检查flash recovery area的使用情况,可以看见archivelog已经很大了，达到63.27SQL> 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 63.27 0 29 BACKUPPIECE 0 0 0 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 05.计算flash recovery area已经占用的空间SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;SUM(PERCENT_SPACE_USED)*3/100-----------------------------1.89816.找到recovery目录SQL> show parameter recoverNAME TYPE V ALUE------------------------------------ ----------- ------------------------------db_recovery_file_dest string F:\oracle\product\10.2.0/flash_recovery_areadb_recovery_file_dest_size big integer 2Grecovery_parallelism integer 07.上述结果告诉我们，归档位置用的是默认值，放在flash_recovery_area下（F:\oracle\product\10.2.0/flash_recovery_area）转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件（比如360以后的）注意:在删除归档日志后，必须用RMAN维护控制文件，否则空间显示仍然不释放。

Oracl‎e数据库的‎归档日志写‎满磁盘空间‎解决办法‎‎1、数据库‎不能启动‎SQ‎L> st‎a rtup‎O‎R ACLE‎例程已经‎启动。

‎Tot‎a l Sy‎s tem ‎G loba‎l Are‎a 289‎40697‎6 byt‎e s‎Fixe‎d Siz‎e‎‎‎ 1‎24857‎6 byt‎e s‎Vari‎a ble ‎S ize ‎‎‎ 83‎88678‎4 byt‎e s‎Data‎b ase ‎B uffe‎r s ‎‎ 197‎13228‎8 byt‎e s‎Redo‎Buff‎e rs ‎‎‎ 7‎13932‎8 byt‎e s‎数据库装‎载完毕。

‎OR‎A-160‎38: 日‎志 2 序‎列号 44‎无法归档‎O‎R A-19‎809: ‎超出了恢复‎文件数的限‎制‎O RA-0‎0312:‎联机日志‎2 线程‎1:‎'D:‎\ORAC‎L E\PR‎O DUCT‎\10.2‎.0\OR‎A DATA‎\ORCL‎\REDO‎02.LO‎G' ‎2、查看‎$ORAC‎L E_HO‎M E\ad‎m in\S‎I D\bd‎u mp\a‎l ert_‎S ID.l‎o g日志‎Th‎u Feb‎19 0‎9:45:‎33 20‎09‎Erro‎r s in‎file‎d:\o‎r acle‎\prod‎u ct\1‎0.2.0‎\admi‎n\orc‎l\bdu‎m p\or‎c l_ar‎c1_66‎0.trc‎:‎O RA-1‎9815:‎WARN‎I NG: ‎d b_re‎c over‎y_fil‎e_des‎t_siz‎e of ‎21474‎83648‎byte‎sis ‎99.95‎% use‎d, an‎d has‎1129‎472 r‎e main‎i ng b‎y tes ‎a vail‎a ble.‎T‎h u Fe‎b 19 ‎09:45‎:33 2‎009‎Err‎o rs i‎n fil‎e d:\‎o racl‎e\pro‎d uct\‎10.2.‎0\adm‎i n\or‎c l\ud‎u mp\o‎r cl_o‎r a_47‎08.tr‎c: ‎ORA-‎19815‎:警告:‎db_r‎e cove‎r y_fi‎l e_de‎s t_si‎z e 字节‎(共 2‎14748‎3648 ‎字节) 已‎使用99‎.95%,‎尚有 1‎12947‎2字节可‎用。

archive log归档日志已满处理方法ORA-00257: archiver error. Connect internal only, until freed 错误的处理方法1. 用sys用户登录sqlplus sys/pass@tt as sysdba2. 看看archiv log所在位置SQL> show parameter log_archive_dest;NAME TYPE V ALUE------------------------------------ ----------- ------------------------------log_archive_dest stringlog_archive_dest_1 stringlog_archive_dest_10 string3. 一般V ALUE为空时，可以用archive log list;检查一下归档目录和log sequenceSQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 360Next log sequence to archive 360Current log sequence 3624. 检查flash recovery area的使用情况,可以看见archivelog已经很大了，达到96.62SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- ---------------CONTROLFILE .13 0 1 ONLINELOG 2.93 0 3 ARCHIVELOG 96.62 0 141 BACKUPPIECE 0 0 0 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 05. 计算flash recovery area已经占用的空间SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;SUM(PERCENT_SPACE_USED)*3/100-----------------------------2.99046. 找到recovery目录, show parameter recoverSQL> show parameter recover;NAME TYPE V ALUE------------------------------------ ----------- ------------------------------db_recovery_file_dest string /u01/app/oracle/flash_recovery_area db_recovery_file_dest_size big integer 5Grecovery_parallelism integer 07 上述结果告诉我们，归档位置用的是默认值，放在flash_recovery_area下(db_recovery_file_dest目录=/u01/app/oracle/flash_recovery_area)[root@sha3 10.2.0]# echo $ORACLE_BASE/u01/app/oracle[root@sha3 10.2.0]# cd $ORACLE_BASE/flash_recovery_area/tt/archivelog转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件（比如360以后的）---------------------------------------------------------------------------------------注意:在删除归档日志后，必须用RMAN维护控制文件，否则空间显示仍然不释放。

Oracle归档日志空间设置及查看归档空间不足引发的问题及解决方法【VIP专享】Oracle归档日志空间不足引发的问题及解决方法归档日志空间不足现的问题的现象1、软件正在操作，突然点击任何菜单无反应；2、打开登录界面后，输入用户名和密码长时间没反应；3、再次打开登录界面登录时，登录画面异常，同时输入用户名和密码后，出现需要提交license提示界面；以下系统管理员操作4、oracle登录操作系统，输入以下命令：[oracle@OASERVER ~]$sqlplussql>connect oa/oa //回车后出现报错5、打开EM时（IE中输入http://10.31.1.200:1158/em），报ORA-00257、ORA-01033等错误；6、oracle客户端工具（如：PLSQL Developer等）连接数据库时报ORA-00257、ORA-01033等错误；*************************************************************** ****************说明：因oracle归档日志还在开启，需定期检测归档日志占用空间大小，归归档日志达到一定比例时要及时清理，以防止归档日志问题导致的oracle服务停止现象，从而影响使用使用OA系统。

1、检测oracle是否可以正常归档oracle用户登录系统[oracle@OASERVER ~]$sqlplussql>connect / as sysdbasql>select * from v$logGROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIME-------- ------- ---------- ---------- ---------- --- ------ ------------- ------------1 1 263 52428800 1 NO CURRENT 5924771 13-DEC-102 1 261 52428800 1 YES INACTIVE 5878129 12-DEC-103 1 262 52428800 1 YES INACTIVE 5899219 13-DEC-10说明：上面列表可看出ARC列可正常归档，如果全部为NO，oracle将无法进行归档，此时oracle实例会自动关闭。