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归档日志占满系统存储空间

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定时清理归档文件,避免再次占满;如不使用,关闭归档日志。

oracle11g_ASM_归档日志闪回区目录空间使用率100%的解决办法

oracle11g_ASM_归档日志闪回区目录空间使用率100%的解决办法

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数据库一次意外宕机的分析处理实记(ora-1578)

ORACLE数据库一次意外宕机的分析处理实记(ora-1578)

一个安静的下午,测试环境中一台装有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 数据库故障解决方案一、引言ORACLE 数据库是一种常用的关系型数据库管理系统,用于存储和管理大量的结构化数据。

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

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

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

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

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

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

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

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

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

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

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

Oracle归档日志已满

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维护控制文件,否则空间显示仍然不释放。

归档日志满处理过程

归档日志满处理过程

ASMCMD> cd archivelog
ASMCMD> ls
2011_10_05/
2011_10_06/
ASMCMD> cd 2011_10_05
ASMCMD> ls -lrt----该命令按时间升序显示文件
ASMCMD>rm filename --filename为要删除的文件名
SQL> alter system setdb_recovery_file_dest_size=4G;
系统已更改。
SQL> show parameter db_recovery_file_dest_size
NAMETYPEVALUE
------------------------------------ ----------- ------------------------------
当数据库运行在归档模式时,如果没有做好备份策略或归档文件和备份文件放到同一个逻辑区,则偶尔会遇到归档日志满导致系统挂起事故。在这样情况下,重启数据库不仅没有用而且将问题更复杂化(记得重启后在HA模式下的共享存储也不见了,进行了手工mount后进行手工删除部分归档日志)。
根据实际环境有不同处理方法,如下是比较通用的处理过程:
2、查看用于归档日志或备份的磁盘空间
在Linux或Unix下可以通过查看空间使用情况:$df -h
如果使用Oracle ASM存储技术,则通过如下命令查看:
$export ORACLE_SID=+ASM1
$asmcmd
ASMCMD> lsdg
3、删除归档日志物理文件,归档日志一般都是位于归档目录下

Oracle数据库的归档日志写满磁盘空间解决办法

Oracle数据库的归档日志写满磁盘空间解决办法

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 日志已满处理方法

archive log 日志已满处理方法

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归档日志空间设置及查看归档空间不足引发的问题及解决方法【VIP专享】

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实例会自动关闭。

Oracle归档日志空间设置及查看 归档空间不足引发的问题及解决方法【VIP专享】

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实例会自动关闭。

ORACLE数据库调整归档日志空间大小

ORACLE数据库调整归档日志空间大小

ORACLE数据库归档日志满后造成无法启动/连接的处理方法在\app\Administrator\diag\rdbms\orcl\orcl\trace(其中orcl根据具体的数据库实例名称而定)路径下的log中可以看到以下信息:ORA-19815: W ARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.Wed Jan 9 15:00:29 2013************************************************************************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 RMANBACKUP RECOVERY AREA command.3. Add disk space and increase db_recovery_file_dest_size parameter toreflect the new space.4. Delete unnecessary files using RMAN DELETE command. If an operatingsystem command was used to delete files, then use RMAN CROSSCHECK andDELETE EXPIRED commands.ORA-19815: W ARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.这句日志意思是db_recovery_file_dest_size已经满了,导致数据库无法启动。

ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案引言概述:ORACLE 数据库作为一种常用的关系型数据库管理系统,广泛应用于企业级应用中。

然而,由于各种原因,数据库故障是不可避免的。

本文将详细介绍ORACLE数据库故障解决方案,匡助管理员更好地应对数据库故障。

一、备份和恢复1.1 定期备份数据:定期备份数据库是避免数据丢失的关键步骤。

管理员应该根据业务需求,选择合适的备份策略,如彻底备份、增量备份或者差异备份,并确保备份数据的完整性和可靠性。

1.2 日志文件的重要性:ORACLE数据库的日志文件记录了数据库的所有操作,包括数据更改和事务。

管理员应该定期备份和归档日志文件,以便在数据库故障时进行恢复。

1.3 恢复策略的选择:在数据库故障发生时,管理员需要选择合适的恢复策略。

常见的恢复策略包括彻底恢复、不彻底恢复和点恢复。

管理员应根据故障的严重程度和数据的重要性来选择合适的恢复策略。

二、故障诊断和监控2.1 监控工具的使用:管理员应该使用合适的监控工具来实时监测数据库的性能和健康状态。

这些工具可以匡助管理员及时发现潜在的故障,并采取相应的措施进行修复。

2.2 日志文件的分析:ORACLE数据库生成为了大量的日志文件,包括错误日志、跟踪文件和警告日志等。

管理员应该定期分析这些日志文件,以便及时发现和解决潜在的故障。

2.3 故障诊断技术:管理员应该熟悉常见的故障诊断技术,如AWR报告、ADDM报告和SQL Trace等。

这些技术可以匡助管理员快速定位和解决数据库故障。

三、性能优化3.1 SQL语句的优化:SQL语句的性能对数据库的整体性能有着重要影响。

管理员应该使用合适的工具和技术,如SQL Tuning Advisor和SQL Trace等,对SQL 语句进行优化,以提高数据库的性能。

3.2 索引的优化:索引是提高数据库查询性能的关键因素。

管理员应该根据业务需求和查询模式,选择合适的索引类型,并定期进行索引的优化和重建。

ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案

ORACLE 数据库故障解决方案故障名称:ORACLE 数据库故障解决方案一、背景介绍ORACLE 数据库是一种常用的关系型数据库管理系统,用于存储和管理大量的数据。

然而,在数据库的运行过程中,可能会浮现各种故障,例如性能下降、连接中断、数据损坏等问题。

为了保证数据库的稳定运行,需要及时解决这些故障。

二、故障解决方案1. 性能下降故障解决方案- 分析数据库性能指标:通过监控工具或者命令,获取数据库的性能指标,如 CPU 使用率、内存利用率、磁盘 I/O 等,以便确定性能下降的原因。

- 优化 SQL 查询语句:通过分析慢查询日志或者执行计划,找出执行时间较长的 SQL 查询语句,并进行优化,如添加索引、重写查询语句等。

- 调整数据库参数:根据数据库的实际情况,适当调整相关参数,如缓冲区大小、并发连接数等,以提升数据库性能。

2. 连接中断故障解决方案- 检查网络连接:确认数据库服务器和客户端之间的网络连接是否正常,如网络是否畅通、防火墙是否阻塞等。

- 检查监听器配置:检查数据库监听器的配置文件,确保监听器正常运行,并监听正确的端口。

- 检查数据库状态:通过查询数据库的状态,确认数据库是否正常运行,如数据库实例是否启动、监听器是否注册等。

3. 数据损坏故障解决方案- 检查数据库文件:通过检查数据库的数据文件、日志文件等,确定是否存在损坏或者丢失的文件。

- 使用备份恢复数据:如果有备份文件,可以使用数据库备份恢复工具进行数据恢复。

注意,恢复操作应在数据库关闭状态下进行。

- 使用数据恢复工具:如果没有备份文件,可以使用数据恢复工具,如Oracle Data Recovery Advisor,进行数据的修复和恢复。

4. 其他常见故障解决方案- 内存溢出故障解决方案:通过增加内存大小或者调整数据库参数,解决内存溢出问题。

- 死锁故障解决方案:通过查询数据库锁表,找出死锁的原因,并进行解锁操作。

- 日志文件满故障解决方案:通过增加日志文件大小或者定期清理日志文件,解决日志文件满的问题。

Oracle数据库频繁归档问题的解决办法

Oracle数据库频繁归档问题的解决办法

Oracle数据库频繁归档问题的解决办法Oracle数据库频繁归档问题的解决办法第一步检查top 输出 CPU 使用率很低iostat 读 M/s 写 K/s iowait %v$session 中的会话不多且都没有大的事务操作db_writer_processes=log_archive_max_processes=主日志组个每个组中个 M大小的日志文件备日志组个每个组中个 M大小的日志文件v$log 除了一个组为current 其它所有日志组状态均为active重启数据库现象依旧第二步判断根据以上检查结果判断应该不是应用层的问题初步判断是系统进程或硬件问题因为是生产系统不到万不得已不要轻易作硬件检测和更换因为那样会需要大量停止服务时间首先采取一般控制日志归档的方法第三步措施增加主日志文件alter database add logfile member /u /oradata/BOSS/redo log to groupalter database add logfile member /u /oradata/BOSS/redo log to groupalter database add logfile member /u /oradata/BOSS/redo log to groupalter database add logfile member /u /oradata/BOSS/redo log to group第四步增加归档进程数由改为alter system set log_archive_max_processes= scope=bothlishixinzhi/Article/program/Oracle/201311/17384。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

第一次宕机时,初始以为是系统内存溢出,于是重启应用服务器,发现应用服务器在启动时报错,错误为无法连接到数据库。

于是连接数据库服务器,打开EM后发现系统报错如图:
提示归档日志写入失败,检查服务器发现磁盘空间满了,于是清理磁盘空间后,重启数据库问题解决。

随后把服务器磁盘空间扩容,直接给了oracle数据所在盘1TB的磁盘空间。

第二次又出现此问题,经过仔细检查,并与同事确认后,发现是由于ORACLE数据库的归档日志被启用了,而我们系统默认是没有启用ORACLE数据库归档日志这个功能的。

使用sql命令查看:
Sql>sqlplus / as nolog;---------------------启动sql*Plus
Sql> connect sys/password@orcl as sysdba;
Sql> archive log list;
数据库日志模式存档模式
自动存档启用
存档终点USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列4888
下一个存档日志序列4890
当前日志序列4890
Sql> show parameter db_recovery_file_dest;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string D:\oracle\product\10.2.0/flash_recovery_area db_recovery_file_dest_size big integer 20G
发现默认的归档路径为D:\oracle\product\10.2.0/flash_recovery_area。

而且限制使用空间为20G。

由于每天产生的oracle归档日志差不多就占用2个G的磁盘空间,而且oracle自身并不会自动清理也没有相关设置自动清理归档日志的功能,一段时间不进行清理,20G空间很快就满了。

与客户商议,准备关闭归档日志功能,客户了解情况后,觉得归档日志功能还是需要开启,(归档日志是oracle灾难恢复的必要数据),于是准备把归档日志使用空间扩大,设成200g。

处理方法:
一、首先要处理日志空间满的情况:
1、删除归档日志物理文件,归档日志一般都是位于D:\oracle\product\10.2.0\flash_recovery_area\ORCL\ARCHIVELOG目录下,以日期文件夹存放,删除时至少保留最近几天的日志用于数据库恢复。

2、归档日志的物理文件删除后,ORACLE可以正常登录了,但是还没完全把归档日志删除干净,ORACLE的controlfile中仍然记录着这些archivelog的信息,在oracle的OEM 管理器中有可视化的日志展现出,当我们手工清除archive目录下的文件后,这些记录并没有被我们从controlfile中清除掉,利用RMAN进行删除操作;
进入cmd,
1.指定数据库实例
C:/Documents and Settings/Administrator>SET ORACLE_SID =orcl
2.连接数据库
C:/Documents and Settings/Administrator>RMAN TARGET SYS/password@orcl
3.查看归档日志的状态
RMAN> list archivelog all;
4.手工删除归档日志文件
RMAN> DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';(删除7天以前的日志记录)
5.退出rman
RMAN> exit
二、扩大归档日志使用空间,设成200g,使用sql命令:
SQL> alter system set db_recovery_file_dest_size=214748364800;---设置使用空间大小(20*1024*1024*1024)
System altered
SQL> show parameter db_recovery_file_dest;---查看归档日志路径限额NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string D:\oracle\product\10.2.0/flash_recovery_area db_recovery_file_dest_size big integer 200G
然后重启数据库后,系统可以正常使用了。

但是,由于启用了归档日志,即便设置成了200G的使用空间,按照每天2G的数据增长量,也就3个月数据就能达到了,需要定制任务定时清理归档日志,而删除归档日志只有在RMAN里才能进行,于是在数据库服务器上新建一个bat文件(文件名随意)
编辑此文件为:
rman target 'sys/password' cmdfile 'd:\cmd.txt'―――此处路径、文件名随意
在命令中对应的路径下新建cmd.txt文件,打开编辑此文件,
DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7';
然后在windows计划任务里添加任务,指定每天定时执行此bat文件。

经过一周的运行,归档日志每天定时被清理。

系统正常.。

相关文档
最新文档