一个用onbar进行不完全恢复的比较诡异问题，大家看看是怎么回事？
不完全恢复的比较诡异问题，大家看看是怎么回事？是这样的，我用onbar -b -L 0 做了整库的0级备份，然后进行基于日志的不完全恢复。
测试步骤是：首先，将服务器停止，onmode -kuy,然后运行onbar -r -n 679 rootdbs命令，结果查看bar_log发现其他的dbspace也进行了转储，怎么命令中指定的rootdbs没起作用呢？
$ vi /u01/informix/bar_act.log
2009-12-03 18:10:02 98789876 /u01/informix/bin/onbar_d -r -n 678 rootdbs
2009-12-03 18:10:02 98789876 (-43020) Storage space names ignored for fake backup, whole
system backup/restore, log restore, or log salvage.
2009-12-03 18:10:02 98789876 Successfully connected to Storage Manager.
2009-12-03 18:10:03 98789876 Begin salvage for log 673.
2009-12-03 18:10:03 98789876 Completed salvage of logical log 673 (Storage Manager copy ID: 1443928346 0).
2009-12-03 18:10:03 98789876 Duplicate log unique ID 678 found for specified point-in-log restore.
Onbar is restoring to the latest log unique ID 678.
2009-12-03 18:10:03 98789876 Successfully connected to Storage Manager.
2009-12-03 18:10:04 98789876 Begin reserved pages restore (level 0 of rootdbs, Storage Manager copy ID: 1443928320 0).
2009-12-03 18:10:04 98789876 Completed reserved pages restore (level 0 of rootdbs).
2009-12-03 18:10:04 98789876 Successfully connected to Storage Manager.
2009-12-03 18:10:04 98789876 Begin cold level 0 restore rootdbs (Storage Manager copy ID: 1443928320 0).
2009-12-03 18:10:16 98789876 Completed cold level 0 restore rootdbs.
2009-12-03 18:10:16 98969878 Process 98969878 successfully forked.
2009-12-03 18:10:16 98979878 Process 98979878 successfully forked.
2009-12-03 18:10:16 98989878 Process 98989878 successfully forked.
2009-12-03 18:10:16 98999878 Process 98999878 successfully forked.
2009-12-03 18:10:16 99009878 Process 99009878 successfully forked.
2009-12-03 18:10:16 98969878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 98979878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 98989878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 98999878 Successfully connected to Storage Manager.
2009-12-03 18:10:16 99009878 Successfully connected to Storage Manager.
2009-12-03 18:10:17 98969878 Begin cold level 0 restore logdbs (Storage Manager copy ID: 1443928323 0).
2009-12-03 18:10:18 98979878 Begin cold level 0 restore blobdbs (Storage Manager copy ID: 1443928321 0).
2009-12-03 18:10:19 98969878 Completed cold level 0 restore logdbs.
2009-12-03 18:10:19 98969878 Process 98969878 completed.
2009-12-03 18:10:19 98999878 Begin cold level 0 restore geo3d_dbs (Storage Manager copy ID: 1443928322 0).
2009-12-03 18:10:21 98979878 Completed cold level 0 restore blobdbs.
2009-12-03 18:10:21 98979878 Process 98979878 completed.
2009-12-03 18:10:26 98989878 Begin cold level 0 restore geo3d_data2 (Storage Manager copy ID: 1443928324 0).
2009-12-03 18:10:27 98999878 Completed cold level 0 restore geo3d_dbs.
2009-12-03 18:10:27 98999878 Process 98999878 completed.
2009-12-03 19:48:43 1017410172 /u01/informix/bin/onbar_d -b -l
2009-12-03 19:48:47 1017410172 Begin backup logical log 679.
2009-12-03 19:48:47 1017410172 Successfully connected to Storage Manager.
2009-12-03 19:48:49 1017410172 Completed backup logical log 679 (Storage Manager copy ID: 1443928347 0).
2009-12-03 19:48:49 1017410172 /u01/informix/bin/onbar_d complete, returning 0 (0x00)
那位碰到过这种情况，是什么原因呢？ 你在onbar回复中使用了-n选项，这是一种特殊的时间点恢复，它要求必须恢复所有的dbspace以保证数据库的一致性。所以你加的rootdbs其实是被忽略的。 明白，谢谢。
我使用onbar -r -t "2009-12-03 14:00:00" 时恢复，提示错误：
2009-12-04 09:06:41 1278812786 Invalid Point In Time value specified: .
不知道啥原因，怎么解决俄u？
另外，问一下，是不是基于某个dbspace 进行恢复到某个日志点的不完全恢复不能实现呀？
回复 #3 wysfenghuo007 的帖子
备份时加上-w，则时间点就没有什么限制了；否则就要查ixbar里面的记录了。不明白你为何需要恢复某个dbs到n个log，日志是一整体的，试想如果一个表分布在多个dbs上，你只恢复其中一个dbs到指定日志，那么这个表的数据如何保持一致呢？如果只是为了恢复dbs上面的表到指定日志或时间点，建议你用onchecker吧。
[ 本帖最后由 3sane 于 2009-12-4 19:53 编辑 ] 原帖由 3sane 于 2009-12-4 19:52 发表 http://bbs3.chinaunix.net/images/common/back.gif
备份时加上-w，则时间点就没有什么限制了；否则就要查ixbar里面的记录了。
不明白你为何需要恢复某个dbs到n个log，日志是一整体的，试想如果一个表分布在多个dbs上，你只恢复其中一个dbs到指定日志，那么这个表 ...
是archecker ~
页:
[1]