![]() ![]() ![]() Each db2bm thread will process one tablespace at a time until all of the tablespaces are backed up. The backup will then start to read from the tablespaces largest to smallest (as we know the largest will take the longest to process) from the beginning to the end (high water mark) of the used extents in the tablespace. In addition, it will allocate a number of backup buffers from the utility heap (UTILHEAP) to buffer the data between the readers and writers which is again either calculated by DB2 or provided in the command. ![]() It will allocate a niumber of media writers based on the number of targets or sessions defined in the backup command. The backup coordinating agent will allocate a number of tablespace readers (db2bm threads) based on the calculated parallelism or the user defined values. The basic method for reading from the tablespaces and writing that data to the backup media is the same for both. There are two types of DB2 backups offline (no changes allowed in the database for the duration of the backup) and online (changes are allowed during the backup). The DB2 online backup and restore has the ability to back up that moving target and then using the transaction logs, bring it to a consistent point (the end of the backup or later) at the end of the restore and rollforward process. ![]() There is no guarantee that a DB2 page will be consistent internally, much less in sync with it's neighbors on disk. Unless DB2 is paused (write suspended) for a filesystem snapshot of all the neccesary paths (typical SNAPSHOT backup) a standard filesystem backup is backing up a moving target, each file block will be copied in the state it's in when the OS backup reads that block from the file. First and foremost, a filesystem backup is no substitute for a DB2 backup. I have been asked about backup and restore (including performance) in the past few weeks and wanted to explore the backup and restore from a DB2 perspective. ![]()
0 Comments
Leave a Reply. |