DB2 Storage

DB2 and HSM

This page discusses how DB2 works with z/OS archiving products like DFHSM and FDRABR. These products are designed to manage your disk space efficiently by moving data sets that have not been used recently to less-expensive storage. They can also be used for disk level backup and recovery and can delete data sets automatically based on retention settings. An HSM tool can save you money by migrating unused data off to tape, but with databases, it is essential that you do not compromise performance to save a bit of money. DB2 data can be carved up as follows.

  • System files, like the Catalog , BSDS and Active logs are definitely not HSM candidates as the system will grind to a halt without them.
  • Archive logs are HSM candidates, but duplex copies need to be kept on different ML2 tapes. Best bet is to assign a management class to the copy2 version, which puts it straight off to tape, while letting the copy1 version live a day or so on disk. That should ensure they don't end up on the same ML2 tape. If you use HSM to expire the logs, make sure the retention period matches the ARCRETN value in DB2.
  • Image copies are probably going to be created on tape. If your tape is system managed, then make sure the expiration of image copies is consistent with the expiration of archive logs, and the whole lot is recorded in DB2 by the MODIFY utility.
  • Online Production databases are probably best left alone. There is nothing in principle to stop batch databases from being HSM managed, but they should not be deleted by HSM
  • Development databases can be successfully managed with HSM. The only caveat is that they should not be scratched by HSM, or any other non-DB2 utility. This is because the user databases and logs are all defined in the DB2 Catalog, and if they are deleted externally, DB2 doesn't know about it. One potential issue with DB2 and HSM, is that if your DB2 databases are maintained by a utility generator, then some generators reset all the access dates, which means the databases never get migrated. Or even worse, you have a lot of migrated databases, and you install a utility generator. On the first run, it recalls all your files. If you use a utility generator, try to get one which is HSM aware.

For DB2 to recognise archived files, you need to set RECALL=Y in the DSNZPARM parameter. DB2 can recall user page sets that have been migrated. Whether DFHSM recall occurs automatically is determined by the values of the RECALL DATABASE and RECALL DELAY fields of installation panel DSNTIPO. If the value of the RECALL DATABASE field is NO, automatic recall is not performed and the page set is considered an unavailable resource. It must be recalled explicitly before it can be used by DB2. If the value of the RECALL DATABASE field is YES, DFSMShsm is invoked to recall the page sets automatically. The program waits for the recall for the amount of time that is specified by the RECALL DELAY parameter. If the recall is not completed within that time, the program receives an error message indicating that the page set is unavailable but that recall was initiated. Whether DFSMShsm recall occurs automatically is determined by the values of the RECALL DATABASE and RECALL DELAY fields of installation panel DSNTIPO. If the value of the RECALL DATABASE field is NO, automatic recall is not performed and the page set is considered an unavailable resource. It must be recalled explicitly before it can be used by DB2. If the value of the RECALL DATABASE field is YES, DFSMShsm is invoked to recall the page sets automatically. The program waits for the recall for the amount of time that is specified by the RECALL DELAY parameter. If the recall is not completed within that time, the program receives an error message indicating that the page set is unavailable but that recall was initiated.

DFHSM has a free space release facility, but it will not work on DB2 databases. FDRCPK can do this, and I've found this very useful when a development DB2 pool is running out of space. If the database is open, FDRCPK will not touch it, but as most development databases are stopped, FDRCPK will free up a lot of space.

You can use DB2 BACKUP SYSTEM and RESTORE SYSTEM utilities, which backup DB2 databases at volume level, and uses DFSMShsm for the back up and restore functions. However this relies on all the DB2 data sets existing on SMS managed volumes. IBM warns that if you use the BACKUP SYSTEM utility to create system-level backups, then you must not use DFHSM to migrate DB2 table spaces and indexes. Image copy backups seem to be a better option.

Finally, DFHSM can be used to assist with image copies. see the DB2 Image Copy section for details