ADSM-L

Re: [ADSM-L] DB Mirroring - Poll and question

2008-08-20 14:15:20
Subject: Re: [ADSM-L] DB Mirroring - Poll and question
From: "Huebner,Andy,FORT WORTH,IT" <Andy.Huebner AT ALCONLABS DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 20 Aug 2008 13:13:43 -0500
Hardware mirroring and application mirroring serve slightly different
purposes.  TSM mirroring saved our bacon once, the hardware mirrors did
not.

Andy Huebner

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Howard Coles
Sent: Wednesday, August 20, 2008 11:26 AM
To: ADSM-L AT VM.MARIST DOT EDU
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?


This e-mail (including any attachments) is confidential and may be legally 
privileged. If you are not an intended recipient or an authorized 
representative of an intended recipient, you are prohibited from using, copying 
or distributing the information in this e-mail or its attachments. If you have 
received this e-mail in error, please notify the sender immediately by return 
e-mail and delete all copies of this message and any attachments.
Thank you.