ADSM-L

Re: TSM: DB Best Practises ?

2002-10-04 05:18:22
Subject: Re: TSM: DB Best Practises ?
From: "Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 4 Oct 2002 11:13:40 +0200
Hi Rafael!
I do not agree with you on this.
An AUDITDB is a recovery utility, not a maintenance utility.
There are a lot of sites out there, running for several years without ever
having to perform a AUDITDB.
You are also insinuating that planning an AUDITDB every now and then
shortens it's runtime. As far as I know an AUDITDB scans all database
records so it doesn't make any difference if you audited your database
before or not.
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: Rafael Mendez [mailto:rafael_mendez AT STARMEDIA DOT COM]
Sent: Thursday, October 03, 2002 15:34
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM: DB Best Practises ?


Hi Riaan,
I would like to share with you my experience here. I have seen how people
administering TSM server forget how important is to have planned the
AUDITDB.
Just one week ago, one of our customers HAD TO execute an audit db after 3
years of not to do it. That causes the TSM server had to be stopped for more
than 50 hours!!!!!!. (50 hours without backup or any possibility to
restore).
So, with this expample, my personal opinion is, TSM server administrator
should plan one (at least) or two "audit db" a year.
Of course, I am concius about to stop TSM server is not an easy issue but
lots of problems could be avoided running the AUDIT DB.
It would be interesting that someone outhere gives us a point of view on
this issue.

Hope this helps you in the long way to learn TSM.

Rafael
-------
to: Riaan Louwrens <riaanl AT SOURCECONSULTING.CO DOT ZA>
cc:
date: 10/3/2002 8:37:39 AM
subject: TSM: DB Best Practises ?



> Hi There,

>

> Been monitoring the list the last couple of weeks. Seeing as we are

> relatively new to the "world of TSM".

>

> I havent come across this (yet) in any of the admin / installation / user

> guides but I woudl like to know if there is a "best practises" w.r.t

> maintaining our tivoli server. (this is where the personal experience out

> there REALLY comes in handy ...) I have already drawn up a short list -
feel

> free to add to it ....

>

> Daily Backups

> Reclamation (daily)

> Migration

> Create Offsite Copies

> Expiration

> Backup TSM DB

> SnapShot TSM DB

> Backup Volhist

> Expire Inv

>

> If possible any integrity or consistency check that we can run  to verify

> the DB ? TSM internal commands ? or external utilities ?

>

> Second Question: (I know I am pushing it - but seeing as I already have
the

> guru's attention) - Does TSM have a utility that "scans" in a tape and

> re-populates the DB ? Example: We have a tape and we arent sure what data
it

> contains - can one "scan" (for lack of a better term) the contents ? Can
one

> restore from that tape (say to a temp location) to view the contents ?

>

> Any help is appreciated.

>

>

> Regards,

>

>

> Riaan Louwrens

> Source Consulting SA

>


____________________________________________________________________________
___________________________
Obtin gratis tu cuenta de correo en StarMedia Email. !Regmstrate hoy mismo!.
http://www.starmedia.com/email


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

<Prev in Thread] Current Thread [Next in Thread>