Chinaunix

标题: NBU6.0MP4 做sybase 容灾过程中出现是问题请达人帮忙看下 [打印本页]

作者: zgc888 时间: 2008-04-21 10:14
标题: NBU6.0MP4 做sybase 容灾过程中出现是问题请达人帮忙看下
环境：master A:windows2003 NBU6.0 MP4 SERVER 接了个小的阵列\r\n client B:solaris 10 .5.1 NBU CLIENT sybase option 安装了 sybase \r\n 容灾服务器：C ：solaris 10 5.1 NBU CLIENT

作者: yddll 时间: 2008-04-21 13:03
file descriptor 179 is no longer active\r\n\r\n你的C机器上有什么变化吗？最近

作者: zgc888 时间: 2008-04-21 13:42
没有变化！！除非就是闲置时间而已！！库是一直运行的！！如果有变化我会找到他的日志的！

作者: yddll 时间: 2008-04-21 15:26
1、The job was successfully completed, but some files may have been\r\nbusy or unaccessible. See the problems report or the client\'s logs for more details\r\n\r\n2、生产库是不是增加了文件？\r\n\r\n3、c机的库可不可以先drop掉再恢复呢？

作者: zgc888 时间: 2008-04-21 15:36
生产库是一直运行的！是客户的关键文件！！我知道文件busy 但是那个不是我要解决的问题！！现在是备份的成功的但是恢复是失败飞！！和C机上的库没关系！！我再说下原理！B :远程机器 sybase正常用跑客户的关键应用，sybase定时做dump 然后有NBU备份dump文件以image的文件方式存储！C机器在夜里的一个时间段开始执行 bprestore 把image文件还原到C机器上来！！变成dump文件并load到数据库中现在就是最后这步出错当然如果备份失败也可引起的！现在的问题是另外1家也出现了这个问题！！他备份的完全成功的！！还有另外8家的运行状况完全正常

作者: huanglao2002 时间: 2008-04-21 17:38
明白你的意思。\r\n对于你需要从B机，恢复到你的C机。\r\n不是简单使用bprestore就可以完成的。\r\n因为在catalog中系统只记录clientB，默认情况下netbackup是不允许恢复到其他client的。\r\n\r\n建议你联系你们的供应商寻求支持。

作者: zgc888 时间: 2008-04-21 17:45
回答楼上的！！！请你看清楚！！我的脚本是自己做的！已经可用了！！其他8家正在用！！不是你说的那什么 catalog ~我就是供应商 ~~我这样做的前提是我已经理解了NBU的运行原理！！而且已经在实际中使用了

作者: zgc888 时间: 2008-04-21 17:50
我强调一下哦 \r\n！！我这个东西是已经做起来了！！也正常运行了2个月了！！现在是有其中两家恢复有问题了！！但是不知道是什么问题引起的！现在是找原因！不是说这个动作是否可行！！请看清楚

作者: yddll 时间: 2008-04-21 17:52
不是我没理解你的意思，是你没理解我的意思\r\n1、问第一个问题是我怀疑你的备份和文件恢复可能并不是成功的\r\n2、问第二个问题我是问源数据库是不是增加了数据设备文件，我是怀疑你只是恢复了用户数据库，而没动master，所以可能有信息不一致的答复\r\n3、问第三个问题，是因为很多情况下，直接恢复数据库是可行的，但是经验之谈是删掉要恢复的库，再建一个新的等大或者更大数据库（设备名要一致），然后再恢复，是百试百灵的\r\n\r\n明白我的意思了吗？\r\n\r\n这么多年没做备份了，我真的懒得去翻那些sybase文档了:wink: :wink:\n\n[ 本帖最后由 yddll 于 2008-4-23 17:06 编辑 ]

作者: heroesray 时间: 2008-04-21 22:05
从请求恢复到timeout超时查不多一个小时，日志报告就是nbu的disk manager请求文件超时导致，disk storage unit最多允许多少jobs,multiplexing设置没有，master server的golbal attributes的jobs是否改了？\r\n你这种情况用sybase自己的replication server最合适了，不知道怎么想的非用nbu的备份恢复，你容灾服务器的sybase是自动的恢复那？看样子不像，要生成自动恢复的脚本得需要一定的shell编程功底。\r\n\r\n\r\n2008-4-15 2:22:54 - begin reading\r\n2008-4-15 3:20:49 - Error bpdm(pid=13240) wait for child pid 14256 timeout \r\n2008-4-15 3:20:50 - Error bpdm(pid=14256) The following files/folders were not restored: \r\n2008-4-15 3:20:50 - Error bpdm(pid=14256) UTF - /GZFY.JUDGE.D.0.24281.14-04-2008.22:14:23 \r\n\r\n2008-4-15 3:20:50 - end reading; read time: 00:57:56\r\n2008-4-15 3:20:51 - restored image ntgzfy_1208179804 - (network connection timed out(41)); restore time 00:58:06\r\n2008-4-15 3:20:54 - end Restore; elapsed time: 00:58:11\r\nthe restore failed to recover the requested files(5)\r\n2008-4-15 3:20:55 - Error bpbrm(pid=12140) client restore EXIT STATUS 41: network connection timed out

作者: zgc888 时间: 2008-04-22 08:36
谢谢楼上的！我会按照你给我的思路去考虑问题！！看是不是新增加了设备文件！再次表示感谢

作者: zgc888 时间: 2008-04-22 08:39
谢谢10楼的兄弟！！！也谢谢其他兄弟的支持！！个人感觉10楼的兄弟明白我的意思了！！其他兄弟一直在表示对我写的脚本表示怀疑！！那可是我的心血啊！！我写了3个月才写出来的！！

作者: zgc888 时间: 2008-04-22 08:42
回答11楼的！你说的那个作业数和master属性设置过了！个人认为不是那个问题！！其次！你说的sybase自己的恢复服务器！不是没考虑而是商务和客户沟通之间的问题！！技术都是在经济的基础上的！！呵呵！！谢谢大家

作者: FOR_FREE 时间: 2008-04-23 09:41
NBU日志不是说了恢复不成功么，有些文件没恢复。你生产机上的dump文件都没恢复完全，做库的恢复肯定就错误了。

作者: xiaomao2006 时间: 2008-04-23 15:21
同意10楼,看看设备文件吧\r\n\r\n提示的信息不能真正反映问题本质

欢迎光临 Chinaunix (http://bbs.chinaunix.net/)