最近检查备份，发现问题：某生产库增量备份需要12个小时，正常备份只需要5秒。请看截图
再次描述一下上面的问题：调用v$rman_backup_job_details ，查询显示196次备份是持续了12小时，而rman 则显示196次备份为5秒。检查文件的Linux最后访问时间为7-30 11:01
这就是我说的：由v$rman_backup_job_details引起的Oracle“bug”问题。我首先想到是，是不是oracle 的一个bug，2边时间统计不一致。
好了，问题都搞清楚了吧？现在开始解决问题。
问题是发现了，问题困扰了我很久，但是一直都没有解决。机会终于来了，一次，检查系统中的定时任务日志，发现记录异常：查看系统/var/log/cron日志，发现时间都比系统时间晚了12个小时。系统时区有问题。心中狂喜，有线索了。
查看时间 date,正常。查看/etc/sysconfig/clock，有错误，写着：
zone="America/New_York"，刚好相差12个时区。
问题最终解决：调整/etc/sysconfig/clock为shanghai时区，重启。
再次描述一下上面的问题：调用v$rman_backup_job_details ，查询显示196次备份是持续了12小时，而rman 则显示196次备份为5秒。检查文件的Linux最后访问时间为7-30 11:01
这就是我说的：由v$rman_backup_job_details引起的Oracle“bug”问题。我首先想到是，是不是oracle 的一个bug，2边时间统计不一致。
好了，问题都搞清楚了吧？现在开始解决问题。
问题是发现了，问题困扰了我很久，但是一直都没有解决。机会终于来了，一次，检查系统中的定时任务日志，发现记录异常：查看系统/var/log/cron日志，发现时间都比系统时间晚了12个小时。系统时区有问题。心中狂喜，有线索了。
查看时间 date,正常。查看/etc/sysconfig/clock，有错误，写着：
zone="America/New_York"，刚好相差12个时区。
问题最终解决：调整/etc/sysconfig/clock为shanghai时区，重启。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/30393770/viewspace-1777342/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
linux时间
请登录后发表评论
登录
全部评论
最新文章
- sysbench fileio 压测磁盘raid 5 raid 1 raid10 raid 50 情况
- oracle orion 压测磁盘性能raid10 raid5 raid50 数据
- tpcc-mysql 压测报告
- mysql benchmarksql 压测
- mysql ,tidb sysbench 测试结果记录
- pt-online-schema-change 错误集 Wide character
- mysql lock 大量会话锁住，快速定位，快速解锁
- tidb Error: Operation aborted by user answer '' (cliutil.operation_aborted)
- Oracle的OEM enterprise manager mail notificatio 邮件告警通知设置
- redis cluster 集群故障恢复操作思路
