Correction: In an earlier email, below, I stated:
... The INCLUDEd RMAN script would be able to tell what policy & schedule name was calling it (both policy & trigger-schedule name are cmd-line params). ... I've just tested this and it's not true - the command line isn't where these values are passed in, they're passed into the script in the form of environmental variables. Here's the list from my test: The variable list from my test is: NB_ORA_CINC=0 NB_ORA_CLASS=<policy name> NB_ORA_CLIENT=<client name> NB_ORA_FULL=1 NB_ORA_INCR=0 NB_ORA_MODE=B NB_ORA_PC_SCHED=<trigger schedule name> NB_ORA_POLICY=<policy name> NB_ORA_SCHEDULED=1 NB_ORA_SERV=<master server name> The NB_ORA_CINC & NB_ORA_INCR seems strange - there's no current full/diff/cumu setting in the trigger schedule's setup. Perhaps this is for future use? Sorry, I should've checked this first. -M -----Original Message----- From: Donaldson, Mark - Broomfield, CO In my opinion, the DBA's have absolutely no need to have access to the admin console. You could backup every database to one policy if you with, there's not need for a 1:1 or 2:1 ration of policies to database instances. You'll need at least a 1:1 ratio if you're using Netbackup as the scheduler for the backups (cold backups or no special archived redo treatment). You'll probably want 2:1 ratio if you're doing hot backups and backing up archived redo logs on a different schedule than the data files. Here's how we do it. For (hot) data backups, we call the RMAN data-backup script. We use the Netbackup scheduler for this. The policy for this looks like this: Policy Name: P_AT-01_RM_Hot_oraclesid Policy Type: Oracle Active: yes Effective date: 06/09/2003 13:42:30 Block Incremental: no Mult. Data Streams: no Client Encrypt: no Checkpoint: no Policy Priority: 5 Max Jobs/Policy: Unlimited Disaster Recovery: 0 Residence: LTO2_Group Volume Pool: Oracle Keyword: (none specified) HW/OS/Client: RS6000 AIX5 at-01 Include: /opt/apps/oracle/admin/scripts/backupdb.sh Schedule: Automatic_Scheduled_Backup Type: Automatic Full Backup Frequency: every 1 day Maximum MPX: 4 Synthetic: 0 PFI Recovery: 0 Retention Level: 3 (1 month) Number Copies: 1 Fail on Error: 0 Residence: (specific storage unit not required) Volume Pool: (same as policy volume pool) Daily Windows: Sunday 19:00:00 --> Sunday 23:00:00 Schedule: DATASCHED Type: Application Backup Maximum MPX: 4 Synthetic: 0 PFI Recovery: 0 Retention Level: 3 (1 month) Number Copies: 1 Fail on Error: 0 Residence: (specific storage unit not required) Volume Pool: (same as policy volume pool) Daily Windows: Sunday 00:00:00 --> Sunday 24:00:00 Monday 00:00:00 --> Monday 24:00:00 Tuesday 00:00:00 --> Tuesday 24:00:00 Wednesday 00:00:00 --> Wednesday 24:00:00 Thursday 00:00:00 --> Thursday 24:00:00 Friday 00:00:00 --> Friday 24:00:00 Saturday 00:00:00 --> Saturday 24:00:00 OK, then. The policy type is Oracle - no surpise there. Everything else in the general policy attributes is pretty much self explanatory - nothing special here. The Automatic_Scheduled_Backup schedule is what I call the "trigger schedule", the NB schedule type is "Automatic Full Backup". This is the schedule that will run the RMAN backup script on the at-01 client. The RMAN backup script on the client is the one on the INCLUDE line. The script knows what this policy name is (it comes in as a command-line parameter) or it could have the policy name hard-coded somewhere in the script. When the RMAN script is run is controlled by the standard scheduling windows for that schedule. The other schedule is the one that recieves the data blocks from oracle, schedule type "Application Backup". It has a 7x24 schedule because we want to receive the data blocks whenever they're sent. This way, the DBA's can run their RMAN script on demand, bypassing the trigger schedule, and the policy is capable of recieving the blocks whenever they're sent. This give the DBA's a large level of control on their backups without actually giving them control of Netbackup. (This is actually a simplified printout, we have different schedules for RMAN Full & Incremental backups. The choice of full & incremental is left up to the RMAN script {based on day-of-week} and it chooses the schedule name appropriate for that type of backup. The reason for two schedules to receive the data blocks is that full backups on production databases use inline-tape-copy to create two copies, one for offsite. Incrementals are not duplicated. The policy above is for a test environment database so it really doesn't need different schedules for full vs. incremental. Without this need to treat fulls and incrementals differently, this could be done with only a single "Application Backup" type schedule.) Each hot backup has a sister policy for the archived redo backups. The trigger schedule for these is set to run every 6 hours, three times a day, to backup the archived-redo (6-hour freq on a 13-hour window), calling a specific backup script for RMAN archived redo. They also have an "application backup" schedule to receive the blocks from the archived redo. We have threshold monitors on the archived-redo filesystems that can call the archived-redo script if the filesystems get too full. This prevents the filesystem from overfilling if we have a hot hour of activity. The reason for separate Hot & Archive policies is historical and I just can't get the DBA's to rewrite their backup script. Here's how I'd do it today, starting from scratch. Hot backups, using Netbackup as the scheduling agent. Each database would have a single policy. Each policy would have two trigger schedule types, one for data, one for archived-redo. There would be three "application backups" (data receiving schedules). One for full backups, one for incrementals, & one for archived redo. The INCLUDEd RMAN script would be able to tell what policy & schedule name was calling it (both policy & trigger-schedule name are cmd-line params). The policy name set in the RMAN script for NB_ORA_POLICY would be the policy from the command-line. The schedule set for NB_ORA_SCHED (recieving the data blocks from RMAN) would be chosen based on the trigger schedule name (also on the command-line). If the trigger schedule was the data backup, choose either the FULL or INCR schedule based on whatever params the DBA's code into the script. If the trigger sched was the archive-redo backup, then choose the archive redo schedule. This would allow you to write archived redo to a different tape pool than data blocks (a good idea, IMO) and still allow the flexibility to treat full oracle backups diffently than incrementals. A different shop I worked in had the DBA's scheduling their database backups whenever they wanted via cron. We had some handshake deals to keep them from bombarding the server but they had full control of their schedules. I this case, oracle's crontab ran the backup script for each instance when they wanted. I could use one NB policy in total, with two "application backup" schedules in it. Each backup script sent its data to the same policy name. The two schedules were, again, one for data & one for redo, the backup script specified the schedule name appropriate to the type of backup intended. I used the two schedules to write the data to a different pool than redo - same "good idea" as above. This one policy handled multiple servers by simply having more than one client in the allowed client list. Since I wasn't triggering the backup, I didn't have to segragate my policy by client & sid. Well - hope this all helps. Keep your DBA's out of your console! -M -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, January 13, 2006 6:12 AM To: veritas-bu@mailman.eng.auburn.edu Cc: [EMAIL PROTECTED] Subject: [Veritas-bu] RE: Oracle RAC backups I have shown the DBA's how to initiate backup and restore using the client software, jbpSA, the windows Backup Archive and Restore utility and command line options too. The DBA team finds these methods unacceptable, and want access to the NBU console. The DBA's are used to having access to the Admin Console on the product they currently use. Their environment is exclusively Oracle running on Unix, while the NBU environment is all Intel which is a lot more heterogenous with multiple operating systems, databases, email and clustered servers. The policy and scheduling is relatively more complex than the Unix environment. Only the data recovery team has access to NBU. I am still trying to understand the options for Oracle Policy configurations. I have currently configured a policy using the Oracle Template Wizard on the client. It seems that if using templates you have to limit each policy to 1 client and 1 template. That would mean at least 2 policies per database. Vincent Mase _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu _______________________________________________ Veritas-bu maillist - Veritas-bu@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu