Notes On Backup and Recovery :
On the left you can see the DB2 table spaces and their associated containers.
When you invoke the BACKUP utility, the db2agent process is spawned to control the flow between the buffer manipulators (the db2bm processes are used to read data off disk and into shared memory) and the db2med process (which reads from shared memory and writes the pages out to the target devices).
There are no restrictions with respect to how fast these processes will run; however, you can control them in relation to your environment's workload by using the DB2 throttling feature. To architect this utility to run as a fast as possible, the buffer manipulator has been coded such that it doesn't have to give data to a specific device controller. Think of it as a "race" -- DB2 doesn't care in what order the pages are placed on the backup media, just how fast it can get it there.
There is however one level of association: each table space will be assigned to one process that is solely responsible for processing all the data in that table space. The number of buffer manipulators is controlled by the parallelism option used when invoking the BACKUP utility. For example, if you set this option to 2, you will have two db2bm processes that can each read two separate table spaces in parallel.
The db2med processes spawned are equal to the number of targets you give it. For example, with Tivoli Storage Manager, if wanted to open three sessions, DB2 sets up three streams to the Tivoli server. This will help DB2 drive parallelism to the archive media.
If you are backing your data to a file system, and that file system is a virtualization of multiple disks, you should specify the mount point multiple times. For example, in a DB2 for Windows environment, you would enter the command as follows:
Incremental Backup:
Incremental backup first made its way into the product in the V7.2 release. We've been seeing the popularity of this type of backup increasing since it was first introduced -- especially for data warehouses where a small percentage of the data changes.
Incremental backup allows you to back up only index and data pages that have changed since a previous backup.
The exception is for long field and large object data in "dirty" table spaces, which are always backed up.
There is no incremental support for this type of data because these data types have a different physical format than our index and data pages, and currently DB2 cannot determine at backup time if that data has changed. This exception will be removed in a future release of DB2.
From this figure you can see that an incremental backup is really based on the last full backup. This means that an incremental backup taken on Tuesday would include all of Monday's and Tuesday's changes since the full backup (in our example) was performed on Sunday.
Delta backups are based on the last incremental or delta backup. For a delta backup, you need to maintain all the backups taken since the last full backup in order to be able to reconstruct the data. For example, to recover data to the end of business day Wednesday, you would need the delta backup images for Monday, Tuesday, and Wednesday (or Wednesday's log files). If you took an incremental backup on Tuesday, then you would only need the incremental image from Tuesday, and Wednesday's delta backup image (or log files).
In addition to the changed pages, an incremental backup will include the database's metadata (database configuration, history file, table space definitions, and so on) to assist in recovery. This metadata is not incremental; it is a full copy each and every time.
By default, a DB2 database is not configured for incremental backups because there is a very minimal impact on runtime performance that's incurred to enable DB2 to perform this kind of backup. To enable this kind of backup, set the TRACKMOD database configuration parameter to ON (changing this parameter won't take affect until the next database activation).
When TRACKMOD is enabled, the first write operation will mark the data's hosting table space as dirty. If the table space isn't dirty, DB2 won't even look at it when a backup is started. If DB2 sees a dirty bit for a table space, it will go and inspect the extents within the marked table space (they are also marked with dirty bits) and ultimately only pull changed data pages into the backup image. The tracking feature used to support incremental backup is entirely internal and doesn't require any storage considerations.
An incremental backup is not permitted until a non-incremental backup is taken to set a base from which it can recover -- this is to support incremental restore which always requires a non-incremental base image.
DB2 can perform an online or offline backup.
Online backups can run during normal SELECT, INSERT, DELETE, and UPDATE activity against the database. The only restriction when running an online backup in DB2 is that you cannot drop a table space while that table space is actively being backed up.
With an offline backup, DB2 knows that it's the only application reading from the database, and therefore it doesn't need to worry about locks. With an online backup, things are a little different.
DB2 has to implement a locking strategy for an online backup. For large objects and long field data, DB2 escalates Intent None (IN) locks to Share (S) locks and therefore is approximately 10% slower.
An online backup will likely require some more memory from the UTIL_HEAP memory allocation to allocate some internal structures that help support this operation.
The database history file is becoming a more and more crucial part of the database engine. The database history file is a record of administrative operations. It is individually restored from any type of backup image (it is part of the metadata we detailed earlier). Events recorded in this file include operations such as backup, restore, rolling forward of the logs, loads, queiscing of the database or table space, table space alters, and dropped tables (when dropped table recovery is enabled). The information about these operations that are recorded include the objects affected (database, table space, or table), the location and device type (backup image or load copy), range of relevant log files, start and completion time of the operation, and the resultant SQLCA code. Previously this was an informational file that you could query. DB2 now uses this file to support recoverability like automatic restore. The new log manager uses this file as well.
This information is kept in a file and not in a DB2 table because the information is needed for recovery. If the database was ever not available, we could not leverage it for database recoverability. Therefore, the database history is stored in an ASCII file and included in the backup image where we can retrieve and process it.
Third party backup Support :
When "plugged" into a vendor's archive software, instead of writing the backup information to a file, DB2 will write the backup data to these interfaces, sent as a stream of bits directly to the target archive server.
For example, if you're using TSM, then DB2 will load the TSM API, and so on. These libraries are loaded directly into the DB2 kernel and run in our address space. You don't have to worry about the quality of the vendor's plug-in code (as of DB2 V7+FP11) as DB2 will protect the instance address from a failure of a partner's code. In fact, before every operation, DB2 will get the state of the signal handlers before and reset them afterwards. This means that even if the vendor's code traps, the database engine will not go down (obviously the backup operation itself will fail).
0 comments:
Post a Comment