ADSM-L

Re: copy serialization shared , shared static, shared dynamic

2004-12-15 13:47:20
Subject: Re: copy serialization shared , shared static, shared dynamic
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 15 Dec 2004 11:17:41 -0700
See the reference information for DEFINE COPYGROUP regarding the 
SERIALIZATION parameter. It contains warning info about using the *DYNAMIC 
serialization methods.

As for the *STATIC serialization methods, consider:

STATIC tries to back the file up once. If it can't capture an unchanged 
version, then the file is skipped.

SHRSTATIC will try up to 4 times to back up a changing file. Though it 
will skip the file if it ultimately cannot get an unchanged version, at 
leat you get several tries. The downside is that when the file is retried, 
the current transaction (which can include other files as well) has to be 
resent, and thus represents an increase in backup run time.

In general, having a good backup version takes precedence over 
performance, and therefore SHRSTATIC is what I would recommend over 
STATIC. In general, use of STATIC or *DYNAMIC methods should be on an 
exception basis only, when the trade-offs between serialization, value of 
the data, risk of fuzzy backp or no backup, etc., are fully understood.

My two cents.

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

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" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/15/2004 
07:16:32:

> Hi,
> 
> I know that we could use these modes depending on the user requests,
> but i would like to find out what is the best practice? 
> i read in 5.2,that it should be shared static? do these parameters 
> also cut down on inspection time during backups? how reliable is the
> data when it is time to restore?
> 
> 
> > Please let me know
> > Thanks,
> > Perpetua
> >
> > --------------------------------
> > This e-mail may be privileged and/or confidential, and the sender 
> does not waive any related rights and obligations. Any distribution,
> use or copying of this e-mail or the information it contains by 
> other than an intended recipient is unauthorized. If you received 
> this e-mail in error, please advise me (by return e-mail or 
> otherwise) immediately.
> >
> > Ce courriel est confidentiel et protege. L'expediteur ne renonce 
> pas aux droits et obligations qui s'y rapportent. Toute diffusion, 
> utilisation ou copie de ce message ou des renseignements qu'il 
> contient par une personne autre que le (les) destinataire(s) 
> designe(s) est interdite. Si vous recevez ce courriel par erreur, 
> veuillez m'en aviser immediatement, par retour de courriel ou par un
> autre moyen.
> > ================================
> 
> 
> <font face="Times New Roman" size="3">
> 
<p>------------------------------------------------------------------------------
> </p>
> <p> This e-mail may be privileged and/or confidential, and the 
> sender does not waive any related rights and obligations. Any 
> distribution, use or copying of this e-mail or the information it 
> contains by other than an intended recipient is unauthorized. If you
> received this e-mail in error, please advise me (by return e-mail or
> otherwise) immediately.</p>
> <p> Ce courriel est confidentiel et protégé. L'expéditeur ne renonce
> pas aux droits et obligations qui s'y rapportent. Toute diffusion, 
> utilisation ou copie de ce message ou des renseignements qu'il 
> contient par une personne autre que le (les) destinataire(s) 
> désigné(s) est interdite. Si vous recevez ce courriel par erreur, 
> veuillez m'en aviser immédiatement, par retour de courriel ou par un
> autre moyen.</p>
> <p>====================================================</p>
> </font>

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