Re: Expiration performance TSM 5.5 (request)

[Loon, EJ van - SPLXO]

Hi Daniel!
I'm running 3 servers, the database on one of them was reorganized about a year 
ago. The performance on this server is similar to the other two. 

Thank you guys for all your replies (and questions ;-). I'm leaving for a one 
week holyday this afternoon, I will answer all the questions when I'm back.
Please keep your expiration performance figures coming. TSM Support said that 
more that more than 1000 object/sec is probably not possible, but you proved 
otherwise. It should be possible to at least make it run 8 times as fast.
Kind regards,
Eric van Loon

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel 
Sparrman
Sent: donderdag 16 februari 2012 16:26
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration performance TSM 5.5 (request)

Hi Eric

Out of curiosity, how long has the TSM server existed, and how long has it been 
since you did an unload/load database?

Fragmentation could also be the root cause to expiration taking to long.

Regards

Daniel 


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från: "Loon, EJ van - SPLXO" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 16:19
Ärende: Re: Expiration performance TSM 5.5 (request)

Hi Daniel!
Been there, done that... 
a) We completely redesigned our database layout. Each database file is located 
on one single hdisk, one single vg and one single filesystem. We are using 10 
database volumes and tried everything. LUN's are striped across multiple 
arrays, the backend is using raid 1. Performance of the disks outside of TSM is 
fine: 120 Mb/sec read as long as we do not use mirroring, write even better 
(because of cache) around 180 Mb/sec. Even when we try to imitate TSM (by doing 
4k reads using dd) read performance is fine.
b) Tried several setups for the log too, still no improvement.
c) I think you mean the way the vg is mirrored? All vg's are using parallel.
d) Tried that too, the only effect is that log utilization during the day is 
much lower (of course).
e) Cache hit ration is 99.9% so the bufferpool should be large enough.
I have done extensive I/O analysis along with TSM support, there is no queuing, 
0.0 most of the time...
Thanks for your reply!
Kind regards,
Eric van Loon

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel 
Sparrman
Sent: donderdag 16 februari 2012 15:12
To: ADSM-L@VM.MARIST.EDU
Subject: Ang: Expiration performance TSM 5.5 (request)

Hi

To begin with, the guidelines for database setup is something similiar to:

a) 8-12 primary database volumes (since you're on 5.x you can still use TSM 
mirroring). Each volume should be in it's own filesystem, preferably on their 
own spindles (harddrives). If possible, make sure that your storage group 
assigns you 8-12 volumes from different arrays within the Vmax if possible, or 
at least as many arrays as possible. If they assign you 8 volumes from the same 
array, performance will be horrible.

b) Log should reside on it's own volume(s). Since the log is sequential, 
raid-10 is the optimal setup. 

c) Using DB mirroring in parallell mode will increase performance

d) Using LOG mirroring in normal mode will aswell increase performance

e) Max sure you have enough bufferpool

>From your description, it sounds like a) is the place to start, I wouldnt be 
>surprised if your db volumes are located (some of them or all of them) within 
>the same array.

What operating system are you using? If you're on AIX, try checking I/O 
statistics during expiration to see if your queues are getting full (as in 100% 
utilization of the disks using iostat).  If so, try increasing the queues, and 
go to your storage guys and have them look at the underlying Vmax to determine 
if there are any configuration issues there.

Performance issues with expiration and database backups usually relates to the 
fact that the read-performance of the underlying array is limited.

Best Regards

Daniel Sparrman


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från: "Loon, EJ van - SPLXO" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 15:02
Ärende: Expiration performance TSM 5.5 (request)

Hi TSM-ers!
I'm struggling with the performance of our expiration process. I can't
get it any faster than 100 object/second max. We tried everything, like
using more or less database volumes, multiple volumes per filesystem,
mirroring, unmirroring, but nothing seems to have any positive effect.
We are using SAN at

Re: Expiration performance TSM 5.5 (request)

[Richard Rhodes]

Some things to think about and look at - in no order:
- What kind of response time are your I/O's getting at the  AIX level (ioscan)? 
  
- Check the average sampled read/write times for your luns in the vmax.  You 
should be seeing 1ms writes and <10ms reads (fc tier and flash tier) and slow 
+15ms reads for a sata tier. (going off the top of my head, but that sounds 
like what I see on ours)    
- I assume you have dual paths.  Are you using PowerPath or MPIO.  Pull up nmon 
and see if your I/O's are evenly spread between your hba paths.
- Look at the queue depth for the hba and hdisks.  We find the hba default 
often to be too low for large I/O processing.
- Are your luns on FASTVP in the vmax?  If you have a sata tier/pool, 
expiration could be reading lots of little used blocks that have fallen to the 
lowest tier.  You would see very slow reads in this case for the expiration 
reads.
- Are the front end ports on the vmax overloaded?  We've seen major queuing 
problems in the vmax FA's if iops exceed 20k on a port.  QUite simply - host 
hba's can over power a vmax fa port.  (or multiple host hba's sharing a FA 
port)  I don't think this is it - expiration does a small continious data 
stream, but if the fa port is overloaded you could have a problem.
- Watch the tsm cache hit ratio.  I've seen our say it's 99% when I've looked 
at it during the day.  One night I was in late and saw that during backup 
processing it was way down in the low 90%.  Check it over time.


The single thing above for a quick check on if this is a disk performance issue 
is the vmax sampled average read/write times for your luns.

Rick




-"ADSM: Dist Stor Manager"  wrote: -
To: ADSM-L@VM.MARIST.EDU
From: "Loon, EJ van - SPLXO" 
Sent by: "ADSM: Dist Stor Manager" 
Date: 02/16/2012 10:14AM
Subject: Re: Expiration performance TSM 5.5 (request)

Hi Daniel!
Been there, done that... 
a) We completely redesigned our database layout. Each database file is located 
on one single hdisk, one single vg and one single filesystem. We are using 10 
database volumes and tried everything. LUN's are striped across multiple 
arrays, the backend is using raid 1. Performance of the disks outside of TSM is 
fine: 120 Mb/sec read as long as we do not use mirroring, write even better 
(because of cache) around 180 Mb/sec. Even when we try to imitate TSM (by doing 
4k reads using dd) read performance is fine.
b) Tried several setups for the log too, still no improvement.
c) I think you mean the way the vg is mirrored? All vg's are using parallel.
d) Tried that too, the only effect is that log utilization during the day is 
much lower (of course).
e) Cache hit ration is 99.9% so the bufferpool should be large enough.
I have done extensive I/O analysis along with TSM support, there is no queuing, 
0.0 most of the time...
Thanks for your reply!
Kind regards,
Eric van Loon

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel 
Sparrman
Sent: donderdag 16 februari 2012 15:12
To: ADSM-L@VM.MARIST.EDU
Subject: Ang: Expiration performance TSM 5.5 (request)

Hi

To begin with, the guidelines for database setup is something similiar to:

a) 8-12 primary database volumes (since you're on 5.x you can still use TSM 
mirroring). Each volume should be in it's own filesystem, preferably on their 
own spindles (harddrives). If possible, make sure that your storage group 
assigns you 8-12 volumes from different arrays within the Vmax if possible, or 
at least as many arrays as possible. If they assign you 8 volumes from the same 
array, performance will be horrible.

b) Log should reside on it's own volume(s). Since the log is sequential, 
raid-10 is the optimal setup. 

c) Using DB mirroring in parallell mode will increase performance

d) Using LOG mirroring in normal mode will aswell increase performance

e) Max sure you have enough bufferpool

From your description, it sounds like a) is the place to start, I wouldnt be 
surprised if your db volumes are located (some of them or all of them) within 
the same array.

What operating system are you using? If you're on AIX, try checking I/O 
statistics during expiration to see if your queues are getting full (as in 100% 
utilization of the disks using iostat).  If so, try increasing the queues, and 
go to your storage guys and have them look at the underlying Vmax to determine 
if there are any configuration issues there.

Performance issues with expiration and database backups usually relates to the 
fact that the read-performance of the underlying array is limited.

Best Regards

Daniel Sparrman


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från:

Re: Expiration performance TSM 5.5 (request)

[Richard Sims]

I would stay away from database reorganization as a treatment, as that's a 
risky, time-consuming operation with a long service outage and likely 
short-lived benefits.

Your buffer pool cache hit percentage may look fine, but if the pool is 
oversized, paging might be happening to support it, which will be a drag on the 
system. (Technote 1405086)

In the classic TSM database, load distribution among the database volumes was 
problematic, where a lot of activity may be concentrated on one or a few 
volumes.

For comparative numbers, you might want to see what the rate is on a Delete 
Filespace relative to Expire Inventory, to possibly point out Expire Inventory 
as having issues specific to it, rather than your overall system configuration.

I would imagine that you are allowing Expire Inventory to run to completion 
each time it runs. A cancel may cause TSM to start over compiling a list of 
expiration candidates, which is added overhead. Whereas expiration involves 
database updates, and thus locking, it may run into lock conflicts with other 
processes operating in the same area. The expiration of System Objects used to 
involve a huge, grouped transaction, but was changed to do that work in clumps.

The situation may be one you won't find an answer for, unfortunately.

Richard Sims

Re: Expiration performance TSM 5.5 (request)

[Daniel Sparrman]

I'm pretty sure we can agree that expiration should be alot higher than 100 
objects / sec.

The question is more WHY he's getting 100 objects / sec. According to previous 
information, disks should be in order, so the next questions would be:

a) What platform are you on?

b) How long has this bTSM server been running, and when did you last do a 
unload/load DB (since it's TSM 5)?

If disks are in order, load isnt to heavy, disks are ok and not congested, the 
only reason why expiration would be slow on performance is one of the following:

a) You're database is heavily fragmented, causing your expiration to look 
through alot of empty space (since expiration is sequential)

b) You have a bug in your current TSM code

c) Your server is running out of other resources than disk (memory, RAM) though 
I think you would have checked this by now

Expiration / sec of objects isnt related to the amount of objects, total 
expiration time is, so even though you would have a billion objects to look 
through, expiration / sec would be fast, but the time to complete would be long.

Best Regards

Daniel


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE


-"ADSM: Dist Stor Manager"  skrev: - 
Till: ADSM-L@VM.MARIST.EDU
Från: "Allen S. Rout" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 18:55
Ärende: Re: Expiration performance TSM 5.5 (request)


On 02/16/2012 09:02 AM, Loon, EJ van - SPLXO wrote:

>
> select activity, cast((end_time) as date) as "Date",
> (examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
> "Objects Examined/Hr" from summary where activity='EXPIRATION' and
> days(end_time)-days(start_time)=0

I'm getting between 900/s and 1300/s.

AIX, 5.5, on an EMC VNX with Fast Cache (SSD caching).

- Allen S. Rout

Re: Expiration performance TSM 5.5 (request)

[Allen S. Rout]

On 02/16/2012 09:02 AM, Loon, EJ van - SPLXO wrote:



select activity, cast((end_time) as date) as "Date",
(examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
"Objects Examined/Hr" from summary where activity='EXPIRATION' and
days(end_time)-days(start_time)=0


I'm getting between 900/s and 1300/s.

AIX, 5.5, on an EMC VNX with Fast Cache (SSD caching).

- Allen S. Rout

Re: Expiration performance TSM 5.5 (request)

[Steven Langdale]

Hi Eric

Using your selects on my local TSM instance I am getting between 761 to
1057 obs/s the vast majority are round 800.

The DB is a tiddler @ 92GB and 77% util.  I have 12 DB vols at about 12.2GB
each (don't recall why that size tbh) across TWO filesystems.  Most of the
in use volumes are on the 1st filesystem.  So, in summary, NOT an optimal
design.

What is your server platform?  Mine is AIX.

I know little about VMAX as we are 100% an IBM shop - but the 1st thing i'd
check for in your environ is the queue depth on the DB disks and the HBA's
that service it.  I know that the AIX defaults can be very low.

Steven


On 16 February 2012 14:02, Loon, EJ van - SPLXO wrote:

> Hi TSM-ers!
> I'm struggling with the performance of our expiration process. I can't
> get it any faster than 100 object/second max. We tried everything, like
> using more or less database volumes, multiple volumes per filesystem,
> mirroring, unmirroring, but nothing seems to have any positive effect.
> We are using SAN attached enterprise class storage (EMC Vmax) with the
> fastest disks available.
> I have seen other users with similar (or larger) databases with much
> higher figures, like more than 1000 objects/sec, so there must be
> something I can do to achieve this. In 2007 at the Oxford TSM Symposium
> (http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk%
> 20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec
> is possible.
> I would really like to know from other TSM 5.5 users how their
> expiration is performing. Could you please let me know by sending me the
> output from the following two SQL queries, along with the platform you
> are using:
>
> select activity, cast((end_time) as date) as "Date",
> (examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
> "Objects Examined/Hr" from summary where activity='EXPIRATION' and
> days(end_time)-days(start_time)=0
>
> select capacity_mb as "Capacity MB", pct_utilized as "Percentage in
> use", cast(capacity_mb*pct_utilized/100 as integer) as "Used MB" from db
>
> Thank you VERY much for your help in advance
> Kind regards,
> Eric van Loon
> KLM Royal Dutch Airlines
> For
> information, services and offers, please visit our web site:
> http://www.klm.com. This e-mail and any attachment may contain
> confidential and privileged material intended for the addressee only. If
> you are not the addressee, you are notified that no part of the e-mail or
> any attachment may be disclosed, copied or distributed, and that any other
> action related to this e-mail or attachment is strictly prohibited, and may
> be unlawful. If you have received this e-mail by error, please notify the
> sender immediately by return e-mail, and delete this
> message.Koninklijke Luchtvaart Maatschappij NV (KLM), its
> subsidiaries and/or its employees shall not be liable for the incorrect or
> incomplete transmission of this e-mail or any attachments, nor responsible
> for any delay in receipt.Koninklijke Luchtvaart Maatschappij N.V. (also
> known as KLM Royal Dutch Airlines) is registered in Amstelveen, The
> Netherlands, with registered number  33014286
> 
>

Re: Expiration performance TSM 5.5 (request)

[Daniel Sparrman]

Hi Eric

Out of curiosity, how long has the TSM server existed, and how long has it been 
since you did an unload/load database?

Fragmentation could also be the root cause to expiration taking to long.

Regards

Daniel 


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från: "Loon, EJ van - SPLXO" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 16:19
Ärende: Re: Expiration performance TSM 5.5 (request)

Hi Daniel!
Been there, done that... 
a) We completely redesigned our database layout. Each database file is located 
on one single hdisk, one single vg and one single filesystem. We are using 10 
database volumes and tried everything. LUN's are striped across multiple 
arrays, the backend is using raid 1. Performance of the disks outside of TSM is 
fine: 120 Mb/sec read as long as we do not use mirroring, write even better 
(because of cache) around 180 Mb/sec. Even when we try to imitate TSM (by doing 
4k reads using dd) read performance is fine.
b) Tried several setups for the log too, still no improvement.
c) I think you mean the way the vg is mirrored? All vg's are using parallel.
d) Tried that too, the only effect is that log utilization during the day is 
much lower (of course).
e) Cache hit ration is 99.9% so the bufferpool should be large enough.
I have done extensive I/O analysis along with TSM support, there is no queuing, 
0.0 most of the time...
Thanks for your reply!
Kind regards,
Eric van Loon

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel 
Sparrman
Sent: donderdag 16 februari 2012 15:12
To: ADSM-L@VM.MARIST.EDU
Subject: Ang: Expiration performance TSM 5.5 (request)

Hi

To begin with, the guidelines for database setup is something similiar to:

a) 8-12 primary database volumes (since you're on 5.x you can still use TSM 
mirroring). Each volume should be in it's own filesystem, preferably on their 
own spindles (harddrives). If possible, make sure that your storage group 
assigns you 8-12 volumes from different arrays within the Vmax if possible, or 
at least as many arrays as possible. If they assign you 8 volumes from the same 
array, performance will be horrible.

b) Log should reside on it's own volume(s). Since the log is sequential, 
raid-10 is the optimal setup. 

c) Using DB mirroring in parallell mode will increase performance

d) Using LOG mirroring in normal mode will aswell increase performance

e) Max sure you have enough bufferpool

>From your description, it sounds like a) is the place to start, I wouldnt be 
>surprised if your db volumes are located (some of them or all of them) within 
>the same array.

What operating system are you using? If you're on AIX, try checking I/O 
statistics during expiration to see if your queues are getting full (as in 100% 
utilization of the disks using iostat).  If so, try increasing the queues, and 
go to your storage guys and have them look at the underlying Vmax to determine 
if there are any configuration issues there.

Performance issues with expiration and database backups usually relates to the 
fact that the read-performance of the underlying array is limited.

Best Regards

Daniel Sparrman


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från: "Loon, EJ van - SPLXO" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 15:02
Ärende: Expiration performance TSM 5.5 (request)

Hi TSM-ers!
I'm struggling with the performance of our expiration process. I can't
get it any faster than 100 object/second max. We tried everything, like
using more or less database volumes, multiple volumes per filesystem,
mirroring, unmirroring, but nothing seems to have any positive effect.
We are using SAN attached enterprise class storage (EMC Vmax) with the
fastest disks available.
I have seen other users with similar (or larger) databases with much
higher figures, like more than 1000 objects/sec, so there must be
something I can do to achieve this. In 2007 at the Oxford TSM Symposium
(http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk%
20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec
is possible.
I would really like to know from other TSM 5.5 users how their
expiration is performing. Could you please let me know by sending me the
output from the following two SQL queries, along with the platform you
are using:

select activity, cast((end_time) as date) as "Date",
(examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
"Objects Examined/Hr" fro

Re: Expiration performance TSM 5.5 (request)

[Loon, EJ van - SPLXO]

Hi Daniel!
Been there, done that... 
a) We completely redesigned our database layout. Each database file is located 
on one single hdisk, one single vg and one single filesystem. We are using 10 
database volumes and tried everything. LUN's are striped across multiple 
arrays, the backend is using raid 1. Performance of the disks outside of TSM is 
fine: 120 Mb/sec read as long as we do not use mirroring, write even better 
(because of cache) around 180 Mb/sec. Even when we try to imitate TSM (by doing 
4k reads using dd) read performance is fine.
b) Tried several setups for the log too, still no improvement.
c) I think you mean the way the vg is mirrored? All vg's are using parallel.
d) Tried that too, the only effect is that log utilization during the day is 
much lower (of course).
e) Cache hit ration is 99.9% so the bufferpool should be large enough.
I have done extensive I/O analysis along with TSM support, there is no queuing, 
0.0 most of the time...
Thanks for your reply!
Kind regards,
Eric van Loon

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Daniel 
Sparrman
Sent: donderdag 16 februari 2012 15:12
To: ADSM-L@VM.MARIST.EDU
Subject: Ang: Expiration performance TSM 5.5 (request)

Hi

To begin with, the guidelines for database setup is something similiar to:

a) 8-12 primary database volumes (since you're on 5.x you can still use TSM 
mirroring). Each volume should be in it's own filesystem, preferably on their 
own spindles (harddrives). If possible, make sure that your storage group 
assigns you 8-12 volumes from different arrays within the Vmax if possible, or 
at least as many arrays as possible. If they assign you 8 volumes from the same 
array, performance will be horrible.

b) Log should reside on it's own volume(s). Since the log is sequential, 
raid-10 is the optimal setup. 

c) Using DB mirroring in parallell mode will increase performance

d) Using LOG mirroring in normal mode will aswell increase performance

e) Max sure you have enough bufferpool

>From your description, it sounds like a) is the place to start, I wouldnt be 
>surprised if your db volumes are located (some of them or all of them) within 
>the same array.

What operating system are you using? If you're on AIX, try checking I/O 
statistics during expiration to see if your queues are getting full (as in 100% 
utilization of the disks using iostat).  If so, try increasing the queues, and 
go to your storage guys and have them look at the underlying Vmax to determine 
if there are any configuration issues there.

Performance issues with expiration and database backups usually relates to the 
fact that the read-performance of the underlying array is limited.

Best Regards

Daniel Sparrman


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från: "Loon, EJ van - SPLXO" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 15:02
Ärende: Expiration performance TSM 5.5 (request)

Hi TSM-ers!
I'm struggling with the performance of our expiration process. I can't
get it any faster than 100 object/second max. We tried everything, like
using more or less database volumes, multiple volumes per filesystem,
mirroring, unmirroring, but nothing seems to have any positive effect.
We are using SAN attached enterprise class storage (EMC Vmax) with the
fastest disks available.
I have seen other users with similar (or larger) databases with much
higher figures, like more than 1000 objects/sec, so there must be
something I can do to achieve this. In 2007 at the Oxford TSM Symposium
(http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk%
20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec
is possible.
I would really like to know from other TSM 5.5 users how their
expiration is performing. Could you please let me know by sending me the
output from the following two SQL queries, along with the platform you
are using:

select activity, cast((end_time) as date) as "Date",
(examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
"Objects Examined/Hr" from summary where activity='EXPIRATION' and
days(end_time)-days(start_time)=0

select capacity_mb as "Capacity MB", pct_utilized as "Percentage in
use", cast(capacity_mb*pct_utilized/100 as integer) as "Used MB" from db

Thank you VERY much for your help in advance
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
For 
information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other

Re: Expiration performance TSM 5.5 (request)

[Loon, EJ van - SPLXO]

Hi Gary!
I know about the Windows 2008 system state performance issue which will
never be resolved in 5.5, but expiration performance is similar on
another server, which only contains 3 Windows 2008 nodes... 
Thanks!
Kind regards,
Eric van Loon

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Lee, Gary
Sent: donderdag 16 februari 2012 15:32
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration performance TSM 5.5 (request)

Do you have many win 2008 and win 7 clients with client version 6.2.2?

For some reason (forget the apar), expiration is very slow with these
clients.

I am going to 6.3 soon, and hope to solve this with that move.
I have a 6.2 server, can't get your script to run, but observation tells
me that expirations that run hours on 5.5 run in minutes on 6.2.

 


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of
Loon, EJ van - SPLXO
Sent: Thursday, February 16, 2012 9:02 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration performance TSM 5.5 (request)

Hi TSM-ers!
I'm struggling with the performance of our expiration process. I can't
get it any faster than 100 object/second max. We tried everything, like
using more or less database volumes, multiple volumes per filesystem,
mirroring, unmirroring, but nothing seems to have any positive effect.
We are using SAN attached enterprise class storage (EMC Vmax) with the
fastest disks available.
I have seen other users with similar (or larger) databases with much
higher figures, like more than 1000 objects/sec, so there must be
something I can do to achieve this. In 2007 at the Oxford TSM Symposium
(http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk%
20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec
is possible.
I would really like to know from other TSM 5.5 users how their
expiration is performing. Could you please let me know by sending me the
output from the following two SQL queries, along with the platform you
are using:

select activity, cast((end_time) as date) as "Date",
(examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
"Objects Examined/Hr" from summary where activity='EXPIRATION' and
days(end_time)-days(start_time)=0

select capacity_mb as "Capacity MB", pct_utilized as "Percentage in
use", cast(capacity_mb*pct_utilized/100 as integer) as "Used MB" from db

Thank you VERY much for your help in advance
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
For
information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message.Koninklijke Luchtvaart Maatschappij NV (KLM), its
subsidiaries and/or its employees shall not be liable for the incorrect
or incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.Koninklijke Luchtvaart
Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered
in Amstelveen, The Netherlands, with registered number  33014286


For information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message. 

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its 
employees shall not be liable for the incorrect or incomplete transmission of 
this e-mail or any attachments, nor responsible for any delay in receipt. 
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch 
Airlines) is registered in Amstelveen, The Netherlands, with registered number 
33014286

Re: Expiration performance TSM 5.5 (request)

[Daniel Sparrman]

Well, since you have multi-threaded expiration in TSM v6 (basically 1 thread 
per volume) expiration is alot faster.

That could be an easy way of handling your expiration problems, going to v6, 
but if your databasevolumes are located on the same arrays, you'll still get 
lousy performance, just spread over multiple thread instead of one ;)

Best Regards

Daniel 


Daniel Sparrman
Exist i Stockholm AB
Växel: 08-754 98 00
Fax: 08-754 97 30
daniel.sparr...@exist.se
http://www.existgruppen.se
Posthusgatan 1 761 30 NORRTÄLJE

-"ADSM: Dist Stor Manager"  skrev: -
Till: ADSM-L@VM.MARIST.EDU
Från: "Lee, Gary" 
Sänt av: "ADSM: Dist Stor Manager" 
Datum: 02/16/2012 15:32
Ärende: Re: Expiration performance TSM 5.5 (request)

Do you have many win 2008 and win 7 clients with client version 6.2.2?

For some reason (forget the apar), expiration is very slow with these clients.

I am going to 6.3 soon, and hope to solve this with that move.
I have a 6.2 server, can't get your script to run, but observation tells me 
that expirations that run hours on 5.5 run in minutes on 6.2.

 


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, 
EJ van - SPLXO
Sent: Thursday, February 16, 2012 9:02 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration performance TSM 5.5 (request)

Hi TSM-ers!
I'm struggling with the performance of our expiration process. I can't
get it any faster than 100 object/second max. We tried everything, like
using more or less database volumes, multiple volumes per filesystem,
mirroring, unmirroring, but nothing seems to have any positive effect.
We are using SAN attached enterprise class storage (EMC Vmax) with the
fastest disks available.
I have seen other users with similar (or larger) databases with much
higher figures, like more than 1000 objects/sec, so there must be
something I can do to achieve this. In 2007 at the Oxford TSM Symposium
(http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk%
20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec
is possible.
I would really like to know from other TSM 5.5 users how their
expiration is performing. Could you please let me know by sending me the
output from the following two SQL queries, along with the platform you
are using:

select activity, cast((end_time) as date) as "Date",
(examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
"Objects Examined/Hr" from summary where activity='EXPIRATION' and
days(end_time)-days(start_time)=0

select capacity_mb as "Capacity MB", pct_utilized as "Percentage in
use", cast(capacity_mb*pct_utilized/100 as integer) as "Used MB" from db

Thank you VERY much for your help in advance
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
For 
information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.Koninklijke Luchtvaart Maatschappij NV 
(KLM), its subsidiaries and/or its employees shall not be liable for the 
incorrect or incomplete transmission of this e-mail or any attachments, nor 
responsible for any delay in receipt.Koninklijke Luchtvaart Maatschappij 
N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The 
Netherlands, with registered number  33014286 

Re: Expiration performance TSM 5.5 (request)

[Lee, Gary]

Do you have many win 2008 and win 7 clients with client version 6.2.2?

For some reason (forget the apar), expiration is very slow with these clients.

I am going to 6.3 soon, and hope to solve this with that move.
I have a 6.2 server, can't get your script to run, but observation tells me 
that expirations that run hours on 5.5 run in minutes on 6.2.

 


Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310

 
-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Loon, 
EJ van - SPLXO
Sent: Thursday, February 16, 2012 9:02 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration performance TSM 5.5 (request)

Hi TSM-ers!
I'm struggling with the performance of our expiration process. I can't
get it any faster than 100 object/second max. We tried everything, like
using more or less database volumes, multiple volumes per filesystem,
mirroring, unmirroring, but nothing seems to have any positive effect.
We are using SAN attached enterprise class storage (EMC Vmax) with the
fastest disks available.
I have seen other users with similar (or larger) databases with much
higher figures, like more than 1000 objects/sec, so there must be
something I can do to achieve this. In 2007 at the Oxford TSM Symposium
(http://tsm-symposium.oucs.ox.ac.uk/2007/papers/Dave%20Canan%20-%20Disk%
20Tuning%20and%20TSM.pdf page 25) IBM also stated that 1000 object/sec
is possible.
I would really like to know from other TSM 5.5 users how their
expiration is performing. Could you please let me know by sending me the
output from the following two SQL queries, along with the platform you
are using:

select activity, cast((end_time) as date) as "Date",
(examined/cast((end_time-start_time) seconds as decimal(18,13))*3600)
"Objects Examined/Hr" from summary where activity='EXPIRATION' and
days(end_time)-days(start_time)=0

select capacity_mb as "Capacity MB", pct_utilized as "Percentage in
use", cast(capacity_mb*pct_utilized/100 as integer) as "Used MB" from db

Thank you VERY much for your help in advance
Kind regards,
Eric van Loon
KLM Royal Dutch Airlines
For 
information, services and offers, please visit our web site: 
http://www.klm.com. This e-mail and any attachment may contain confidential and 
privileged material intended for the addressee only. If you are not the 
addressee, you are notified that no part of the e-mail or any attachment may be 
disclosed, copied or distributed, and that any other action related to this 
e-mail or attachment is strictly prohibited, and may be unlawful. If you have 
received this e-mail by error, please notify the sender immediately by return 
e-mail, and delete this message.Koninklijke Luchtvaart Maatschappij NV 
(KLM), its subsidiaries and/or its employees shall not be liable for the 
incorrect or incomplete transmission of this e-mail or any attachments, nor 
responsible for any delay in receipt.Koninklijke Luchtvaart Maatschappij 
N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The 
Netherlands, with registered number  33014286 

Re: expiration

[Shawn Drew]

This has been one of my gripes for a while.   The main problem with this
is the vocabulary that the client uses.
A TSM client just "deactivates" a file, it doesn't expire anything despite
what the client log says.  The Server expiration process will then
analyze the inactive files and decide what to do with it (i.e. delete or
keep it) according to the management class.
Depending on your management class settings, it is possible that the
Server expiration will decide to keep the
inactive file around for a long time.   The server expiration process
ignores any active files.

Regards,
Shawn

Shawn Drew





Internet
tbr...@cenhud.com

Sent by: ADSM-L@VM.MARIST.EDU
10/20/2011 09:00 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] expiration






As a client performs a backup it expires files and this is evident in the
logs. Later the expiration inventory

process runs on the server. Are the files just marked for expiration by
the client and the expiration process

actually updates the database.



If I have a client that I need to not run a backup on for specific DR
reasons since it is missing some files.

I don't want the backup to mark those as expired and thus actually expired
as part of the inventory process



Thus if I run the full expire inventory process on the server and not the
client backup the missing files

on the server wont expire and will remain active.



Hope I explained the situation right.



Thanks,



Tim Brown
Systems Specialist - Project Leader
Central Hudson Gas & Electric
284 South Ave
Poughkeepsie, NY 12601
Email: tbr...@cenhud.com <>
Phone: 845-486-5643
Fax: 845-486-5921
Cell: 845-235-4255




This message contains confidential information and is only for the
intended recipient. If the reader of this message is not the intended
recipient, or an employee or agent responsible for delivering this message
to the intended recipient, please notify the sender immediately by
replying to this note and deleting all copies and attachments.



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.

Re: expiration

[Zoltan Forray/AC/VCU]

and, if you deleted a file/object and ran a backup, all previously
inactive copies are flushed (up to the value set in your Management Class)
and the last n-copies become inactive and are kept for the number of days
specified in your MC "retain only" value.



From:   "Allen S. Rout" 
To: ADSM-L@VM.MARIST.EDU
Date:   10/20/2011 10:47 AM
Subject:Re: [ADSM-L] expiration
Sent by:"ADSM: Dist Stor Manager" 



On 10/20/2011 09:00 AM, Tim Brown wrote:

> If I have a client that I need to not run a backup on for specific
> DR reasons since it is missing some files.  I don't want the backup
> to mark those as expired and thus actually expired as part of the
> inventory process

> Thus if I run the full expire inventory process on the server and
> not the client backup the missing files on the server wont expire
> and will remain active.


An important distinction here: older "Inactive" file versions will
continue to age away and be discarded by successive expiration
processes.

But if the file was active the last time you ran an incremental of the
machine, it will stay that way, and you can expire inventory as often
as you like.  Only inactive file versions will be eventually pared
away.


- Allen S. Rout

Re: expiration

[Allen S. Rout]

On 10/20/2011 09:00 AM, Tim Brown wrote:


If I have a client that I need to not run a backup on for specific
DR reasons since it is missing some files.  I don't want the backup
to mark those as expired and thus actually expired as part of the
inventory process



Thus if I run the full expire inventory process on the server and
not the client backup the missing files on the server wont expire
and will remain active.



An important distinction here: older "Inactive" file versions will
continue to age away and be discarded by successive expiration
processes.

But if the file was active the last time you ran an incremental of the
machine, it will stay that way, and you can expire inventory as often
as you like.  Only inactive file versions will be eventually pared
away.


- Allen S. Rout

Re: Expiration causes backups to hang

[David E Ehresman]

Yes it is.  But it just showed up between the time of my last email and
when you looked.  Don't believe the timestamp on the directory!

Thanks,
David

>>> Zoltan Forray  4/25/2011 9:18 AM >>>
Huh?  AIX version is here:

FTP://service.boulder.ibm.com//storage/tivoli-storage-management/patches/server/AIX/6.2.2.30/6.2.2.30-TIV-TSMALL-AIX.bin

On Mon, Apr 25, 2011 at 9:11 AM, David E Ehresman
wrote:

> OK.  I was only checking for the AIX version which is still not
posted.
> I do see the Linux version now that I looked for it.
>
> David
>
> >>> Zoltan Forray  4/25/2011 8:59 AM >>>
> I run the Linux version and get it directly from the FTP site so
mine
> is at:
>
>
>
FTP://service.boulder.ibm.com//storage/tivoli-storage-management/patches/server/Linux/6.2.2.30/6.2.2.30-TIV-TSMALL-Linuxx86_64.bin
>
> On Mon, Apr 25, 2011 at 8:19 AM, David E Ehresman
> wrote:
>
> > Where might one find the 6.2.2.30 patch?
> >
> > >>> Zoltan Forray  4/24/2011 7:46 AM >>>
> > 6.2.2.30 is out as an official patch.
> > On Apr 24, 2011 7:33 AM, "Hans Christian Riksheim"
> 
> > wrote:
> > > Problem is resolved.
> > >
> > > We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and
> > expiration
> > > rates are 5-10 times higher and no hangs yet. We observe that
> System
> > State
> > > expirations from 2008 servers are much faster now.
> > >
> > > Hans Chr.
> > >
> > > On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim <
> > bull...@gmail.com
> > >> wrote:
> > >
> > >> Hi,
> > >>
> > >> anyone else have this problem? Running 6.2.2 on AIX 6.1.
> Submitting
> > a PMR
> > >> on this in parallell.
> > >>
> > >> When I say hang I mean a complete hang. All incoming backups
> stops.
> > Traffic
> > >> is resumed when we cancel expiration.
> > >>
> > >> Hans Chr.
> > >>
> >
>
>
>
> --
> Zoltan Forray
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zfor...@vcu.edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations
> will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more
details
> visit
> http://infosecurity.vcu.edu/phishing.html
>



--
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations
will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit
http://infosecurity.vcu.edu/phishing.html

Re: Expiration causes backups to hang

[Zoltan Forray]

Huh?  AIX version is here:

FTP://service.boulder.ibm.com//storage/tivoli-storage-management/patches/server/AIX/6.2.2.30/6.2.2.30-TIV-TSMALL-AIX.bin

On Mon, Apr 25, 2011 at 9:11 AM, David E Ehresman
wrote:

> OK.  I was only checking for the AIX version which is still not posted.
> I do see the Linux version now that I looked for it.
>
> David
>
> >>> Zoltan Forray  4/25/2011 8:59 AM >>>
> I run the Linux version and get it directly from the FTP site so mine
> is at:
>
>
> FTP://service.boulder.ibm.com//storage/tivoli-storage-management/patches/server/Linux/6.2.2.30/6.2.2.30-TIV-TSMALL-Linuxx86_64.bin
>
> On Mon, Apr 25, 2011 at 8:19 AM, David E Ehresman
> wrote:
>
> > Where might one find the 6.2.2.30 patch?
> >
> > >>> Zoltan Forray  4/24/2011 7:46 AM >>>
> > 6.2.2.30 is out as an official patch.
> > On Apr 24, 2011 7:33 AM, "Hans Christian Riksheim"
> 
> > wrote:
> > > Problem is resolved.
> > >
> > > We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and
> > expiration
> > > rates are 5-10 times higher and no hangs yet. We observe that
> System
> > State
> > > expirations from 2008 servers are much faster now.
> > >
> > > Hans Chr.
> > >
> > > On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim <
> > bull...@gmail.com
> > >> wrote:
> > >
> > >> Hi,
> > >>
> > >> anyone else have this problem? Running 6.2.2 on AIX 6.1.
> Submitting
> > a PMR
> > >> on this in parallell.
> > >>
> > >> When I say hang I mean a complete hang. All incoming backups
> stops.
> > Traffic
> > >> is resumed when we cancel expiration.
> > >>
> > >> Hans Chr.
> > >>
> >
>
>
>
> --
> Zoltan Forray
> TSM Software & Hardware Administrator
> Virginia Commonwealth University
> UCC/Office of Technology Services
> zfor...@vcu.edu - 804-828-4807
> Don't be a phishing victim - VCU and other reputable organizations
> will
> never use email to request that you reply with your password, social
> security number or confidential personal information. For more details
> visit
> http://infosecurity.vcu.edu/phishing.html
>



--
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details visit
http://infosecurity.vcu.edu/phishing.html

Re: Expiration causes backups to hang

[David E Ehresman]

OK.  I was only checking for the AIX version which is still not posted.
I do see the Linux version now that I looked for it.

David

>>> Zoltan Forray  4/25/2011 8:59 AM >>>
I run the Linux version and get it directly from the FTP site so mine
is at:

FTP://service.boulder.ibm.com//storage/tivoli-storage-management/patches/server/Linux/6.2.2.30/6.2.2.30-TIV-TSMALL-Linuxx86_64.bin

On Mon, Apr 25, 2011 at 8:19 AM, David E Ehresman
wrote:

> Where might one find the 6.2.2.30 patch?
>
> >>> Zoltan Forray  4/24/2011 7:46 AM >>>
> 6.2.2.30 is out as an official patch.
> On Apr 24, 2011 7:33 AM, "Hans Christian Riksheim"

> wrote:
> > Problem is resolved.
> >
> > We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and
> expiration
> > rates are 5-10 times higher and no hangs yet. We observe that
System
> State
> > expirations from 2008 servers are much faster now.
> >
> > Hans Chr.
> >
> > On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim <
> bull...@gmail.com
> >> wrote:
> >
> >> Hi,
> >>
> >> anyone else have this problem? Running 6.2.2 on AIX 6.1.
Submitting
> a PMR
> >> on this in parallell.
> >>
> >> When I say hang I mean a complete hang. All incoming backups
stops.
> Traffic
> >> is resumed when we cancel expiration.
> >>
> >> Hans Chr.
> >>
>



--
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations
will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit
http://infosecurity.vcu.edu/phishing.html

Re: Expiration causes backups to hang

[Zoltan Forray]

I run the Linux version and get it directly from the FTP site so mine is at:

FTP://service.boulder.ibm.com//storage/tivoli-storage-management/patches/server/Linux/6.2.2.30/6.2.2.30-TIV-TSMALL-Linuxx86_64.bin

On Mon, Apr 25, 2011 at 8:19 AM, David E Ehresman
wrote:

> Where might one find the 6.2.2.30 patch?
>
> >>> Zoltan Forray  4/24/2011 7:46 AM >>>
> 6.2.2.30 is out as an official patch.
> On Apr 24, 2011 7:33 AM, "Hans Christian Riksheim" 
> wrote:
> > Problem is resolved.
> >
> > We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and
> expiration
> > rates are 5-10 times higher and no hangs yet. We observe that System
> State
> > expirations from 2008 servers are much faster now.
> >
> > Hans Chr.
> >
> > On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim <
> bull...@gmail.com
> >> wrote:
> >
> >> Hi,
> >>
> >> anyone else have this problem? Running 6.2.2 on AIX 6.1. Submitting
> a PMR
> >> on this in parallell.
> >>
> >> When I say hang I mean a complete hang. All incoming backups stops.
> Traffic
> >> is resumed when we cancel expiration.
> >>
> >> Hans Chr.
> >>
>



--
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details visit
http://infosecurity.vcu.edu/phishing.html

Re: Expiration causes backups to hang

[David E Ehresman]

Where might one find the 6.2.2.30 patch?

>>> Zoltan Forray  4/24/2011 7:46 AM >>>
6.2.2.30 is out as an official patch.
On Apr 24, 2011 7:33 AM, "Hans Christian Riksheim" 
wrote:
> Problem is resolved.
>
> We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and
expiration
> rates are 5-10 times higher and no hangs yet. We observe that System
State
> expirations from 2008 servers are much faster now.
>
> Hans Chr.
>
> On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim <
bull...@gmail.com
>> wrote:
>
>> Hi,
>>
>> anyone else have this problem? Running 6.2.2 on AIX 6.1. Submitting
a PMR
>> on this in parallell.
>>
>> When I say hang I mean a complete hang. All incoming backups stops.
Traffic
>> is resumed when we cancel expiration.
>>
>> Hans Chr.
>>

Re: Expiration causes backups to hang

[Zoltan Forray]

6.2.2.30 is out as an official patch.
On Apr 24, 2011 7:33 AM, "Hans Christian Riksheim" 
wrote:
> Problem is resolved.
>
> We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and expiration
> rates are 5-10 times higher and no hangs yet. We observe that System State
> expirations from 2008 servers are much faster now.
>
> Hans Chr.
>
> On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim <
bull...@gmail.com
>> wrote:
>
>> Hi,
>>
>> anyone else have this problem? Running 6.2.2 on AIX 6.1. Submitting a PMR
>> on this in parallell.
>>
>> When I say hang I mean a complete hang. All incoming backups stops.
Traffic
>> is resumed when we cancel expiration.
>>
>> Hans Chr.
>>

Re: Expiration causes backups to hang

[Hans Christian Riksheim]

Problem is resolved.

We upgraded from 6.2.2.0 to 6.2.2.25(6.2.2.2 patch + efix) and expiration
rates are 5-10 times higher and no hangs yet. We observe that System State
expirations from 2008 servers are much faster now.

Hans Chr.

On Wed, Apr 13, 2011 at 10:17 AM, Hans Christian Riksheim  wrote:

> Hi,
>
> anyone else have this problem? Running 6.2.2 on AIX 6.1. Submitting a PMR
> on this in parallell.
>
> When I say hang I mean a complete hang. All incoming backups stops. Traffic
> is resumed when we cancel expiration.
>
> Hans Chr.
>

Re: Expiration causes backups to hang

[Clark, Margaret]

We had a somewhat similar problem almost a year ago, which was caused by 
Windows 2008 TSM clients older than the 6.2 release:
IC66810: 6.1.2 AND 6.1.3 TSM WINDOWS CLIENTS WITH DEFAULT SYSTEM STATE WRITERS 
ON WIN 7 AND 2008 R2 MAY GET FULL SYSTEM STATE BACKUPS
The problem went away when the clients were upgraded to 6.2.1.0 (now I'd use 
6.2.2.0).
- Margaret Clark

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Hans 
Christian Riksheim
Sent: Wednesday, April 13, 2011 1:18 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration causes backups to hang

Hi,

anyone else have this problem? Running 6.2.2 on AIX 6.1. Submitting a PMR on
this in parallell.

When I say hang I mean a complete hang. All incoming backups stops. Traffic
is resumed when we cancel expiration.

Hans Chr.

Re: Expiration causes backups to hang

[Billaudeau, Pierre]

Hi Hans,
We are still having problem with the expiration on some filesystem node 
but instead of hanging, the DB is growing at an incredible pace then TSM 
crashes. This is with 6.1.3 and cancel expiration command would not respond. We 
identified some Windows 2008 servers (Systemstate filesystem) that was so big 
(14M entries) and excluded them from Expiration process. Expiration runs very 
fine since then and we were hoping 6.2.2 would solve the problem but from what 
you experience it does not look good.

Pierre Billaudeau
Analyste en stockage
Livraison des Infrastructures Serveurs
Société des Alcools du Québec
514-254-6000 x 6559

-Message d'origine-
De : ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] De la part de Hans 
Christian Riksheim
Envoyé : 13 avril 2011 04:18
À : ADSM-L@VM.MARIST.EDU
Objet : [ADSM-L] Expiration causes backups to hang

Hi,

anyone else have this problem? Running 6.2.2 on AIX 6.1. Submitting a PMR on
this in parallell.

When I say hang I mean a complete hang. All incoming backups stops. Traffic
is resumed when we cancel expiration.

Hans Chr.


--


Information confidentielle : Le présent message, ainsi que tout fichier qui y 
est joint, est envoyé à l'intention exclusive de son ou de ses destinataires; 
il est de nature confidentielle et peut constituer une information privilégiée. 
Nous avertissons toute personne autre que le destinataire prévu que tout 
examen, réacheminement, impression, copie, distribution ou autre utilisation de 
ce message et de tout fichier qui y est joint est strictement interdit. Si vous 
n'êtes pas le destinataire prévu, veuillez en aviser immédiatement l'expéditeur 
par retour de courriel et supprimer ce message et tout document joint de votre 
système. Merci.

Re: Expiration processing

[Shawn Drew]

Technically correct, Just make sure you disable the auto expiration  (q
opt EXPINTERVAL)

If I were confronted with a temporary need like this (as I have been in
the past), I'd rather just change the RETE and RETO until you can resume
expiration.  I think that is much safer.  You won't have to worry about an
accidental "expire inv" running.

Regards,
Shawn

Shawn Drew





Internet
deehr...@louisville.edu

Sent by: ADSM-L@VM.MARIST.EDU
03/09/2011 09:41 AM
Please respond to
ADSM-L@VM.MARIST.EDU


To
ADSM-L
cc

Subject
[ADSM-L] Expiration processing






I have a copygroup with VERE and VERD set to NOLIMIT and RETE and RETO
set to 30 days.

If I do NOT do expiration processing (expire inventory), will inactive
backups remain accessible longer than 30 days until expiration
processing resumes?

David



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.

Re: Expiration and Delete Filespace causing TSM DB to grow and crash

[Billaudeau, Pierre]

Wanda   - Client is 6.1.3.0 and I am upgrading it right now to 6.2.1 .
Richard - Most of the backup data is collocated to 1-2 tapes. I will try the 
delete vol discard=yes .

Thanks for the help,

Pierre Billaudeau
Analyste en stockage
Livraison des Infrastructures Serveurs
Société des Alcools du Québec
514-254-6000 x 6559

-Message d'origine-
De : ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] De la part de 
Prather, Wanda
Envoyé : 23 novembre 2010 15:40
À : ADSM-L@VM.MARIST.EDU
Objet : Re: [ADSM-L] Expiration and Delete Filespace causing TSM DB to grow and 
crash

Also, have you upgraded your Win2K8 to 6.2.1?
That client version does "true" incremental backups of Win2K8, that is backing 
up only the system state files that have actually changed.  That should help 
with the problem over time.



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of 
Richard Sims
Sent: Tuesday, November 23, 2010 2:46 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration and Delete Filespace causing TSM DB to grow 
and crash

It is often the case that such backups are segregated on their own volumes, 
where that allows you to perform a Delete Volume to dispose of the stuff in a 
meta manner.

   Richard Sims



___
Information confidentielle:
Le présent message, ainsi que tout fichier qui y est joint, est envoyé à 
l'intention exclusive de son ou de ses destinataires; il est de nature 
confidentielle et peut constituer une information privilégiée. Nous avertissons 
toute personne autre que le destinataire prévu que tout examen, réacheminement, 
impression, copie, distribution ou autre utilisation de ce message et de tout 
fichier qui y  est joint est strictement interdit. Si vous n'êtes pas le 
destinataire prévu, veuillez en aviser immédiatement l'expéditeur par retour de 
courriel et  supprimer ce message et tout document joint de votre système. 
Merci.

Re: Expiration and Delete Filespace causing TSM DB to grow and crash

[Prather, Wanda]

Also, have you upgraded your Win2K8 to 6.2.1?
That client version does "true" incremental backups of Win2K8, that is backing 
up only the system state files that have actually changed.  That should help 
with the problem over time.



-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of 
Richard Sims
Sent: Tuesday, November 23, 2010 2:46 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration and Delete Filespace causing TSM DB to grow 
and crash

It is often the case that such backups are segregated on their own volumes, 
where that allows you to perform a Delete Volume to dispose of the stuff in a 
meta manner.

   Richard Sims

Re: Expiration and Delete Filespace causing TSM DB to grow and crash

[Richard Sims]

It is often the case that such backups are segregated on their own volumes, 
where that allows you to perform a Delete Volume to dispose of the stuff in a 
meta manner.

   Richard Sims

Re: Expiration question

[Richard Sims]

There is Cancel Expiration,
and then there is Cancel Process on that process number, to different effect.  
;-)

Re: Expiration question

[Zoltan Forray/AC/VCU]

No, you didn't miss any responses.  I haven't seen any, either.

It did finally finish - after running for 7-days.  I guess it will take
many such passes to catch up since obviously it can only run
one-at-a-time.



From:
"Clark, Margaret" 
To:
ADSM-L@VM.MARIST.EDU
Date:
08/25/2010 02:50 PM
Subject:
Re: [ADSM-L] Expiration question
Sent by:
"ADSM: Dist Stor Manager" 



A bit late, but I don't recall any previous responses to this...  It will
do no good to cancel a running expiration process.  When you start again,
expiration picks up exactly where it left off.  Trying to cancel it just
prolongs the agony.
No idea about the retries, sorry.
- Margaret Clark

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Monday, August 23, 2010 7:32 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration question

I have 2-issues with expiration processing.

First, on my 5.5.4.2 server - we stopped expiration for more than a week,
to perform recovery of a large SAN failure.

Now, expiration has been running since 08/17 and still running.  Expired
over 24M objects out of 29M examined.  Didn't know if I should be
concerned.  It seems to be working OK and the numbers keep changing so it
isn't stuck.  Didn't know if I should fully cancel it (vs cancel
expiration) and restart or just leave it along.  Never had an expire run
so long!

Second, I am mildly concerned about the expiration processing/messages
from my 6.1.3.4 server:

 355 Expiration   Processed 69 nodes, examined 734917 objects,
deleting 733029 backup objects, 0 archive objects, 0 DB backup volumes, 0
recovery plan files; 1087 objects have been retried and 801 errors
encountered.

Why the errors and so many?  I don't recall any errors from expiration
from any of the 5.5.x servers?  What about the "retried"?   Retried what?



Speaking of 6.1, anyone have any issues upgrading 6.1.3.x to 6.1.4.1?  I
realize there are some big changes in 6.1.4.x and am concerned about
effecting my only 6.1 production server but I am seeing a lot of problems
purportedly fixed in 6.1.4.1.

I was never able to upgrade a test 6.1.x server to 6.2.x.  Things got so
farged up I had to have it wiped and rebuilt (couldn't upgrade to 6.2 and
couldn't remove it successfully).
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html

Re: Expiration question

[Clark, Margaret]

A bit late, but I don't recall any previous responses to this...  It will do no 
good to cancel a running expiration process.  When you start again, expiration 
picks up exactly where it left off.  Trying to cancel it just prolongs the 
agony.
No idea about the retries, sorry.
- Margaret Clark

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan 
Forray/AC/VCU
Sent: Monday, August 23, 2010 7:32 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration question

I have 2-issues with expiration processing.

First, on my 5.5.4.2 server - we stopped expiration for more than a week,
to perform recovery of a large SAN failure.

Now, expiration has been running since 08/17 and still running.  Expired
over 24M objects out of 29M examined.  Didn't know if I should be
concerned.  It seems to be working OK and the numbers keep changing so it
isn't stuck.  Didn't know if I should fully cancel it (vs cancel
expiration) and restart or just leave it along.  Never had an expire run
so long!

Second, I am mildly concerned about the expiration processing/messages
from my 6.1.3.4 server:

 355 Expiration   Processed 69 nodes, examined 734917 objects,
deleting 733029 backup objects, 0 archive objects, 0 DB backup volumes, 0
recovery plan files; 1087 objects have been retried and 801 errors
encountered.

Why the errors and so many?  I don't recall any errors from expiration
from any of the 5.5.x servers?  What about the "retried"?   Retried what?



Speaking of 6.1, anyone have any issues upgrading 6.1.3.x to 6.1.4.1?  I
realize there are some big changes in 6.1.4.x and am concerned about
effecting my only 6.1 production server but I am seeing a lot of problems
purportedly fixed in 6.1.4.1.

I was never able to upgrade a test 6.1.x server to 6.2.x.  Things got so
farged up I had to have it wiped and rebuilt (couldn't upgrade to 6.2 and
couldn't remove it successfully).
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zfor...@vcu.edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html

Re: Expiration Questions

[David McClelland]

This would suggest to me that any inactive objects (modified or deleted)
bound to this management class will be expired/removed from TSM-managed
storage 30 days from their inactivation date (subject to expiration
processing).

>From the TSM Server, the only way I can think of checking this would be by
looking at the INACTIVE objects in the BACKUPS table for this node and count
forward the RETEXTRA/RETONLY days (according to the management class to
which they're bound if not the below) from their DEACTIVATE_DATE. This could
be very resource intensive.

You might be able to find some information from the client side, looking in
the BA client restore panel, checking to view inactive objects, and then
check your newly inactive objects and the management class to which they are
bound.

/David Mc
London, UK

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Jones, Eric J
Sent: 23 March 2010 13:22
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration Questions

Good Morning.
The policy on this particular machine is.
==
Policy
Set Name


ACTIVE

Versions Versions   Retain  Retain
Data DataExtraOnly
  Exists  Deleted Versions Version
   ---
No Limit No Limit   30  30
===
Is there a way to see how many files will expire in the next day and/or week
for a particular server/workstation?

Thanks
Eric

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
David McClelland
Sent: Friday, March 19, 2010 10:07 AM
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] Expiration Questions

Hi Eric,

When you say, "We have a 30 day policy", could you send the output of a `Q
COPYGROUP` for the relevant management class?

Cheers,

David McClelland
London, UK

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Jones, Eric J
Sent: 19 March 2010 13:04
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration Questions

We are running TSM 5.4 server on an AIX machine with our clients(Windows
2003/2008) running also running TSM 5.4.
My question is we changed permissions on all our files on 1 of our servers
32 days ago which caused them all to be backed up again.
We have a 30 day policy on the files for retention so I had expected a large
expiration to take place 2 days ago but it hasn't taken place yet.  Is there
a way to tell
1:  When these files will expire?
2: How many versions of the files are currently on the server and how many
days until they expire?

Thanks
Eric

Re: Expiration Questions

[Richard Sims]

On Mar 23, 2010, at 9:22 AM, Jones, Eric J wrote:

> Is there a way to see how many files will expire in the next day and/or week 
> for a particular server/workstation?

You would have to trawl through the enormous Backups table, matching on 
CLASS_NAME and operating on the DEACTIVATE_DATE field in conjunction with the 
retention limit value.  The processing time and database workspace required may 
well be prohibitive.

   Richard Sims

Re: Expiration Questions

[Jones, Eric J]

Good Morning.
The policy on this particular machine is.
==
Policy
Set Name


ACTIVE

Versions Versions   Retain  Retain
Data DataExtraOnly
  Exists  Deleted Versions Version
   ---
No Limit No Limit   30  30
===
Is there a way to see how many files will expire in the next day and/or week 
for a particular server/workstation?

Thanks
Eric

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of David 
McClelland
Sent: Friday, March 19, 2010 10:07 AM
To: ADSM-L@vm.marist.edu
Subject: Re: [ADSM-L] Expiration Questions

Hi Eric,

When you say, "We have a 30 day policy", could you send the output of a `Q 
COPYGROUP` for the relevant management class?

Cheers,

David McClelland
London, UK

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Jones, 
Eric J
Sent: 19 March 2010 13:04
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration Questions

We are running TSM 5.4 server on an AIX machine with our clients(Windows
2003/2008) running also running TSM 5.4.
My question is we changed permissions on all our files on 1 of our servers
32 days ago which caused them all to be backed up again.
We have a 30 day policy on the files for retention so I had expected a large 
expiration to take place 2 days ago but it hasn't taken place yet.  Is there a 
way to tell
1:  When these files will expire?
2: How many versions of the files are currently on the server and how many days 
until they expire?

Thanks
Eric

Re: Expiration Questions

[David McClelland]

Hi Eric,

When you say, "We have a 30 day policy", could you send the output of a `Q
COPYGROUP` for the relevant management class?

Cheers,

David McClelland
London, UK

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of
Jones, Eric J
Sent: 19 March 2010 13:04
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration Questions

We are running TSM 5.4 server on an AIX machine with our clients(Windows
2003/2008) running also running TSM 5.4.
My question is we changed permissions on all our files on 1 of our servers
32 days ago which caused them all to be backed up again.
We have a 30 day policy on the files for retention so I had expected a large
expiration to take place 2 days ago but it hasn't taken place yet.  Is there
a way to tell
1:  When these files will expire?
2: How many versions of the files are currently on the server and how many
days until they expire?

Thanks
Eric

Re: Expiration of Exchange

[Fred Johanson]

Thanks Del,

Redfaced, I confess that I didn't extract the whole truth out of Mr. Exchange.  
This morning he admitted that he had used the same client name for testing the 
EXCHANGE TDP and never deleted his test files.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Del 
Hoobler
Sent: Thursday, October 08, 2009 6:05 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration of Exchange

Hi Fred,

All files backed up in an Exchange VSS backup are part of a "group".
The files in a "group" are all managed together. That means they expire
together
according to the management class of the "group" leader.

And so... I think something else is going on here. In fact, Gary probably
called it right when he said that maybe your normal file-level backup
client
is backing up these files.

If you cannot figure this out, you should call IBM support.

Thanks,

Del




"ADSM: Dist Stor Manager"  wrote on 10/07/2009
09:33:19 PM:

> [image removed]
>
> Expiration of Exchange
>
> Fred Johanson
>
> to:
>
> ADSM-L
>
> 10/07/2009 09:34 PM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" 
>
> Please respond to "ADSM: Dist Stor Manager"
>
> We use Copy Services instead of the TDP for EXCHANGE.  We want to
> keep backups for 30 days, which does work.  The .edb files are daily
> marked as inactive and roll off as expected.  But an examination by
> Mr. Exchange shows that there are .log files which are never marked
> as inactive, and, thus, are immortal, so far to the sum of 50 Tb on
> site (and the same offsite).  We obviously missed something in
> configuration, but what?
>
> To complicate matters, we tried to modify the client to allow
> deletion of backups (Mr. Exchange discovered on his own that "del ba
> *log todate=current_date-30" will get rid of the unwanted) but keep
> getting the client is accessing the server message, on an empty
> machine.  While waiting to figure this out, we could do "del vol xxx
> discarddat=y" on all those volumes more than 5 weeks old, but there
> must be some way to prevent this in the future.
>
>

Re: Expiration of Exchange

[Del Hoobler]

Hi Fred,

All files backed up in an Exchange VSS backup are part of a "group".
The files in a "group" are all managed together. That means they expire
together
according to the management class of the "group" leader.

And so... I think something else is going on here. In fact, Gary probably
called it right when he said that maybe your normal file-level backup
client
is backing up these files.

If you cannot figure this out, you should call IBM support.

Thanks,

Del




"ADSM: Dist Stor Manager"  wrote on 10/07/2009
09:33:19 PM:

> [image removed]
>
> Expiration of Exchange
>
> Fred Johanson
>
> to:
>
> ADSM-L
>
> 10/07/2009 09:34 PM
>
> Sent by:
>
> "ADSM: Dist Stor Manager" 
>
> Please respond to "ADSM: Dist Stor Manager"
>
> We use Copy Services instead of the TDP for EXCHANGE.  We want to
> keep backups for 30 days, which does work.  The .edb files are daily
> marked as inactive and roll off as expected.  But an examination by
> Mr. Exchange shows that there are .log files which are never marked
> as inactive, and, thus, are immortal, so far to the sum of 50 Tb on
> site (and the same offsite).  We obviously missed something in
> configuration, but what?
>
> To complicate matters, we tried to modify the client to allow
> deletion of backups (Mr. Exchange discovered on his own that "del ba
> *log todate=current_date-30" will get rid of the unwanted) but keep
> getting the client is accessing the server message, on an empty
> machine.  While waiting to figure this out, we could do "del vol xxx
> discarddat=y" on all those volumes more than 5 weeks old, but there
> must be some way to prevent this in the future.
>
>

Re: Expiration of Exchange

[Fred Johanson]

Gary,

This is the copygroup definition:

VERE nol
VERD NOL
RETE 30
RETO 60

Yet we have backups from May '08.





ADSM-L@VM.MARIST.EDU

From: ADSM: Dist Stor Manager [ads...@vm.marist.edu] On Behalf Of Gary Bowers 
[gbow...@itrus.com]
Sent: Wednesday, October 07, 2009 8:53 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration of Exchange

My guess is that you are mounting up the filesystem, and backing up
the files directly.  The log files in Exchange are probably getting a
new name as they are truncated, which means that there are no versions
of the files, only a single version that goes from active to inactive
when it is deleted from the server.  Check your "Retain Only"
parameter of the TSM Exchange Management class.  Make sure that this
is set to 30 days and not 365 or nolimit.  This should delete older
files, but only from the date they get marked inactive.

Gary
Itrus Technologies


On Oct 7, 2009, at 8:33 PM, Fred Johanson wrote:

> We use Copy Services instead of the TDP for EXCHANGE.  We want to
> keep backups for 30 days, which does work.  The .edb files are daily
> marked as inactive and roll off as expected.  But an examination by
> Mr. Exchange shows that there are .log files which are never marked
> as inactive, and, thus, are immortal, so far to the sum of 50 Tb on
> site (and the same offsite).  We obviously missed something in
> configuration, but what?
>
> To complicate matters, we tried to modify the client to allow
> deletion of backups (Mr. Exchange discovered on his own that "del ba
> *log todate=current_date-30" will get rid of the unwanted) but keep
> getting the client is accessing the server message, on an empty
> machine.  While waiting to figure this out, we could do "del vol xxx
> discarddat=y" on all those volumes more than 5 weeks old, but there
> must be some way to prevent this in the future.
>

Re: Expiration of Exchange

[Gary Bowers]

My guess is that you are mounting up the filesystem, and backing up
the files directly.  The log files in Exchange are probably getting a
new name as they are truncated, which means that there are no versions
of the files, only a single version that goes from active to inactive
when it is deleted from the server.  Check your "Retain Only"
parameter of the TSM Exchange Management class.  Make sure that this
is set to 30 days and not 365 or nolimit.  This should delete older
files, but only from the date they get marked inactive.

Gary
Itrus Technologies


On Oct 7, 2009, at 8:33 PM, Fred Johanson wrote:


We use Copy Services instead of the TDP for EXCHANGE.  We want to
keep backups for 30 days, which does work.  The .edb files are daily
marked as inactive and roll off as expected.  But an examination by
Mr. Exchange shows that there are .log files which are never marked
as inactive, and, thus, are immortal, so far to the sum of 50 Tb on
site (and the same offsite).  We obviously missed something in
configuration, but what?

To complicate matters, we tried to modify the client to allow
deletion of backups (Mr. Exchange discovered on his own that "del ba
*log todate=current_date-30" will get rid of the unwanted) but keep
getting the client is accessing the server message, on an empty
machine.  While waiting to figure this out, we could do "del vol xxx
discarddat=y" on all those volumes more than 5 weeks old, but there
must be some way to prevent this in the future.

Re: Expiration of Data in TSM...

[Richard Sims]

On Apr 1, 2009, at 7:56 AM, Kiran wrote:


Hi,

Do we have any option in TSM from which we can expire only
particular file
extensions to get expired for Archive data??


That's the function of Delete Archive, provided in the client.  See
examples in the manual, under the description of the Delete ARchive
command.  Beyond that, the TSM architecture prevails, with retention
policies governing overall expiration.

   Richard Sims

Re: Expiration

[Roger Deschner]

.
There's an easier way to get the node number. It's explained very well
at http://www.lascon.co.uk/d005303.htm so I won't repeat it here. Just
beware that the result of this process of starting at NODE 38 will be a
number in hex. You must convert it to decimal for use on the
undocumented args to the EXPIRE INVENTORY command.

I do this all the time, if I know there's some client node that has a
bunch of tapes tied up that could be freed for reclamation by starting
expiration with that node. Works great, especially if you're digging out
of one of those awful expiration mudpits where you run out of scratch
tapes and your database is bloated. (Why does this happen when I go on
vacation?)

OTOH, to skip a node, you could control expiration with a TSM Script
that contains two EXPIRE INVENTORY commands. For instance, if you figure
out that you want to skip node 42 (decimal) you could put these in your
script:

  expire inventory beginnode=1 endnode=41
  commit(not sure it's needed but it can't hurt)
  expire inventory beginnode=43 endnode=99

One caveat I discovered the hard way is, you cannot start this script
manually from a dsmadmc session. You must start it via an admin
schedule. The reason is just like the unix nohup command. If you do run
it manually, then you must keep that dsmadmc session logged in until the
script finishes, or else it will stop when you do. What will happen is
that the first EXPIRE INVENTORY command will run to completion, but the
second one will not start. RUNning it via a 1-time admin schedule solves
that problem. (To make an admin schedule run only once, add the
EXPIRE=TODAY option.)

Just beware that as somebody else pointed out, skipping expiration
probably will not accomplish what you want. Instead you need to assign
that node to a different policy domain where things are kept forever.
I keep one of those handy for cases of e-discovery.

Roger Deschner  University of Illinois at Chicago [EMAIL PROTECTED]
There are only 10 types of people in the world: Those who understand
binary, and those who don't ...


On Fri, 15 Aug 2008, Schneider, Jim wrote:

>
>To run expiration for one node use the following undocumented
>parameters:
>expire inventory beginnode= endnode=
>
>To get the node numbers, use the following case-sensitive commands from
>a dsmadmc session:
>create sqltable Nodes Mynodes
>select c0,c1 from Mynodes order by c1
>drop sqltable Mynodes
>
>To bypass expiration on one node use a pair of commands.  I wrote a
>script to issue the first command, wait for it to end, then issue the
>second command.
>For example,
>expire inventory beginnode= endnode=103
>expire inventory beginnode=105 endnode=
>
>The nodes are numbered in the order in which they were registered.
>There will be gaps if any nodes were deleted.
>
>Hope this helps,
>Jim Schneider
>
>-Original Message-
>From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
>Zoltan Forray/AC/VCU
>Sent: Friday, August 15, 2008 10:59 AM
>To: ADSM-L@VM.MARIST.EDU
>Subject: Re: [ADSM-L] Expiration
>
>I would like the reverse...to run expiration AGAINST one specific
>node.   I hope V6 adds this.
>
>
>
>"Lepre, James" <[EMAIL PROTECTED]>
>Sent by: "ADSM: Dist Stor Manager" 
>08/15/2008 11:50 AM
>Please respond to
>"ADSM: Dist Stor Manager" 
>
>
>To
>ADSM-L@VM.MARIST.EDU
>cc
>
>Subject
>Re: [ADSM-L] Expiration
>
>
>
>
>
>
>Hello Everyone,
>
> Is there a way to stop expiration from happening on a certain Node?
>
>Thank you
>
>James Lepre
>
>
>
>
>---
>Confidentiality Notice: The information in this e-mail and any
>attachments
>thereto is intended for the named recipient(s) only.  This e-mail,
>including any attachments, may contain information that is privileged
>and
>confidential  and subject to legal restrictions and penalties regarding
>its unauthorized disclosure or other use.  If you are not the intended
>recipient, you are hereby notified that any disclosure, copying,
>distribution, or the taking of any action or inaction in reliance on the
>contents of this e-mail and any of its attachments is STRICTLY
>PROHIBITED.
> If you have received this e-mail in error, please immediately notify
>the
>sender via return e-mail; delete this e-mail and all attachments from
>your
>e-mail  system and your computer system and network; and destroy any
>paper
>copies you may have in your possession. Thank you for your cooperation.
>

Re: Expiration

[Schneider, Jim]

James and Zoltan,

To run expiration for one node use the following undocumented
parameters:
expire inventory beginnode= endnode=

To get the node numbers, use the following case-sensitive commands from
a dsmadmc session:
create sqltable Nodes Mynodes
select c0,c1 from Mynodes order by c1
drop sqltable Mynodes

To bypass expiration on one node use a pair of commands.  I wrote a
script to issue the first command, wait for it to end, then issue the
second command.
For example,
expire inventory beginnode= endnode=103
expire inventory beginnode=105 endnode=

The nodes are numbered in the order in which they were registered.
There will be gaps if any nodes were deleted.

Hope this helps,
Jim Schneider

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 10:59 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration

I would like the reverse...to run expiration AGAINST one specific
node.   I hope V6 adds this.



"Lepre, James" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 11:50 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration






Hello Everyone,

 Is there a way to stop expiration from happening on a certain Node?

Thank you

James Lepre




---
Confidentiality Notice: The information in this e-mail and any
attachments
thereto is intended for the named recipient(s) only.  This e-mail,
including any attachments, may contain information that is privileged
and
confidential  and subject to legal restrictions and penalties regarding
its unauthorized disclosure or other use.  If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action or inaction in reliance on the
contents of this e-mail and any of its attachments is STRICTLY
PROHIBITED.
 If you have received this e-mail in error, please immediately notify
the
sender via return e-mail; delete this e-mail and all attachments from
your
e-mail  system and your computer system and network; and destroy any
paper
copies you may have in your possession. Thank you for your cooperation.

Re: Expiration

[Kevin Boatright]

copy a domain and change the management class retention and versioning to no 
limit and bind the node to that domain. 
 
>>> "Lepre, James" <[EMAIL PROTECTED]> 08/15/08 11:49 AM >>> 
Hello Everyone,

 Is there a way to stop expiration from happening on a certain Node?

Thank you

James Lepre


  
  
---
Confidentiality Notice: The information in this e-mail and any attachments 
thereto is intended for the named recipient(s) only.  This e-mail, including 
any attachments, may contain information that is privileged and confidential  
and subject to legal restrictions and penalties regarding its unauthorized 
disclosure or other use.  If you are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution, or the taking of any 
action or inaction in reliance on the contents of this e-mail and any of its 
attachments is STRICTLY PROHIBITED.  If you have received this e-mail in error, 
please immediately notify the sender via return e-mail; delete this e-mail and 
all attachments from your e-mail  system and your computer system and network; 
and destroy any paper copies you may have in your possession. Thank you for 
your cooperation.

Re: Expiration

[Wanda Prather]

No.
But even if you could, it doesn't do what you think.

If you are retaining 5 versions of a file, when you run the 6th backup, the
1st version is gone/expired/inaccessible.  Whether expiration has run or
not, you can't get that 1st version back (unless you restore your TSM DB to
a prior date).

Stopping expiration will prevent TSM from freeing up DB space and updating
the %reclaim values on your tape.

But the only way to increase retention of files, is to modify the mgt class
definitions they are bound to.

W





On 8/15/08, Lepre, James <[EMAIL PROTECTED]> wrote:
>
> Hello Everyone,
>
> Is there a way to stop expiration from happening on a certain Node?
>
> Thank you
>
> James Lepre
>
>
>
>
> ---
> Confidentiality Notice: The information in this e-mail and any attachments
> thereto is intended for the named recipient(s) only.  This e-mail, including
> any attachments, may contain information that is privileged and
> confidential  and subject to legal restrictions and penalties regarding its
> unauthorized disclosure or other use.  If you are not the intended
> recipient, you are hereby notified that any disclosure, copying,
> distribution, or the taking of any action or inaction in reliance on the
> contents of this e-mail and any of its attachments is STRICTLY
> PROHIBITED.  If you have received this e-mail in error, please immediately
> notify the sender via return e-mail; delete this e-mail and all attachments
> from your e-mail  system and your computer system and network; and destroy
> any paper copies you may have in your possession. Thank you for your
> cooperation.
>

Re: Expiration

[Zoltan Forray/AC/VCU]

I would like the reverse...to run expiration AGAINST one specific
node.   I hope V6 adds this.



"Lepre, James" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 11:50 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration






Hello Everyone,

 Is there a way to stop expiration from happening on a certain Node?

Thank you

James Lepre




---
Confidentiality Notice: The information in this e-mail and any attachments
thereto is intended for the named recipient(s) only.  This e-mail,
including any attachments, may contain information that is privileged and
confidential  and subject to legal restrictions and penalties regarding
its unauthorized disclosure or other use.  If you are not the intended
recipient, you are hereby notified that any disclosure, copying,
distribution, or the taking of any action or inaction in reliance on the
contents of this e-mail and any of its attachments is STRICTLY PROHIBITED.
 If you have received this e-mail in error, please immediately notify the
sender via return e-mail; delete this e-mail and all attachments from your
e-mail  system and your computer system and network; and destroy any paper
copies you may have in your possession. Thank you for your cooperation.

Re: Expiration

[Lepre, James]

Hello Everyone,

 Is there a way to stop expiration from happening on a certain Node?

Thank you

James Lepre


  
  
---
Confidentiality Notice: The information in this e-mail and any attachments 
thereto is intended for the named recipient(s) only.  This e-mail, including 
any attachments, may contain information that is privileged and confidential  
and subject to legal restrictions and penalties regarding its unauthorized 
disclosure or other use.  If you are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution, or the taking of any 
action or inaction in reliance on the contents of this e-mail and any of its 
attachments is STRICTLY PROHIBITED.  If you have received this e-mail in error, 
please immediately notify the sender via return e-mail; delete this e-mail and 
all attachments from your e-mail  system and your computer system and network; 
and destroy any paper copies you may have in your possession. Thank you for 
your cooperation.

Re: Expiration on a Test server

[Richard Cowen]

I did not interview much. The install date is in the status tren reoport file.

-Original Message-
From: Kauffman, Tom <[EMAIL PROTECTED]>
Sent: Friday, August 15, 2008 11:34 AM
To: ADSM-L@VM.MARIST.EDU 
Subject: Re: [ADSM-L] Expiration on a Test server

FWIW, we use multiple networks for TSM backups/archives - and we use DNS.

My TSM server is columbia; it also answers to columbia-pri (our 'private' 
network for SAP only); columbia-adm (administrative); columbia-bu1, 
columbia-bu2, columbia-bu3, and columbia-bu4 (gigabit dedicated backup 
networks). In addition we use CNAMES in our DNS that point to the columbia 
names. All our DSM.SYS entries reference the cnames, so we can move to a new 
TSM server any time we want just by changing the cname entries in DNS.

The primary network uses the 10.x.y.z address range; all the others are from 
192.168.y.z.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan 
Forray/AC/VCU
Sent: Friday, August 15, 2008 11:06 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration on a Test server

We don't use DNS references. We use specific IP addresses to force
communications onto a private connection/subnet between the servers.

Sounds like I need to go with the "unplug from the network" method before
I start the server up and run the expire.

Thanks for all the feedback.  I am glad I asked.



Richard Rhodes <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 10:54 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






This is exactly what I do when testing a new TSM upgrade.  I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance).  That way
the test system is completely
 isolated with no chance of trying to  contact a production server.

TEST BY TRYING TO PING the production servers/instances!
We use AIX.  One thing to watch our for is that the default lookup order
is
DNS first, hosts file second.  (at
that's how our systems were)  I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager"  wrote on 08/15/2008
10:37:46 AM:

> When we did our upgrade testing we did not allow the test server to talk
> to the production server by creating a false entry in the hosts file.
> We also did not allow our test server to connect to the libraries.  This
> may be the paranoid approach, but we did not break anything.
>


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
CONFIDENTIALITY NOTICE:  This email and any attachments are for the 
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in 
reliance upon this message. If you have received this in error, please 
notify us immediately by return email and promptly delete this message 
and its attachments from your computer system. We do not waive  
attorney-client or work product privilege by the transmission of this
message.

Re: Expiration on a Test server

[Kauffman, Tom]

FWIW, we use multiple networks for TSM backups/archives - and we use DNS.

My TSM server is columbia; it also answers to columbia-pri (our 'private' 
network for SAP only); columbia-adm (administrative); columbia-bu1, 
columbia-bu2, columbia-bu3, and columbia-bu4 (gigabit dedicated backup 
networks). In addition we use CNAMES in our DNS that point to the columbia 
names. All our DSM.SYS entries reference the cnames, so we can move to a new 
TSM server any time we want just by changing the cname entries in DNS.

The primary network uses the 10.x.y.z address range; all the others are from 
192.168.y.z.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan 
Forray/AC/VCU
Sent: Friday, August 15, 2008 11:06 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration on a Test server

We don't use DNS references. We use specific IP addresses to force
communications onto a private connection/subnet between the servers.

Sounds like I need to go with the "unplug from the network" method before
I start the server up and run the expire.

Thanks for all the feedback.  I am glad I asked.



Richard Rhodes <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 10:54 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






This is exactly what I do when testing a new TSM upgrade.  I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance).  That way
the test system is completely
 isolated with no chance of trying to  contact a production server.

TEST BY TRYING TO PING the production servers/instances!
We use AIX.  One thing to watch our for is that the default lookup order
is
DNS first, hosts file second.  (at
that's how our systems were)  I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager"  wrote on 08/15/2008
10:37:46 AM:

> When we did our upgrade testing we did not allow the test server to talk
> to the production server by creating a false entry in the hosts file.
> We also did not allow our test server to connect to the libraries.  This
> may be the paranoid approach, but we did not break anything.
>


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
CONFIDENTIALITY NOTICE:  This email and any attachments are for the 
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in 
reliance upon this message. If you have received this in error, please 
notify us immediately by return email and promptly delete this message 
and its attachments from your computer system. We do not waive  
attorney-client or work product privilege by the transmission of this
message.

Re: Expiration on a Test server

[Kauffman, Tom]

Ah - A light dawns.

You have a TSM server, 'A', on host 'A' that has connections to a library, 
disk, and other such. You are now building a new copy of the TSM server 'A' on 
host 'B'. If host 'B' does not have physical contact with the library AND your 
new server 'A' does not have a server definition for the old 'A' you should be 
OK.

Like I say, we've never done server to server setups. But I do think it would 
be unusual to define a server to itself, which would be the only way I could 
see the new copy attaching to the old copy at the server level.

When I run my validation tests here I make sure that the normal TSM config for 
my test environment continues to point to the production server. Then I use a 
custom DSM.OPT pointing to a test server stanza in the DSM.SYS to access the 
test TSM server for both client and administrative command-line tools. I also 
partition my library (I have a 3584) and set up an absolute minimum library 
environment -- but only after I've played with expiration.

Does this help, or have I confused the issue?

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan 
Forray/AC/VCU
Sent: Friday, August 15, 2008 10:39 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration on a Test server

This is one of the reasons I haven't brought it up after the reload, yet.

The test server isn't going to use/do anything but test things like EXPIRE
INVENTORY.  We will be erasing/reloading it numerous times.

So, how do I avoid these possible complication?  Disconnect the ethernet
cable and work from the console?  Remove/change the test servers
definition from the production server?




Richard Sims <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 10:28 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






On Aug 15, 2008, at 10:10 AM, Zoltan Forray/AC/VCU wrote:

> Will doing this effect the actual, live data on the production server,
> since they see each other?  I was concerned it would try to release
> tapes
> and such.

By covertly sharing the real tape library inventory, you're playing
with fire, as the test TSM goes to use "expired" tapes for database
backups and any other server scheduled or triggered events.  That
server may also adjust the settings of tapes in the library, out of
sync with what the real server is doing.  Interesting situations may
result.

Richard Sims
CONFIDENTIALITY NOTICE:  This email and any attachments are for the 
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in 
reliance upon this message. If you have received this in error, please 
notify us immediately by return email and promptly delete this message 
and its attachments from your computer system. We do not waive  
attorney-client or work product privilege by the transmission of this
message.

Re: Expiration on a Test server

[Zoltan Forray/AC/VCU]

We don't use DNS references. We use specific IP addresses to force
communications onto a private connection/subnet between the servers.

Sounds like I need to go with the "unplug from the network" method before
I start the server up and run the expire.

Thanks for all the feedback.  I am glad I asked.



Richard Rhodes <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 10:54 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






This is exactly what I do when testing a new TSM upgrade.  I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance).  That way
the test system is completely
 isolated with no chance of trying to  contact a production server.

TEST BY TRYING TO PING the production servers/instances!
We use AIX.  One thing to watch our for is that the default lookup order
is
DNS first, hosts file second.  (at
that's how our systems were)  I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager"  wrote on 08/15/2008
10:37:46 AM:

> When we did our upgrade testing we did not allow the test server to talk
> to the production server by creating a false entry in the hosts file.
> We also did not allow our test server to connect to the libraries.  This
> may be the paranoid approach, but we did not break anything.
>


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Re: Expiration on a Test server

[Richard Rhodes]

This is exactly what I do when testing a new TSM upgrade.  I restore a DB
to our test server, but before
starting it I put bogus entries in the /etc/hosts file for each of our
production tsm instances and AIX servers, including
the library manager (we have dns aliases for each TSM instance).  That way
the test system is completely
 isolated with no chance of trying to  contact a production server.

TEST BY TRYING TO PING the production servers/instances!
We use AIX.  One thing to watch our for is that the default lookup order is
DNS first, hosts file second.  (at
that's how our systems were)  I had to change the search order in the
/etc/netsvc.conf file to do local search
first, then DNS.

Rick

"ADSM: Dist Stor Manager"  wrote on 08/15/2008
10:37:46 AM:

> When we did our upgrade testing we did not allow the test server to talk
> to the production server by creating a false entry in the hosts file.
> We also did not allow our test server to connect to the libraries.  This
> may be the paranoid approach, but we did not break anything.
>


-
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.

Re: Expiration on a Test server

[Kauffman, Tom]

Zoltan -

I wouldn't touch this configuration with someone else's sharp stick.

For one thing, to run expiration in a realistic manner you'll be limited to one 
run per day unless you change the date on the test server.

I'd break the testing into at least two stages -- one as a stand-alone, running 
the expire inventory with the production database copy, and the second as a TSM 
server with it's own database (not sure of the terminology here; we've never 
set up multiple servers with one library manager).

If you could logically or physically partition the library for a while that 
would let you test the library interface before swapping servers.

Tom

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan 
Forray/AC/VCU
Sent: Friday, August 15, 2008 10:10 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Expiration on a Test server

We have purchased a new, even beefier server then our last one.

To make sure it is configured optimally, we want to test how long an
expire inventory runs.  Our biggest server is up to 190G DB and expires
run 40-48hours.

I installed and configured the new server, connecting it to the main, tape
library owning server, which happens to be the one with the big DB.

I have taken the 190G DB and restored it to this new server.

Never having done this, I may be asking stupid question, but want to be
sure I don't do anything irreversible that may effect the production
server.

I want to run an EXPIRE INVENTORY against the restored database, perhaps
numerous times.

Will doing this effect the actual, live data on the production server,
since they see each other?  I was concerned it would try to release tapes
and such.
CONFIDENTIALITY NOTICE:  This email and any attachments are for the 
exclusive and confidential use of the intended recipient.  If you are not
the intended recipient, please do not read, distribute or take action in 
reliance upon this message. If you have received this in error, please 
notify us immediately by return email and promptly delete this message 
and its attachments from your computer system. We do not waive  
attorney-client or work product privilege by the transmission of this
message.

Re: Expiration on a Test server

[Zoltan Forray/AC/VCU]

This is one of the reasons I haven't brought it up after the reload, yet.

The test server isn't going to use/do anything but test things like EXPIRE
INVENTORY.  We will be eraseing/reloading it numerous times.

So, how do I avoid these possible complication?  Disconnect the ethernet
cable and work from the console?  Remove/change the test servers
definition from the production server?




Richard Sims <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
08/15/2008 10:28 AM
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@VM.MARIST.EDU
cc

Subject
Re: [ADSM-L] Expiration on a Test server






On Aug 15, 2008, at 10:10 AM, Zoltan Forray/AC/VCU wrote:

> Will doing this effect the actual, live data on the production server,
> since they see each other?  I was concerned it would try to release
> tapes
> and such.

By covertly sharing the real tape library inventory, you're playing
with fire, as the test TSM goes to use "expired" tapes for database
backups and any other server scheduled or triggered events.  That
server may also adjust the settings of tapes in the library, out of
sync with what the real server is doing.  Interesting situations may
result.

Richard Sims

Re: Expiration on a Test server

[Huebner,Andy,FORT WORTH,IT]

When we did our upgrade testing we did not allow the test server to talk
to the production server by creating a false entry in the hosts file.
We also did not allow our test server to connect to the libraries.  This
may be the paranoid approach, but we did not break anything.

Andy Huebner
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Zoltan Forray/AC/VCU
Sent: Friday, August 15, 2008 9:10 AM
To: ADSM-L@VM.MARIST.EDU
Subject: [ADSM-L] Expiration on a Test server

We have purchased a new, even beefier server then our last one.

To make sure it is configured optimally, we want to test how long an
expire inventory runs.  Our biggest server is up to 190G DB and expires
run 40-48hours.

I installed and configured the new server, connecting it to the main,
tape
library owning server, which happens to be the one with the big DB.

I have taken the 190G DB and restored it to this new server.

Never having done this, I may be asking stupid question, but want to be
sure I don't do anything irreversible that may effect the production
server.

I want to run an EXPIRE INVENTORY against the restored database, perhaps
numerous times.

Will doing this effect the actual, live data on the production server,
since they see each other?  I was concerned it would try to release
tapes
and such.


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.

Re: Expiration on a Test server

[Richard Sims]

On Aug 15, 2008, at 10:10 AM, Zoltan Forray/AC/VCU wrote:


Will doing this effect the actual, live data on the production server,
since they see each other?  I was concerned it would try to release
tapes
and such.


By covertly sharing the real tape library inventory, you're playing
with fire, as the test TSM goes to use "expired" tapes for database
backups and any other server scheduled or triggered events.  That
server may also adjust the settings of tapes in the library, out of
sync with what the real server is doing.  Interesting situations may
result.

   Richard Sims

Re: Expiration Query

[Thomas Denier]

-Jeff White wrote: -

>I have a query regarding expiration
>
>Recently implemented new retention policies new reduce the amount of
>version of windows files we have in TSM storage. Before implementing,
>i ran this script to get the total number of files in storage at that
>time:
>
>SELECT SUM(NUM_FILES), NODE_NAME FROM OCCUPANCY GROUP BY NODE_NAME
>order >by 1 desc
>
>This told me i had 125,171,962 files in storage
>
>I run expiry every day, capture and record from the activity log the
>number of backup objects deleted every day. Over the first 10 days,
>this totalled 6,652,218 files.
>
>I then re-ran the above script and the total number of files was
>113,796,651, a difference of 11,375,311.
>
>Was i wrong to expect number of expired files to match the actual
>difference?

Are you using copy storage pools? If so, expiring one object will
typically reduce the sum of the occupancy counts by two, because
both the count for the relevant primary storage pool and the
count for the associated copy storage pool will decrease.

Note that there are some objects that TSM can recreate from data in
the TSM database without needing to put anything in storage pools.
Zero length files, Unix directories, and Unix special files can
usually be handled this way. Expiring such objects will have no
effect on the occupancy counts.

Re: Expiration Query

[Leandro Mazur]

I think the both numbers should match, if didn't backuped anything at all
after ran the first command...

On Thu, Apr 17, 2008 at 5:59 AM, Jeff White <[EMAIL PROTECTED]>
wrote:

> Hi
>
>
>
> TSM v5.4.0
>
>
>
> I have a query regarding expiration
>
>
>
> Recently implemented new retention policies new reduce the amount of
> version of windows files we have in TSM storage. Before implementing, i
> ran this script to get the total number of files in storage at that
> time:
>
>
>
> SELECT SUM(NUM_FILES), NODE_NAME FROM OCCUPANCY GROUP BY NODE_NAME order
> by 1 desc
>
>
>
> This told me i had 125,171,962 files in storage
>
>
>
> I run expiry every day, capture and record from the activity log the
> number of backup objects deleted every day. Over the first 10 days, this
> totalled 6,652,218 files.
>
>
>
> I then re-ran the above script and the total number of files was
> 113,796,651, a difference of 11,375,311.
>
>
>
> Was i wrong to expect number of expired files to match the actual
> difference?
>
>
>
>
>
> Thanks
>
>
>
> Jeff
>
>
> 
> Woolworths plc
> Registered Office: 242 Marylebone Road, London NW1 6JL
> Registered in England, Number 104206
>
> This e-mail is only intended for the person(s) to whom it is addressed and
> may contain confidential information.  Unless stated to the contrary, any
> opinions or comments are personal to the writer and do not represent the
> official view of the company.  If you have received this e-mail in error,
> please notify us immediately by reply e-mail and then delete this message
> from your system Please do not copy it or use it for any purposes,  or
> disclose its contents to any other person.  Thank you for your
> co-operation.
>
> 
>
> 
> Email scanned for viruses and unwanted content by emailsystems
>
> Information regarding this service can be found at www.emailsystems.com




--
__
Leandro Mazur

Re: Expiration

[William Boyer]

Nothing that I'm aware of, but you could always run a couple select statements 
before and after the expiration process to list the
total occupancy of the stgpool(s) defined in your VTL:

Select sum(physical_mb) from occupancy where stgpool_name in 
('stgpool1','stgpool2',...)

The list of stgpool(s) that are defined to your VTL in UPPERCASE.

This should give you a before and after occupancy picture.

Bill Boyer
"Life is like riding a bicycle. To keep your balance you must keep moving" - ??
 


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Lepre, 
James
Sent: Tuesday, March 11, 2008 10:22 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration

Hello All,

  Is there a SELECT Statement that would tell you how many files are expired 
and how much data this correlates to?  For example if
we expire 1,000,000 file that could be 500MB of actual data.  The reason for 
this request is because we need to know how much data
is actually coming off of our VTL from the expiration process.

Thank you in Advance

James

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Hans 
Christian Riksheim
Sent: Monday, March 10, 2008 6:46 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM has built-in encryption?

A lot of people opt for the transparent encryption scheme where the key is held 
in the TSM database and it seems that IBM is moving
in that direction with this feature being the only option in 5.5 for the 
BA-client. It seems that I am the only one who wants it the
other way around.
 
As I see it, client-key encryption offers far better security. OK, you must 
protect the key and store it on paper or other media on
more than one secure location in case of DR but isn't that the whole game with 
crypto anyways? No key? Sorry, no data for you!
Transparent encryption on the other hand is easier but security is poorer. 
 
I have thought on some security breach scenarios and compared the two schemes. 
Correct me if I am wrong on any of the
technicalities.
 
Tapping the lines between data center(customer) and backup site:
The is the same for both client-key encryption and transparent encryption. A 
snooper will in both cases only get DES56/AES128
garble. 
 
Lost/stolen tape media:
This depends. The data tapes alone are protected with both schemes. But if you 
also get hold of the DBbackup tapes(Hijack the truck
with DR tapes) you can restore the TSM-server with the keys if you are using 
transparent encryption. With client-key encryption the
data is safe from inspection because you do not have the keys.
 
Backup site breakin:
The data will be safe with client-key encryption. With transparent encryption 
the intruder will have full access to all data.
 
 
Backup-LAN:
Someone puts a client into your Backup-LAN or one client that is already there 
wants to snoop into another clients data. For example
if backup is outsourced different customers/competitors are sharing the same 
TSM infrastructure. With transparent encryption you can
access all the data on the TSM server IF you have an admin password for an 
account with system privilege. And a lot of admin
passwords are not that secret. Many places admin password are not changed for 
different reasons. In some setups with config manager
and library sharing it is seen as too cumbersome to change these passwords. 
Anyway, in this scenario transparent encryption offers
no security. Client-key encryption does.
 
 
Trusting the TSM administrator:
I'm not saying that TSM administrators are an untrustworthy lot. But with 
client-key encryption you don't have to trust the TSM
admin and it is a big difference. If I offer a TSM service, backup "through a 
hole in the wall" or what it is called, the customer
can set the encryption key himself and even if I wanted to, would have no 
chance of retrieving his data and giving it away. The
backup is as secure as the customers own standard for protecting the key. He 
does not have to rely on the supplier of the TSM
service.
 
 
I guess there are more examples and pros and cons but this sums it up for me: I 
want IBM to continue with client-key encryption for
the BA client, offer the same option for TDPO(though there are other means to 
the end in Oracle10/11) and likewise for
Exchange(where I'm not sure of which options exist in the application itself).
 
 
Best regards
 
Hans Chr. Riksheim
 
 
 
 
 
 
 
 
 
 



Fra: ADSM: Dist Stor Manager på vegne av Wanda Prather
Sendt: to 06.03.2008 17:03
Til: ADSM-L@VM.MARIST.EDU
Emne: Re: TSM has built-in encryption?



The TSM clients (including TDP's) can encrypt at AES 256.  You take a hit on 
performance for both backup and restore; you need to
also turn on compression on the client, as encrypted data can't be compressed 
by the tape drive.

If you want to encrypt using the backup client, I STRONGLY r

Re: EXPIRATION

[Lepre, James]

Hello All,

 

  Is there a SELECT Statement that would tell you how many files are
expired and how much data this correlates to?  For example if we expire
1,000,000 file that could be 500MB of actual data.  The reason for this
request is because we need to know how much data is actually coming off
of our VTL from the expiration process.

 

Thank you in Advance

 

James


  
  
---
Confidentiality Notice: The information in this e-mail and any attachments 
thereto is intended for the named recipient(s) only.  This e-mail, including 
any attachments, may contain information that is privileged and confidential  
and subject to legal restrictions and penalties regarding its unauthorized 
disclosure or other use.  If you are not the intended recipient, you are hereby 
notified that any disclosure, copying, distribution, or the taking of any 
action or inaction in reliance on the contents of this e-mail and any of its 
attachments is STRICTLY PROHIBITED.  If you have received this e-mail in error, 
please immediately notify the sender via return e-mail; delete this e-mail and 
all attachments from your e-mail  system and your computer system and network; 
and destroy any paper copies you may have in your possession. Thank you for 
your cooperation.

Re: Expiration

[Lepre, James]

Hello All,

  Is there a SELECT Statement that would tell you how many files are expired 
and how much data this correlates to?  For example if we expire 1,000,000 file 
that could be 500MB of actual data.  The reason for this request is because we 
need to know how much data is actually coming off of our VTL from the 
expiration process.

Thank you in Advance

James

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Hans 
Christian Riksheim
Sent: Monday, March 10, 2008 6:46 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] TSM has built-in encryption?

A lot of people opt for the transparent encryption scheme where the key is held 
in the TSM database and it seems that IBM is moving in that direction with this 
feature being the only option in 5.5 for the BA-client. It seems that I am the 
only one who wants it the other way around.
 
As I see it, client-key encryption offers far better security. OK, you must 
protect the key and store it on paper or other media on more than one secure 
location in case of DR but isn't that the whole game with crypto anyways? No 
key? Sorry, no data for you! Transparent encryption on the other hand is easier 
but security is poorer. 
 
I have thought on some security breach scenarios and compared the two schemes. 
Correct me if I am wrong on any of the technicalities.
 
Tapping the lines between data center(customer) and backup site:
The is the same for both client-key encryption and transparent encryption. A 
snooper will in both cases only get DES56/AES128 garble. 
 
Lost/stolen tape media:
This depends. The data tapes alone are protected with both schemes. But if you 
also get hold of the DBbackup tapes(Hijack the truck with DR tapes) you can 
restore the TSM-server with the keys if you are using transparent encryption. 
With client-key encryption the data is safe from inspection because you do not 
have the keys.
 
Backup site breakin:
The data will be safe with client-key encryption. With transparent encryption 
the intruder will have full access to all data.
 
 
Backup-LAN:
Someone puts a client into your Backup-LAN or one client that is already there 
wants to snoop into another clients data. For example if backup is outsourced 
different customers/competitors are sharing the same TSM infrastructure. With 
transparent encryption you can access all the data on the TSM server IF you 
have an admin password for an account with system privilege. And a lot of admin 
passwords are not that secret. Many places admin password are not changed for 
different reasons. In some setups with config manager and library sharing it is 
seen as too cumbersome to change these passwords. Anyway, in this scenario 
transparent encryption offers no security. Client-key encryption does.
 
 
Trusting the TSM administrator:
I'm not saying that TSM administrators are an untrustworthy lot. But with 
client-key encryption you don't have to trust the TSM admin and it is a big 
difference. If I offer a TSM service, backup "through a hole in the wall" or 
what it is called, the customer can set the encryption key himself and even if 
I wanted to, would have no chance of retrieving his data and giving it away. 
The backup is as secure as the customers own standard for protecting the key. 
He does not have to rely on the supplier of the TSM service.
 
 
I guess there are more examples and pros and cons but this sums it up for me: I 
want IBM to continue with client-key encryption for the BA client, offer the 
same option for TDPO(though there are other means to the end in Oracle10/11) 
and likewise for Exchange(where I'm not sure of which options exist in the 
application itself).
 
 
Best regards
 
Hans Chr. Riksheim
 
 
 
 
 
 
 
 
 
 



Fra: ADSM: Dist Stor Manager på vegne av Wanda Prather
Sendt: to 06.03.2008 17:03
Til: ADSM-L@VM.MARIST.EDU
Emne: Re: TSM has built-in encryption?



The TSM clients (including TDP's) can encrypt at AES 256.  You take a hit on
performance for both backup and restore; you need to also turn on
compression on the client, as encrypted data can't be compressed by the tape
drive.

If you want to encrypt using the backup client, I STRONGLY recommend you
upgrade to 5.5, where the TSM server manages the keys for you.  Prior to
that level, you have to maintain the keys manually; if you lose the keys and
have to go to a DR site, you won't get your data back.  At 5.5, the keys are
generated randomly and maintained in the TSM data base.  (The TDP's have the
keys managed by the TSM data base starting at 5.3; for regular clients, that
feature starts at 5.5).

A better/cleaner method is encrypting outboard in the hardware.  Look into
upgrading your drives to LTO4; then (with an additional feature code on your
3584) you can do the encryption outboard, with no performance hit.  TSM can
still maintain the keys for you, if you want, or you can use an external key
manager that IBM provides.

Whether or not 

Re: Expiration process is running but Data inside tape not deleted (expire)

[Richard Sims]

On Jul 11, 2007, at 7:46 AM, hshahizul wrote:


Hi Dr. TSM


Well... I'm an EMT: the doctors are residents at IBM.  :-)


I have check my TSM Server

TSM 5.3.0.0


You're running base-level code, which is asking for problems.  Never
do that, when v.r.m.0 maintenance is available.  I strongly advise
that you apply the latest 5.3 maintenance.  See below.


AIX 5.2.0.0 ML 01

I have check on the DEACTIVE_DATE from query and I found out a lot of
filespace backup.

DEACTIVATE_DATE is 1900-01-01


As explained in ADSM QuickFacts, this is the "negative infinity" fake
timestamp that the TSM server's expiration prep thread applies to
objects which have exceeded the versions or age policy values, and
are candidates for deletion from the TSM database.  An Expire
Inventory which runs to completion should dispose of such entries.

I would advise applying the latest TSM server 5.3 maintenance, and
thereafter run EXPIre Inventory Quiet=No, letting it run to
completion.  If the resulting ANR0812I message shows no deletions,
review the expiration progress messages in your Activity Log for
issues.  (For that matter, pore over your Activity Log for the past
several days to see if there are unrealized problems.)  If still
stumped, it's one for TSM Support.

   Richard Sims

Re: Expiration process is running but Data inside tape not deleted (expire)

[hshahizul]

Hi Dr. TSM

I have check my TSM Server

TSM 5.3.0.0
AIX 5.2.0.0 ML 01

I have check on the DEACTIVE_DATE from query and I found out a lot of
filespace backup.

DEACTIVATE_DATE is 1900-01-01


Please advice.

Tq.

-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Richard Sims
Sent: Tuesday, July 10, 2007 10:14 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] Expiration process is running but Data inside tape not
deleted (expire)

The retention policies you think are in use may not be, particularly
if Query COpygroup does not show them activated; or you may be
assuming that backup data dominates the inventory, whereas Archive
data may (Query COpygroup Type=Archive).  If you never see data
expiring though client data is transitioning every day, then this may
be the case.

I would do spot checks of the BACKUPS table, using very focused
Select lookups, to examine the DEACTIVATE_DATE relative to the
retention period.  I would also spot check the ARCHIVES table, again
in a very focused way, checking the ARCHIVE_DATE vs. retention
period.  And, as I recommend in ADSM QuickFacts topic "Expiration not
happening", do SHow TIME and verify that the computer date and time
are correct.

Lastly, you say that your server level is TSM 5.3.  When posting,
include the third digit, so we know the maintenance level.  If at
5.3.0, it is healthy to get some maintenance on that system.

   Richard Sims

Re: Expiration process is running but Data inside tape not deleted (expire)

[Richard Sims]

The retention policies you think are in use may not be, particularly
if Query COpygroup does not show them activated; or you may be
assuming that backup data dominates the inventory, whereas Archive
data may (Query COpygroup Type=Archive).  If you never see data
expiring though client data is transitioning every day, then this may
be the case.

I would do spot checks of the BACKUPS table, using very focused
Select lookups, to examine the DEACTIVATE_DATE relative to the
retention period.  I would also spot check the ARCHIVES table, again
in a very focused way, checking the ARCHIVE_DATE vs. retention
period.  And, as I recommend in ADSM QuickFacts topic "Expiration not
happening", do SHow TIME and verify that the computer date and time
are correct.

Lastly, you say that your server level is TSM 5.3.  When posting,
include the third digit, so we know the maintenance level.  If at
5.3.0, it is healthy to get some maintenance on that system.

  Richard Sims

Re. Expiration

[Markus Engelhard]

Hi Kevin,

I like this one...

Rebinding will not cure the inactive file with no active file problem, nore
will archives be rebound ar correctly pointed out. So there are basically
two options left:

a) Create another TSM-server instance with one donain an all that with one
default management class which keeps everything forever. To make double
sure, don't run expiration on this server. Export your node and data.
Depending on your needs, keep on backing up the node on the old system with
your defaults expiring old data or move the node to the new server to keep
everything forever.

b) simpler: create a management domain with all defaults keeping data
forever and move node and data to it. Here you can either rename the node
or create a new one in the old domain to back up data. This is not quite so
tamper-proof, as expration will hav to run on the server and changing
parameters by accident (I think someone called that junior admin had a good
idea some time ago) could delete data by accident


Regards,

Markus


--
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte
Weitergabe dieser Mail oder von Teilen dieser Mail ist nicht gestattet.

Wir haben alle verkehrsüblichen Maßnahmen unternommen, um das Risiko der
Verbreitung virenbefallener Software oder E-Mails zu minimieren, dennoch
raten wir Ihnen, Ihre eigenen Virenkontrollen auf alle Anhänge an dieser
Nachricht durchzuführen. Wir schließen außer für den Fall von Vorsatz oder
grober Fahrlässigkeit die Haftung für jeglichen Verlust oder Schäden durch
virenbefallene Software oder E-Mails aus.

Jede von der Bank versendete E-Mail ist sorgfältig erstellt worden, dennoch
schließen wir die rechtliche Verbindlichkeit aus; sie kann nicht zu einer
irgendwie gearteten Verpflichtung zu Lasten der Bank ausgelegt werden.
__

This e-mail may contain confidential and/or privileged information. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorised copying, disclosure or distribution of  the material in this
e-mail or of parts hereof is strictly forbidden.

We have taken precautions to minimize the risk of transmitting software
viruses but nevertheless advise you to carry out your own virus checks on
any attachment of this message. We accept no liability for loss or damage
caused by software viruses except in case of gross negligence or willful
behaviour.

Any e-mail messages from the Bank are sent in good faith, but shall not be
binding or construed as constituting any kind of obligation on the part of
the Bank.

Re: Expiration

[Helder Garcia]

On 2/7/07, Kevin Boatright <[EMAIL PROTECTED]> wrote:


The management class has been changed on active files but not on
inactive files.



Are you refering to backup objects? How did you find out that the above is
happening? issuing select statements on BACKUPS table?
I'm asking because this is not supposed to happen. when you change the
management class for some object on option file, next time you run a backup
those objects will be rebound to these new management class.
Also, make sure you run a full incremental backup after some change on the
management class attributes.

From the Admin Guide:


"A partial incremental backup should complete more quickly and require less
memory. When a client uses partial incremental backup, only files that have
changed since the last incremental backup are backed up. Attributes in the
management class that would cause a file to be backed up when doing a full
incremental backup are ignored. For example, unchanged files are not backed
up even when they are assigned to a management class that specifies absolute
mode and the minimum days between backups (frequency) has passed. The server
also does less processing for a partial incremental backup. For example, the
server does not expire files or rebind management classes to files during a
partial incremental backup. If clients must use partial incremental backups,
they should periodically perform full incremental backups to ensure that
complete backups are done and backup files are stored according to
policies."

What you may be having is:
- You changed attributes from the management class (backup copy group). The
management class name remains the same on the select results. To be sure the
new settings are applied (retention, number of versions, etc), run a full
incremental;
- You assigned the files to other management class. The select should
reports the new management class (after a backup). If the MC doesn't change,
you may have some typo on the option file, so the rebind is not actually
happening and the files fall on the default MC;

Archive objects are never rebound.
--
Helder Garcia

Re: Expiration

[BEYERS Kurt]

Kevin,
 
How about taking a full export or creating a backupset of the nodes in question?
 
The active files on the servers won't never expire since you've changed the 
management classes. And if a restore is requested for a file that is not foud 
any more, you will have to dig into the export or backupset. The latter restore 
will ask some more time but I guess that the frequency of such a restore will 
be low too;
 
best regards,
Kurt



Van: ADSM: Dist Stor Manager namens Thomas Denier
Verzonden: wo 7/02/2007 19:44
Aan: ADSM-L@VM.MARIST.EDU
Onderwerp: Re: [ADSM-L] Expiration



-Kevin Boatright wrote: -

>Is there any way expire inventory on all nodes except for a select
>few? I have two servers that I cannot delete any data on.
>
>I changed the management class on thse two servers to not delete
>files. The management class has been changed on active files but
>not on inactive files. But, when expiration runs next, it will
>delete the inactive files.
>
>Any recommendations?

A long time ago my site had a problem that caused expiration to
hang at a certain directory. IBM informed us of undocumented
options to the 'expire inventory' command to control the first
and last nodes processed (nodes are processed in order of
registration time). We alternated between expiring from the
oldest node to the one just before the problem node, and
expiring from the node just after the problem node to the
newest node. I don't know whether these options still exist
in the current server code. I couldn't find my notes on that
episode.

I am not sure this type of facility would help you. Other
sites have tried to keep files restorable by suppressing
inventory expiration. If I remember correctly, they found
that the client would not restore or even list files that
were eligible for expiration, even if the files had not
in fact been removed from the TSM database by inventoryexpiration.


*** Disclaimer ***

Vlaamse Radio- en Televisieomroep
Auguste Reyerslaan 52, 1043 Brussel

nv van publiek recht
BTW BE 0244.142.664
RPR Brussel
http://www.vrt.be/disclaimer
 

Re: Expiration

[Thomas Denier]

-Kevin Boatright wrote: -

>Is there any way expire inventory on all nodes except for a select
>few? I have two servers that I cannot delete any data on.
>
>I changed the management class on thse two servers to not delete
>files. The management class has been changed on active files but
>not on inactive files. But, when expiration runs next, it will
>delete the inactive files.
>
>Any recommendations?

A long time ago my site had a problem that caused expiration to
hang at a certain directory. IBM informed us of undocumented
options to the 'expire inventory' command to control the first
and last nodes processed (nodes are processed in order of
registration time). We alternated between expiring from the
oldest node to the one just before the problem node, and
expiring from the node just after the problem node to the
newest node. I don't know whether these options still exist
in the current server code. I couldn't find my notes on that
episode.

I am not sure this type of facility would help you. Other
sites have tried to keep files restorable by suppressing
inventory expiration. If I remember correctly, they found
that the client would not restore or even list files that
were eligible for expiration, even if the files had not
in fact been removed from the TSM database by inventoryexpiration.

Re: Expiration

[Richard Sims]

On Feb 7, 2007, at 11:06 AM, Kevin Boatright wrote:


Is there any way expire inventory on all nodes except for a select
few?
I have two servers that I cannot delete any data on.


No - there is no such capability with Expire Inventory.


I changed the management class on thse two servers to not delete
files.
The management class has been changed on active files but not on
inactive files. But, when expiration runs next, it will delete the
inactive files.


To keep the old files around, you need to boost at least the
retention period within the Copy Group(s) in the Management Classes
to which the files are bound.  You may also need to boost the
versions value, if ongoing backups will "push out" what you want to
keep.

  Richard Sims

Re: Expiration running over 24 hours

[Sung Y Lee]

I wouldn't say expiration running over 24 hours a cause for alarm per say.
I have seen expiration running over 10 days.  This occurred when TSM server
was upgraded to address expiration issue with Windows system objects.  Few
years back.

That being said, I would examine past actlog to see if any irregular anr
messages appears during expiration to see if  abnormality is spotted.

Sung Y. Lee

"ADSM: Dist Stor Manager"  wrote on 11/02/2006
02:01:44 PM:

> To Whom It May Concern:
>
> Expiration ran over 24 hours yesterday. I cancelled it when the DB
> backup job started. We recently migrated 30-40 volumes from an old
> sequential pool that became went into pending. About 30 volumes passed
> the re-use delay period and went to scratch 2 days ago. I was wondering
> if this could have the cause of an extended expiration job.
>
> Any thoughts would be appreciated.
>
>
> George Hughes
>
> Senior UNIX Engineer
>
> Children's National Medical Center
>
> 12211 Plum Orchard Dr.
>
> Silver Spring, MD 20904
>
> (301) 572-3693
>
>
> Confidentiality Notice: This e-mail message, including any attachments,
is
> for the sole use of the intended recipient(s) and may contain
confidential
> and privileged information.  Any unauthorized review, use, disclosure or
> distribution is prohibited.  If you are not the intended recipient,
please
> contact the sender by reply e-mail and destroy all copies of the
> original message.
>

Re: expiration Oracle backups

[Allen S. Rout]

==> On Fri, 14 Oct 2005 09:41:34 +0200, Rainer Holzinger <[EMAIL PROTECTED]> 
said:


> In general this works fine in our installation. But in the meantime there is
> one Oracle system where we have found 'old' TDPO objects in TSM storage but
> no entries in the RMAN recovery catalog. Even a 'TDPOSYNC SYNCDB' did not
> remove or inactivate the TDPO objects which should be there anymore. I will
> test some other things and come back to the list if there's a solution.

This sounds like what we're getting.

If you want a guinea pig, let me know. :)

- Allen S. Rout

Re: expiration Oracle backups

[Rainer Holzinger]

Hello,

I'm running 18 Oracle systems on HP-UX which are backed up by TDP for
Oracle.
The TDP for Oracle version is 5.2.1.0, the TSM servers 5.2.4.1 on AIX
5.2 ML05. Oracle serves are at level 9i and 10g.
Our Oracle administrators have written a RMAN script that deletes
obsolete backups. I was monitoring the first deletes from RMAN and seen
that the delete from RMAN inactivates the TDPO objects on the TSM
server. The next expire inventory process will delete the TDPO objects
from the TSM database and managed storage. I think this is the reason
for BACKDEL=yes, Versions Data Deleted = 0 and Retain Only Version = 0.

In general this works fine in our installation. But in the meantime
there is one Oracle system where we have found 'old' TDPO objects in TSM
storage but no entries in the RMAN recovery catalog. Even a 'TDPOSYNC
SYNCDB' did not remove or inactivate the TDPO objects which should be
there anymore. I will test some other things and come back to the list
if there's a solution.

best regards,
Rainer


> -Original Message-
> From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf
> Of Jurjen Oskam
> Sent: Friday, October 14, 2005 9:13 AM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] expiration Oracle backups
>
> On Thu, Oct 13, 2005 at 07:38:18AM -0700, Neil Rasmussen wrote:
>
> > When deleting Rman objects on the TSM Server, TDP Oracle uses the
> delete
> > function on objectsthe objects do not move to inactive they are
> just
> > simply deleted from the TSM Server.
>
> While the manual says to create nodes for RMAN with Delete Backup
> permission set to yes, the manual also says to use a managementclass
> that
> has Versions Data Deleted = 0 and Retain Only Version = 0. If what you
> say
> is true (and I have no reason to doubt that :) ), then these settings
> are
> not relevant, since there are no inactive RMAN objects. Am I right?
>
> --
> Jurjen Oskam

Re: expiration Oracle backups

[Jurjen Oskam]

On Thu, Oct 13, 2005 at 07:38:18AM -0700, Neil Rasmussen wrote:

> When deleting Rman objects on the TSM Server, TDP Oracle uses the delete
> function on objectsthe objects do not move to inactive they are just
> simply deleted from the TSM Server.

While the manual says to create nodes for RMAN with Delete Backup
permission set to yes, the manual also says to use a managementclass that
has Versions Data Deleted = 0 and Retain Only Version = 0. If what you say
is true (and I have no reason to doubt that :) ), then these settings are
not relevant, since there are no inactive RMAN objects. Am I right?

--
Jurjen Oskam

Re: expiration Oracle backups

[Helder Garcia]

Here is a script I use to expire RMAN backups. Note that I filter
(egrep) the backup pieces based on tags. This way I have separated
expiring scripts for daily, weekly, and monthly backups.



#!/usr/bin/bash
export ORACLE_BASE=/oracle/product/920/admin
export ORACLE_HOME=/oracle/product/920
export LD_LIBRARY_PATH=/oracle/product/920/lib32:/usr/dt/lib:/usr/openwin/lib
export TNS_ADMIN=/oracle/product/920/network/admin
export LD_LIBRARY_PATH_64=/oracle/product/920/lib
export ORA_NLS33=/oracle/product/920/ocommon/nls/admin/data
export NLS_DATE_FORMAT="dd/mm/ hh24:mi:ss"
export ARQLOG=/opt/tivoli/tsm/client/log/ORACLE_SIDobsolete_`date
'+%Y%m%d%H%M%S'`.log
export ORACLE_SID=ORACLE_SID

target=user/[EMAIL PROTECTED]

parms="parms 
'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_restore.opt)'"
catalog='rmanuser/[EMAIL PROTECTED]'

#Registra log de inicio
date '+Inicio do script de remocao de objetos obsoletos em %d/%m/%Y as
%H:%M:%S' >$ARQLOG


dbobsolete_tape=/tmp/ob_tape.log
cmdfile=/tmp/delete.cmd

if [ -f $dbobsolete_tape ]
then
rm $dbobsolete_tape
fi

if [ -f $cmdfile ]
then
rm $cmdfile
fi
# Get a list of obsolete tape files
$ORACLE_HOME/bin/rman msgno target $target rcvcat $catalog msglog
$dbobsolete_tape << EOF > /dev/null
run {
  allocate channel t1 type 'sbt_tape'
  parms 
'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_restore.opt)';
  report obsolete redundancy=45;
  release channel t1;
}
EOF

# sed options
del_bpiece="-e /RMAN-06285/ s/\(.* \)\(.*\)$/change backuppiece '\2' delete;/"

# Create the RMAN command to delete the obsolete files
echo "allocate channel for delete type 'sbt_tape' $parms ;" >> $cmdfile
grep RMAN-06285 $dbobsolete_tape | egrep 'bkp_full|ctl_|arc_' | sed
"$del_bpiece" >> $cmdfile
echo "release channel;" >> $cmdfile

# Execute the RMAN command file to delete the obsolete files
$ORACLE_HOME/bin/rman msgno target $target rcvcat $catalog msglog
$ARQLOG cmdfile $cmdfile

if [ $? -gt 0 ]
then
date '+Termino do script com erro em %d/%m/%Y as %H:%M:%S' >>$ARQLOG
exit 1
else
date '+Termino do script com sucesso em %d/%m/%Y as %H:%M:%S' >>$ARQLOG
fi


On 10/13/05, Kurt Beyers <[EMAIL PROTECTED]> wrote:
> Hello,
>
> My environment is the following:
>
> TSM 5.3.2 server on Windows2003
> Sun Solaris 5.8 with Oracle 8.1.7.4 with a TSM BA client 5.3.x and the TDP 
> for databases 5.3
>
> The backup of the Oracle databases is already working. The metadata of the 
> backups is written in the control files of the Oracle database.
>
> The backups are bound to a mgmt class with the correct settings (as every 
> object receives a unique name in TSM).
>
> The expiration must first be done in Oracle with a script, eg expire the 
> backups older than X days. Could anybody share a working script? I'm still 
> struggling to get it working as it should.
>
> But how are the backups made inactive in the TSM database after they have 
> been deleted in Oracle? The 'tdposync' tool only works when the metadata is 
> stored in a recovery catalog database. And after a forced deletion of the 
> backups in RMAN, they do not become inactive in TSM either. How can the 
> metadata in the TSM database be synchronized with the metadata in Oracle 
> (control file) .
>
> I know this must have been discussed in the past already, but a search of the 
> old threads didn't  clear it out yet.
>
> thanks a lot,
> Kurt
>
>
>


--
Helder Garcia

Re: expiration Oracle backups

[Allen S. Rout]

==> On Thu, 13 Oct 2005 07:38:18 -0700, Neil Rasmussen <[EMAIL PROTECTED]> said:


> When deleting Rman objects on the TSM Server, TDP Oracle uses the delete
> function on objectsthe objects do not move to inactive they are just
> simply deleted from the TSM Server.

Hmm, I thought they did move to inactive; They have their 'inactivate date'
set to the 1900, so unless you are retaining NOLIMIT, they'll dissapear next
expiration.  [ rustle through Oracle problem-trace logs ]  Here's an example.

These are from

 'select * from backups where node_name='WEBCT-DB' order by 
filespace_name,backup_date'



Before: [ query taken at 09:58 ]
WEBCT-DB/webct-db   1   ACTIVE_VERSION  FILE//  
df_WEBCT_4416_1_568435025   124553476   2005-09-08 02:42:02.00  
oracle  DEFAULT

After: [ query taken at 10:01 ]
WEBCT-DB/webct-db   1   INACTIVE_VERSIONFILE//  
df_WEBCT_4416_1_568435025   124553476   2005-09-08 02:42:02.00  
1900-01-01 00:00:00.00 oracle  DEFAULT


Is there something I'm missing about this?  Or is that just what happens in
the DB when the API issues a 'Delete this file' request?


> So if you are certain that Rman is deleting the objects from the
> controlfile, then my guess is that your TSM Node is not configured with
> "backdel=yes".

Second the motion.  We ran into this.


- Allen S. Rout

Re: expiration Oracle backups

[Allen S. Rout]

==> On Thu, 13 Oct 2005 15:19:53 +0200, Kurt Beyers <[EMAIL PROTECTED]> said:

> My environment is the following:

> TSM 5.3.2 server on Windows2003
> Sun Solaris 5.8 with Oracle 8.1.7.4 with a TSM BA client 5.3.x and the TDP 
> for databases 5.3

> [ ... ]

> But how are the backups made inactive in the TSM database after they have
> been deleted in Oracle? The 'tdposync' tool only works when the metadata is
> stored in a recovery catalog database. And after a forced deletion of the
> backups in RMAN, they do not become inactive in TSM either. How can the
> metadata in the TSM database be synchronized with the metadata in Oracle
> (control file) .


Oracle's delete-obsolete-backups function does not work.  We're chasing this
with Oracle Support right now, and they have confirmed that they have a bug.

Our solution is to periodically switch TSM nodes to which a given Oracle DB is
backing up, and once our recovery period has passed, we discard the old node.

We've lovingly documented the state before and after various operations, so if
you want help proving your case to Oracle, let me know.

Alternately, if you come up with a procedure that zaps stuff, do tell. :)

- Allen S. Rout

Re: expiration Oracle backups

[Kurt Beyers]

Neil,
 
Here is the output of 'list backups' and 'crosscheck backup of databases' for 
the ERK oracle instance:
 
# rman target rman/rman nocatalog
Recovery Manager: Release 8.1.7.4.0 - Production
RMAN-06005: connected to target database: ERK (DBID=39192858)
RMAN-06009: using target database controlfile instead of recovery catalog
RMAN> list backup;
RMAN-03022: compiling command: list
RMAN> allocate channel for delete type 'sbt_tape'
2> parms 'ENV=(TDPO_OPTFILE=/opt/tivoli/tsm/client/oracle/bin64/tdpo_erk.opt)';
RMAN-03022: compiling command: allocate
RMAN-03023: executing command: allocate
RMAN-08030: allocated channel: delete
RMAN-08500: channel delete: sid=12 devtype=SBT_TAPE
RMAN-08526: channel delete: Tivoli Data Protection for Oracle: version 5.2.0.0
RMAN> crosscheck backup of database;
RMAN-03022: compiling command: XCHECK
RMAN-03023: executing command: XCHECK
RMAN>
 
No backups are found any more. The TSM node name for the Oracle backup is 
server_ORA_ERK. Here is the output of two queries in TSM:
 
q node server_ORA_ERK f=d;
 Node Name: server_ORA_ERK
  Platform: TDP Oracle SUN
   Client OS Level: 5.8
Client Version: Version 5, Release 3, Level 0.11
Policy Domain Name: POL_client
 Last Access Date/Time: 10/13/2005 15:04:17
Days Since Last Access: <1
Password Set Date/Time: 10/12/2005 14:34:14
   Days Since Password Set: 1
 Invalid Sign-on Count: 0
   Locked?: No
   Contact:
   Compression: Client
   Archive Delete Allowed?: Yes
Backup Delete Allowed?: Yes
Registration Date/Time: 10/12/2005 11:42:20
 Registering Administrator: ADMIN
Last Communication Method Used: Tcp/Ip
   Bytes Received Last Session: 2,073
   Bytes Sent Last Session: 2,170
  Duration of Last Session: 4.00
   Pct. Idle Wait Last Session: 0.00
select state, ll_name, backup_date from backups where 
node_name='server_ORA_ERK';
 STATE LL_NAME   BACKUP_DATE
-- -- --
ACTIVE_VERSION df_571506337_1_1   2005-10-12
 15:44:32.00
ACTIVE_VERSION df_571506339_2_1   2005-10-12
 15:44:32.00
...
 
The node is allowed to delete it's own backups and all of the backups are still 
active. No errors are found in the tdpoerror.log file.
 
During the deletion of the backups in RMAN, new sessions are opened and closed 
in the activity log for the node but no other messages are logged.
 
Any other ideas about what might be the issue? If required, I'll log a PMR of 
course.
 
thanks,
Kurt



From: ADSM: Dist Stor Manager on behalf of Neil Rasmussen
Sent: Thu 13/10/2005 16:38
To: ADSM-L@VM.MARIST.EDU
Subject: Re: [ADSM-L] expiration Oracle backups



Kurt,

When deleting Rman objects on the TSM Server, TDP Oracle uses the delete
function on objectsthe objects do not move to inactive they are just
simply deleted from the TSM Server. So if you are certain that Rman is
deleting the objects from the controlfile, then my guess is that your TSM
Node is not configured with "backdel=yes". One simple way to know what is
going on during the deletion is to look in the tdpoerror.log this should
tell you if the objects are being deleted or if there is an error
occurring during the delete. Unfortunately, Oracle ignores errors that
come from the delete functions so any error that TDP Oracle gives during
deletion is lost, the only way to know for sure is the "tdpoerror.log"


Regards,

Neil Rasmussen
Software Development
Data Protection for Oracle
[EMAIL PROTECTED]




Kurt Beyers <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
10/13/2005 06:19 AM
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L@VM.MARIST.EDU
cc

Subject
expiration Oracle backups






Hello,

My environment is the following:

TSM 5.3.2 server on Windows2003
Sun Solaris 5.8 with Oracle 8.1.7.4 with a TSM BA client 5.3.x and the TDP
for databases 5.3

The backup of the Oracle databases is already working. The metadata of the
backups is written in the control files of the Oracle database.

The backups are bound to a mgmt class with the correct settings (as every
object receives a unique name in TSM).

The expiration must first be done in Oracle with a script, eg expire the
backups older than X days. Could anybody share a working script? I'm still
struggling to get it working as it should.

But how are the backups made inactive in the TSM database after they have
been deleted in Oracle? The 'tdposync' tool only works when the metadata
is stored in a recovery catalog database. And after a forced deletion of
the backups in RMAN, they do not become inactive in TSM either. How can
the metadata in the TSM database be synchronized

Re: expiration Oracle backups

[Neil Rasmussen]

Kurt,

When deleting Rman objects on the TSM Server, TDP Oracle uses the delete
function on objectsthe objects do not move to inactive they are just
simply deleted from the TSM Server. So if you are certain that Rman is
deleting the objects from the controlfile, then my guess is that your TSM
Node is not configured with "backdel=yes". One simple way to know what is
going on during the deletion is to look in the tdpoerror.log this should
tell you if the objects are being deleted or if there is an error
occurring during the delete. Unfortunately, Oracle ignores errors that
come from the delete functions so any error that TDP Oracle gives during
deletion is lost, the only way to know for sure is the "tdpoerror.log"


Regards,

Neil Rasmussen
Software Development
Data Protection for Oracle
[EMAIL PROTECTED]




Kurt Beyers <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
10/13/2005 06:19 AM
Please respond to
"ADSM: Dist Stor Manager"


To
ADSM-L@VM.MARIST.EDU
cc

Subject
expiration Oracle backups






Hello,

My environment is the following:

TSM 5.3.2 server on Windows2003
Sun Solaris 5.8 with Oracle 8.1.7.4 with a TSM BA client 5.3.x and the TDP
for databases 5.3

The backup of the Oracle databases is already working. The metadata of the
backups is written in the control files of the Oracle database.

The backups are bound to a mgmt class with the correct settings (as every
object receives a unique name in TSM).

The expiration must first be done in Oracle with a script, eg expire the
backups older than X days. Could anybody share a working script? I'm still
struggling to get it working as it should.

But how are the backups made inactive in the TSM database after they have
been deleted in Oracle? The 'tdposync' tool only works when the metadata
is stored in a recovery catalog database. And after a forced deletion of
the backups in RMAN, they do not become inactive in TSM either. How can
the metadata in the TSM database be synchronized with the metadata in
Oracle (control file) .

I know this must have been discussed in the past already, but a search of
the old threads didn't  clear it out yet.

thanks a lot,
Kurt

Re: Expiration / deletion of inactive files do not appear to be working for SQL-BACKTRACK

[David E Ehresman]

Then, since TSM see them all as still active, I'd guess that Backtrack is not 
expiring the files.

David

>>> [EMAIL PROTECTED] 05/20/05 11:05 AM >>>
Yes, SQL-BACKTRACK is responsible for updating the status of the
uniquely name file.

>>> [EMAIL PROTECTED] 05/20/2005 10:43:53 AM >>>
In TSM for Databases, each backup file has a unique name and rman is
responsible for "deleting" them, thus triggering the TSM expiration
cycle.  Does Backtrack work the same way?

>>> [EMAIL PROTECTED] 05/19/05 2:34 PM >>>
Hi:
We've just discovered q peculiar problem with expiration involing the
SQL-BACKTRACK product and SYBASE and ORACLE databases. They do not
appear to be expiring.

The managment class rules are:

DOMAIN_NAME CLASS_NAME  VEREXISTS   VERDELETED  RETEXTRA
RETONLY DESTINATION
SPAIX   DBBKUP1 60  0   30  0   AIXDISKBACK

And a "query backup /BACKTRACK:obackups.physical/*/* -inactive"
returns
a HUGE list of files that are inactive.
They should all have been deleted with the RETONLY set to 0.

Am I missing something?

A DB called SQL-BACKTRACK support and the responce was SQL-BACKTRACK
marked them inactive; at that point TSM
is not correctly removing them per the definitions.

Flat files in other management groups are behaving correctly.


API  5,242,880  B  10/15/03   02:54:53DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-10-2003.02:55:41-21544
API  5,242,880  B  11/15/03   02:59:13DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-11-2003.02:59:04-43356
API  5,242,880  B  12/15/02   02:55:59DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-12-2002.02:55:42-31662
API  5,242,880  B  12/15/03   02:50:43DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-12-2003.02:50:28-19182
API  5,242,880  B  01/16/03   03:03:22DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-01-2003.03:03:16-32618
API  5,242,880  B  01/16/04   02:57:23DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-01-2004.02:57:00-28874
API  5,242,880  B  02/16/03   02:48:22DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-02-2003.02:48:26-21274
API  5,242,880  B  02/16/04   02:48:41DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-02-2004.02:48:10-39458
API  5,242,880  B  03/16/03   02:50:47DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-03-2003.02:50:59-32472
API  5,242,880  B  03/16/04   02:54:33DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-03-2004.02:54:33-33320
API  5,242,880  B  04/16/03   03:04:45DBBKUP1 A
/BACKTRACK:obackups.phy

>>> [EMAIL PROTECTED] 05/10/2005 9:27:12 AM >>>
Mario,
   We've been using St. Bernard OFM 9 in conjuction with TSM 5.2.2
(client vers. of course) to backup both our GroupWise 6, and now
GroupWise 6.5 servers in the last year without problems. We've also
done
successful restores of the GroupWise servers.


>>> [EMAIL PROTECTED] 05/09/05 3:41 PM >>>

Hi list,

I need to perform an online backup of a Novell Groupwise environment
using
TSM ... does anybody knows how can I accomplish this ?

Thanks.

Mario



Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html

Re: Expiration / deletion of inactive files do not appear to be working for SQL-BACKTRACK

[Lawrence Clark]

Yes, SQL-BACKTRACK is responsible for updating the status of the
uniquely name file.

>>> [EMAIL PROTECTED] 05/20/2005 10:43:53 AM >>>
In TSM for Databases, each backup file has a unique name and rman is
responsible for "deleting" them, thus triggering the TSM expiration
cycle.  Does Backtrack work the same way?

>>> [EMAIL PROTECTED] 05/19/05 2:34 PM >>>
Hi:
We've just discovered q peculiar problem with expiration involing the
SQL-BACKTRACK product and SYBASE and ORACLE databases. They do not
appear to be expiring.

The managment class rules are:

DOMAIN_NAME CLASS_NAME  VEREXISTS   VERDELETED  RETEXTRA
RETONLY DESTINATION
SPAIX   DBBKUP1 60  0   30  0   AIXDISKBACK

And a "query backup /BACKTRACK:obackups.physical/*/* -inactive"
returns
a HUGE list of files that are inactive.
They should all have been deleted with the RETONLY set to 0.

Am I missing something?

A DB called SQL-BACKTRACK support and the responce was SQL-BACKTRACK
marked them inactive; at that point TSM
is not correctly removing them per the definitions.

Flat files in other management groups are behaving correctly.


API  5,242,880  B  10/15/03   02:54:53DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-10-2003.02:55:41-21544
API  5,242,880  B  11/15/03   02:59:13DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-11-2003.02:59:04-43356
API  5,242,880  B  12/15/02   02:55:59DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-12-2002.02:55:42-31662
API  5,242,880  B  12/15/03   02:50:43DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-12-2003.02:50:28-19182
API  5,242,880  B  01/16/03   03:03:22DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-01-2003.03:03:16-32618
API  5,242,880  B  01/16/04   02:57:23DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-01-2004.02:57:00-28874
API  5,242,880  B  02/16/03   02:48:22DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-02-2003.02:48:26-21274
API  5,242,880  B  02/16/04   02:48:41DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-02-2004.02:48:10-39458
API  5,242,880  B  03/16/03   02:50:47DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-03-2003.02:50:59-32472
API  5,242,880  B  03/16/04   02:54:33DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-03-2004.02:54:33-33320
API  5,242,880  B  04/16/03   03:04:45DBBKUP1 A
/BACKTRACK:obackups.phy

>>> [EMAIL PROTECTED] 05/10/2005 9:27:12 AM >>>
Mario,
   We've been using St. Bernard OFM 9 in conjuction with TSM 5.2.2
(client vers. of course) to backup both our GroupWise 6, and now
GroupWise 6.5 servers in the last year without problems. We've also
done
successful restores of the GroupWise servers.


>>> [EMAIL PROTECTED] 05/09/05 3:41 PM >>>

Hi list,

I need to perform an online backup of a Novell Groupwise environment
using
TSM ... does anybody knows how can I accomplish this ?

Thanks.

Mario



Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html

Re: Expiration / deletion of inactive files do not appear to be working for SQL-BACKTRACK

[David E Ehresman]

In TSM for Databases, each backup file has a unique name and rman is 
responsible for "deleting" them, thus triggering the TSM expiration cycle.  
Does Backtrack work the same way?

>>> [EMAIL PROTECTED] 05/19/05 2:34 PM >>>
Hi:
We've just discovered q peculiar problem with expiration involing the
SQL-BACKTRACK product and SYBASE and ORACLE databases. They do not
appear to be expiring.

The managment class rules are:

DOMAIN_NAME CLASS_NAME  VEREXISTS   VERDELETED  RETEXTRA
RETONLY DESTINATION
SPAIX   DBBKUP1 60  0   30  0   AIXDISKBACK

And a "query backup /BACKTRACK:obackups.physical/*/* -inactive" returns
a HUGE list of files that are inactive.
They should all have been deleted with the RETONLY set to 0.

Am I missing something?

A DB called SQL-BACKTRACK support and the responce was SQL-BACKTRACK
marked them inactive; at that point TSM
is not correctly removing them per the definitions.

Flat files in other management groups are behaving correctly.


API  5,242,880  B  10/15/03   02:54:53DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-10-2003.02:55:41-21544
API  5,242,880  B  11/15/03   02:59:13DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-11-2003.02:59:04-43356
API  5,242,880  B  12/15/02   02:55:59DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-12-2002.02:55:42-31662
API  5,242,880  B  12/15/03   02:50:43DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.15-12-2003.02:50:28-19182
API  5,242,880  B  01/16/03   03:03:22DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-01-2003.03:03:16-32618
API  5,242,880  B  01/16/04   02:57:23DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-01-2004.02:57:00-28874
API  5,242,880  B  02/16/03   02:48:22DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-02-2003.02:48:26-21274
API  5,242,880  B  02/16/04   02:48:41DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-02-2004.02:48:10-39458
API  5,242,880  B  03/16/03   02:50:47DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-03-2003.02:50:59-32472
API  5,242,880  B  03/16/04   02:54:33DBBKUP1 A
/BACKTRACK:obackups.phy
sical/BRSSBKUP/controlfiles-0.16-03-2004.02:54:33-33320
API  5,242,880  B  04/16/03   03:04:45DBBKUP1 A
/BACKTRACK:obackups.phy

>>> [EMAIL PROTECTED] 05/10/2005 9:27:12 AM >>>
Mario,
   We've been using St. Bernard OFM 9 in conjuction with TSM 5.2.2
(client vers. of course) to backup both our GroupWise 6, and now
GroupWise 6.5 servers in the last year without problems. We've also done
successful restores of the GroupWise servers.


>>> [EMAIL PROTECTED] 05/09/05 3:41 PM >>>

Hi list,

I need to perform an online backup of a Novell Groupwise environment
using
TSM ... does anybody knows how can I accomplish this ?

Thanks.

Mario



Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html

Re: Expiration / deletion of inactive files do not appear to be working for SQL-BACKTRACK

[Thomas Denier]

> Hi:
> We've just discovered q peculiar problem with expiration involing the
> SQL-BACKTRACK product and SYBASE and ORACLE databases. They do not
> appear to be expiring.
>
> The managment class rules are:
>
> DOMAIN_NAME CLASS_NAME VEREXISTS VERDELETED RETEXTRA RETONLY DESTINATION
> SPAIX DBBKUP1 60 0 30 0 AIXDISKBACK
>
> And a "query backup /BACKTRACK:obackups.physical/*/* -inactive" returns
> a HUGE list of files that are inactive.
> They should all have been deleted with the RETONLY set to 0.
>
> Am I missing something?

The -inactive option causes the query to list inactive files as well as
active files, not inactive files instead of active files. In the query
output line below, the 'A' after 'DBBKUP1' indicates that the file is
active. The rest of the query output lines in your original message
also showed active files. It is not clear that you have any inactive
backups of Oracle and Sybase data.

When our site had problems with SQL/BackTrack (we has since switched to
TDP), the most frequent cause was forgetting to specify 'backdelete=yes'
when registering nodes.

> A DB called SQL-BACKTRACK support and the responce was SQL-BACKTRACK
> marked them inactive; at that point TSM
> is not correctly removing them per the definitions.
>
> Flat files in other management groups are behaving correctly.
>
>
> API  5,242,880  B  10/15/03   02:54:53DBBKUP1 A
> /BACKTRACK:obackups.phy
> sical/BRSSBKUP/controlfiles-0.15-10-2003.02:55:41-21544

Re: Re Expiration of Files and Directories

[Richard Sims]

Don't try to use one tool for all purposes. Where the need is to pick
and choose certain files to keep for certain lengths of time, the
better tool to use is Archive rather than Backup. This gets you where
you want to be and eliminates policy disparities between files and
directories. I would not try to twist Backup to achieve that objective.
  Richard Sims
On Apr 20, 2005, at 11:07 AM, Farren Minns wrote:
OK, thanks for that, and I can understand that there is a need for a
dir to
be required for files that are to be contained within it, but I have
another problem with this.
Let's say I want create the new management class that I want to use to
keep
just a certain directories files for a certain length of time ( and
also
that the retain only setting will be higher than the standard mc we are
currently using ). Now, what I don't like here is that fact that the
retain
only setting is then applied to all dirs on the client being backed
up. Why
does this not just get applied to the directory (and sub dirs), in
question, and is there a way to stop this from happening?

Re Expiration of Files and Directories

[Farren Minns]

OK, thanks for that, and I can understand that there is a need for a dir to
be required for files that are to be contained within it, but I have
another problem with this.
Let's say I want create the new management class that I want to use to keep
just a certain directories files for a certain length of time ( and also
that the retain only setting will be higher than the standard mc we are
currently using ). Now, what I don't like here is that fact that the retain
only setting is then applied to all dirs on the client being backed up. Why
does this not just get applied to the directory (and sub dirs), in
question, and is there a way to stop this from happening?

Many thanks again

Farren Minns
Solaris System Admin / Oracle DBA
IT - Hosting Services

John Wiley & Sons, Ltd.




Direcories may expire, but files never end up in "limbo". Examine the
BACKUPS table: each object is fully identified by filespace and its
full path, which obviously includes its containing directory. Backing
up a directory, as an object, is usually rather meaningless in a Unix
environment as such directories have no supplementary info. In a
Windows environment, there is a lot of supplementary info, which is why
Windows directories end up in storage pools while traditional Unix
directories are simply identified in the TSM database.

In a restoral, surrogate replacement directory info is planted where
either the dir is not in the TSM db, or has not yet been encountered in
Restore Order. The absence of a directory in TSM is problematic in GUI
restorals, where the GUI wants to present each dir as you navigate down
the path tree: this can cause the GUI to go no further. TSM wants
directories to exist at least as long as contained objects, for a
reason.

   Richard Sims

On Apr 20, 2005, at 9:56 AM, Farren Minns wrote:

> Hi all TSMers
>
> Running TSM 5.1.6.2 on Solaris and have a question regarding the
> different
> way that directories and files are dealt with. I have always been used
> to
> excluding files, directories, file spaces etc and also including them
> with
> different management classes should the need arise for something other
> than
> our standard retention settings. However, I have only just learnt
> about the
> dirmc setting and this has lead me to believe that we probably a few
> million entries in our TSM db for directories that are no longer
> relevant (
> the deleted files having been expired after 60 days but the directories
> having been bound to one of our higher retention man classes ). So
> here is
> my question.
>
> Lets say I have a retention policy on a dir that states that the only
> copy
> of a file (after deletion), should be kept in backup for 365 days but
> that
> I have a dirmc setting in the clients dsm.sys files that will expire
> all
> deleted directories after just 60 days, how does TSM handle this? What
> happens re expiration after 60 days? Do the directories get expired
> and the
> files just end up in some kind of limbo?
>
> Many thanks in advance


##
The information contained in this e-mail and any subsequent 
correspondence is private and confidential and intended solely 
for the named recipient(s).  If you are not a named recipient, 
you must not copy, distribute, or disseminate the information, 
open any attachment, or take any action in reliance on it.  If you 
have received the e-mail in error, please notify the sender and delete
the e-mail.  

Any views or opinions expressed in this e-mail are those of the 
individual sender, unless otherwise stated.  Although this e-mail has 
been scanned for viruses you should rely on your own virus check, as 
the sender accepts no liability for any damage arising out of any bug 
or virus infection.
##

Re: Re Expiration of Files and Directories

[Richard Sims]

Direcories may expire, but files never end up in "limbo". Examine the
BACKUPS table: each object is fully identified by filespace and its
full path, which obviously includes its containing directory. Backing
up a directory, as an object, is usually rather meaningless in a Unix
environment as such directories have no supplementary info. In a
Windows environment, there is a lot of supplementary info, which is why
Windows directories end up in storage pools while traditional Unix
directories are simply identified in the TSM database.
In a restoral, surrogate replacement directory info is planted where
either the dir is not in the TSM db, or has not yet been encountered in
Restore Order. The absence of a directory in TSM is problematic in GUI
restorals, where the GUI wants to present each dir as you navigate down
the path tree: this can cause the GUI to go no further. TSM wants
directories to exist at least as long as contained objects, for a
reason.
   Richard Sims
On Apr 20, 2005, at 9:56 AM, Farren Minns wrote:
Hi all TSMers
Running TSM 5.1.6.2 on Solaris and have a question regarding the
different
way that directories and files are dealt with. I have always been used
to
excluding files, directories, file spaces etc and also including them
with
different management classes should the need arise for something other
than
our standard retention settings. However, I have only just learnt
about the
dirmc setting and this has lead me to believe that we probably a few
million entries in our TSM db for directories that are no longer
relevant (
the deleted files having been expired after 60 days but the directories
having been bound to one of our higher retention man classes ). So
here is
my question.
Lets say I have a retention policy on a dir that states that the only
copy
of a file (after deletion), should be kept in backup for 365 days but
that
I have a dirmc setting in the clients dsm.sys files that will expire
all
deleted directories after just 60 days, how does TSM handle this? What
happens re expiration after 60 days? Do the directories get expired
and the
files just end up in some kind of limbo?
Many thanks in advance

Re Expiration of Files and Directories

[Farren Minns]

Hi all TSMers

Running TSM 5.1.6.2 on Solaris and have a question regarding the different
way that directories and files are dealt with. I have always been used to
excluding files, directories, file spaces etc and also including them with
different management classes should the need arise for something other than
our standard retention settings. However, I have only just learnt about the
dirmc setting and this has lead me to believe that we probably a few
million entries in our TSM db for directories that are no longer relevant (
the deleted files having been expired after 60 days but the directories
having been bound to one of our higher retention man classes ). So here is
my question.

Lets say I have a retention policy on a dir that states that the only copy
of a file (after deletion), should be kept in backup for 365 days but that
I have a dirmc setting in the clients dsm.sys files that will expire all
deleted directories after just 60 days, how does TSM handle this? What
happens re expiration after 60 days? Do the directories get expired and the
files just end up in some kind of limbo?

Many thanks in advance

Farren Minns
Solaris System Admin / Oracle DBA
IT - Hosting Services

John Wiley & Sons, Ltd


##
The information contained in this e-mail and any subsequent
correspondence is private and confidential and intended solely
for the named recipient(s).  If you are not a named recipient,
you must not copy, distribute, or disseminate the information,
open any attachment, or take any action in reliance on it.  If you
have received the e-mail in error, please notify the sender and delete
the e-mail.

Any views or opinions expressed in this e-mail are those of the
individual sender, unless otherwise stated.  Although this e-mail has
been scanned for viruses you should rely on your own virus check, as
the sender accepts no liability for any damage arising out of any bug
or virus infection.
##

Re: Expiration

[Stapleton, Mark]

From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On 
Behalf Of Rob Hefty
>When this process completes, there is a listing of objects examined and
>deleted outputted to the activity log.  What is the objects a reference
>to; is it filespaces, files, directories...etc?
>
>
>03/31/2005 02:26:38  ANR0984I Process 31 for EXPIRE INVENTORY
>started in the BACKGROUND at 02:26:38. (SESSION: 1677, PROCESS: 31)

>03/31/2005 02:26:38  ANR0811I Inventory client file expiration
>started as process 31. (SESSION: 1677, PROCESS: 31)
>03/31/2005 03:03:35  ANR0812I Inventory file expiration process 31
>completed: examined 1200811 objects, deleting 214852 backup objects,
>0 archive objects, 0 DB backup volumes, and 0 recovery plan files. 
>0 errors were encountered. (SESSION: 1677, PROCESS: 31)

Yes. ;o)

The references are to pointers that have been deleted from the TSM
database; those pointers relate to all objects that have to do with
backups, archives, and other miscellaneous items that require expiration
due to management class settings and other parameters.

--
Mark Stapleton ([EMAIL PROTECTED])
IBM Certified Advanced Deployment Professional
Tivoli Storage Management Solutions 2005
Office 262.521.5627  

Re: Expiration Fails

[Richard Sims]

Given that you're running a "museum" level of the product, you can't
contact IBM for help on this. I would begin by studying the Activity
Log around the time the problem started to get perspective on what
caused it - particularly if there was a server crash, and possibly the
loss of a db mirror. You're still not telling us the full level of your
server: there is a 3.1.2.90 level you might apply, if not already
there, which may mitigate future problems within ADSM 3.1, but I would
not expect it to correct the current, unless Activity Log research
suggests otherwise. Whereas this problem is occurring in Expiration as
well as Migration, it's unlikely that there's a simple external cause,
such as a corrupted device driver.
Beyond that, you're stuck with either performing an AUDITDB and hope
for the best, or restore to before the problem. Either way, be sure to
have a full db backup before you shut down.
   Richard Sims
On Feb 22, 2005, at 8:31 AM, Thando Ndaba wrote:
I `im running adsm 3.1 for sun solaris 2.6
This started happening since monday morning.
When this expiration runs, nothing alse is happening on the server.
...

Re: Expiration Fails

[Thando Ndaba]

I `im running adsm 3.1 for sun solaris 2.6 
This started happening since monday morning. 
When this expiration runs, nothing alse is happening on the server.

I have also noticed that ever since this problem, I cannot migrate my disk pool 
to tape
and yet 
the disk volumes are all online 
the access=readw
but I get:
ANR1000I Migration process 74 started for storage pool
  ORA-DISK-NEW.
02/21/05   04:13:05  ANR1032W Migration process 72 terminated for storage 
pool
  ORA-DISK-NEW - internal server error detected.
02/21/05   04:13:41  ANR1002I Migration for storage pool ORA-DISK-NEW will 
be
  retried in 60 seconds.
 
Please note I`m new to TSM. So I`m getting used to reporting problems.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Richard Sims
Sent: Tuesday, February 22, 2005 3:21 PM
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration Fails


First and foremost: When posting such server problems, include your TSM
server level information, e.g. "5.1.7.3". This will allow everyone to
ascertain whether this is an old problem, resolved by some maintenance,
or something new.

Now, does this occur at every expiration? Is any other server process
running at the time?

Do not be tempted to run an AUDITDB without contacting IBM about the
problem, and having them advise on a course of action: you could end up
in worse trouble if you just plow ahead.

 Richard Sims

On Feb 22, 2005, at 8:06 AM, Thando Ndaba wrote:

> I`m getting the following errors when my expi inv runs. Can anyone
> help?
>
> 02/22/05   06:00:10  ANRD imexp.c(4030): Object 0.97915738
> could not be
>   deleted - expiration will continue.
> ...

Re: Expiration Fails

[Richard Sims]

First and foremost: When posting such server problems, include your TSM
server level information, e.g. "5.1.7.3". This will allow everyone to
ascertain whether this is an old problem, resolved by some maintenance,
or something new.
Now, does this occur at every expiration? Is any other server process
running at the time?
Do not be tempted to run an AUDITDB without contacting IBM about the
problem, and having them advise on a course of action: you could end up
in worse trouble if you just plow ahead.
Richard Sims
On Feb 22, 2005, at 8:06 AM, Thando Ndaba wrote:
I`m getting the following errors when my expi inv runs. Can anyone
help?
02/22/05   06:00:10  ANRD imexp.c(4030): Object 0.97915738
could not be
  deleted - expiration will continue.
...

Re: Expiration Fails

[Oscar Kolsteren]

Hi Thando,

I would run an AUDIT DB, maybe this will solve your problem

Regards,

O. Kolsteren

Met vriendelijke groet,


Oscar Kolsteren
Senior beheer RS6000 / TSM

ING Nederland/OPS&IT/OM/Support/SSP/Team5 
Locatiecode PA 06.17
Haarlemmerweg 506-520, 1014 BL Amsterdam 
(   +31 20 584 5966 / 06 55812968
Fax  +31 20 584 5869
*   [EMAIL PROTECTED]
:-)  Out of office: vrijdag na 11:00 uur



-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Thando 
Ndaba
Sent: dinsdag 22 februari 2005 14:07
To: ADSM-L@VM.MARIST.EDU
Subject: Expiration Fails


Hi TSMers 
 
I`m getting the following errors when my expi inv runs. Can anyone help?
 
 
 

02/22/05   06:00:10  ANRD imexp.c(4030): Object 0.97915738 could not be
  deleted - expiration will continue.
02/22/05   06:00:10  ANRD imexp.c(4030): Object 0.97915739 could not be
  deleted - expiration will continue.
02/22/05   06:00:10  ANRD imexp.c(4030): Object 0.97943353 could not be
  deleted - expiration will continue.
02/22/05   06:01:54  ANRD imexp.c(4030): Object 0.97949781 could not be
  deleted - expiration will continue.
02/22/05   06:03:27  ANRD imexp.c(4030): Object 0.97949782 could not be
  deleted - expiration will continue.
02/22/05   06:04:57  ANRD imexp.c(4030): Object 0.97949783 could not be
  deleted - expiration will continue.
02/22/05   06:06:25  ANRD imexp.c(4030): Object 0.97949784 could not be
  deleted - expiration will continue.
02/22/05   06:07:52  ANRD imexp.c(4030): Object 0.97949785 could not be
  deleted - expiration will continue.
02/22/05   06:09:18  ANRD imexp.c(4030): Object 0.97949786 could not be
  deleted - expiration will continue.
02/22/05   06:10:44  ANRD imexp.c(4030): Object 0.97949787 could not be
  deleted - expiration will continue.
02/22/05   06:12:10  ANRD imexp.c(4030): Object 0.97949788 could not be
  deleted - expiration will continue.
more...   ( to continue, 'C' to cancel)

 
 
Regards
Thando Ndaba
Hosts Infrastracture 
É: +27(0)12 3399626 
*: +27(0)83 3992117 
*: +27(0)12 325 6351 
*:[EMAIL PROTECTED] 

 

 


-
ATTENTION:
The information in this electronic mail message is private and
confidential, and only intended for the addressee. Should you
receive this message by mistake, you are hereby notified that
any disclosure, reproduction, distribution or use of this
message is strictly prohibited. Please inform the sender by
reply transmission and delete the message without copying or
opening it.

Messages and attachments are scanned for all viruses known.
If this message contains password-protected attachments, the
files have NOT been scanned for viruses by the ING mail domain.
Always scan attachments before opening them.
-

Re: Expiration/inactive node

[Lambelet,Rene,VEVEY,GLOBE Center CSC]

Hi,

you could also export this node to tape, and use relative timing if import 
needed for the audit

René LAMBELET
NESTEC  SA
GLOBE - Global Business Excellence
GC-Central Support Center
SD-IT
Av. Nestlé 55  CH-1800 Vevey (Switzerland) 
tél +41 (0)21 924'35'43  fax +41 (0)21 703'30'17  local BUS-10 
119
mailto:[EMAIL PROTECTED]

>   This e-mail message is confidential and for the use of the intended 
> recipient(s) only. 
>   Unauthorized use or treatment of all or part of this message is 
> strictly prohibited. 
>   Unintended recipients: please notify the sender and delete the original 
> message, 
>   any attachments and any copies from your computer and back-up system 
> immediately. 
>   Thank you.


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Bob Booth - CITES
Sent: Saturday,19. February 2005 19:38
To: ADSM-L@VM.MARIST.EDU
Subject: Re: Expiration/inactive node


On Sat, Feb 19, 2005 at 10:26:33AM -0800, Sam Sheppard wrote:
> Due to a legal investigation, I have been asked to 'freeze' the backups
> on one of my client machines.  We removed the client from the schedule
> and changed the NODENAME parm in the dsm.opt file to specify a new
> name.
>
> My question regards expiration processing for the 'frozen' node.  My
> understanding is that, as long as the client doesn't connect to the TSM
> server, no expiration will take place.  Is this indeed the case or is
> there still some expiration of files on this system that will take
> place during expire inventory processing?  Will a subsequent backup be
> the only way to trigger expiration?

Expiration will still 'delete' inactive items based on the policy domain
mgmtclass (copy group) settings.  If you truly need to freeze all activity
for this node, including not removing files/directories that have been
marked inactive, you may have to create a new domain with unlimited
retention for all copies inactive.

It is true however, that if another backup isn't performed, the files that
are now marked as active, will stay that way, until the administrator
deletes them with a delete filespace command.

hth,

bob

Re: Expiration/inactive node

[Bob Booth - CITES]

On Sat, Feb 19, 2005 at 10:26:33AM -0800, Sam Sheppard wrote:
> Due to a legal investigation, I have been asked to 'freeze' the backups
> on one of my client machines.  We removed the client from the schedule
> and changed the NODENAME parm in the dsm.opt file to specify a new
> name.
>
> My question regards expiration processing for the 'frozen' node.  My
> understanding is that, as long as the client doesn't connect to the TSM
> server, no expiration will take place.  Is this indeed the case or is
> there still some expiration of files on this system that will take
> place during expire inventory processing?  Will a subsequent backup be
> the only way to trigger expiration?

Expiration will still 'delete' inactive items based on the policy domain
mgmtclass (copy group) settings.  If you truly need to freeze all activity
for this node, including not removing files/directories that have been
marked inactive, you may have to create a new domain with unlimited
retention for all copies inactive.

It is true however, that if another backup isn't performed, the files that
are now marked as active, will stay that way, until the administrator
deletes them with a delete filespace command.

hth,

bob

Re: Expiration

[Andrew Raibeck]

Two possible APARs: IC36396, IC34933.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED]
Internet e-mail: [EMAIL PROTECTED]

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager"  wrote on 02/01/2005
05:04:01:

> Good Morning.
> I have a question about expiration.
> I have a 90 day policy for data on the servers(Versions Data Exists
> - Nolimit, Version Data Deleted - Nolimit, retain Extra Versions 90
> and Retain Only Version 90).  My question is how can I tell if data
> is being expired and how many files on a particular machine?  What I
> checked is a machine that is backing up everynight with about 2000
> files(SYSETM OBJECT) but the file count keeps growing.  It's been 95
> days since the 1st backup so I would have thought the file count
> would be leveling off.  I see when expiration runs that the server
> is listed for each of it's filespaces but I have no idea how many
> files if any it expired.
> The TSM servers is AIX 5.2 with TSM 5.2.2 and the client is Win2K
> with TSM 5.2.2
> I want to make sure that the old files are expiring so we do not
> keep growing in size.  It's one of many machines so the final count
> for how many files expired in expiration does not tell me which
> machine it came from.
>
> Have a Great Day,
> Eric

Re: Expiration

[Hart, Charles]

We had a similar situation, for us the WIn SysObjs were killing us.  Being that 
the Win SysObj change on almost a daily basis and there's quite a few per Win 
Server, we created a Mngt class just for Windows sysobj and put a specific 
retention of 10 Versions.  We also do a Server side Client Opt file so we were 
able to force the following incexl option to all the windows boxes using the 
new mngt class.  We saw a 50% reduction in the TSM DB and significant reduction 
in the expiration process.

 Option: INCLEXCL
Sequence number: 2
   Override: Yes
   Option Value: INCLUDE.SYSTEMOBJECT ALL SYSTEM_OBJECTS




-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Behalf Of
Jones, Eric J
Sent: Tuesday, February 01, 2005 6:04 AM
To: ADSM-L@VM.MARIST.EDU
Subject: Expiration


Good Morning.
I have a question about expiration.
I have a 90 day policy for data on the servers(Versions Data Exists - Nolimit, 
Version Data Deleted - Nolimit, retain Extra Versions 90 and Retain Only 
Version 90).  My question is how can I tell if data is being expired and how 
many files on a particular machine?  What I checked is a machine that is 
backing up everynight with about 2000 files(SYSETM OBJECT) but the file count 
keeps growing.  It's been 95 days since the 1st backup so I would have thought 
the file count would be leveling off.  I see when expiration runs that the 
server is listed for each of it's filespaces but I have no idea how many files 
if any it expired.
The TSM servers is AIX 5.2 with TSM 5.2.2 and the client is Win2K with TSM 5.2.2
I want to make sure that the old files are expiring so we do not keep growing 
in size.  It's one of many machines so the final count for how many files 
expired in expiration does not tell me which machine it came from.

Have a Great Day,
Eric

Re: Expiration

[John Naylor]

Eric,
Run  Q OCC to a file before and after expiration
John



"Jones, Eric J" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" 
01/02/2005 12:04
Please respond to
"ADSM: Dist Stor Manager" 


To
ADSM-L@vm.marist.edu
cc

Subject
Expiration






Good Morning.
I have a question about expiration.
I have a 90 day policy for data on the servers(Versions Data Exists -
Nolimit, Version Data Deleted - Nolimit, retain Extra Versions 90 and
Retain Only Version 90).  My question is how can I tell if data is being
expired and how many files on a particular machine?  What I checked is a
machine that is backing up everynight with about 2000 files(SYSETM OBJECT)
but the file count keeps growing.  It's been 95 days since the 1st backup
so I would have thought the file count would be leveling off.  I see when
expiration runs that the server is listed for each of it's filespaces but
I have no idea how many files if any it expired.
The TSM servers is AIX 5.2 with TSM 5.2.2 and the client is Win2K with TSM
5.2.2
I want to make sure that the old files are expiring so we do not keep
growing in size.  It's one of many machines so the final count for how
many files expired in expiration does not tell me which machine it came
from.

Have a Great Day,
Eric



**
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern
Energy Group.
It is intended solely for the addressees. Access to this E-Mail by
anyone else is unauthorised. If you are not the intended recipient,
any disclosure, copying, distribution or any action taken or omitted
to be taken in reliance on it, is prohibited and may be unlawful.
Any unauthorised recipient should advise the sender immediately of
the error in transmission. Unless specifically stated otherwise, this email (or 
any attachments to it) is not an offer capable of acceptance or acceptance of 
an offer and it does not form part of a binding contractual agreement.


Scottish Hydro-Electric, Southern Electric, SWALEC and S+S
are trading names of the Scottish and Southern Energy Group.
**

Re: Expiration performance

[Dave Canan]

We have seen this type of behavior on performance PMRs. Often, a
DB will backup within the select command backup guidelines, but expiration
objects examined per hour will be slow. There also is a correlation between
the amount of fragmentation and the expiration time. In some cases, we have
seen that a DB that is fragmented by 50% goes through expiration up to 5
times faster after being de-fragmented.
And yet, I am hesitant to recommend that everyone rush right out
and do an unload/reload of the DB. Why? First, because of the time involved
(and the downtime!). Second, it appears that it is always a short-term
benefit. Databases, by their very nature, are fragmented. Third, I have
always wondered if this can actually hurt you performance wise. If a
database is de-fragmented, it will probably end up on fewer TSM database
volumes, and this could actually make performance worse in the short term
until it gets fragmented.
I am certainly open to discussion on this one. In general, the ATS
performance team has found that if expire inventory runs well, than most
TSM "things" (DB backup, reclamation, backups in general, etc) run well.
At 08:32 AM 9/13/2004 -0600, you wrote:
Hmm...
So from the responses posted so far, it looks like those folks
with smaller databases (there are a couple posts from folks with ~3GB of
utilized DB space) are the only ones who seem to be getting the mythical
>5M objects/hour on expirations.
Those of us with larger DBs seem to be getting only in the <1M
objects/hour range. Now that I see the other posts, I guess I don't feel
like such an under-achiever anymore ;-)
__
Here's the stats from one of my servers:
IBM P-series M80
8CPUs, 6GB RAM.
AIX 5.2 ML1
TSM Server version 5.2.1.3
TSM DB - ~35GB on SSA D40 drawers w/fastwrite cache turned on. JBOD
configuration.
ACTIVITY DatePages backed Up/Hr
-- -- -
FULL_DBBACKUP  2004-09-02  17272800
FULL_DBBACKUP  2004-09-03  18475200
FULL_DBBACKUP  2004-09-04  18666000
FULL_DBBACKUP  2004-09-05  18961200
FULL_DBBACKUP  2004-09-06  18442800
FULL_DBBACKUP  2004-09-07  18640800
FULL_DBBACKUP  2004-09-08  18608400
FULL_DBBACKUP  2004-09-09  18597600
FULL_DBBACKUP  2004-09-10  18885600
---
ACTIVITY DateObjects Examined Up/Hr
-- -- -
EXPIRATION 2004-09-02964800
EXPIRATION 2004-09-0327
EXPIRATION 2004-09-04306000
EXPIRATION 2004-09-05291600
EXPIRATION 2004-09-06248400
EXPIRATION 2004-09-07302400
EXPIRATION 2004-09-08288000
EXPIRATION 2004-09-09594000
EXPIRATION 2004-09-10306000
FWIW, it seems like over the last few years, every time I
upgrade the TSM server to the next version (TSM 4.1 -> 5.1 -> 5.2) I've
noticed a slowdown in the speed of the expiration process.
Ben
-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Mueller, Ken
Sent: Monday, September 13, 2004 7:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Expiration performance
Our TSM setup is not nearly as large as most of yours, but for what it's
worth, here are our values for the past month:
FULL_DBBACKUP  2004-08-14   6537600
FULL_DBBACKUP  2004-08-15   6051600
FULL_DBBACKUP  2004-08-16   6303600
FULL_DBBACKUP  2004-08-17   5511600
FULL_DBBACKUP  2004-08-17  12970800
FULL_DBBACKUP  2004-08-18   6739200
FULL_DBBACKUP  2004-08-19   7081200
FULL_DBBACKUP  2004-08-20   7657200
FULL_DBBACKUP  2004-08-21   7927200
FULL_DBBACKUP  2004-08-22   7945200
FULL_DBBACKUP  2004-08-23   5875200
FULL_DBBACKUP  2004-08-24   6343200
FULL_DBBACKUP  2004-08-25  

Re: Expiration performance

[Ben Bullock]

Hmm...

So from the responses posted so far, it looks like those folks
with smaller databases (there are a couple posts from folks with ~3GB of
utilized DB space) are the only ones who seem to be getting the mythical
>5M objects/hour on expirations.

Those of us with larger DBs seem to be getting only in the <1M
objects/hour range. Now that I see the other posts, I guess I don't feel
like such an under-achiever anymore ;-)


__
Here's the stats from one of my servers:
IBM P-series M80
8CPUs, 6GB RAM.
AIX 5.2 ML1
TSM Server version 5.2.1.3
TSM DB - ~35GB on SSA D40 drawers w/fastwrite cache turned on. JBOD
configuration.

ACTIVITY DatePages backed Up/Hr
-- -- -
FULL_DBBACKUP  2004-09-02  17272800
FULL_DBBACKUP  2004-09-03  18475200
FULL_DBBACKUP  2004-09-04  18666000
FULL_DBBACKUP  2004-09-05  18961200
FULL_DBBACKUP  2004-09-06  18442800
FULL_DBBACKUP  2004-09-07  18640800
FULL_DBBACKUP  2004-09-08  18608400
FULL_DBBACKUP  2004-09-09  18597600
FULL_DBBACKUP  2004-09-10  18885600
---
ACTIVITY DateObjects Examined Up/Hr
-- -- -
EXPIRATION 2004-09-02964800
EXPIRATION 2004-09-0327
EXPIRATION 2004-09-04306000
EXPIRATION 2004-09-05291600
EXPIRATION 2004-09-06248400
EXPIRATION 2004-09-07302400
EXPIRATION 2004-09-08288000
EXPIRATION 2004-09-09594000
EXPIRATION 2004-09-10306000

FWIW, it seems like over the last few years, every time I
upgrade the TSM server to the next version (TSM 4.1 -> 5.1 -> 5.2) I've
noticed a slowdown in the speed of the expiration process. 

Ben


-Original Message-
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of
Mueller, Ken
Sent: Monday, September 13, 2004 7:48 AM
To: [EMAIL PROTECTED]
Subject: Re: Expiration performance


Our TSM setup is not nearly as large as most of yours, but for what it's
worth, here are our values for the past month:

FULL_DBBACKUP  2004-08-14   6537600
FULL_DBBACKUP  2004-08-15   6051600
FULL_DBBACKUP  2004-08-16   6303600
FULL_DBBACKUP  2004-08-17   5511600
FULL_DBBACKUP  2004-08-17  12970800
FULL_DBBACKUP  2004-08-18   6739200
FULL_DBBACKUP  2004-08-19   7081200
FULL_DBBACKUP  2004-08-20   7657200
FULL_DBBACKUP  2004-08-21   7927200
FULL_DBBACKUP  2004-08-22   7945200
FULL_DBBACKUP  2004-08-23   5875200
FULL_DBBACKUP  2004-08-24   6343200
FULL_DBBACKUP  2004-08-25   7992000
FULL_DBBACKUP  2004-08-26   5904000
FULL_DBBACKUP  2004-08-27   8514000
FULL_DBBACKUP  2004-08-28   7419600
FULL_DBBACKUP  2004-08-29   5922000
FULL_DBBACKUP  2004-08-30   6379200
FULL_DBBACKUP  2004-08-31   7578000
FULL_DBBACKUP  2004-09-01   8089200
FULL_DBBACKUP  2004-09-02   7473600
FULL_DBBACKUP  2004-09-03   5533200
FULL_DBBACKUP  2004-09-04   5644800
FULL_DBBACKUP  2004-09-05   8298000
FULL_DBBACKUP  2004-09-06   6627600
FULL_DBBACKUP  2004-09-07   6937200
FULL_DBBACKUP  2004-09-08   6778800
FULL_DBBACKUP  2004-09-09   8236800
FULL_DBBACKUP  2004-09-10   8859600
FULL_DBBACKUP  2004-09-11   8974800
F

Re: Expiration performance

[Mueller, Ken]

ler
Magna Carta Companies


-Original Message-
From: Christo Heuer [mailto:[EMAIL PROTECTED]
Sent: Monday, September 13, 2004 3:13 AM
To: [EMAIL PROTECTED]
Subject: Re: Expiration performance


Hi Ben,

I agree with you on these points - ran Dave's script on our main TSM server
- and the Database backup performance is exceptionally good - the slowest
I'm seeing is  3100:
FULL_DBBACKUP  2004-09-03  62625600
FULL_DBBACKUP  2004-09-04  56156400
FULL_DBBACKUP  2004-09-05  59911200
FULL_DBBACKUP  2004-09-06  51152400
FULL_DBBACKUP  2004-09-07  57801600
FULL_DBBACKUP  2004-09-08  60886800
FULL_DBBACKUP  2004-09-09  52707600
FULL_DBBACKUP  2004-09-10  59018400
FULL_DBBACKUP  2004-09-11  57938400
FULL_DBBACKUP  2004-09-12  58968000

The average seems to be in the region of 5000 +, so from that point of
view it seems excellent - but the expiration sucks according to the script.

ACTIVITY DateObjects Examined Up/Hr
-- -- -
EXPIRATION 2004-08-14856800
EXPIRATION 2004-08-14867600
EXPIRATION 2004-08-15864000
EXPIRATION 2004-08-17770400
EXPIRATION 2004-08-18669600
EXPIRATION 2004-08-19846000
EXPIRATION 2004-08-20734400

So, yes, it seems that Ymmv, but is there anyone out there getting good
performance from expiration? If there are people out there, don't you want
to share your environment with us - might be able to collectively cast some
light on the lower expiration figures.

For the record, my environment is as follows:
AIX 5.2
TSM 5.2.2.5
DB size 105Gig - 93% utilized - 13 Lun's (One over the recommendation). Disk
subsys - FastT900 File system - RLV Tape technology: 3584 with Lto-2 drives.
P650 (4 Processors and 4Gig Ram)

Regards
ChristoH

===
Yes, interesting stats. On all my TSM servers, they get above 5M
pages for the DB backup, but none of them are above 3.8M objects on the
expire inventory. Some in the 2M, others only in the .5 M range.

These random thoughts pointed at the group, not necessarily Joe.

Since my db backups (sequential reads) go well, but the expire
inventory (random reads and writes) are slow, might that point to DB
fragmentation? Improper tuning of TSM buffers? Overcommittal of the
fast-write disk cache? Bad karma?

One would think that the more files deleted during the expire
inventory, the longer it will take for the expire inventory to progress? No?
I can run 2 expire inventories in a row and the second one goes much much
quicker because there are very few changes to the DB to be made. It seems
like the performance on the "number of objects examined" is really one of
those "your mileage may vary" kind of stats.

Perhaps I'm not getting the performance I should out of the
expiration...

Ben



__
Important Notice:

Important restrictions, qualifications and
disclaimers ("the Disclaimer") apply to this email.

To read this click on the following address:

http://www.absa.co.za/ABSA/EMail_Disclaimer

The Disclaimer forms part of the content of this
email in terms of section 11 of the Electronic
Communications and Transactions Act, 25 of 2002.

If you are unable to access the Disclaimer,
send a blank e-mail to [EMAIL PROTECTED] and we
will send you a copy of the Disclaimer.

Re: Expiration performance (my stats)

[Miles Purdy]

RS/6000 model 6h1
600 MHZ 
2-way
4 GB RAM
Disk: HP XP 1024

tsm: UNXR>select activity, cast ((end_time) as date) as "Date", (examined/cast 
((end_time-start_time) seconds as deci  mal (18,13)) *3600) "Objects Examined 
Up/Hr" from summary where activity='EXPIRATION' and days (end_time) -  days 
(start_time)=0

ACTIVITY DateObjects Examined Up/Hr
-- -- -
EXPIRATION 2004-08-14   4755600
EXPIRATION 2004-08-16   5137200
EXPIRATION 2004-08-17   5083200
EXPIRATION 2004-08-18   5248800
EXPIRATION 2004-08-19   4957200
EXPIRATION 2004-08-20   4672800
EXPIRATION 2004-08-21   5241600
EXPIRATION 2004-08-23   5626800
EXPIRATION 2004-08-24   6055200
EXPIRATION 2004-08-25   5346000
EXPIRATION 2004-08-26   5004000
EXPIRATION 2004-08-27   5202000
EXPIRATION 2004-08-28   5464800
EXPIRATION 2004-08-30   5076000
EXPIRATION 2004-08-31   5464800
EXPIRATION 2004-09-01   5148000
EXPIRATION 2004-09-02   5018400
EXPIRATION 2004-09-03   5176800
EXPIRATION 2004-09-04   5439600
EXPIRATION 2004-09-06   4395600
EXPIRATION 2004-09-07   6656400
EXPIRATION 2004-09-08   5454000
EXPIRATION 2004-09-09   5025600
EXPIRATION 2004-09-10   3938400
EXPIRATION 2004-09-11   5529600


tsm: UNXR>q db f=d

  Available Space (MB): 32 760
Assigned Capacity (MB): 32 760
Maximum Extension (MB): 0
Maximum Reduction (MB): 27 804
 Page Size (bytes): 4 096
Total Usable Pages: 8 386 560
Used Pages: 837 206
  Pct Util: 10.0
 Max. Pct Util: 10.0
  Physical Volumes: 4
 Buffer Pool Pages: 262 144
 Total Buffer Requests: 973 701 185
Cache Hit Pct.: 99.38
   Cache Wait Pct.: 0.00
   Backup in Progress?: No
Type of Backup In Progress:
  Incrementals Since Last Full: 0
Changed Since Last Backup (MB): 0.89
Percentage Changed: 0.03
Last Complete Backup Date/Time: 09/13/04   07:40:58


tsm: UNXR>q dbvol f=d

Volume Name  Copy   Volume Name  Copy   Volume Name  
Copy   Available Allocated Free
(Copy 1) Status (Copy 2) Status (Copy 3) 
Status Space SpaceSpace
   
  (MB)  (MB) (MB)
 --  --  
-- - - 
/dev/rTSMdbC1Sync'd /dev/rTSMdbC2Sync'd  
Undef-16 38016 3800
  
ined
/dev/rTSMdbB1Sync'd /dev/rTSMdbB2Sync'd  
Undef-16 38016 3800
  
ined


>>> [EMAIL PROTECTED] 13-Sep-04 2:12:45 AM >>>
Hi Ben,

I agree with you on these points - ran Dave's script on our main
TSM server - and the Database backup performance is exceptionally
good - the slowest I'm seeing is  3100:
FULL_DBBACKUP  2004-09-03  62625600
FULL_DBBACKUP  2004-09-04  56156400
FULL_DBBACKUP  2004-09-05  59911200
FULL_DBBACKUP  2004-09-06  51152400
FULL_DBBACKUP  2004-09-07  57801600
FULL_DBBACKUP  2004-09-08  60886800
FULL_DBBACKUP  2004-09-09  52707600
FULL_DBBACKUP  2004-09-10  59018400
FULL_DBBACKUP  2004-09-11  57938400
FULL_DBBACKUP  2004-09-12 

Re: Expiration performance

[goc]

and EXP_PERF

ACTIVITY Date Objects ExaminedUp/Hr
-- -- -
EXPIRATION 2004-08-14568800
EXPIRATION 2004-08-15486000
EXPIRATION 2004-08-16511200
EXPIRATION 2004-08-21640800
EXPIRATION 2004-08-22619200
EXPIRATION 2004-08-24655200
EXPIRATION 2004-08-25666000
EXPIRATION 2004-08-27594000
EXPIRATION 2004-08-28687600
EXPIRATION 2004-08-2963
EXPIRATION 2004-08-30748800
EXPIRATION 2004-08-31748800
EXPIRATION 2004-09-01572400
EXPIRATION 2004-09-04770400
EXPIRATION 2004-09-05662400
EXPIRATION 2004-09-06108000
EXPIRATION 2004-09-06698400
EXPIRATION 2004-09-08723600
EXPIRATION 2004-09-10626400
EXPIRATION 2004-09-10   1245600
EXPIRATION 2004-09-11709200

- Original Message -
From: "Michael Garnebode" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, September 13, 2004 10:01 AM
Subject: AW: Expiration performance


Hi,

i will share our values for expiration and dbbackup performance.
The comparison with Chistos values look like :-(

AIX 5.1
TSM-Server 5.1.9.3 (P630 , 4 GB Ram, 4 CPU)
TSM-DB 41 GB 67% Utilization on EMC-DMX 801
IBM 3584 with 10 LTO2

tsm: SWX00306>run db_backup_perf

ACTIVITY DatePages backed Up/Hr
-- -- -
FULL_DBBACKUP  2004-09-06   4896000
FULL_DBBACKUP  2004-09-06   5965200
FULL_DBBACKUP  2004-09-07   6667200
FULL_DBBACKUP  2004-09-07   6490800
FULL_DBBACKUP  2004-09-08   6004800
FULL_DBBACKUP  2004-09-08   6609600
FULL_DBBACKUP  2004-09-09   5886000
FULL_DBBACKUP  2004-09-09   7081200
FULL_DBBACKUP  2004-09-09   5644800
FULL_DBBACKUP  2004-09-09   5569200
FULL_DBBACKUP  2004-09-10   7462800
FULL_DBBACKUP  2004-09-10   4885200
FULL_DBBACKUP  2004-09-11   6534000
FULL_DBBACKUP  2004-09-11   8168400
FULL_DBBACKUP  2004-09-11   7196400
FULL_DBBACKUP  2004-09-11   5486400
FULL_DBBACKUP  2004-09-12   7153200
FULL_DBBACKUP  2004-09-12   5378400
FULL_DBBACKUP  2004-09-12   3402000
FULL_DBBACKUP  2004-09-13   7628400
ANR1462I RUN: Command script DB_BACKUP_PERF completed successfully.

tsm: SWX00306>run expiration_perf

ACTIVITY DateObjects Examined Up/Hr
-- -- -
EXPIRATION 2004-09-06277200
EXPIRATION 2004-09-07349200
EXPIRATION 2004-09-08 97200
EXPIRATION 2004-09-09334800
EXPIRATION 2004-09-10356400
EXPIRATION 2004-09-11338400
EXPIRATION 2004-09-12244800
ANR1462I RUN: Command script EXPIRATION_PERF completed successfully.

Regards

Michael Garnebode
Diplom-Informatiker
Systemberater

Schmitz RZ Consult
Gesellschaft f|r DV-Beratung und Projektmanagement mbH
Im Blumersfeld 22
50259 Pulheim
Tel.: +49 (0) 2238/922266
Fax:  +49 (0) 2238/922267
EMail: [EMAIL PROTECTED]

-Urspr|ngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von
Christo Heuer
Gesendet: Montag, 13. September 2004 09:13
An: [EMAIL PROTECTED]
Betreff: Re:

Re: Expiration performance

[goc]

itz RZ Consult
Gesellschaft f|r DV-Beratung und Projektmanagement mbH
Im Blumersfeld 22
50259 Pulheim
Tel.: +49 (0) 2238/922266
Fax:  +49 (0) 2238/922267
EMail: [EMAIL PROTECTED]

-Urspr|ngliche Nachricht-
Von: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] Im Auftrag von
Christo Heuer
Gesendet: Montag, 13. September 2004 09:13
An: [EMAIL PROTECTED]
Betreff: Re: Expiration performance


Hi Ben,

I agree with you on these points - ran Dave's script on our main TSM
server - and the Database backup performance is exceptionally good - the
slowest I'm seeing is  3100:
FULL_DBBACKUP  2004-09-03  62625600
FULL_DBBACKUP  2004-09-04  56156400
FULL_DBBACKUP  2004-09-05  59911200
FULL_DBBACKUP  2004-09-06  51152400
FULL_DBBACKUP  2004-09-07  57801600
FULL_DBBACKUP  2004-09-08  60886800
FULL_DBBACKUP  2004-09-09  52707600
FULL_DBBACKUP  2004-09-10  59018400
FULL_DBBACKUP  2004-09-11  57938400
FULL_DBBACKUP  2004-09-12  58968000

The average seems to be in the region of 5000 +, so from that point of
view it seems excellent - but the expiration sucks according to the script.

ACTIVITY DateObjects Examined Up/Hr
-- -- -
EXPIRATION 2004-08-14856800
EXPIRATION 2004-08-14867600
EXPIRATION 2004-08-15864000
EXPIRATION 2004-08-17770400
EXPIRATION 2004-08-18669600
EXPIRATION 2004-08-19846000
EXPIRATION 2004-08-20734400

So, yes, it seems that Ymmv, but is there anyone out there getting good
performance from expiration? If there are people out there, don't you want
to share your environment with us - might be able to collectively cast some
light on the lower expiration figures.

For the record, my environment is as follows:
AIX 5.2
TSM 5.2.2.5
DB size 105Gig - 93% utilized - 13 Lun's (One over the recommendation). Disk
subsys - FastT900 File system - RLV Tape technology: 3584 with Lto-2 drives.
P650 (4 Processors and 4Gig Ram)

Regards
ChristoH

===
Yes, interesting stats. On all my TSM servers, they get above 5M
pages for the DB backup, but none of them are above 3.8M objects on the
expire inventory. Some in the 2M, others only in the .5 M range.

These random thoughts pointed at the group, not necessarily Joe.

Since my db backups (sequential reads) go well, but the expire
inventory (random reads and writes) are slow, might that point to DB
fragmentation? Improper tuning of TSM buffers? Overcommittal of the
fast-write disk cache? Bad karma?

One would think that the more files deleted during the expire
inventory, the longer it will take for the expire inventory to progress? No?
I can run 2 expire inventories in a row and the second one goes much much
quicker because there are very few changes to the DB to be made. It seems
like the performance on the "number of objects examined" is really one of
those "your mileage may vary" kind of stats.

Perhaps I'm not getting the performance I should out of the
expiration...

Ben



__
Important Notice:

Important restrictions, qualifications and
disclaimers ("the Disclaimer") apply to this email.

To read this click on the following address:

http://www.absa.co.za/ABSA/EMail_Disclaimer

The Disclaimer forms part of the content of this
email in terms of section 11 of the Electronic
Communications and Transactions Act, 25 of 2002.

If you are unable to access the Disclaimer,
send a blank e-mail to [EMAIL PROTECTED] and we
will send you a copy of the Disclaimer.