检查点未完成或者归档未完成
2014-02-12 14:40
155 查看
有时会在alert.log中看到
Thread 2 cannot allocate new log,sequence 1585
Checkpoint not complete
Current log# 1 seq# 1584 mem# 0: / .../...redo01.log
在告警日志中有时会出现Checkpoint not complete或者Archival required,他们的效果类似。
发生情况:1.DBWR还没有完成重做日志所保护数据的检查点
2.ARCH还没有把将重做日志归档
3.日志文件切换
4.日志缓冲区空间问题
在这种情况下数据库会暂停用户的活动,出现这种情况一般因为:
1.日志文件大小不合适
2.DBWR太慢
3.ARCH太慢
有时数据库会出现前10000行很快,然后就会呈喷射状进行:10000行后,就暂停,然后又很快,之后又暂停的情况。
一下是一些解决方法:
1.加快DBWR。启用ASYNC I/O、使用DBWR I/O从属进程,或者使用多个DBWR进程。看看系统产生的I/O,查看是否有一个磁盘(或者一组磁盘)"太热",相应地需要将数据散步看。这个建议对ARCH也适用。这种做法的好处是,不用付出代价就能有所收获,性能会提高,而且不必修改任何逻辑结构代码。这种方法确实没有缺点。
2.增加日志文件个数。
3.重新增加更大日志文件。
4.频繁发生检查点。可以使用一个更小的快缓冲区缓存,这种方法不建议使用,会产生更多严重后果。采用这种方法是设置FAST_START_MTTR_TARGET、LOG_CHECKPOINT_INTERVAL、或者LOG_CHECKPOINT_TIMEOUT之类的参数。(不建议这么用,缺点多多)
Thread 2 cannot allocate new log,sequence 1585
Checkpoint not complete
Current log# 1 seq# 1584 mem# 0: / .../...redo01.log
在告警日志中有时会出现Checkpoint not complete或者Archival required,他们的效果类似。
发生情况:1.DBWR还没有完成重做日志所保护数据的检查点
2.ARCH还没有把将重做日志归档
3.日志文件切换
4.日志缓冲区空间问题
在这种情况下数据库会暂停用户的活动,出现这种情况一般因为:
1.日志文件大小不合适
2.DBWR太慢
3.ARCH太慢
有时数据库会出现前10000行很快,然后就会呈喷射状进行:10000行后,就暂停,然后又很快,之后又暂停的情况。
一下是一些解决方法:
1.加快DBWR。启用ASYNC I/O、使用DBWR I/O从属进程,或者使用多个DBWR进程。看看系统产生的I/O,查看是否有一个磁盘(或者一组磁盘)"太热",相应地需要将数据散步看。这个建议对ARCH也适用。这种做法的好处是,不用付出代价就能有所收获,性能会提高,而且不必修改任何逻辑结构代码。这种方法确实没有缺点。
2.增加日志文件个数。
3.重新增加更大日志文件。
4.频繁发生检查点。可以使用一个更小的快缓冲区缓存,这种方法不建议使用,会产生更多严重后果。采用这种方法是设置FAST_START_MTTR_TARGET、LOG_CHECKPOINT_INTERVAL、或者LOG_CHECKPOINT_TIMEOUT之类的参数。(不建议这么用,缺点多多)
相关文章推荐
- js去掉前后空格
- mongodb数据迁移命令
- tomcat中三种部署项目的方法
- android ndk自动编译
- Ubuntu下配置samba实现文件夹共享
- Unix(cubian of cubieboard2)自启动与FTP服务架设
- 关于XMLEncoder和XMLDecoder
- Web负载均衡的几种实现方式
- ASP.NET MVC统一异常处理
- Android事件分发机制完全解析,带你从源码的角度彻底理解(下)
- 通过dojoConfig 配置 Dojo <6>
- Android开发教程——应用程序之间如何实现沟通
- Android事件分发机制完全解析,带你从源码的角度彻底理解(下)
- sql,char,varchar
- Linux学习篇(三)Code::Bolcks多线程学习
- VS2008出现atlcom.h错误的解决办法
- 还原真实的 cache recovery
- Mysql从5.0升级到 5.1.73
- DNS负载均衡
- lib无法访问另外lib中的头文件