来讨论一个recovery的问题

wangzhonnew

for catalog that is easy, db2initdb can be used to change database name and then users can just catalog it with a different name

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?
do you know if the "BACKUP SYSTEM" will suspend io write activities during the backup?
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)

wangzhonnew

that is interesting to know db2 for z support this kind of recovery strategy don't know when this kind of feature can be port to LUW

askgyliu

原帖由 Pythagoras 于 2008-11-19 07:49 发表
why db2 doesn't know anything about this flashcopy
Because this flashcopy is NOT triggered by DB2, there is no info stored in the DB2 catalog or anywhere. Other words, this flashcopy is taken from the OS side, out of DB2 control.

This is precisely the key point.

Let's back to the original question posted by Wangzhonnew. What does the "flashcopy" or OS Copy of the database files mean when Wangzhonnew posted the question? I assume what he means is some kind of flashcopy technique commonly known in the storage management, but not the "flashcopy triggered by DB2"?

It does not really matter by whom or where the flashcopy is triggered, but the precedure of the trigger is important.

When "flashcopy triggered by DB2", what is exactly fired off? Like in Wangzhonnew's follow-up question, does such flashcopy triggered by DB2 incur any IO suspection to the database before the storage level flashcopy is fired?

Now can we conclude that a pure storage level flashcopy does NOT guarantee any database consistency, and is not a valid backup solution?

[ 本帖最后由 askgyliu 于 2008-11-22 22:56 编辑 ]

askgyliu

原帖由 wangzhonnew 于 2008-11-18 21:54 发表
and askgyliu, may i ask what kind of test you did for "However, I will not be able to use an image created with copy-without-write-suspend to recover the database."?
Did you use something like "consistency-group" introduced in ibm flashcopy to make sure the image is consistent at FS level? (i'm not the man for storage, the bottomline for this is that we need to make sure the image of the copy is consistent at filesystem level, all pages must be sync for a particular point-in-time)

I only did a simple test, created the database into the instance home directory, and "tar" the whole directory with and without write suspect to the database. And the image with write suspect was recoverable, while the image without write suspect could not be recovered.

I assume your flashcopy is meant at the storage level, and as in my previous post, I take a storage level flashcopy as a faster way to create a synchronized image copy, while OS command copy is a slower way to synchronize the image.

You may also notice that flashcopy by itself it NOT instantaneous. Flashcopy also takes some seconds or even hours to synchronize the image.

Don't get what you mean by "all pages must be sync for a particular point-in-time)"?

askgyliu

原帖由 棉花糖ONE 于 2008-11-18 22:55 发表
这讨论的和oracle的instance recovery和media recovery没多大区别吧

There is some difference here.

For Oracle media recovery, the backup image must be taken after the database or tablespace is put into the backup mode. And my point is the similar in DB2 is to put the database into write-suspect mode before the backup image is taken.

The question from Wangzhonew is whether a flashcopy without db involvement is recoverable while the database is running, and my answer is "no".

Pythagoras

When "flashcopy triggered by DB2", what is exactly fired off? Like in Wangzhonnew's follow-up question, does such flashcopy triggered by DB2 incur any IO suspection to the database before the storage level flashcopy is fired?

No, it dose NOT incur any IO suspension. The only difference I know is DB2-trigger flashcopy will record something in the catalog (for restore/recovery) while OS-trigger flashcopy not.

You may also notice that flashcopy by itself it NOT instantaneous. Flashcopy also takes some seconds or even hours to synchronize the image.
Don't get what you mean by "all pages must be sync for a particular point-in-time)"?

Flashcopy, to a certain extent, is instantaneous. Flashcopy DOES take seconds, minutes, even hours, but that is in background. And the resultant disks made by split mirror are all at the same time, exactly. So, all pages are sync for a particular point-in-time.

whether a flashcopy without db involvement is recoverable while the database is running

My answer is YES or NO, see my posts before.

askgyliu

Just some comparison to Oracle. When Oracle puts the database into backup mode, the database is still available for online transaction, i.e. no IO suspection to the database, but the redo log volume is much higher as Oracle needs to record more information in order to recover the database should there be a need.

Traditionally, DB2 for LUW uses db2 backup command to take the database backup, and now the image cloning option is available with the write-suspection to the database, i.e. the database is NOT available for online transaction when the synchronization is still in process.

If the flashcopy triggered by DB2 for z/OS does record some information in the catalog, for recovery purpose, theoretically I can understand that should be a working option if proper logging is done, just like what Oracle has implemented.

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

The question posted is regarding whether some OS level file system backup, being it flashcopy or OS copy or the like, but NOT involved any database action, can be used to recover a database. And my answer is "NO", the reason being is that the OS level file system backup (without DB intervention such as write suspect to the DB2 for LUW, or triggered by DB2 for z/OS - this in turn triggers some action at DB2 catalog) can not guarantee the database consistency, and the file system IO has NO relationship to database transaction in nature.

askgyliu

原帖由 wangzhonnew 于 2008-11-9 11:54 发表

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

DB2/Oracle always use write-ahead mechamism, i.e. the transaction will be record in the log file before it can be committed, hence the memory can be flushed. When the instance crashes, there should not be any lost of commited transactions if all the log files are still available.

However, "crash recovery" is essentionally different from OS level copy when the database is still only. When system crashes, the system is forcefully "write suspect".

Even the storage vendor can provide a snapshot of the database (without IO suspection) while the database is still online, and provide some mechamism to recover the storage to the latest status or PIT,  the whole solution will be very complex, and the ROI needs to be justified in a hard way.

With that said, I do see that some storage technique is available to have a snapshot of the database without any additional IO incurred in the online database, such as IBM Global Mirroring. But this is usually used as DR plan, not the regular db backup method. And IBM Global Mirroring requires a sequence of actions (IO suspected in the mirroring if I remember correctly  and other actions) before a working database can be restored.

Another issues with such solution is, as far as I know, there is no way to roll forward the database, i.e. the restored database always must be a snapshot, and can not rollforward any further. Maybe Wangzhonnew can check out from IBM?

askgyliu

The book "Backup & Recovery" has some interesting discussion of how Oracle hot backup works at pages 440 to 443, i.e. puting DB into the backup mode, and takes a copy of the data files while the database is still running, and how Oracle knows to recover such files.

http://www.amazon.com/Backup-Rec ... 27622284&sr=8-1

This should have answered Wangzhonnew's original question.

wangzhonnew

原帖由 askgyliu 于 2008-11-24 21:44 发表


Another issues with such solution is, as far as I know, there is no way to roll forward the database, i.e. the restored database always must be a snapshot, and can not rollforward any further. Maybe Wangzhonnew can check out from IBM?

i think db2inidb can set the FS split mirrow to standby status:
http://publib.boulder.ibm.com/in ... 9%6e%69%64%62%22%20

it sounds like people can do rollforward on it:
# Roll the database forward to the end of the logs or to a point-in-time.