二楼[zhuqibs]完美回答了此问题。 曾遇到过这样一种情况:同样的数据库版本,搭建测试机时,利用正式库 exp 导出备份进行 imp 导入测试机中,查询该用户模式下的表数量发现,正式库与测试库表数量不一致(测试库少)。后来发现 是
完全同意二楼ostrich的观点:只是提醒大家注意下 在利用 ftp 下载备份文件进行恢复测试时,突然出现文件损坏的现象无法恢复数据库。通过对比发现,备份的文件与 ftp 传到服务器上的文件以及下载到测试环境进行恢复测试的文
巧雷说的是一种方式,确实很慢。不过可以通过定义游标的方式+分批处理 这样就快很多,不用担心服务器硬件资源不够用。 建议采用 load 游标方式进行迁移。 Load 语句中需要带 nonrecoverable; 参数,不然迁移完毕数据库后
Oracle方面的坏块 应该不是物理上的坏道吧。 没准同一个块区装OS就没问题
db2 数据库可以有导出表的作业进行另一种形式的备份,有问题时只恢复单独某个表。其他数据库也有类似的语句。 如果不是真正DBA,像我一样只是个皮毛的运维管理员 遇到坏块的问题还是去恢复吧。我只有一次在测试的情况
我们单位大大小小的数据库系统有40多套:)。涉及db2、oracle、mysql、sqlserver MongoDB、redis、 PG、 GP、TIDB、PI等 我都快数不过来了。更兴奋的是不同系统还用了不同的数据库版本,比如mysql有5.5 5.7 8.0 s
巧雷老师的回答很专业。确实,数据库备份只是最后一张底牌。我们不能什么都依靠备份。结合楼主的应用场景,首先“ 如果真出了问题,感觉恢复的时间根本接受不了 ” 既然业务恢复停机窗口要求很短,数据量又大的情况下,作为
要查找对数据库的相关操作一般需要开启数据库审计功能,而开启审计默认情况下容易导致系统表空间满的问题,我们的生产环境中系统多,数据库量多运维人员少,一般都需要关闭审计功能而且数据库表空间设置为自动增长,只要利用za
这个问题爱数一体机厂家一直没有查到根本原因,现在我们禁用了备份一体机备份,经过两周的跟踪发现mysql集群一直运行正常。应该不是数据库集群的问题。替换方案就是自己编写脚本对数据库进行本地备份后,利用备份一体机备
这个问题会涉及几个方面:网络、数据库性能、服务器资源占用情况。需要根据实际情况去查找根源。1、网络问题是首先应该考虑的,既然是远程连接,首先得保证网络不能有太高的延迟。可以用ping去跟踪下。如果网络延迟大或者
关于TWT使用指南社区专家合作厂商入驻社区企业招聘投诉建议版权与免责声明联系我们 © 2024 talkwithtrend — talk with trend,talk with technologist京ICP备09031017号-30