--On Tuesday, January 21, 2003 11:03 AM -0500 Davina Treiber <treiber AT HOTPOP
DOT COM> wrote:
On Tue, 21 Jan 2003 15:41:52 -0000, Wood, R A (Bob)
<WoodR AT CHEVRONTEXACO DOT COM> wrote:
Just a quick question on this.
Do you want your backups to start if the tmp file is there? The tmp file
is there because something didn't work OK, right? Are you concerned
about that?
Yes you should be concerned, because what it means is that the last backup
failed in some way. Perhaps the client crashed during the backup or the
group was aborted in some particularly nasty way. By now it is too late to
worry about. So yes, you do want your backup to start - even more so since
your last one probably failed.
However, it's worse than that - the backup will always start, but if the tmp
file is there it will not run the pre/post commands, and won't tell you
about it (unless you count the pointless messages in 6.1.2 and 6.1.3 which
appear even when all is well). If you were counting on a database being
stopped in order to get a consistent backup you can forget it.
I think the tmp file is useful to allow end users (database administrator or
application
administrators) to hold their backup. I completely understand that if this
file is there then the
pre/post commands are not run, but that is the point of the file. The DBA or
Application owner
wanted the processes not to stop because they were doing something that would
be affected by this.
Take this example. An application owner prepares a large batch job to import
stuff into their
application and the underlying Oracle Database. Before his job run, he creates
the tmp file so the
database is not shutdown therefore aborting his import and possibly corrupting
the database (or a
text based index file in this particular application). Now my backup comes
around to run and does
not execute the pre/post commands as the file exists so I do not get a clean
backup of the
database, but I DO get a backup.
How am I notified? Easily, Networker tells me in its savegroup notification
that redo logs or
database files changed size during backup. This means my backup was not
successful and I need to
investigate as to why. So I disagree that Networker will not notify you (it
certainly does not
specifically tell you that the Oracle database was up during backup...)
Lastly, if the night before backup was successful and last nights backup gives me
"file changed
size" error I can still recover the database. Running a database in archive
log mode will create
archive logs when the redo logs switch. I can recover the last successful
backup (2 nights ago)
and replay the archive logs and current redo log to get a point in time
recovery.
So as you can see, under certain circumstances this is very useful. I agree
Networker should do a
better job of telling you that the backup failed or the pre/post commands were
not run.
My thoughts.
Christopher T. Beers - UNIX Systems Engineer
Syracuse University - Computing and Media Services
250 Machinery Hall Syracuse, NY 13244
(315) 443-4103 Office (315) 443-1621 Fax
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
