注意后台看似不相关脚本的干扰：
在做数据库备份恢复演练时，发现每次使用备份的数据文件进行恢复后系统无法查询数据，
恢复脚本的逻辑是：
首先，检查当前数据库进程是否存在，若存在，先停，在继续。
其次，将备份的数据文件恢复到目标路径
第三，启动数据库，加载数据
整个过程完后，发现无法读取数据，偶然的想法把最后一步的启动改为重启，区别是重启会检查数据库进程，存在则杀掉进程再启动。
居然这种情况恢复后一切正常，能够正常的对数据进行操作。
仔细比较数据库启动和重启的差别，确认唯一的不同就是上面的启动前干掉已有的进程。而在恢复的第一步就干掉了数据库进程，莫非有其他脚本
调起了数据库进程，忽然想起后台是有watchdog监控的，定时会拉起数据库。至此恍然，另一方面在数据库正在启动或已启动完成，再次调用启动脚本，
仍然简单的提示一个success也是误导本次错误定位的原因。[@more@]
在做数据库备份恢复演练时，发现每次使用备份的数据文件进行恢复后系统无法查询数据，
恢复脚本的逻辑是：
首先，检查当前数据库进程是否存在，若存在，先停，在继续。
其次，将备份的数据文件恢复到目标路径
第三，启动数据库，加载数据
整个过程完后，发现无法读取数据，偶然的想法把最后一步的启动改为重启，区别是重启会检查数据库进程，存在则杀掉进程再启动。
居然这种情况恢复后一切正常，能够正常的对数据进行操作。
仔细比较数据库启动和重启的差别，确认唯一的不同就是上面的启动前干掉已有的进程。而在恢复的第一步就干掉了数据库进程，莫非有其他脚本
调起了数据库进程，忽然想起后台是有watchdog监控的，定时会拉起数据库。至此恍然，另一方面在数据库正在启动或已启动完成，再次调用启动脚本，
仍然简单的提示一个success也是误导本次错误定位的原因。[@more@]
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/23937368/viewspace-1056540/ ，如需转载，请注明出处，否则将追究法律责任。
上一篇：
最近正在阅读和打算阅读的几本书
下一篇：
好书推荐
请登录后发表评论
登录
全部评论
