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-
I saw these on this page:
http://www.lascon.co.uk/d005002.htm
Also, The latest performance tuning guide database performance section:
http://publib.boulder.ibm.com/infocenter/tivihelp/v1r1/index.jsp?topic=/com.ibm.itsmm.doc/b_perf_tuning_guide27.htm
Regards,
Shawn
___
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 ti
No, we don't run it daily, since it runs so long and slows everything else
down.
I had thought about running timed expires, daily. Maybe it's time to turn
that on.
Nicholas Rodolfich <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager"
08/20/2008 05:33 PM
Please respond to
"ADSM: Dist Stor
Why not use some old IBM scripts when comparing performance???
The scrips was orginally published under "How to determine when disk
tuning is needed for your ITSM server"
at http://www-1.ibm.com/support/docview.wss?uid=swg21141810. See
discussion at
http://www.mail-archive.com/adsm-l@vm.marist.ed
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
(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:[EMAIL PROTECTED] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L@VM.MARIST.ED
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 in
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:[EMAIL PROTECTED] On Behalf Of
Howard Coles
Sent: Wednesday, August 20,
Define LOTS?
My specs are:
194GB DB
206TB Occupancy
342,194,690 files
"Schneider, Jim" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager"
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L@VM.MARIST.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 [mailto:[EMAIL PROTECTED] On Behalf Of
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] DB Mirroring - Poll a
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 <[EMAIL PROTECTED]>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L]
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 Linu
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
eve
Mirrored DB and log volumes. Parallel write is on.
Andy Huebner
-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 questio
15 matches
Mail list logo
