ORACLE归档日志异常增长处理方法
解决Oracle数据库归档日志占满磁盘空间问题
解决Oracle数据库归档⽇志占满磁盘空间问题1、常⽤命令SQL> show parameter log_archive_dest;SQL> archive log list;SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;ARCHIVELOG 96.62 0 141SQL> select sum(percent_space_used)*3/100 from v$flash_recovery_area_usage;2.9904SQL> show parameter recover;db_recovery_file_dest string /u01/oracle/flash_recovery_areadb_recovery_file_dest_size big integer 2G2、删除⽇志cd $ORACLE_BASE/flash_recovery_area/orcl/archivelog转移或清除对应的归档⽇志, 删除⼀些不⽤的⽇期⽬录的⽂件，注意保留最后⼏个⽂件在删除归档⽇志后，必须⽤RMAN维护控制⽂件，否则空间显⽰仍然不释放。
3、删除RMAN过期备份rman target sys/passwordRMAN> crosscheck archivelog all;RMAN> delete expired archivelog all;或者RMAN> delete archivelog until time “sysdate-1″;4、再查SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;5、修改⼤⼩SQL> alter system set db_recovery_file_dest_size=4G scope=both;总结以上所述是⼩编给⼤家介绍的解决Oracle数据库归档⽇志占满磁盘空间问题，希望对⼤家有所帮助，如果⼤家有任何疑问请给我留⾔，⼩编会及时回复⼤家的。
Oracle物化视图定时全量刷新导致归档日志骤增
Oracle物化视图定时全量刷新导致归档⽇志骤增⼀、问题描述 某项⽬组来电，说有⼀个源表约2万多条的物化视图，每5分钟定时全量(Complete)刷新⼀次，⼀天下来，导致Oracle数据库归档⽇志骤增。
⼆、问题分析及解决 先明确⼀个问题：归档⽇志(Archive Log)和重做⽇志(REDO Log)的关系。
Oracle的重做⽇志是⼀组（或⼏组）⽂件，按⼀定的规则顺序循环写，当重做⽇志写满后，从头开始写之前，如果数据库在归档模式(Archive)，则在重写之前，需要把当前的重做⽇志进⾏归档(Archive)，形成归档⽇志。
即归档⽇志来⾃于重做⽇志。
基于此，可以通过减少产⽣重做⽇志的量来达到减少归档⽇志量的⽬的。
综合⼀下： 1、不要全量刷新，采⽤在源表上记录物化视图⽇志的⽅式，实现快速刷新，减少更新的数据量，达到减少重做⽇志的⽬的； 2、指定物化视图为nologging模式 3、减少或取消其上的索引（2W条记录，如果使⽤得⽐较频繁，甚⾄可以考虑把它cache到内存中） 4、如果⼀定要有索引，⾃⼰写刷新的Job，先disable索引，然后刷新，然后重建索引（唯⼀索引可能有问题）。
5、评估业务、技术要求，考虑取消物化视图，建⽴⼀般视图，在访问该视图时，直接从源表中查询。
三、验证过程 验证全量刷新的物化视图产⽣的REDO⽇志的⼤⼩：-- 建⽴源表create table big_table as select * from dba_objects;-- 我机器上（11g），⼤概8W条记录select count(*) from big_table;/*开始验证全量刷新产⽣的REDO⽇志的量*/-- 建⽴物化视图create materialized view big_table_mv as select * from big_table;-- 查看⽬前REDO⽇志的量（重新启动数据库会⾃动清理）-- 记录下数值，⽤于接下来的⽐较select , b.value from v$statname a, v$mystat b where a.statisti = b.statistic# and = 'redo size';--243964-- ⼿⼯全量刷新物化视图begindbms_mview.refresh( 'BIG_TABLE_MV', 'C' );end;-- 再查看REDO⽇志的量，⽐较⼀下-- 记录下数值，⽤于接下来的⽐较select , b.value, to_char( b.value-&V, '999999999999' ) diff from v$statname a, v$mystat b where a.statistic# = b.statistic# and = 'redo size';--value:38845196--diff:38601232，增加了约37M-- 还是⽐较可观的-- 把物化视图改为nologging模式alter table big_table_mv nologging;-- 再全量刷新begindbms_mview.refresh( 'BIG_TABLE_MV', 'C' );end;-- 再查看REDO⽇志的量，⽐较⼀下-- 记录下数值，⽤于接下来的⽐较select , b.value, to_char( b.value-&V, '999999999999' ) diff from v$statname a, v$mystat b where a.statistic# = b.statistic# and = 'redo size';--value:77495608--diff:38894376，增加了约37M，全量刷新时，指定nologging没有什么效果喔。
归档日志空间满
归档⽇志空间满和 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数据库归档日志满后造成系统宕机的处理方法
第一次宕机时，初始以为是系统内存溢出，于是重启应用服务器，发现应用服务器在启动时报错，错误为无法连接到数据库。
于是连接数据库服务器，打开EM后发现系统报错如图：提示归档日志写入失败，检查服务器发现磁盘空间满了，于是清理磁盘空间后，重启数据库问题解决。
随后把服务器磁盘空间扩容，直接给了oracle数据所在盘1TB的磁盘空间。
第二次又出现此问题，经过仔细检查，并与同事确认后，发现是由于ORACLE数据库的归档日志被启用了，而我们系统默认是没有启用ORACLE数据库归档日志这个功能的。
使用sql命令查看：Sql>sqlplus / as nolog;---------------------启动sql*PlusSql> connect sys/password@orcl as sysdba;Sql> archive log list;数据库日志模式存档模式自动存档启用存档终点USE_DB_RECOVERY_FILE_DEST最早的联机日志序列4888下一个存档日志序列4890当前日志序列4890Sql> 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空间很快就满了。
数据库日志增长解决方法
数据库⽇志增长解决⽅法
数据库⽇志增长过快解决⽅法：
1: 删除LOG
1：分离数据库企业管理器－＞服务器－＞数据库－＞右键－＞分离数据库
2：删除LOG⽂件
3：附加数据库企业管理器－＞服务器－＞数据库－＞右键－＞附加数据库
此法⽣成新的LOG，⼤⼩只有500多K
再将此数据库设置⾃动收缩
或⽤代码：
下⾯的⽰例分离 pubs，然后将 pubs 中的⼀个⽂件附加到当前服务器。
EXEC sp_detach_db @dbname = 'pubs '
EXEC sp_attach_single_file_db @dbname = 'pubs ',
@physname = 'c:\Program Files\Microsoft SQL Server\MSSQL\Data\pubs.mdf '
2:清空⽇志
DUMP TRANSACTION 库名 WITH NO_LOG
再：
企业管理器--右键你要压缩的数据库--所有任务--收缩数据库--收缩⽂件--选择⽇志⽂件--在收缩⽅式⾥选择收缩⾄XXM,这⾥会给出⼀个允许收缩到的最⼩M数,直接输⼊这个数,确定就可以了
3: 果想以后不让它增长
企业管理器－＞服务器－＞数据库－＞属性－＞事务⽇志－＞将⽂件增长限制为2M
1、设置数据库为简单模式
--> 数据库的属性
--> “选项”页
--> “模型”选为“简单”
2、截断⽇志，收缩数据库
backup log 数据库名 with no_log
go
dbcc shrinkdatabase(数据库名)
go。
归档日志异常增长处理方法
案例描述：近日湖北运维反应湖北数据库归档日志生成过快,导致磁盘空间占满，引起数据库宕机。
问题看起来很简单，只要清理下归档日志然后重启就能解决，但这只是治标不治本的方法，显然是要找到归档日志增长异常频繁的原因。
最后通过LogMiner分析归档日志发现是运维部署了频繁update的语句，停了后归档日志变为正常.下面是详细步骤1.通过v$archived_log视图查看最近归档日志状态select to_char(COMPLETION_TIME，’yyyymmdd')， count（*)from v＄archived_log twhere t。
COMPLETION_TIME 〉sysdate — 20group by to_char（COMPLETION_TIME，’yyyymmdd')order by to_char(COMPLETION_TIME, ’yyyymmdd');2.查看今天的归档日志情况，看到8点左右归档日志增长最大select to_char(FIRST_TIME，'yyyymmddhh24')， count（＊)from sys。
v_$archived_log twhere t。
FIRST_TIME 〉 trunc(sysdate）group by to_char（FIRST_TIME，’yyyymmddhh24')order by to_char(FIRST_TIME，'yyyymmddhh24’)3.查看今天八点的归档日志的路径select name， COMPLETION_TIME， t.FIRST_TIME, t.RESETLOGS_TIME from sys.v_＄archived_log twhere to_char(FIRST_TIME，’yyyymmddhh24'） = 2015081108order by t.FIRST_TIME desc；4.打开toad，连接数据库，打开日志分析工具logminer(database→diagnose→logminer)5．点击next6.把第三步得到的归档日志的路径输入file to mine7。
oracle11g开启归档模式及修改归档目录日志满
oracle11g开启归档模式及修改归档⽬录⽇志满oracle 11g开启归档模式及修改归档⽬录⽇志满/s/blog_95b5eb8c01018ylb.htmloracle 11g开启归档模式及修改归档⽬录2011-06-28 22:29在Oracle 11g，开启archive log模式时，默认归档⽬录为db_recovery_file_dest指定。
此参数在pfile/spfile中可以指定：db_recovery_file_dest='/u01/app/oracle/flash_recovery_area'更改归档模式需要在mount状态下，更改归档模式。
SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.SQL> startup mountORACLE instance started.--如果安装多个库，会报错，找不到句柄exit 再⽤管理员进⼊Total System Global Area 1258291200 bytesFixed Size 1219160 bytesVariable Size 318768552 bytesDatabase Buffers 922746880 bytesRedo Buffers 15556608 bytesDatabase mounted.SQL> alter database archivelog;Database altered.SQL> alter database open;Database altered.SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DESTOldest online log sequence 15Next log sequence to archive 17Current log sequence 17更改log_archive_dest_1参数可更改归档⽇志⽬录（pfile/spfile中参数db_recovery_file_dest指定的⽬录将⽆效）SQL> alter system set log_archive_dest_1='location=/data/oracle/log1/archive_log'; 最后的⽬录名称需要为archive_log! Linux:alter system set log_archive_dest_1='location=/u01/oracle/log/archive_log';System altered.SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination /data/oracle/log1/archive_logOldest online log sequence 26Next log sequence to archive 28Current log sequence 28实际上从Oracle 10g开始，可以⽣成多份⼀样的⽇志，保存多个位置，以防不测，⽅法如下：SQL>alter system set log_archive_dest_2='location=/data/oracle/log2/archive_log';SQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination /data/oracle/log2/archive_log 只能看到最新设置的归档⽬录。
oracle异常处理步骤
oracle异常处理步骤
Oracle数据库异常处理步骤如下：
1. 定位异常：首先确定出现异常的具体位置，可以通过数据库日志、错误消息和异常堆栈跟踪等方式来定位。
2. 分析异常：对异常进行详细分析，了解异常的原因和影响。
3. 恢复数据库：根据异常的严重程度决定是否需要恢复数据库。
如果是较小的异常，可以进行手动或自动恢复；如果是较严重的异常，可能需要进行数据库的备份和恢复操作。
4. 修复异常：根据异常的具体情况，进行相应的修复操作。
这可能包括删除无效的数据、重建索引、修复损坏的表结构等。
5. 进行测试：在修复异常之后，进行必要的测试，确保数据库的正常运行。
可以执行一些SQL查询、事务处理和性能测试等，以验证修复操作的有效性。
6. 监控和预防措施：定期监控数据库的运行情况，及时发现异常并采取相应的措施。
同时，采取一些预防措施，如定期备份数据库、设置合适的权限和访问控制、优化SQL查询等，以
减少数据库异常的发生。
归档日志满的解决办法
归档日志满的解决办法
1、适当增大日志目录大小：在文件系统范围内扩容，增加虚拟内存空间；
2、定期删除过期存档：删除归档了一段时间的日志文件。
很多时候，由于不知道日志文件的实际用处，往往采用保守策略，定期删除较早的，周期性的删除；
3、采用刷新覆盖的方式：日志文件非常庞大时可以采用这种方式；
4、采用日志归档工具：比如ELK（Elasticsearch、Logstash、Kibana）等日志归档工具，也可以方便，快捷的实现日志收集整理上报；
5、采用云服务进行日志管理：在云环境上直接安装日志管理工具，可以免去很多日志文件定期清理等负担，让日志收集、整理和分析更加高效便捷。
归档日志增长过快处理解决
处理归档日志增加过快一例(2010-08-25 20:03:47)转载▼标签：分类：原创文章oracle归档日志增加过快处理归档日志增加过快一例摘要本文介绍了不久前作者是如何彻底解决一家医院数据库由于归档日志增长过快,导致磁盘剩余空间占满，引起宕机全过程。
通过本案例的描述,我们可以了解到当遇到数据库宕机问题时，应该如何分析现象、找到问题关键、最终彻底解决该问题的一个总体思路，最后还应该深入思考该问题产生的原因，总结出避免以后再出现该问题的建议。
关键字: ORACLE、归档日志、宕机、DML语句初步了解早上一来到公司，XZH就告诉我接到CQ公司的有一个技术申请，大致情况为一家三甲医院，采用Rac+Linux环境，启用了归档模式，但是由于日志增长过快，我们的技术人员设虽然置自动删除归档的任务，但是还是没有避免磁盘空间被占满，已经引起医院2次全院无法使用，虽然CQ公司也安排多名技术人员去现场处理，但是医院认为一直没有解决彻底，因此信息主管对此意见较大，希望公司安排技术支持部现场彻底解决该问题。
通过申请描述，我大致了解到以下几个关键点：1.医院启用了归档，也做了定期自动删除归档日志的任务。
2.由于归档日志增加过快，已经导致医院2号节点宕机。
3.我们的技术人员去了几次，都未彻底解决，用户已经意见很大了。
这只是个初步情况，往往只能了解问题的大概，具体的问题产生的原因还是得到用户那里去才能真正了解，于是立即出发，前往用户处处理问题。
现场分析问题到达医院，同系统管理员互相寒暄了几句，了解大体情况是医院昨天凌晨部分科室反映不能登录导航台，于是系统管理员深夜被叫到医院，查看服务器发现数据库已经宕机，检查磁盘空间，发现其中一个节点的剩余空间为0，于是立即删除部分过去的归档日志，重新启动服务器，下面科室才能够正常登录，谈话间不断听见系统管理员抱怨深夜到医院是如何如何不情愿，看来意见是比较大。
而且同样的问题不久前才出现过一次，当时是中午，询问同去的同事，了解到确实不久前也出现过一次同样的情况，当时认为是归档日志的定期删除保留的日志时间太长，当时保留的是30天的日志，后来改为保留5天的日志，心想不会再出现该问题，没想到还是无法避免。
Oracle数据库归档日志日常管理及建议
Oracle数据库归档日志日常管理与建议1.简介近日，项目组偶有发生归档日志占满归档目录空间导致数据库hang住（无响应），导致系统不能正常应用的情况。
针对此类问题，笔者从 Oracle 数据库归档模式、归档模式的优缺点、归档日志日常管理方法等各方面浅析并整理出归档日志日常管理与建议。
请各项目组依据实际情况，规范管理归档日志，排查相关隐患，以保证系统的正常高效运营。
另外，对于已开启数据库归档模式的项目组，若数据库管理权限不在我方，可将相关归档管理建议与当地运维部门充分沟通，避免归档的不当管理引起事故。
2.数据库归档模式与归档日志2.1 数据库运行模式简介Oracle数据库包括归档模式与非归档模式两种运行模式。
一般情况下 Oracle数据库的联机重做日志会记录对数据库所做的所有的修改，如创建对象；插入、删除、更新对象；删除对象等，这些操作都会记录在联机重做日志里。
Oracle数据库至少要有 2 个联机重做日志组。
当一个联机重做日志组被写满（假设为1）的时候，就会发生日志切换，这时联机重做日志组2（假设为 2）成为当前使用的日志，当联机重做日志组 2 写满的时候，又会发生日志切换，去写联机重做日志组1，这样反复进行。
如果数据库处于非归档模式，联机日志在切换时就会被丢弃。
而在归档模式下，当发生日志切换的时候，被切换的联机日志会被归档。
如当前在使用联机重做日志1，当 1 被写满时，发生日志切换，开始写联机重做日志2，这时联机重做日志 1 的内容会被拷贝到一个指定的目录下。
这个目录为归档目录，这个过程称之为归档，拷贝的文件叫归档日志。
2.2 归档模式优点与归档日志作用数据库运行在归档模式时，后台进程 ARCH 会将联机日志的内容拷贝到归档目录生成归档日志。
当数据库出现介质失败时，使用数据文件备份，归档日志和重做日志可以完全恢复数据库。
因此，开启归档模式及归档日志的益处与作用是非常明显的：1.可以进行完全、不完全恢复。
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。
oracle数据库归档日志满问题解决方案
用户登录时提示ORA-00257：archiver error. Connect internal only ,util freed用户登陆的时候提示：ORA-00257: archiver error. Connect internal only, until freed1. 用sys用户登录sqlplus sys/pass@tt as sysdba2. 看看archiv log所在位置SQL> show parameter log_archive_dest;NAME TYPE VALUE------------------------------------ ----------- ------------------------------ log_archive_dest stringlog_archive_dest_1 stringlog_archive_dest_10 string3. 一般VALUE为空时，可以用archive log list;检查一下归档目录和log sequenceSQL> archive log list;Database log mode Archive ModeAutomatic archival EnabledArchive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 360Next log sequence to archive 360Current log sequence 3624. 检查flash recovery area的使用情况,可以看见archivelog已经很大了，达到96.62 SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- --------------- CONTROLFILE .13 0 1ONLINELOG 2.93 0 3ARCHIVELOG 96.62 0 141 BACKUPPIECE 0 0 0IMAGECOPY 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 VALUE------------------------------------ ----------- ------------------------------db_recovery_file_dest string /u01/app/oracle/flash_recovery_areadb_recovery_file_dest_size big integer 5Grecovery_parallelism integer 07 上述结果告诉我们，归档位置用的是默认值，放在flash_recovery_area下(db_recovery_file_dest目录=/u01/app/oracle/flash_recovery_area)[*************.0]#echo$ORACLE_BASE/u01/app/oracle[*************.0]#cd$ORACLE_BASE/flash_recovery_area/tt/archivelog转移或清除对应的归档日志, 删除一些不用的日期目录的文件，注意保留最后几个文件（比如360以后的）--------------------------------------------------------------------------------------- 注意:在删除归档日志后，必须用RMAN维护控制文件，否则空间显示仍然不释放。
Oracle数据库的归档日志写满磁盘空间解决办法
Oracle数据库的归档日志写满磁盘空间解决办法1、数据库不能启动SQL> sta rtupOR ACLE例程已经启动。
Tota l Sys tem G lobal Area 289406976 byte sFixed Size 1248576 byte sVaria ble S ize 83886784 byte sDatab ase B uffer s 197132288 byte sRedoBuffe rs 7139328 byte s数据库装载完毕。
ORA-16038: 日志 2 序列号 44无法归档OR A-19809: 超出了恢复文件数的限制O RA-00312:联机日志2 线程1:'D:\ORACL E\PRO DUCT\10.2.0\ORA DATA\ORCL\REDO02.LOG' 2、查看$ORACL E_HOM E\adm in\SI D\bdu mp\al ert_S ID.lo g日志Thu Feb19 09:45:33 2009Error s infiled:\or acle\produ ct\10.2.0\admin\orcl\bdum p\orc l_arc1_660.trc:O RA-19815:WARNI NG: d b_rec overy_file_dest_size of 2147483648bytesis 99.95% used, and has1129472 re maini ng by tes a vaila ble.Th u Feb 19 09:45:33 2009Erro rs in file d:\o racle\prod uct\10.2.0\admi n\orc l\udu mp\or cl_or a_4708.trc: ORA-19815:警告:db_re cover y_fil e_des t_siz e 字节(共 2147483648 字节) 已使用99.95%,尚有 1129472字节可用。
解决oracle归档日志写满了（ORA00257）的问题-电脑资料
解决oracle归档日志写满了（ORA00257）的问题-电脑资料解决ORA-00257: archiver error. Connect internal only, until freed此问题属于归档日志满了，。
解决办法：SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;FILE_TYPE PERCENT_SPACE_USEDPERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- ---------------CONTROLFILE 0 0 0ONLINELOG 0 0 0ARCHIVELOG 99.9 0 255BACKUPPIECE 0 0 0IMAGECOPY 0 0 0FLASHBACKLOG 0 0 0注：可以看出，ARCHIVELOG日志已经达到99.9%了，电脑资料《解决oracle归档日志写满了(ORA00257)的问题》(https://)。
要把它清除掉!SQL> quitC:\Documents and Settings\Administrator>rmanRMAN> connect target system/myoracle@orcl注：system为oracle用户，myoracle为oracle用户密码，orcl 为连接的数据库名称SID。
RMAN> crosscheck archivelog all;RMAN> delete expired archivelog all;注：删除过期的归档这样就把归档文件删除了。
再进入sqlplus 查看ARCHIVELOG日志使用率！第二种方法就是增大闪回日志文件的最大大小。
如下：alter system set DB_RECOVERY_FILE_DEST_SIZE=10g以上处理方法是当遇到出现日志写满报错时的处理，建议最好做个任务，定时删除日志，如下：DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'; //删除七天前的归档DELETE ARCHIVELOG FROM TIME 'SYSDATE-7'; //删除七天到现在的归档作者清晨迎朝阳。
归档日志量增长异常分析_结论为物化视图无法使用增量刷新导致
归档⽇志量增长异常分析_结论为物化视图⽆法使⽤增量刷新导致对于客户的问题故障进⾏总结1）问题现象归档⽇志，每⼩时切换最低60于次，每天产⽣归档⽇志720g,由于归档⽇志过多，定时清理归档不及时，导致Arch磁盘组空间极易消耗殆尽，导致业务⽆法操作，业务连续性收到影响。
2）短期处理⼿⼯处理，临时清理⼀天前归档，保障业务连续性RMAN>DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-1';3)问题定位使⽤Logminer⼯具进⾏挖掘，在2019年03⽉05⽇晚上9点，与2019年03⽉06⽇早上7点，⽇志挖掘top3输出结果相同。
对于数据库来说，不同时间段，业务连续性的对同⼀个表insert,delete，JOB定时调⽤可能实现。
USERNAME OWNER NAME TYPE_NAME OPERATION COUNTBJ_SELECTION BJ_SELECTION YD_BARGAIN_PRICE TABLE INSERT 1481521BJ_SELECTION BJ_SELECTION YD_BARGAIN_PRICE TABLE DELETE 1481521BJ_SELECTION INTERNAL 4444594JOB视图查询SQL> select job,log_user,last_date,next_date,broken,interval,what from dba_jobs where WHAT like '%YD_BARGAIN_PRICE%';JOB LOG_USER LAST_DATE NEXT_DATE B INTERVAL WHAT---------- ----------------------------- ----------------------------- -------------------1365 BJ_SELECTION 2019-03-0609:29:532019-03-0609:29:59 NSYSDATE + NUMTODSINTERVAL(2,'SECOND')dbms_refresh.refresh('"BJ_SELECTION"."YD_BARGAIN_PRICE"');1366 BJ_TEST_SELECTION 2019-03-0609:30:022019-03-0609:30:04 NSYSDATE + NUMTODSINTERVAL(2,'SECOND')dbms_refresh.refresh('"BJ_TEST_SELECTION"."YD_BARGAIN_PRICE"');JOB间隔2s，执⾏物化视图刷新。
oracle异常处理步骤
oracle异常处理步骤
2024-10-26
一、什么是Oracle异常处理？
Oracle异常处理是指在Oracle数据库中的处理异常的一种方式。
Oracle异常处理可以防止不必要的错误和异常，将数据库的安全和稳定
性提高到一个可控制的水平。
Oracle异常处理的目的是系统检测到它不
能直接处理的一些情况时，它可以根据异常处理进行一些修正的操作以及
抛出错误信息或警报等，从而可以保证系统的稳定性。
二、Oracle异常处理的步骤
1、确定错误工作流：
在Oracle数据库中，异常处理的第一步就是要确保错误工作流的正
确性，即在几个关键的步骤中定义一个顺序性的行为，并在出现异常时迅
速处理这些异常，但要注意不能将一次异常处理结果影响到后续的工作流程。
2、编写异常处理过程：
编写异常处理过程要注意的第一点是要加入异常处理过程的名字，以
及触发条件；第二点是要指定异常处理的方法，可以使用PL/SQL程序模
块来编写异常处理过程，模块要完成以下功能：（1）处理错误的内容；（2）改变错误的状态；（3）报告错误的信息；（4）保存错误的日志等。
3、实施异常处理：
实际应用中，Oracle数据库系统可以根据异常处理的结果自动实施异常处理，且会通过报错信息或警告信息等来指导管理员或开发人员尽快处理异常。
oracle异常处理步骤
Oracle异常处理步骤引言Oracle是一种关系型数据库管理系统，广泛应用于企业级应用中。
在使用Oracle 数据库的过程中，难免会遇到各种各样的异常情况，如连接失败、SQL语句执行错误等。
为了保证系统的稳定性和可靠性，及时有效地处理这些异常是非常重要的。
本文将详细介绍Oracle异常处理的步骤和方法，帮助读者更好地理解和解决数据库异常问题。
1. 异常分类Oracle数据库中的异常可以分为两类：用户定义异常和系统定义异常。
1.1 用户定义异常用户定义异常是由开发人员在PL/SQL块中通过使用RAISE语句手动触发的异常。
这些异常可以根据具体业务需求进行定义和处理。
1.2 系统定义异常系统定义异常是由Oracle数据库自身抛出的异常。
这些异常通常是由于数据库操作错误、资源不足、权限问题等引起的。
2. 异常处理步骤在处理Oracle异常时，可以按照以下步骤进行操作：2.1 确定异常类型首先，需要确定异常的类型，是用户定义异常还是系统定义异常。
通过查看异常信息和错误代码，可以初步判断异常的类型。
2.2 查看错误信息在捕获到异常后，可以使用DBMS_OUTPUT.PUT_LINE语句打印出错误信息，以便进行调试和定位问题。
例如：BEGIN-- some code hereEXCEPTIONWHEN OTHERS THENDBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM);END;根据错误信息，可以进一步分析异常的原因。
常见的异常原因包括SQL语句错误、数据库连接问题、权限不足等。
通过查看错误信息中的详细描述，可以帮助定位问题。
2.4 修复异常根据异常的原因，采取相应的措施修复异常。
例如，对于SQL语句错误，可以检查语法、表结构等；对于连接问题，可以检查网络连接、数据库监听等；对于权限问题，可以检查用户权限设置等。
2.5 异常处理策略针对不同类型的异常，可以制定相应的异常处理策略。
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实例会自动关闭。
数据库日志异常增加故障排除1例
2022年 5月 May 2022Digital Technology &Application 第40卷 第5期Vol.40 No.5数字技术与应用11图1 数据库正常时日志生成情况Fig.1 Log generation when the database is normal中图分类号:TP311.13 文献标识码:A 文章编号:1007-9416(2022)05-0011-03DOI:10.19695/12-1369.2022.05.04数据库日志异常增加故障排除1例武警湖南总队医院信息科 李春林 周根鸿目的：探讨利用数据库日志文件进行安全预警，保护数据库安全。
方法：定期巡视数据库日志文件，发现异常时进行分析，使用数据日志分析工作进行分析。
结果：日志异常必定反映出数据产生异常。
结论：加强对数据库日志文件的定期巡查和分析，确保数据库的安全运行。
我院医院信息系统采用ORACLE数据库为基础数据库，版本为Oracle 11g，运行方式为归档模式，日志文件大小为12M，数据规模为120G，自2015年升级以收稿日期:2022-01-27作者简介:李春林(1969—),男,湖南娄底人,硕士研究生,主任技师,主要从事医院信息化建设及医院信息系统研究和网络安全防护工作。
来连续正常运转。
1 故障情况在例行的数据库巡查过程中，发现归档日志异常增加。
即由过去的40min左右产生一个归档日志，变成了每10min左右连续产生2个甚至3个归档日志。
有科室反映前端统计查询程序有比平时慢的现象。
而且这种频繁的产生归档日志不是在数据库生产高峰时段。
如果不及时排除故障，将会造成磁盘空间的过快消耗，关键是要找到数据库日志异常过快增加的根本原因，数据库安全数字技术与应用 第 40 卷12才有保障。
正常和异常的日志分别如图1、图2所示：2 故障分析日志文件是对整个数据库的读写进行忠实记录的文件，主要包括对以下三类语句记录：DML（Data Manipulation Language）语句如：SELECT、UPDATE、INSERT、DELETE；DDL（Grant、Deny、Revoke）语句如：CREATE、ALTER、DROP 等； DCL（Data Control Language）语句如： Grant、Deny、Revoke等语句[1]。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
案例描述：客户反应数据库归档日志生成过快，导致磁盘空间占满，引起数据库宕机。
问题看起来很简单，只要清理下归档日志然后重启就能解决，但这只是治标不治本的方法，显然是要找到归档日志增长异常频繁的原因。
最后通过LogMiner分析归档日志发现是运维部署了频繁update的语句，停了后归档日志变为正常。
下面是详细步骤
1.通过v$archived_log视图查看最近归档日志状态
select to_char(COMPLETION_TIME, 'yyyymmdd'), count(*)
from v$archived_log t
where PLETION_TIME > sysdate - 20
group by to_char(COMPLETION_TIME, 'yyyymmdd')
order by to_char(COMPLETION_TIME, 'yyyymmdd');
2.查看今天的归档日志情况，看到8点左右归档日志增长最大
select to_char(FIRST_TIME, 'yyyymmddhh24'), count(*)
from sys.v_$archived_log t
where t.FIRST_TIME > trunc(sysdate)
group by to_char(FIRST_TIME, 'yyyymmddhh24')
order by to_char(FIRST_TIME, 'yyyymmddhh24')
3.查看今天八点的归档日志的路径
select name, COMPLETION_TIME, t.FIRST_TIME, t.RESETLOGS_TIME from sys.v_$archived_log t
where to_char(FIRST_TIME, 'yyyymmddhh24') = 2015081108
order by t.FIRST_TIME desc;
4.打开toad，连接数据库，打开日志分析工具logminer
（database→diagnose→logminer）
5．点击next
6.把第三步得到的归档日志的路径输入file to mine
7.点击运行图标，分析日志，得到sql语句。