We don’t use the oracle agent to
backup.
We have a script that uses RMAN to backup
to disk.
The same script test to see if the backup
finished ok,
If not email DBA’a that the backup
to disk failed,
If it worked, then the script does a ‘user
backup’ of the disk file/dir to tape
Test if it worked to tape
If not email NB admin that the backup to
tape failed
If it worked email everybody that it
worked.
I don’t think they take the database
down to do the rman backup, but back it up hot.
And yes it does take extra space for the
backup.
But that means I don’t have to buy
the oracle agent from NetBackup or figure out how to configure it.
Means that the DBA’s can control the
backups. Start one if they need, or comment out the crontabs entry if
they don’t want it to start.
I am only reasonable for the part of the script
that does the user backup to tape.
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of Nardello, John
Sent: Tuesday, May 19, 2009 11:15
AM
To: WEAVER, Simon (external)
Cc:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Pre /
Post Scripts on Backup Jobs with Streams
I'd lean towards doing one of two things.
1) Tell them if they
don't want to use the agent, then they have to dump their DB to a flat file and
you'll back that up for them. No worries about the DB being left down that way,
but it can take a unholy amount of space depending on the instance. =) If the
file isn't finished dumping by the time the backup job kicks off, they accept
that they won't get a backup that day.
OR
2) Tell them if they
don't want to use the agent, they have to make arrangements on their side to
put the DB into hot/cold backup mode during 'x' window for the backups to
happen. You'll run the risk of the backup getting out of sync with said window,
but at least the users will always be able to get into the DB at the end of the
window. The business owner would have to sign off on this known risk of course.
Regardless, time to start writing up some
'standard backup options' documentation for upper management to sign off on.
That way the only available options are ones you're okay with supporting, they
don't get to force you into ugly situations like scripting DB start/stops
with multiple child jobs.
- John Nardello
From:
veritas-bu-bounces AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-bounces AT mailman.eng.auburn DOT edu] On Behalf Of WEAVER, Simon (external)
Sent: Tuesday, May 19, 2009 4:48
AM
To: Ed Wilts
Cc:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Pre /
Post Scripts on Backup Jobs with Streams
Ed
the "Oracle" job is not a big
deal, seeing as the Oracle DBA wants this method used, rather than using the
recommended method and supported one! Again, they see it as "Cost
constraints".
I do not see it this way, and although
they have been given the options, its on their own shoulders should it go
wrong.
I have come across many companies that
accept risks .... and in most cases, suffer as a result !
Cannot keep talking to a brick wall if it
is not going to listen ..
Simon
From: Ed Wilts
[mailto:ewilts AT ewilts DOT org]
Sent: Tuesday, May 19, 2009 12:38
PM
To: WEAVER, Simon (external)
Cc:
veritas-bu AT mailman.eng.auburn DOT edu
Subject: Re: [Veritas-bu] Pre /
Post Scripts on Backup Jobs with Streams
On Tue, May 19, 2009 at 1:07 AM, WEAVER, Simon (external) <simon.weaver AT astrium.eads DOT net>
wrote:
I have used "ST" before, not
just for Oracle, but other tasks. There is no real risk here and yes fully
understand why agents are out there, but if the business accept the risk, then
they have to accept the consequences!
When you have multi-streamed jobs, yes, there are real risks. If
every job completes successfully, you could be fine, but if one stream fails,
you could fail to restart Oracle. Or you'll restart Oracle and NetBackup
will restart the stream while Oracle is up. Because you haven't tripped
over the risks does not they aren't there.
The concept of parent jobs didn't get added until 6.0.
It's fine for you to say that business can accept the risk, but it's your job
to get them to understand the risks - their backups will occasionally leave the
database down, or their backups are not available for recovery because a stream
ran with the database up.
Rarely have I see a business unit "accept the consequences"...
This email (including any attachments) may contain confidential and/or privileged information or information otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately, do not copy this message or any attachments and do not use it for any purpose or disclose its content to any person, but delete this message and any attachments from your system. Astrium disclaims any and all liability if this email transmission was virus corrupted, altered or falsified. -o- Astrium Limited, Registered in England and Wales No. 2449259 Registered Office: Gunnels Wood Road, Stevenage, Hertfordshire, SG1 2AS, England |
