ADSM-L

Re: [ADSM-L] Oracle v9 backup and restore without TDP

2013-09-12 10:41:09
Subject: Re: [ADSM-L] Oracle v9 backup and restore without TDP
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 12 Sep 2013 16:39:12 +0200
Thanks for your reply Rick this helps.

About this "Logs are archived to TSM every 5-30 minutes depending on the
system disk availability."
How does this work and is it really an archive or a backup of archive logs?
Do you just run a dsmc i on the directory that contains the oracle archive
logs, do you use rman do place them somewhere or something other than this?

For me it is a little unclear if I can just pickup the log files with the
B/A client without rman knowing and remove the files that I have sent to
TSM (as an archive or normal backup file)

And can you determine the name of the database backups to disk when using
rman so I have some idea about the filenames used?

Many thanks so far! :-)

  Stefan



On Thu, Sep 12, 2013 at 4:26 PM, Rick Adamson
<RickAdamson AT biloholdings DOT com>wrote:

> Stefan,
> While I prefer to use the rman design as depicted in the Oracle/TSM doco,
> here is how I have done this in the past.
>
> Tasks are script based, executed by cron, and use rman so the repository
> and catalogs are maintained.
> Logs are archived to TSM every 5-30 minutes depending on the system disk
> availability.
> Database backups are sent to local disk daily using rman.
> Each process creates a dummy, or lock file that is checked before
> execution to assure that the processes do not run simultaneously.
>
> On the TSM server the flat-files obviously create a retention issue so I
> made a management class for the flat-file directories with the following
> backup settings (even though Oracle cuts log files they are not archived,
> Oracle log files are always stored as backup items):
> Versions Data Exists: 1
> Retain Extra Versions: 0
> Versions Data Deleted: 1
> Retain Only Version: 14
>
> A cron job maintains the latest 3 versions of the DB flat file backups on
> disk, purging those that are older.
> Rman retention is set to 14 days.
> Flat file DB backups: when the object is deleted from the disk by the cron
> task TSM's next file backup will set them as inactive and expire them once
> the "Retain Only Version" setting, in my case 14 days, is met.
>
> The final piece is to make sure you still create and schedule a rman task
> to purge, crosscheck, and sync the repository/catalog and expire the old
> log files that are backed up to the TSM server.
>
> The "versions exist and retain extra" are kind of irrelevant as all the
> flat-files have a unique file-name and remain active versions until they
> are removed from the file-system.
>
> The RMAN retention setting and "Retain Only" can be adjusted to meet your
> retention needs.
>
>
>
> -Rick Adamson
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Stefan Folkerts
> Sent: Thursday, September 12, 2013 9:26 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L] Oracle v9 backup and restore without TDP
>
> Hi guy's,
>
> A customer of ours is investigating cutting out the Oracle TDP for Oracle
> v9 and replacing it with rman backups to disk that get picked up by the
> TSM B/A client.
>
> I am wondering if people here are doing this already.
>
> I'm no Oracle or rman man but I wonder if you can create a workable
> environment with scripting and procedures, I understand we need disk space
> for the 'dumps' to disk and some space to stage the restore from TSM before
> it goes back to Oracle.
>
> But how about archive log backups and how to go about telling rman a
> backup is back on another disk ready to restore to Oracle.
> Can you script the name of the backups with rman and is this usually done
> with the B/A archive function or the backup function.
> I can image that the Oracle naming might be an issue.
>
> If anybody here could give me some pointers that would be great, it's a
> fairly large Oracle environment with full backups of more than 40TB's and
> single database or multiple TB's.
>
> Regards,
>    Stefan
>