Szymon is right, you don't have to use the SYS password. I would make a
few modifications to the script, though. I do not recommend using su -
oracle, as that calls Oracle's environment. I understand that this was
to get variables like ORACLE_HOME, etc. However, it can also have very
weird consequences in a number of circumstances. Consider, for example,
what would happen if the DBAs prefer csh as their shell. I prefer
instead to specify the variable I need in the script. I get ORACLE_HOME
from the oratab file based on the instance I'm backing up, then I create
everything else from there. (Yes I believe anything worth backing up is
worth having in the oratab file. I tell the DBAs if it's not in oratab,
it ain't getting backed up. ;) )
I also prefer specifying the rman catalog password inside the rman
script, rather than in the command that's calling the rman script. That
way it doesn't show up on a ps listing. You can do this by putting
"connect catalog userid/passwd@rman_sid;" as the first line in the rman
script.
Here's a couple of other tidbits...
Yes, you can use rman without a recovery catalog. In fact, looking at
the release notes even shows that Oracle continues to enhance what you
can do without a catalog. If you don't use a catalog, rman data is
stored in the controlfile. Storing your recovery information inside the
thing you want to recover is never a good idea. It would be much better
to have a centralized recovery catalog that contains all the recovery
information for all instances. It's also a good idea if this catalog is
on a different server than any of the databases it is tracking.
It's also much easier to create the catalog now by just using the create
catalog command in rman. Large environments might want to use more than
one rman catalog, and back up each of those catalogs using an rman
instance that's connected to the other catalog. You might also consider
performing a hot or cold backup of the rman catalog by some method that
doesn't use rman.
Always keep a record of your DBID. This may come in very handy if you
lose your control file, , especially if you have multiple databases with
the same name.
Create persistent parameters (since 9i)
Now you can create persistent values for things like automatic channels,
channel parallelism, retention policies, backups options, etc. (They
are stored in your recovery catalog, and can be accessed and used by any
instance using that catalog.) Each persistent parameter that you create
is one less parameter that you have to specify on the command line. The
ultimate goal here is that you would simply be able to tell rman to
backup database, and everything else would come from these parameters.
The parameters that can be set persistently can be viewed by using the
show all command in an rman session. It will list all of parameters,
and show you which of them you have customized, and which of them are
still set to the default values. The following is the example shown in
Oracle's documentation.
RMAN> show all;
RMAN configuration parameters are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1; # default
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP OFF; # default
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; #
default
CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; #
default
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO
'/oracle/product/10.2.0/db_1/dbs/snapcf_orcl.f'; # default
Using persistent parameters will greatly simply your rman scripts. To
create or modify these parameters, simply connect to rman and issue
commands like those shown here:
RMAN> CONFIGURE BACKUP OPTIMIZATION ON;
RMAN> CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON;
---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Szymon Madej
Sent: Friday, January 11, 2008 7:14 AM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] can i avoid use of SYS password for RMAN
scripts?
Hello!
I'm new to this list (and to the NetWorker too), so I say 'Hello' to
everybody. I was using TSM previously, but my current employee uses
NetWorker.
The answer for your question Mark is yes, you can avoid SYS password in
scripts, but you can't avoid password to Recovery Catalog user if you
are
using it.
I'm assuming that you want to backup Oracle databases in UNIX
environment
(you mentioned 'root' user). NetWorker uses a root account to run
scripts,
but you can write a wrapper script ie:
#!/bin/bash
### Run RMAN backup script as oracle user.
su - oracle -c /nsr/rman/backup_rman.sh
### If script returns OK, call save.
SCRIPT_RESULT=$?
if [ ${SCRIPT_RESULT} -eq 0 ]; then
save $@
fi
In my environment /nsr/rman/backup_rman.sh script call RMAN with:
rman target / catalog rman/catalog_pass@RMANCATALOG cmdfile
/nsr/rman/backup.rman
In my case I use Recovery Catalog, so I must provide a user/password to
Recovery Catalog database, but If you use control files instead Recovery
Catalog there is no need to put it there.
Best regards
Szymon Madej
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
