As the saying goes "In a perfect world.......". I agree on not running client backups during expiration and that is how it starts out (beginning at 8am Saturdays), but invariably runs into the next backup cycle.
These machines have 8GB RAM and are dedicated to TSM. Quad 3Ghz processors. RH Linux 4 (old - new is RH 5) SMP. I have been tweaking BUFFPOOLSIZE and it is currently set to 1.5GB (IIRC, performance docs say 1/8 to 1/4 of RAM). Howard Coles <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 08/20/2008 12:28 PM Please respond to "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] DB Mirroring - Poll and question IF you have your db on hardware mirrored disks then creating a mirrored DB will not help you. However, some general guides are to have multiple, smaller db volumes, as this allows more concurrent processes to run against the db. Also DO NOT run client backups while expire is running, it slows everything down (or so has been my experience). I normally use 20 GB volumes or smaller and have more of them on AIX machines, and this works well. The question is how much RAM/Processor power does that Linux box have? Check your buffpool page settings, and make sure there are enough of them. See Ya' Howard > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf > Of Zoltan Forray/AC/VCU > Sent: Wednesday, August 20, 2008 11:15 AM > To: ADSM-L@VM.MARIST.EDU > Subject: [ADSM-L] DB Mirroring - Poll and question > > I am curious how many folks use TSM to mirror their databases? Do you > use "parallel write"? > > As I experiment with my new server (see previous email about testing > expiration), I wonder if the DB mirroring and parallel writing on my > production servers is causing such a large difference in EXPIRE > INVENTORY > processing. > > On my big, 194GB production Linux server, an EXPIRE INVENTORY runs 40- > 48 > hours. Granted, the server is very busy performing other tasks such as > client backups, stgbackups and such. The DB buffers and such are > configured identically to the production server. > > On my first test expire run on my new test server (to which I reloaded > the > 194GB production DB), the expire ran in 10-hours - 1/4 of the usual > time. > > Besides the obviously idle server, I am wondering what else effects the > expiration run time. > > In this stage of the test configuration, I configured a single 194GB > DB > volume vs the production server which has had it's DB grow in > increments > and therefore is comprised of 10+ volumes. > > The test system is not mirroring the database (this will be in the > second > test). > > So, what else could be causing a major impact on the expire inventory > process? > > The old "performance and tuning" guides used to recommend multiple DB > volumes (concurrent I/O?) as well as mirroring. Are these still good > ideas for todays Linux servers, especially since I can't put each DB > volume onto separate spindles/disks. If all I have is one, internal, > physically mirrored (RAID 0/1) HD for the DB primary volumes, are > multiple > volumes causing lots of head-contention/movement? > > Your thoughts on this?
