backup using RMAN

I would start in the online docs.  They will likely explain the differences better than we can here:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmcncpt.htm#BRADV109

•A differential incremental backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0


•A cumulative incremental backup, which backs up all blocks changed after the most recent incremental backup at level 0

As for other types:  That is pretty much it.

Where there are some differences is what happens after the backup.

We use Incrementally Updating backups:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmbckba.htm#BRADV8186

In a nutshell:
Take the last level1 and apply it against your last level0.  This way if you ever have to recover, you don't need to apply a lot of level1 backups.

As far as the steps:
Every system and company is different.  There really isn't a one-size fits all.  You will have different requirements on how long/many files you keep before deleting, if you go disk-to-disk-to-tape or disk-to-tape, etc...

Figure out what you need and go through the docs.  Then test, test, test!

"I would start in the online docs.  They will likely explain the differences better than we can here:
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmcncpt.htm#BRADV109"

that one is the one can only make me understand what is level 0 (full back) and level 1( incremental backup), so I come and ask for help as this make me confuse.

"incremental backup at level 1 or 0" why incremental backup can be 1 ? full backup is 0, right?

what I see is there are 2 x incremental backup:
1) A differential incremental
2)A cumulative incremental

"In a nutshell:
 Take the last level1 and apply it against your last level0.  This way if you ever have to recover, you don't need to apply a lot of level1 backups."

yeah, that's why I don't understand why incremental can be level 1 or 0, it should be just level 1, right?

"Figure out what you need and go through the docs.  Then test, test, test! "

I knew, but clear up concept first.

so level 0 backup each week as full backup , then level 1 incremental backup daily or hourly, when recover, just recover based on that weekly level 0 backup and then followed by that last level 1 backup and instance resume, right?

"Keep it simple:
 level 0 is a FULL.
 level 1 is partial (incremental). "

yes, tks,

what is the command to restore a differential incremental backup ?

restore
  INCREMENTAL LEVEL 1 database ;

Select allOpen in new window

?

what is the command to restore a cumulative incremental  backup ?

restore
  INCREMENTAL LEVEL 1 CUMULATIVE
  database;

Select allOpen in new window

?

"1) A differential incremental
        Backs up anything changed since last backup.  The last backup could be a 0 or 1.
"

ok.

>>what is the command to restore a differential incremental backup ?
>>what is the command to restore a cumulative incremental  backup ?

I don't believe there is any difference.  Restore is restore is restore...  The syntax and examples are in the online docs and on the web.

"duplicate database to testdb

is a pl/sql command ?

>>is a pl/sql command ?

RMAN command.

Sorry for confusion, marrowyung.

From a restore from disaster perspective, you wouldn't use duplicate.

I was using it as an example to show you that RMAN knows what backups are available - restore and duplicate both know what the most recent full & incrementals are as well as the archive logs.

what is the diff of use on duplicate and restore?
when should we use duplicate ?

Restore: You've had a failure and need to restore your database to where it was before the failure
Duplicate: You're making a copy of a database - prod to test, for example

excellent ! but then why oracle don't make use of restore to implement the same thing as Duplicate ?

adding one more command making the world complex, right?

Can't answer the "Why" on that - not a part of Oracle's Development team.

However, restore is just that - restore to exactly the same settings as before a failure.

Duplicate is restore and rename and also requires a couple of extra parameters be used during the copy to rename data files and log files etc.

They are close in functionality but really do two different things.

"Duplicate is restore and rename and also requires a couple of extra parameters be used during the copy to rename data files and log files etc.
"

so just like pfile and SPfiles ? so Duplication can do some change/ETL/transformation to the final restored data ?

No, it's a copy of the source, with database optionally renamed.

"optionally renamed. "

that duplicated database must be in other instance, right?

will it be faster than restore?

>> will it be faster than restore?

Duplicate is completely different from a recovery/restore.

They aren't even related to one another.

You cannot compare the two.

Restore recreates/restores a damaged database from available backups.
Duplicate takes a perfectly good and running database and makes an exact copy of it.


Think of it this way:
You have a word document named myResume.doc.  You accidentally delete some of the main text and save it.  You go to last nights backup and restore myResume.doc to what it looked like before you deleted the text.
versus
copy myResume.doc myResume_COPY.doc

"Duplicate takes a perfectly good and running database and makes an exact copy of it."

yeah, good statement. seems reverse in direction in terms of recovery, right?

Ok, if now I need to to PITR ( point in time restore) , I need to do a level 0 backup and keep then keep doing a lot of A differential incremental, each with different name (RMAN know how to name it automatically, right? ), then when really need PITR, it will be ok ?

as far as I know I just need to make sure the differential incremental, then the SCN number can be recent enought for me to do PITR ?

>>good statement. seems reverse in direction in terms of recovery, right?

Duplicate has NOTHING to do with recovery!!!!!!!!!!!

>> I need to do a level 0 backup and keep then keep doing a lot of A differential incremental
That is one method.  A good backup strategy must meet your specific needs.  Each one is different.

The main driving point is: Time to recover and acceptable data loss.

If you have a week to recover or 2 hours, the strategy to back up is COMPLETELY different.

>>make sure the differential incremental, then the SCN number can be recent enought for me to do PITR ?

The SCN controls when the recovery can be comleted to.  Yes, a backup stores the SCN but so does all the online redo and every data file and control file.  This is what makes PITR work.

"Duplicate has NOTHING to do with recovery!!!!!!!!!!!"

okok, got it. that's only my thinking.

"The main driving point is: Time to recover and acceptable data loss."

of course! but it seems all business user will tell the same thing, right?

"The SCN controls when the recovery can be comleted to.  Yes, a backup stores the SCN but so does all the online redo and every data file and control file.  This is what makes PITR work. "

So basically what will be the strategy or method to use in a banking system lke:
1) I need data restore ASAP.
2) I need PITR ?

>>of course! but it seems all business user will tell the same thing, right?

There should be system requirements that define these.

>>1) I need data restore ASAP.

Just like the above comment:  system requirements will tell you this.  There should be a Service Level Agreement (SLA) that defines all this.

>> 2) I need PITR ?

Only if you don't want any data loss.  Seems like a good idea for a Bank system.  Don't you think?

"Seems like a good idea for a Bank system.  Don't you think? "

yeah, that's why I am concerning this.

so  I need to do a level 0 backup and then keep doing a lot of  differential incremental, each with different name (RMAN know how to name it automatically, right? ), then we can implement PITR
 based on this, right?

You really should consider a new level 0 every now and then.  If you take a level 0 and then take level 1's every day for 6 weeks what happens on a restore ?

You restore the level 0, then the most recent level 1 which has fully 6 weeks of changes in it.  

Your recovery time could be excessive.

When considering your disaster recovery plan you need to consider your time for recovery as well as your tolerance for data loss (which in a banking system is pretty much zero).

But something like a level 0 maybe weekly at the outside or twice weekly.  Level 1's on the days you're not doing level 0's.  Then archive logs as often as you deem necessary.

RMAN will handle naming conventions for you.  You can customize them, too.  Here's the 11gR1 docs on the format string: http://docs.oracle.com/cd/B28359_01/backup.111/b28273/rcmsubcl010.htm#RCMRF195

>>so  I need to do a level 0 backup and then keep doing a lot of  differential incremental,

You need whatever meets your specific requirements.  We cannot answer that for you since we do not know your specific systems and requirements.  Most shops have specific requirements that dictate how long a system can be down, data retention requirements, etc...   Your backup strategy needs to comply with those.

As I mentioned in my first post:
We use Incrementally Updating backups.  That takes the last lvl1 you just did and rolls it back into the lvl0.  This way you don't have a TON of lvl1 backups to apply to get back to point-in-time.

To illustrate at least part of the point slightwv is making look at this page in the docs: http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm

It has pictures showing the two types of level 1 backups - cumulative and incremental.

Cumulative means that for any given restore scenario all you need is the most recent level 0 and most recent level 1, rather than every single level 1 since the last level 0.

I also prefer the cumulative approach when taking level 1 backups.

(And I realize that incrementally updating backups are something different again, but that's also mentioned a little further down in the docs)

Steve Wales,

"But something like a level 0 maybe weekly at the outside or twice weekly.  Level 1's on the days you're not doing level 0's.  Then archive logs as often as you deem necessary.
"
you are talking about is I need to do 3 type of backup:
1) level 0 backup.
2) level 1 backup.
3) archive log backup.

am I right ? so this is the type of backup I need to do if I need to do PITR, right?

tks for the link.

slightwv,

sorry I don't get what you mean by :

"We use Incrementally Updating backups. That takes the last lvl1 you just did and rolls it back into the lvl0. "

so this means there are one more types of backup call incrementally updating backup ? and it will just merge the level 1 backup to the existing latest level 0 backup and we will only see one level 0 backup file at the end of the operation ?

Archive logs are a critical part of PITR, so yes, you had better be backing them up too.

Incrementally updating backups are described in the documentation link I gave you in the last reply.

>>you are talking about is I need to do 3 type of backup:

You ALWAYS need to backup archived redo logs no matter if the database backup is lvl0 or lvl1.

The archived redo logs are probably the MOST IMPORTANT files to have.  If you are missing just ONE in the sequence, you cannot recover past the missing archived log.

I keep several sets of archived redo log backups on disk and several different tapes and any given time.

>>and we will only see one level 0 backup file at the end of the operation ?

Assuming you properly delete obsolete backups when you are done:  You will see a lvl0 and a lvl1.

This speeds up time to recovery because you don't have to apply a lot of lvl1 backups to get back to point in time.

>> in the documentation link I gave you in the last reply.

FYI:
Which is the same document (different version) that I posted in my very first post.

slightwv,

"The archived redo logs are probably the MOST IMPORTANT files to have.  If you are missing just ONE in the sequence, you cannot recover past the missing archived log."

Yeah, fully understood.

tks both, very good coaching !

from the link:

http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm
"The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy."

thsi is hard to understand! please help me out.

Steve Wales,

you said:

"You really should consider a new level 0 every now and then.  If you take a level 0 and then take level 1's every day for 6 weeks what happens on a restore ?

 You restore the level 0, then the most recent level 1 which has fully 6 weeks of changes in it.  

 Your recovery time could be excessive."

you just mean no much differenital incremential backup file and no good.

 but from the link, for the differential incremental backup:

 

it seems I am still ok on this, right?

and again, from the link:

 "The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:"

SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS 
  FROM V$BACKUP_DATAFILE 
  WHERE INCREMENTAL_LEVEL > 0 
  AND BLOCKS / DATAFILE_BLOCKS > .5 
  ORDER BY COMPLETION_TIME;

Select allOpen in new window

"Compare the number of blocks in differential or cumulative backups to a base level 0 backup. For example, if you only create level 1 cumulative backups, then when the most recent level 1 backup is about half of the size of the base level 0 backup, take a new level 0."

so by the script, how can we compare the number of blocks to a based level 0 if WHERE INCREMENTAL_LEVEL > 0  ?

>>The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy.

A Full backup and an incremental level 0 are effectively the same thing - except if you are planning on doing incremental level 1's as well as a part of your backup strategy, you need to do the level 0 instead of the full.

I don't know why Oracle decided to do it that way, but they did.  If you plan on doing a full every night then just do a full.  If you plan on doing level 1's then start off with a level 0 and never do a full.

All I was trying to make you understand about the frequency of a level 0 backup is that you can't just take a level 0 and then take level 1's from then on and never take another level 0 again.   Your recovery time becomes longer and longer the further back in time your level 0 is.

Just make sure you're taking a new level 0 from time to time - since that is your starting point of your recovery.  I have some databases where I take a level 0 once a week and some where I take a level 0 twice a week.

>>so by the script, how can we compare the number of blocks to a based level 0 if WHERE INCREMENTAL_LEVEL > 0

Not quite sure what you mean by this.  Chance "> 0" to "= 0" to see the level 0's only if you want to see just the level 0's ?

"A Full backup and an incremental level 0 are effectively the same thing - except if you are planning on doing incremental level 1's as well as a part of your backup strategy, you need to do the level 0 instead of the full."

it seems making sense to me ! so if we need to do differential increment and/or culcumiatve incremental backup as well as full backup TOGETHER, we called it level 0 backup instead of call it full backup?

but the RMAN command will be the same ?

"I don't know why Oracle decided to do it that way, but they did.  If you plan on doing a full every night then just do a full.  If you plan on doing level 1's then start off with a level 0 and never do a full.
"

this mean RMAN command is not the same ?

"All I was trying to make you understand about the frequency of a level 0 backup is that you can't just take a level 0 and then take level 1's from then on and never take another level 0 again. "

tks, but I don't mean that. this is much clear now !

"Just make sure you're taking a new level 0 from time to time - since that is your starting point of your recovery.  I have some databases where I take a level 0 once a week and some where I take a level 0 twice a week.

you seems that you only do level 0 but no level 1 ?

"Not quite sure what you mean by this.  Chance "> 0" to "= 0" to see the level 0's only if you want to see just the level 0's ? "

no ! what I mean is I don't quite understand what the link on that part is talking about:
http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm

it said:

When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 whenever 50% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following query displays the number of blocks written to a backup set for each datafile with at least 50% of its blocks backed up:

SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS 
  FROM V$BACKUP_DATAFILE 
  WHERE INCREMENTAL_LEVEL > 0 
  AND BLOCKS / DATAFILE_BLOCKS > .5 
  ORDER BY COMPLETION_TIME;

Select allOpen in new window

what condition in this query tell me when the datafile has 50% content changed so that I need to run a level 0 backup again ?

if I really, as according to that link, implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily.  In this scheme, Inever have to apply more than a day's worth of redo for complete recovery.

but for PITR, it is also enought and I can restore to any SCN I like ? and RMAN will automatically restore all level 0 file and level 1 file in the right order so I don't ever need to take care about that myself ? then all content will restore up to that SCN ?

>>When deciding how often to take full or level 0 backups, a good rule of thumb

I've never seen any organization that does this:  Hey everyone, time for a new full backup!!!

Everywhere I've ever been and any system that I've ever known about just sets the schedule and it runs automatically.

>>In this scheme, Inever have to apply more than a day's worth of redo for complete recovery.

In a recovery you will first recover your lvl0.  then apply ALL lvl1 backups up to the point in time.

So potentially an entire months worth of data.

>>RMAN will automatically restore all level 0 file and level 1 file in the right order so I don't ever need to take care about that myself ?

Yes.  As long as the backups are pulled from tape and placed in the same folder where Oracle thinks they should be.

I never do another lvl0 unless something happens to the lvl0 I have on disk.  Remember that I roll my lvl1 into my lvl0 so I never have to worry about how many lvl1 backups I have to apply in the event of a disaster.

>>this mean RMAN command is not the same ?

The commands to backup level 0 is indeed different to full.

Full:  Backup Database

Incremental Level 0:  Backup incremental level=0 Database  (that command may not be exactly 100% correct, going from memory but you can see they are different)

>>you seems that you only do level 0 but no level 1 ?

I do my level 1's on the other nights of the week I'm not doing level 0's

"I've never seen any organization that does this:  Hey everyone, time for a new full backup!!!

 Everywhere I've ever been and any system that I've ever known about just sets the schedule and it runs automatically."

that's what the query is about to help us to determine that, right ?

that statement basically make sense ! how many people use it, I would like to listen to you all.

"Yes.  As long as the backups are pulled from tape and placed in the same folder where Oracle thinks they should be."

Please gives URL that has procedure on how to:
1) backup level 0 and level 1 to tap, by using backup set, right?
2) how to check any level 0 and level 1 on the existing database.
3) how to remove the existings one, once add a new one, then use 2) to verify the file exist ?

"I never do another lvl0 unless something happens to the lvl0 I have on disk. "

how can you know if there are problems on level 1?

"Remember that I roll my lvl1 into my lvl0 so I never have to worry about how many lvl1 backups I have to apply in the event of a disaster."

yeah, but bascailly I don't understand how to roll the level 1 to level 0, any URL to explain how to do it? to save space, right?

"The commands to backup level 0 is indeed different to full.

Full:  Backup Database

Incremental Level 0:  Backup incremental level=0 Database  (that command may not be exactly 100% correct, going from memory but you can see they are different)"

so if I do backup data and Backup incremental level=0 Database, the result is the same? but I need to do backup incremental to allow bakcup level 1 later?  backup database command don't allow me to do level 1 backup ?

so any URL show me how to customize the target path of restoration ? so RMAN find everything it needs in a single path and let PITR begin without any problem.

RMAN can backup to tape itself, right ?

"
 I never do another lvl0 unless something happens to the lvl0 I have on disk.  Remember that I roll my lvl1 into my lvl0 so I never have to worry about how many lvl1 backups I have to apply in the event of a disaster. "

I am reading this http://docs.oracle.com/cd/B19306_01/backup.102/b14192/bkup004.htm, are you referring to Incrementally Updated Backups: Rolling Forward Image Copy Backups?

and the image copy backup is the level 0 or full backup? in this case should be level 0 backup?

I see thsi script:

RUN {
   RECOVER COPY OF DATABASE WITH TAG 'incr_update';
   BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update'
       DATABASE;
   }

Select allOpen in new window

it said :

"Even when the BACKUP INCREMENTAL LEVEL 1 ... FOR RECOVER OF COPY command is used with DEVICE TYPE SBT to create a backup on tape, the first time it is used it creates the image copy on disk, and does not write any backup on tape. Subsequent incremental level 1 backups can be created on tape once the image copy is on disk."

then it will always be levle 1 backup on tap but image copy still on disk?  no rolling update to image copy file happen at all ?

or whenever it see "RECOVER COPY OF DATABASE WITH TAG 'incr_update';" at the beginning of this kind of backup, it will causes RMAN to apply any available incremental level 1 backups to a set of datafile copies with the specified tag and this is what make it like MERGE change/backup and oracle called it rolling update?

>>that's what the query is about to help us to determine that, right ?

To be honest, I've never seen that query before.  I assume it might help if your DML is consistent over time but I doubt it is.

You do full backups when the system allows not when some query tells you to.

>>Please gives URL that has procedure on how to:

I'm not sure if it exists.  I would start with the online docs for RMAN and learn the commands.

>>how can you know if there are problems on level 1?

Logs.

>>any URL to explain how to do it? to save space, right?

The online docs is where I learned it.  It isn't just to save space.  It is to save time in the event I need to recover.

>>RMAN can backup to tape itself, right ?

It 'can'.  I used quotes because your tape library would need to know about RMAN backups versus normal system backups.

I have RMAN backup to disk then the backups are put on tape with the normal OS backups.  I don't have to do anything special as far as tape management.  I let the system administrators worry about all that.

>>you referring to Incrementally Updated Backups

Yes.  That is why I mentioned them in my very first post and provided the doc link for them.

>>then it will always be levle 1 backup on tap but image copy still on disk?

It appears the lvl0 will remain on disk.  It sort of makes sense.  How could the lvl1 merge itself into the lvl0 if the lvl0 is on a different tape?

>>and this is what make it like MERGE change/backup and oracle called it rolling update?

I believe so.


It took me a LONG TIME and a LOT of testing before I got my backups to work the way I wanted them.  I spent most of that time in the online docs reading.

"You do full backups when the system allows not when some query tells you to."

 allow not ? please explain further !

">>how can you know if there are problems on level 1?

 Logs.
"

you mean alert.log and trace log ?

" It is to save time in the event I need to recover.
"

tks. but the time to roll the level 1 to level 0 backup is fast enought ?

"It 'can'.  I used quotes because your tape library would need to know about RMAN backups versus normal system backups.
"
so you mena there are settting/configuration need to let RMAN know there are tapes backup system there? any URL on how to configure that? or it usually from the manual of tape system?

"I have RMAN backup to disk then the backups are put on tape with the normal OS backups.  I don't have to do anything special as far as tape management.  I let the system administrators worry about all that.
"

ok, then SA's job, not DBA's job ! so DBA just back that up to disk only ? the SA can push the ball to DBA, right?

so RMAN can't connect to a tape system DIRECTLY ?

" How could the lvl1 merge itself into the lvl0 if the lvl0 is on a different tape?"
I think is the level 0 can be on the SAME tape/ tape library too !

>> allow not ? please explain further !

You typically have a set schedule for backups and these are almost always during a slow period of the day/week/???

You don't do backups when some query tells you it is time to do a backup.

>> you mean alert.log and trace log ?

The backup log.


>>so you mena there are settting/configuration need to let RMAN know there are tapes backup system there?

Tape libraries are told what tapes are for what use.  Somehow the system backups need to be told what tapes are for Oracle and RMAN needs to know what tapes it can use.

I've not configured RMAN to tape backups so I'm not sure how all that works.

>>any URL on how to configure that?

The online docs and the documentation for your tape system.

You might reach out to your Oracle Account Team to see what resources might be available.

>>ok, then SA's job, not DBA's job ! so DBA just back that up to disk only ? the SA can push the ball to DBA, right?

It depends on how you set things up.  I worked with my system administrator and told him when my backups should be finished and what folders they were in.  His system backups ignore the actual Oracle database folders and captures all my backup folders.

>>so RMAN can't connect to a tape system DIRECTLY ?

I never said that.  RMAN can backup directly to tape.

>>I think is the level 0 can be on the SAME tape/ tape library too !

The quote you posted above says the lvl0 must remain on disk.

"Tape libraries are told what tapes are for what use.  Somehow the system backups need to be told what tapes are for Oracle and RMAN needs to know what tapes it can use.

 I've not configured RMAN to tape backups so I'm not sure how all that works."

so for you, your RMAN is not going to backup to tape direclty ,right? you hand all this to system administrator to copy it to tape ?

"His system backups ignore the actual Oracle database folders and captures all my backup folders.
"

yes, it is one of the simplier way !

"The quote you posted above says the lvl0 must remain on disk. "

yes, that's why I ask, seems funny !! why level 0 on disk but level 1 on tape, I can't see why !

>>you hand all this to system administrator to copy it to tape ?

Yes.  My backup folders are just like any other folders the sys admin backups up.

>>why level 0 on disk but level 1 on tape, I can't see why !

Think about how the Incrementally Updating backups work.

Create a lvl1. Take the lvl1 and 'merge' it into the available lvl0.

If that lvl0 was on a tape, how could the merge happen?

"If that lvl0 was on a tape, how could the merge happen? "

but that one is not talk about rolling update yet! I just can't see why!

and ok, now you mean the merge can't happen on tape but HDD, right?

but compression and encryption can happen on tape ?

>>and ok, now you mean the merge can't happen on tape but HDD, right?

Yes.

>> but compression and encryption can happen on tape ?

Yes.  You also need to work with your system administrator if you are going to backup directly to tape.  Many tape devices have compression built in.  If yours does, compressing the backups BEFORE writing them to tape is just a waste of time.

">>and ok, now you mean the merge can't happen on tape but HDD, right?

 Yes.
"
you know what I think is, why don't RMAN see there is a level 0 backup on disk and that just merge it with level 1 backup on tape, then remove level 0 backup on disk and just use the copy on tape.

"If yours does, compressing the backups BEFORE writing them to tape is just a waste of time. "

yes, but usually we just let RMAN compress and encryption at the same time and it should be fastest ?

>>, then remove level 0 backup on disk

If you remove the lvl0 on disk, what lvl0 will the lvl1 merge into?

It would have to go find the one on tape, assuming the tape is still in the device, pull it back onto disk, do the merge then put it back on the tape.

>>yes, but usually we just let RMAN compress and encryption at the same time and it should be fastest ?

If the tape device compresses, how will trying to compress it twice be faster?

Think about it from a file perspective:
You have a file on disk.  Which is faster?

Zip it then copy it
or
Zip it, then zip it again then copy it.

"If you remove the lvl0 on disk, what lvl0 will the lvl1 merge into?

 It would have to go find the one on tape, assuming the tape is still in the device, pull it back onto disk, do the merge then put it back on the tape."

sorry, you misunderstand me! this is also what I am thinking, why level  0 ALWAYS on this and level 1 ALWAYs on TAPE ? why don't just see level 0 backup on disk, then move it to tape AFTER MERGE, simple, right? you can see that RMAN can see level 0 on disk and she make decision to create level 1 on tape, the next time we do backup again, RMAN should already do all the merge on tap instead of finding the level 0 again on disk.

is this mean this design only make sure that backup perfomrance optimized because level 0 on disk is much faster than on tape ?

"If the tape device compresses, how will trying to compress it twice be faster?"

what I mean is let RMAN do both and tape device don't do anything about that, it just store data on tape .

so we are not going to do:

Zip it, then zip it again then copy it.

>>why don't just see level 0 backup on disk, then move it to tape AFTER MERGE, simple, right?

Yes, you need to make sure ALL your backups are eventually on tape.  Preferably more than one since tapes break all the time.

but if I move the level 0 backup to tape , RMAN probably can't see it, then restore fail?

the backup channel need to set to point to the path of level 0 on tape ?

or we can't do this but only local path ?

>>but if I move the level 0 backup to tape , RMAN probably can't see it, then restore fail?

You write a copy of the lvl0 to tape.  Leave the original on disk.

"You write a copy of the lvl0 to tape. "

ahahh, that one will be no use, right?
 but how ? let the tape backup program do it ?

>> ahahh, that one will be no use, right?

It won't be used for future merges but will be invaluable if you lose all your disks or the entire data center is destroyed.

You need to think about many different disaster scenarios when you are developing a disaster recovery plan.

>>let the tape backup program do it ?

Exactly.

I do disk to disk backups and tell our system administrator:
Ignore these folders (the ones with the actual data files).
Backup these folders as normal filesystem backups (my on disk backups).

But, my database is small enough to allow me to do this.  You may not be able to do it.

" will be invaluable if you lose all your disks or the entire data center is destroyed.
"

or valuable ?

"You need to think about many different disaster scenarios when you are developing a disaster recovery plan."

yeah,

"Backup these folders as normal filesystem backups (my on disk backups)."

yeah, as RMAN backup everything to disk and the tape backup program copy them to tape, this is what you mean, right?

"But, my database is small enough to allow me to do this.  You may not be able to do it. "

what is this mean ?

>>as RMAN backup everything to disk and the tape backup program copy them to tape, this is what you mean, right?

Yes.

>>what is this mean ?

You may not have enough disk space or time to do disk-to-disk-to-tape backups.

tks. I am now going to read through the RMAN docu from beginning to see what I need to know more.

will post question later in other ticket, thanks.

man,

sorry to come back, the scritp seems having problem on deleting old backup files:
daily:

Run {
allocate channel ch1 device type disk;
allocate channel ch2 device type disk;
allocate channel ch3 device type disk;
allocate channel ch4 device type disk;
backup archivelog all not backed up 1 times format 'DBBak%d_%U_%T.arcbkp';
delete noprompt obsolete;
}
exit;

Select allOpen in new window

weekly

Run {
allocate channel ch1 device type disk;
allocate channel ch2 device type disk;
allocate channel ch3 device type disk;
allocate channel ch4 device type disk;
backup database format 'DBBak%d_%U_%T.bkp';
backup archivelog all format 'DBBak%d_%U_%T.arcbkp';
backup current controlfile format 'DBBakcontrol_%d_%U_%T.ctl';
delete noprompt obsolete;
}
exit;

Select allOpen in new window