We had the same issue until going to v6.3. DB reorgs were frequently the cause of the problems. We had the ALLOWREORGTABLE server option off to help prevent this, although there's a long-term performance hit from that as well.
If you look in your TSM instance directory, you'll find a db2dump/db2diag.0.log file that you can tail to confirm that. It'll log every time reorganization starts and stops, along with other interesting details. -- Skylar Thompson (skyl...@u.washington.edu) -- Genome Sciences Department, System Administrator -- Foege Building S046, (206)-685-7354 -- University of Washington School of Medicine On 03/22/13 01:38 PM, Prather, Wanda wrote:
Could the active log also be filling because the archive log was full? There are known issues with DB backup triggers in 6.2.2. (although we're Windows, I think the problem is the same) We've seen cases where the server would just fire db backup after db backup after dbbackup, because the active log was getting full. As the db backup doesn't clear the active log anyway, it was pointless. That's fixed in 6.2.5, we haven't seen it since the upgrade. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Roger Deschner Sent: Friday, March 22, 2013 2:01 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Second full DB backup triggered while first was still underway The Archive Log got to 80% full, so it triggered a full TSM DB backup. So far, so good. However, as the first one was finishing, and before it could empty the Archive Log, a second full TSM DB backup was triggered. For a short while, there were two full TSM DB backups running. This second backup was a pointless duplicate, and may possibly be corrupted. It appears there is a window where the trigger does not know that a full DB backup has just been run. TSM Server 6.2.2.30 on AIX 5.3. Roger Deschner University of Illinois at Chicago rog...@uic.edu ======I have not lost my mind -- it is backed up on tape somewhere.=====
