Backup Central

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?

Mirrored DB and log volumes. Parallel write is on.

Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Wednesday, August 20, 2008 11:15 AM
To: ADSM-L < at > VM.MARIST.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.

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

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


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

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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

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

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

Define LOTS?

My specs are:

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





"Schneider, Jim" <jschneider < at > USSCO.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

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

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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.=

(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.EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L < at > VM.MARIST.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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

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.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Schneider, Jim
Sent: 21 August 2008 00:06 AM
To: ADSM-L < at > VM.MARIST.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.EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L < at > VM.MARIST.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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

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 < at > vm.marist.edu/msg51968.html



"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."
Reload = Unload + load DB, or only a restore DB?

//Henrik


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Schneider, Jim
Sent: den 21 augusti 2008 00:06
To: ADSM-L < at > VM.MARIST.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.EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L < at > VM.MARIST.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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you.

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 <NRodolfich < at > CMAONTHEWEB.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 05:33 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > VM.MARIST.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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

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.COM

Sent by: ADSM-L < at > VM.MARIST.EDU
08/21/2008 03:32 AM
Please respond to
ADSM-L < at > VM.MARIST.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.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Schneider, Jim
Sent: 21 August 2008 00:06 AM
To: ADSM-L < at > VM.MARIST.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.EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L < at > VM.MARIST.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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.

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
________________________________________________
Shawn Drew





Internet
SHWL < at > STATOILHYDRO.COM

Sent by: ADSM-L < at > VM.MARIST.EDU
08/21/2008 04:17 AM
Please respond to
ADSM-L < at > VM.MARIST.EDU


To
ADSM-L
cc

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





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 < at > vm.marist.edu/msg51968.html



"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."
Reload = Unload + load DB, or only a restore DB?

//Henrik


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L < at > VM.MARIST.EDU] On Behalf Of
Schneider, Jim
Sent: den 21 augusti 2008 00:06
To: ADSM-L < at > VM.MARIST.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.EDU] On Behalf Of
Nicholas Rodolfich
Sent: Wednesday, August 20, 2008 4:33 PM
To: ADSM-L < at > VM.MARIST.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.COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>
08/20/2008 01:58 PM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L < at > VM.MARIST.EDU>


To
ADSM-L < at > 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
Michael Green
Sent: Wednesday, August 20, 2008 12:48 PM
To: ADSM-L < at > VM.MARIST.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.EDU>
Sent: Wednesday, August 20, 2008 18:14
To: ADSM-L < at > VM.MARIST.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.


-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of
the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and
delete
this message.
Thank you.


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.