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 <Howard.Coles AT ARDENTHEALTH DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/20/2008 12:28 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT 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:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Zoltan Forray/AC/VCU
> Sent: Wednesday, August 20, 2008 11:15 AM
> To: ADSM-L AT VM.MARIST DOT 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?