Monday, November 29, 2010

TSM Database Page Shadow File

The Tivoli Storage Manager database has a file calle the Page Shadow File (dbpgshdw.bdt).  This file is a mirror of transactions that are written to the database.  This occurs only if two options are enabled in the Server Options file (dsmserv.opt). 

DBPAGEShadow Yes

MIRRORWrite DB Parallel

By default TSM installs with the first set to Yes and the second set to Sequential.  This causes the Page Shadow File to not be used.  However, even with the Parallel option being chosen, the Yes option still causes the Tivoli system to require that file.  In fact, one of the big ways I have seen a Tivoli Storage Manager database to get corrupted is having the parameters set as above and then some process lock the Shadow File.  I have seen machine backups that lock each file as they are backed up do this.  When that happens, you better have a good current back up of the database available.

The Page Shadow File is implemented in TSM to help with high volume systems that may get overwhelmed in database updates.  The transactions are written to this file allowing them to be picked up later and processed when there is less system activity.  If you have a system with heavy activity like this, I would encourage use of the shadow file.  I would make sure it is in a location where the system backup will not be touching it.  There is no need for this file to be backed up, and as I said above, locking this file is dangerous.  The location of this file can be determined int he dsmserv.opt.  By default the TSM server looks for it in the server directory that was created when the server instance was created.  By changing the entry to a fully defined path, it can be relocated to any directory on the server. 

If your system is not high volume, I would reccomend changing the default DBPAGEShadow from Yes to No.  Once this is done, you can delete the file and all is fine.  Or it can be left alone since the system will no longer look for it.  This will keep any harm from this file and keep it from causing database corruption if the file is inadvertantly locked by another program.

Wednesday, November 24, 2010

Copy Storage Pools

OK, you have TSM backing up your entire enterprise.  All important data from data from the workstations and servers in your business is being efficiently stored in storage pools on a large san unit.  Each day people are restoring items that were deleted by accident or were needed after it was thought they were no longer needed.  All is going wonderfully.  Right up until a disk gets corrupted in the san.  But they are mirrored?  Guess what?  The corruption was mirrored as well. (Seen this happen).  Now you can spend days getting the affected storage pools recreated.  And since the storage was spread across multiple drives, this means a lot of the storage pools are damaged.

So what would copy storage pools do for this?  If the copy storage pools were available, the TSM system would simply get the files it was looking for from the copies and start automatically recreating the damaged files.  The copy storage pools can also be used to totally recreate any damaged storage pools.  But the main thing is that while files may be restored slightly slower, the users will never actually know that anything happened.  They will get their files restored and no one will be calling for support.