I've seen this recommendation grow over time. The Storage Symposium
presenter, who mentioned it the last time I heard it, said its just a
general number they come up with that is tied to the average server that
TSM is installed on. It's a rule of thumb. As the hardware gets more
powerful over time, they increase this number.
So if you have a monster server that is above the "average" of what people
have out there, you can definitely go above 120gB.
Judge if your db size is appropriate based on DB performance with YOUR
data, such as expiration time, database backups, etc
Regards,
Shawn
________________________________________________
Shawn Drew
Internet
acompton AT ASPENPHARMA DOT COM
Sent by: ADSM-L AT VM.MARIST DOT EDU
08/21/2008 03:32 AM
Please respond to
ADSM-L AT VM.MARIST DOT EDU
To
ADSM-L
cc
Subject
Re: [ADSM-L] DB Mirroring - Poll and question
Hi,
I remember reading somewhere that a TSM DB should ideally not be allowed
to grow passed 120GB before having another instance of TSM.
You will find that you will have a major problem should you have to run
an AUDITDB for example if you ever have errors in your DB. Instead of
hours or a day, you would face an AUDIT of weeks, which happened to a
TSM user in South Africa a while back.
I would look into splitting the Server up.
Regards
Adrian Compton
Aspen Pharmacare Port Elizabeth
tel: +2741 4072855
Fax: +2741 453 7452
Cell: +27823204495
Email: acompton AT aspenpharma DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, Jim
Sent: 21 August 2008 00:06 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] DB Mirroring - Poll and question
(using small voice) I guess it's not "lots." 124,858,663 files, 131 TB
occupancy, 90 GB database, ~100 clients.
Jim
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
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.
This message and any attachments (the "message") is intended solely for
the addressees and is confidential. If you receive this message in error,
please delete it and immediately notify the sender. Any use not in accord
with its purpose, any dissemination or disclosure, either whole or partial,
is prohibited except formal approval. The internet can not guarantee the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will)
not therefore be liable for the message if modified. Please note that certain
functions and services for BNP Paribas may be performed by BNP Paribas RCC, Inc.
|
