来讨论一个recovery的问题

wangzhonnew

一般我们都知道，当数据库在线的时候所作的OS级别的文件系统备份是不能够用来恢复数据库的，现在俺的问题就是：WHY?

理论上来讲，如果文件系统级别的备份能够前滚到某一个特定时间点保证文件系统级别的一致性，当activate数据库的时候crash recovery不是理论上也应该能够recover么？
从文件系统的备份恢复到某一时间点与操作系统断电产生的crash有什么本质的不同，从而使得文件系统备份不能被用来恢复数据库呢？

象征性悬赏10分，奖励第一个回答正确的同学

Pythagoras

so you said in db2 for z, users even doesn't need to stop the database to do backup? and ibm supports that kind of backup strategy?
No, user DOES NOT need to stop the database when running BACKUP SYSTEM utility, it is so-called an ONLINE utility.
IBM absolutely supports this kind of backup strategy, and has a corresponding utility named RESTORE SYSTEM to recover to the PIT. However, this backup method is system scope, meaning that you can't backup a subset of data, but an entire database system. In V8, you even can recover the entire system only, in V9 you can do object-level selective recover based on system-level backup, thru RECOVER utility.
And I think this kind of backup/recover is prompted by some ERP (like SAP,People Soft) customer's requests, and it is a good method to replicate data.

do you know if the "BACKUP SYSTEM" will suspend io write activities during the backup?
No, it is an online utility, backup triggers flashcopy (or compatible disks tech) running background. There is NO impact on service availability, but some disks IO performance degrade is inevitable.  

what happen if we just run a backup from storage  (so db2 doesn't know there's backup), the backup will copy all files used by database and instance, and then can we use this set of backup to "recatalog" and recovery? (of course it's not restore, just crash recovery)
There is no need to recatalog, you have made a disk mirror including complete set of files, then you just restart your DB2 from this mirror, DB2 plays "recovery" automatically when restarted, like a crash recovery.

[ 本帖最后由 Pythagoras 于 2008-11-19 11:10 编辑 ]

jayciedede

狼所指的OS级别的文件系统备份是不是文件系统直接copy?

wangzhonnew

不一定是文件系统的cp，有的时候从文件系统直接用厂商提供的工具作备份比如flash copy之类的。总之就是不用db2得backup，而是用文件系统的备份工具来备份，然后恢复的时候可以根据文件系统级别的增量备份恢复到某一个特定时间点

myfriend2010

也许os的copy 不能把数据库的不一致的数据记录下来，
数据库备份的时候把内存中的工作单元进行了备份！这样当数据库恢复的时候就能找到不一致的数据进行恢复~！
而os的备份，只是对数据文件的备份~！恢复的时候db找不到内存中不一致的unit of work!

myfriend2010

我猜的啊~！等狼定夺！~

wangzhonnew

原帖由 myfriend2010 于 2008-11-9 12:49 发表
也许os的copy 不能把数据库的不一致的数据记录下来，
数据库备份的时候把内存中的工作单元进行了备份！这样当数据库恢复的时候就能找到不一致的数据进行恢复~！
而os的备份，只是对数据文件的备份~！恢复的时候db找不到内存中不一致的unit of work!

不完全正确：）
内存中的数据可以通过crash recovery来恢复。我们的前提已经假定可以把数据文件与日志和控制文件恢复回滚到某一个特定的时间点，而db2是会在向数据文件里面写东西之前先写log，这样在transaction log里面没有提交或者已经提交而没有刷新的东西都是已经存在的，所以crash recovery理论上应该能够完全恢复的，不是么？

unixnewbie

Simply because write IO consistency. As long as write IO suspended, file system level backup, i.e. flashcopy etc. would be fine to rebuild a consistent DB.

myfriend2010

unixnewbie 专业

wangzhonnew

but what happen if user didn't do IO suspend? (of course we all know it will be fine if user used IO suspend, the question is, why it's not support for such backup/recovery strategy if the database was still running)

if there are still applications connecting to the database and insert/update/delete, and users just use flash copy to create consistence-group FS backup (that means all files are consistent at a specific point-in-time, include data file, transaction logs and control files), why users cannot use this image to rebuild database? (in theory, users can use crash recovery to make transaction level consistency after the file systems being restored, correct? )