Well, so far my experimenting with this brand new, totally unused, freshly
loaded DB, has yield some interesting results.

The first run with a single 194GB DB (versus the production which has many
smaller DB volumes to comprise the 194GB) took 12-hours.  There were no
DBcopies.

The second run (2-days later to allow some things to expire) with DBcopies
on a separate physical volume, took 11-hours.

So basically, even if I tried to run an expire every day, it would still
encroach into the daily backups, significantly slowing them down.

My next trick is to increase the BUFPOOLSIZE to 2GB (up from 1.5GB) and
see if that makes a significant improvement.

It seems I have hit a structural/performance limit, which is why I have
this new server - to move things off this server. Unfortunately, we have
some heavy-hitters (one node has over 50M entries).



Nicholas Rodolfich <NRodolfich AT CMAONTHEWEB DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/20/2008 05:33 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






WOW, the 342 Million files is what is killing you but it still seems like
an excessive amount of time. You mentioned Saturday as when it starts. You
are running expiration daily aren't you? You should be able to run
expiration and reclamation to completion each day or you need to look at
another instance or configuration to meet your resource needs. If you
don't
complete expiration and reclamation daily, you will be queueing up
unfinished work each day that will turn into a 24-48 hour expiration
run(sounds like you are there). Expiration and reclamation go
hand-in-hand.
If your expiration doesn't complete then you reclamation can't either. As
a
result, you may have a good number of un-reclaimed and un-expired entries
in your database. BTW, I have always been told, by my TSM mentors, that
due
to the database intensive nature of expiration, that it should always run
by itself.


Define LOTS?

My specs are:

194GB DB
206TB Occupancy
342,194,690 files





"Schneider, Jim" <jschneider AT USSCO DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
08/20/2008 01:58 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






We need 4-6 hours for 90GB DB, ~100 clients.  The servers have LOTS of
files.

-----Original Message-----
From: ADSM: Dist Stor Manager
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] DB Mirroring - Poll and question

48 hours sounds like an awfully looong time to me.
On my busiest Linux server (90gb DB, ~100 clients) expiration completes
in 20-30 minutes.

-----Original Message-----
From: Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] DB Mirroring - Poll and question


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.