Hi ,
Greetings,
You are controlling SAP R/3 database versioning through TSM, not TDP R/3
( ???? )
I take online backup on weekdays ( Mon - Satday ) & offline backup on
Sunday. Online backup and offline backup data goes onto separate
storagepools. I take offsite copy from offline backup storage pool.
How MAX_VERSION parameter of TDP R/3 works here? ( if i want to control
versioning through TDP R/3 ).
Does it see online and offline combinely or separately? If it treats online
and offline combinely , to maintain three versions of offline backup i
shoud use MAX_VERSIONS=21 which is going to eat 21 * 500 GB = 10.5 TB on my
tapepools (????..it sounds tooooooo much ...????). I should go back to TSM
version control.
However, tivoli recommends using TDP R/3 version controlling. Whats the big
reason behind it??
Plz through some light on TSM version control and MAX_VERSION parameter of
TDP R/3.
Regards
Raghu.
"Kauffman,
Tom" To: [EMAIL PROTECTED]
<KauffmanT@NI cc:
BCO.COM> Subject: Re: Management Class and TDP for
Sent by: R/3
"ADSM: Dist
Stor Manager"
<[EMAIL PROTECTED]
RIST.EDU>
12/12/2002
02:29 AM
Please
respond to
"ADSM: Dist
Stor Manager"
Brian --
TDP/R3 does not use backup classes, it uses archive classes.
I currently have four SAP systems running, and have 7 management classes
defined.
First and foremost -- off-line redo log copies. I have two management
classes (PRDLOG1 and PRDLOG2) so I can have two seperate storage pool
chains, disk and tape. There's no point in doing two sets of logs if they
can end up on a common media somewhere. These two classes are used for all
SAP instance redo logs and have a 21-day retention (redo log retention
should match off-line backup retention).
PRDLOG1 ties to storage pool PRDLOG1 (disk) with next pool of PRDLOG1-LT
(lto tape). PRDLOG1-LT gets copied daily to PRDLOG1-LT-COPY for off-site
movement.
PRDLOG1 ties to storage pool PRDLOG2 (disk) with next pool of PRDLOG2-LT
(lto tape). PRDLOG2-LT gets copied daily to ARCH-LT-COPY for off-site
movement. (ARCH-LT-COPY also gets a copy of ARCH-LT which is the lto pool
for all non-SAP oracle archives).
Then my SAP data archive. The production instance uses management class
PRDSAP-ONLINE (online backups, 8 day retention) or PRDSAP-OFFLINE (21 day
retention -- run once per week). Both tie to tape storage pool PRDSAP-LT,
which copies daily to PRDSAP-LT-COPY for off-site rotation.
I do not run reclaims on any of the PRDSAP tape; I just let them die a
natural death after 8 or 21 days. I DO run reclaims on the redo log tapes
copies, and tend to have 4 to 6 lto tapes tied up in either class off-site.
My technical sandbox uses LOCALARCH as a management class. This ties to a
LOCALARCH disk pool with LOCAL-LT as next pool. 21 day retention, no
off-site copy (sandbox and test oracle databases, other archives of systems
that can be rebuilt from off-site copies of production environments).
My test/QA region uses TSTSAP as a mangement class, pointing to an LTO pool
TSTSAP-LT; 21 day retention, no off-site copy. We rebuild from the PRD
environment about every six weeks by cloning.
My DEV environment uses DEVSAP-LT as a management class, pointing to a disk
pool called ARCHIVEPOOL with next pool of ARCH-LT, 21 day retention (and
yes, it copies to ARCH-LT-COPY nightly).
In addition, I run weekly archives of the non-database SAP filesystems
(/sapmnt/SID, /oracle/SID, /usr/sap/trans, and a few local filesystems
using
the PRDLOG1 and PRDLOG2 management classes. These are done to speed up
point-in-time recovery at D/R by laying down the most recent Sunday from
the
archive and then restoring to 'now'.
SAP recommends you keep 3 generations of your off-line backup (archive); 21
days works if you do this weekly. If you run off-line monthly you'll want
90+ days and need to adjust redo log retention to match.
Is there anything else I can add to further confuse the issue? <GD&R>
The mish-mosh of pools I use has been set up to optimise D/R recovery and
the off-site storage pool backup process. They work for us; we've had a
number of successful D/R drills over the years.
Tom Kauffman
NIBCO, Inc
> -----Original Message-----
> From: brian welsh [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 11, 2002 3:06 PM
> To: [EMAIL PROTECTED]
> Subject: Management Class and TDP for R/3
>
>
> Hello,
>
> Server AIX 5.1, TSM 4.2.2.8. Client AIX 4.3, TSM 4.2.1.25,
> and TDP for R/3
> 3.2.0.11 (Oracle)
>
> Question about TDP.
>
> We wanted to use the Management Class on the TSM-server like this:
> Versions Data Exists NOLIMIT
> Versions Data Deleted 3
> Retain Extra Versions 21
> Retain Only Version 30
>
> In the Guide Tivoli Data Protection for R/3 Installation &
> User's Guide for
> Oracle is mentioned to define 4 different Management Classes. I was
> wondering how other people have defined there Management
> Classes. Support
> told me to use 4 different Management Classes because it's in
> the manual so
> they mention something with it (maybe for in the future), but
> what is the
> advantage of 4 different Management Classes. We have 8
> TDP-clients. The
> manual is saying every client his own 4 different Management
> Classes. It's
> not easy to manage that way.
>
> Besides you have to define an archive-copy group. We don't want to use
> Versioning in TDP, but use expiration via TSM-client/server.
> How many days I
> have to define the archive-copy group. I think it has to be
> 21 days. I guess
> that when using Versioning in TDP you have to set these
> parameter on 9999.
> Am I right.
>
> Is there somebody who want to share the definitons used for TDP for
> Management Classes and Copy Groups?
>
> Thanx,
>
> Brian.
>
>
>
>
>
> _________________________________________________________________
> Chatten met je online vrienden via MSN Messenger.
http://messenger.msn.nl/
