dbTalk Databases Forums  

RMAN sample script for Linux

comp.databases.oracle.server comp.databases.oracle.server


Discuss RMAN sample script for Linux in the comp.databases.oracle.server forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Kalle
 
Posts: n/a

Default RMAN sample script for Linux - 06-23-2003 , 10:53 PM






Hi,

I have couple of instances running on Linux (9iRel2), now I would like
to do an online backup with RMAN to a disk and schedule it to happen
every night.

I wonder if you have a sample shell script to do this and could you post
it here.

TIA
Kalle


Reply With Quote
  #2  
Old   
konsultant_1 - konsultancIT.pl
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-24-2003 , 01:28 AM






Kalle wrote:
Quote:
Hi,

I have couple of instances running on Linux (9iRel2), now I would like
to do an online backup with RMAN to a disk and schedule it to happen
every night.

I wonder if you have a sample shell script to do this and could you post
it here.

TIA
Kalle

HI


This is CATALOG version...


Best regards
--

www.konsultancIT.pl
Oracle&MS-SQL consulting

run {
sql "alter system archive log current";
allocate channel ch1 type disk;
backup full
format '/oracle/backup_rman/bckF_%s_%p_%d_%u'
(database include current controlfile);
sql "alter system archive log current";
backup
format '/oracle/backup_rman/bckA_%s_%p_%d_%u'
(archivelog all delete input);
}



Reply With Quote
  #3  
Old   
Arcangelo
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-24-2003 , 08:36 AM




"konsultant_1 - konsultancIT.pl" <konsultant_1 (AT) konsultancIT (DOT) pl> wrote in
message news:3EF7EF86.1040605 (AT) konsultancIT (DOT) pl...
Quote:
Kalle wrote:
Hi,

I have couple of instances running on Linux (9iRel2), now I would like
to do an online backup with RMAN to a disk and schedule it to happen
every night.

I wonder if you have a sample shell script to do this and could you post
it here.

TIA
Kalle

HI


This is CATALOG version...


Best regards
--

www.konsultancIT.pl
Oracle&MS-SQL consulting


----------------------------------------------------------------------------
----


Quote:
run {
sql "alter system archive log current";
allocate channel ch1 type disk;
backup full
format '/oracle/backup_rman/bckF_%s_%p_%d_%u'
(database include current controlfile);
sql "alter system archive log current";
backup
format '/oracle/backup_rman/bckA_%s_%p_%d_%u'
(archivelog all delete input);
}


It's also a very out of date version.

You don't need either of the 'alter system archive log current' lines,
because 9i RMAN throws one in for you automatically before beginning the
backup of archivelogs.

You also don't need the 'include current controlfile' line, because in 9i
RMAN, any time you backup something that includes the SYSTEM datafile, RMAN
throws the controlfile into the backup set automatically.

And, since this is 9i RMAN, Oracle is recommending running without a catalog
database these days, and hence the elaborate script you have is a bit
redundant.

To the original poster: all you need, given that you have 9i Release 2, is:

backup database;

For scheduling, try cron, dbms_job or Enterprise Manager.

;-o




Reply With Quote
  #4  
Old   
Brian Peasland
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-24-2003 , 09:32 AM



Quote:
And, since this is 9i RMAN, Oracle is recommending running without a catalog
database these days, and hence the elaborate script you have is a bit
redundant.
Who is recommending to run without a Recovery Catalog in 9i? What did 9i
introduce that does away with the benefits of a Recovery Catalog? Do you
have docs to back this up?

Cheers,
Brian


--
================================================== =================

Brian Peasland
oracle_dba (AT) remove_spam (DOT) peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
the three"


Reply With Quote
  #5  
Old   
George Barbour
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-24-2003 , 10:03 AM




"Arcangelo" <arcangelo-c (AT) yahoo (DOT) com> wrote

Quote:
"konsultant_1 - konsultancIT.pl" <konsultant_1 (AT) konsultancIT (DOT) pl> wrote in
message news:3EF7EF86.1040605 (AT) konsultancIT (DOT) pl...
Kalle wrote:
Hi,

I have couple of instances running on Linux (9iRel2), now I would like
to do an online backup with RMAN to a disk and schedule it to happen
every night.

I wonder if you have a sample shell script to do this and could you
post
it here.

TIA
Kalle

HI


This is CATALOG version...


Best regards
--

www.konsultancIT.pl
Oracle&MS-SQL consulting



--------------------------------------------------------------------------
--
----


run {
sql "alter system archive log current";
allocate channel ch1 type disk;
backup full
format '/oracle/backup_rman/bckF_%s_%p_%d_%u'
(database include current controlfile);
sql "alter system archive log current";
backup
format '/oracle/backup_rman/bckA_%s_%p_%d_%u'
(archivelog all delete input);
}



It's also a very out of date version.

You don't need either of the 'alter system archive log current' lines,
because 9i RMAN throws one in for you automatically before beginning the
backup of archivelogs.

You also don't need the 'include current controlfile' line, because in 9i
RMAN, any time you backup something that includes the SYSTEM datafile,
RMAN
throws the controlfile into the backup set automatically.

And, since this is 9i RMAN, Oracle is recommending running without a
catalog
database these days, and hence the elaborate script you have is a bit
redundant.

To the original poster: all you need, given that you have 9i Release 2,
is:

backup database;

For scheduling, try cron, dbms_job or Enterprise Manager.

;-o


This is absolute nonsense.
George Barbour.





Reply With Quote
  #6  
Old   
konsultant_1 - konsultancIT.pl
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-24-2003 , 12:12 PM



Arcangelo wrote:

Quote:


It's also a very out of date version.

You don't need either of the 'alter system archive log current' lines,
because 9i RMAN throws one in for you automatically before beginning the
backup of archivelogs.

You also don't need the 'include current controlfile' line, because in 9i
RMAN, any time you backup something that includes the SYSTEM datafile, RMAN
throws the controlfile into the backup set automatically.

And, since this is 9i RMAN, Oracle is recommending running without a catalog
database these days, and hence the elaborate script you have is a bit
redundant.

To the original poster: all you need, given that you have 9i Release 2, is:

backup database;

For scheduling, try cron, dbms_job or Enterprise Manager.

;-o


Hi,

Thank you very much for explanation, but my scripts are able
to run on 8.0.x/8.1.x/9.x.x version Oracle RDBMS.
Not only on 9.x.x, ofcourse you can remove the "alter system..."
clause, RMAN9.x.x makes it automatically.


Best regards...
--

www.konsultancIT.pl
Oracle&MS-SQL consulting



Reply With Quote
  #7  
Old   
Volker Hetzer
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-24-2003 , 12:31 PM



Arcangelo wrote:
Quote:
For scheduling, try cron, dbms_job or Enterprise Manager.
I always thought dbms_job can only schedule ps/sql stuff?
Lots of Greetings!
Volker
--
While it is a known fact that programmers
never make mistakes, it is still a good idea
to humor the users by checking for errors at
critical points in your program.
-Robert D. Schneider, "Optimizing INFORMIX
Applications"





Reply With Quote
  #8  
Old   
Arcangelo
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-25-2003 , 06:16 AM




"George Barbour" <gbarbour (AT) csc (DOT) com> wrote

Quote:
This is absolute nonsense.
George Barbour.

Well, don't mince words, George.

Which bits are absolute nonsense.

And why, of course.

;-(




Reply With Quote
  #9  
Old   
Arcangelo
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-25-2003 , 06:29 AM




"Brian Peasland" <oracle_dba (AT) remove_spam (DOT) peasland.com> wrote

Quote:
And, since this is 9i RMAN, Oracle is recommending running without a
catalog
database these days, and hence the elaborate script you have is a bit
redundant.

Who is recommending to run without a Recovery Catalog in 9i?
Oracle is.

Quote:
What did 9i
introduce that does away with the benefits of a Recovery Catalog?
Stored persistent configuration parameters in the controlfile of the target
database. They are read each time a datafile copy or backup command is
issued. Therefore they don't need to be specified at run-time, and therefore
there is no need for long-winded scripts. One of the major reasons for
having a catalog was to permit the storage of scripts. If scripts are no
longer needed, you don't need a catalog.

Quote:
Do you
have docs to back this up?
Try:
http://download-west.oracle.com/docs...ick.htm#442214
(sorry for the wrapping).

The specific bit of interest is:

"In general, Oracle Corporation advises using a catalog when you manage
multiple databases."

Which can also be read to mean 'we don't advise it for a single database'.

And then, later, explicity they say:

"Hence, unless you manage a network of databases, you may choose to avoid
the overhead and use the control file as the exclusive repository of
metadata"

There's also a line in the new features training course material which
states that something along the lines of 'unless your backup requirements
are unusual or complex, we advise not to use a catalog'.

I can dig out the specific reference from that document if you wish, but not
right this minute.

:->





Reply With Quote
  #10  
Old   
Brian Peasland
 
Posts: n/a

Default Re: RMAN sample script for Linux - 06-25-2003 , 09:34 AM



Quote:
"In general, Oracle Corporation advises using a catalog when you manage
multiple databases."

Which can also be read to mean 'we don't advise it for a single database'.
I don't read it that way at all. That's your interpretation of the
sentence. Let me give you a counter example.....A doctor tells you that
if you have multiple warts, you should get them burned off. Does this
mean that if you have a single wart, you should not get it burned off?
Or, using a more mathematical approach, "A implies B" does not equate to
"NOT A implies NOT B". In fact, is it highly possible that "NOT A
implies B".

Quote:
And then, later, explicity they say:

"Hence, unless you manage a network of databases, you may choose to avoid
the overhead and use the control file as the exclusive repository of
metadata"
Notice that your exact quote includes "...you *may* choose...". It does
not say something like "...we recommend...". Even if you manage a
network of databases, you may choose to avoid the overhead and use the
control files as the exclusive repositories of metadata.

I really doubt that you will find any documentation that matches your
blanket statement, "And, since this is 9i RMAN, Oracle is recommending
running without a catalog database these days". Whether or not you use a
Recovery Catalog is dictated by many factors. As can be seen from the 9i
documentation
(http://download-west.oracle.com/docs...ck.htm#442214),
they include a section titled "Deciding Whether to Use RMAN with a
Recovery Catalog". If your statement was true, then this section would
be very short and say that they don't recommend using a Recovery
Catalog. Instead, this section goes into detail on when it is a good
idea to use a Recovery Catalog.

[quote from the docs]
Benefits of Using the Recovery Catalog as the RMAN Repository
When you use a recovery catalog, RMAN can perform a wider variety of
automated backup and recovery functions than when you use the control
file in the target database as the sole repository of metadata. The
following features are available only with a catalog:

You can store metadata about multiple target databases in a single
catalog.
You can store metadata about multiple incarnations of a single target
database in the catalog. Hence, you can restore backups from any
incarnation.
Resynchronizing the recovery catalog at intervals less than the
CONTROL_FILE_RECORD_KEEP_TIME setting, you can keep historical metadata.
You can report the target database schema at a noncurrent time.
You can store RMAN scripts in the recovery catalog.
When restoring and recovering to a time when the database files that
exist in the database are different from the files recorded in the
mounted control file, the recovery catalog specifies which files that
are needed. Without a catalog, you must first restore a control file
backup that lists the correct set of database files.
If the control file is lost and must be restored from backup, and if
persistent configurations have been made to automate the tape channel
allocation, these configurations are still available when the database
is not mounted.
[/quote from the docs]

The docs go further to say

[quote from the docs]
When you use a control file as the RMAN repository, RMAN still functions
effectively. If you do not use a catalog, read the section "Managing the
RMAN Repository Without a Recovery Catalog". Specifically, make sure
you:

Consider the costs of not using a recovery catalog, as described in
"Understanding Catalog-Only Command Restrictions"
Develop a strategy for backing up the repository, as described in
"Backing Up and Restoring the Control File"
[/quote from the docs]



The way I read the docs, it sounds to me like using a Recovery Catalog
has its pros and cons and the DBA should be weigh each when making their
configuration decisions. Blanket statements like "And, since this is 9i
RMAN, Oracle is recommending running without a catalog database these
days" are simply not true.

Cheers,
Brian

--
================================================== =================

Brian Peasland
oracle_dba (AT) remove_spam (DOT) peasland.com

Remove the "remove_spam." from the email address to email me.


"I can give it to you cheap, quick, and good. Now pick two out of
the three"


Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.