-
Hi All,
I talked to lot of people reg the subject.
Many says that RMAN is an overhead and it is better to write your own scripts to backup ur database.
What do u say.
How one should go about it.
--------------------------
The Time has come ....
-
Going by the book,
If you have more than 5 databases to manage then using RMAN is a wiser approach.
There Nothing You cannot Do, The problem is HOW.
-
The thing I like about RMAN in a large environment is that the interface is universal. You don't have to worry if your DBAs know ksh, perl, or batch files. If they know RMAN scripting, the platform is irrelevent (mostly).
Jeff Hunter
-
Originally posted by marist89
The thing I like about RMAN in a large environment is that the interface is universal. You don't have to worry if your DBAs know ksh, perl, or batch files. If they know RMAN scripting, the platform is irrelevent (mostly).
I agree. Here are 10 good reasons why to use RMAN:
Why RMAN:
1. Stored scripts executable from PL/SQL
2. Backups only changed blocks
3. Ease of automating backups & recovery
4. Logs of B&R
5. Parallel backup
6. Definitions of conditions for B&R
7. Compression of unused blocks
8. Recovery Catalog
9. Less need of DBVERIFY, DB_BLOCK_CHECKING, DB_BLOCK_CHECKSUM
10. No redo log overhead
-
Originally posted by julian
1. Stored scripts executable from PL/SQL
I was not aware of this. How do you execute a RMAN script from PL/SQL?
Jeff Hunter
-
Originally posted by marist89
Originally posted by julian
1. Stored scripts executable from PL/SQL
I was not aware of this. How do you execute a RMAN script from PL/SQL?
I do not know, never tried. However, this is claimed on Page 822 of Couchman's OCP 8i guide.
-
Another good reason It is completly automated .
No user intervension no errors .
If your database is say 200GB with about 100-125 datafiles .Rman will keep a track on everything .RMAN will do 99% work .the 1% work is to write the correct scripts and to execute the correct scripts at the right time .
That's it .
Radhakrishnan.M
-
What they mean by stored script was that you can do the
allocate_channel.rcv:
create script allocate_1_channel {
allocate channel t1 type 'disk';
release channel t1;
}
then you can login to rman and execute the script once,
RMAN> @allocate_channel.rcv
Then you can call the same script recursively for any number of times, like a stored procedure....
RMAN> run { execute script allocate_1_channel; }
---------------------------------------------------------
The good thing was that Oracle is going to mandate it as the form of backup as of 9i. Then recovery is painless (unless you do something stupid, "very rare") Good tool for doing the hot backups. Duplication is easy. Good for a large scale database backup administration.
One huge disadvantage is table recovery. Which is not that easy using RMAN.
Sam
Thanx
Sam
Life is a journey, not a destination!
-
From the post, I assumed that the poster meant you could call your stored scripts from PL/SQL (which would be cool!). In this case, something like:
dbms_rman.execute_script('allocate_1_channel')
No?
Jeff Hunter
-
No. Thats not possible. When you create the script using create script, oracle would use the PLSQL to create the scripts and update the appropriate tables. Then when to get to call the scripts, oracle would us the plsql to fetch the appropriate commands from the appropriate RC tables and views to keep the operation in sync. This is what my 2c about it.
Sam
Thanx
Sam
Life is a journey, not a destination!
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|