本文详细记录了一次在数据库备份恢复过程中遇到的问题，即使用备份数据恢复后无法正常查询数据的情况。通过偶然的尝试将启动脚本更改为重启脚本，问题得以解决。分析了数据库启动与重启的区别，确认了唯一差异在于启动前干掉已有的数据库进程。此外，文章还探讨了后台watchdog监控定时拉起数据库的行为，以及数据库启动或已启动情况下再次调用启动脚本的误导性结果。
注意后台看似不相关脚本的干扰：
在做数据库备份恢复演练时，发现每次使用备份的数据文件进行恢复后系统无法查询数据，
恢复脚本的逻辑是：
首先，检查当前数据库进程是否存在，若存在，先停，在继续。
其次，将备份的数据文件恢复到目标路径
第三，启动数据库，加载数据
整个过程完后，发现无法读取数据，偶然的想法把最后一步的启动改为重启，区别是重启会检查数据库进程，存在则杀掉进程再启动。
居然这种情况恢复后一切正常，能够正常的对数据进行操作。
仔细比较数据库启动和重启的差别，确认唯一的不同就是上面的启动前干掉已有的进程。而在恢复的第一步就干掉了数据库进程，莫非有其他脚本
调起了数据库进程，忽然想起后台是有watchdog监控的，定时会拉起数据库。至此恍然，另一方面在数据库正在启动或已启动完成，再次调用启动脚本，
仍然简单的提示一个success也是误导本次错误定位的原因。[@more@]
在做数据库备份恢复演练时，发现每次使用备份的数据文件进行恢复后系统无法查询数据，
恢复脚本的逻辑是：
首先，检查当前数据库进程是否存在，若存在，先停，在继续。
其次，将备份的数据文件恢复到目标路径
第三，启动数据库，加载数据
整个过程完后，发现无法读取数据，偶然的想法把最后一步的启动改为重启，区别是重启会检查数据库进程，存在则杀掉进程再启动。
居然这种情况恢复后一切正常，能够正常的对数据进行操作。
仔细比较数据库启动和重启的差别，确认唯一的不同就是上面的启动前干掉已有的进程。而在恢复的第一步就干掉了数据库进程，莫非有其他脚本
调起了数据库进程，忽然想起后台是有watchdog监控的，定时会拉起数据库。至此恍然，另一方面在数据库正在启动或已启动完成，再次调用启动脚本，
仍然简单的提示一个success也是误导本次错误定位的原因。[@more@]
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23937368/viewspace-1056540/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/23937368/viewspace-1056540/
扫一扫
1010
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
