Wow. One day I'll learn to type.
-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of
Mark.Donaldson AT cexp DOT com
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 wish, there's no 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: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu]On Behalf Of
Vincent_Mase AT harvardpilgrim DOT org
Sent: Friday, January 13, 2006 6:12 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Cc: tech2187 AT yahoo DOT com
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 AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
