|
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
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
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 |
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
