ANR0380W The database buffer pool recovered from an overcommit of 867 pages. Consider increasing your buffer pool size by 3468 kilobytes

This error occurs when the BUFPOOL is incorrectly sized or SELFTUNE is enabled and the server has been recently restarted - Check the following:

• Is SELFTUNEBUFPOOLSIZE YES in use in the dsmserv.opt?
  
  tsm:> query opt
  
• What is the default configured BUFPOOLSIZE?
  
  tsm:> query opt
  
• What is the the current BUFPOOLSIZE and is SELFTUNE enabled?
  
  tsm:> query db f=d
  
  Multiply the buffer pool pages by 4096 and then divide by 1024.
  

On AIX if BUFPOOL is currently set to less than 10% increase the value by editing the dsmserv.opt, otherwise increase BUFPOOL by the amount specificied (3468K) and then restart the server.

Bad Friday!

Word to the wise! Whenever defining an immediate action schedule be VERY careful not to do what I accidentally did....

DEFINE CLIENTACT

That's all I typed when I accidentally hit return and it issued an immediate action schedule for EVERY client in EVERY domain! Now I think I was aware of this, but I must have forgotten as I repeatedly yelled "CRAP!" as I saw the define results scroll across the screen. Good thing I have a handy shell script to manage things like deleting those schedules when they were created. Still a number of them kicked off even when I thought I had gotten them all.

ACSLS Not Really Ready For Library Sharing!

So we have a large ACSLS library at one of our data centers and we decided to use library sharing with 5.3. Tivoli stated that in 5.3 ACSLS is now supported in a library sharing environment. So we setup library sharing and proceeded to also setup DRM to handle our offsite tape rotation. Now I have used IBM equipment almost exclusively when I was with IBM so this ACSLS stuff is new to me, so when MOVE DRMEDIA did not seem to be working I immediately thought it was an ACSLS issue. The problem was that when we ran a MOVE DRMEDIA the library would only checkout one tape at a time. We have two 40 tape I/O doors so why it would only check out one tape at a time was puzzling(it would wait until the tape was removed from the I/O door before checking out the next tape). So I called Sun/STK and was told it was a software issue. So when I called Tivoli it took days before someone found the issue was in fact TSM. The APAR is IC45537 which states that TSM library clients do not currently support the concurrent checkout of multiple volumes. There was a local work around which entailed using MOVE DRMEDIA REMOVE=NO from the library client, checking them back in on the library controller, and then checking them out on the library controller. It's a mess of a script but it works. This APAR was released in April of 2005 yet I am still having to use a local work around. It just drives me nuts! Especially because the problem was not one that even Tivoli support easily found. Let's hope there is an actual fix in 5.4 but I'm not betting on it.

MOVE DRMEDIA from shared ACSLS library

OK, so I my work has an ACSLS library shared by 7 instances of TSM and my move drmedia commands fail. I have tried it with and without the cap= option and also have used remove=bulk and remove=yes. The volumes fail to checkout and the ACSLS documentation I have found so far does not cover shared ACSLS checkout. Any help is appreciated.

GPFS Revisited

Well I am still having issues with GPFS. It turned out the mmbackup wont work with the filesystem size either and a chat with IBM support was not encouraging. Here is what one of our System Admins found out:

The problem was eventually resolved by IBM GPFS developers. It turns out, they never thought their filesystem would be used in this configuration (i.e. 100,000,000 + inodes on a 200GB filesystem). During the time the filesystem was down, we tried multiple times to copy the data off to a different disk. Due to the sheer number of files on the filesystem, every attempt failed. For instance, I found the following commands would have taken weeks to complete:

# cd $src;find . -depth -print | cpio -pamd $dest
# cd $src; tar cf - . | (cd $dest; tar xf -)


Even with the snapshot, I dont think TSM is going to be able to solve this one. This will probably need to be done at the EMC level, where a bit level copy can be made.

So GPFS is not all it was thought to be. So pass it along and make sure you avoid GPFS for application that will produce large numbers of files.

Looking For Contributors

If you work in a large TSM environment and have experienced issues or tasks that you think passing along would help others please let me know. I am looking for contributors to keep this blog current and make it more open. Send me an e-mail with contribution ideas (you'll need more than 1) and what type of environment you work in.

CDP For Unix?

Has anyone heard of when (if ever) Continuous Data Protection for Files will be available on the Unix platform? I could really use this feature with my GPFS system. Since the application creates hundreds of meta data files daily and is proprietary (hence no TDP support) I am getting killed by the backup timeframe since the each volume has in excess of 4 million files already and incrementals take close to 48hrs. to finish. Anyone heard anything at symposiums or seminars?