.....which is precisely the reason that if there is a crash during a hot
backup, all we need
to do is issue the command 'alter database datafile '<name>' end backup'
which updates only
the file header......the contents of the datafile need not b updated since
they r ALREADY
updated while the hot backup was in progress.
Samir
Samir Sarkar
Oracle DBA - Lennon Team
SchlumbergerSema
Email : samir.sarkar_at_nottingham.sema.slb.com
samir.sarkar_at_sema.co.uk
Phone : +44 (0) 115 - 957 6217
EPABX : +44 (0) 115 - 957 6418 Ext. 76217
Fax : +44 (0) 115 - 957 6018
-----Original Message-----
Sent: 28 January 2002 13:46
To: Multiple recipients of list ORACLE-L
EXCUSE ME???????????????
And just HOW do you think Oracle manages to maintain changes to
database blocks within the datafiles of that tablespace when it is in
hot backup mode if nothing is written to the tablespace? The only thing
that is frozen is the SCN in the datafile header. Oracle continues to
flush dirty blocks down to the disk.
I am so sick and tired of seeing supposedly knowledgeable DBAs
propagating this totally FALSE information.
For a definitive explanation of why this is wrong....
http://www.speakeasy.org/~jwilton/oracle/hot-backup.html
- אדר_יחיאל <adary_at_mehish.co.il> wrote:
> I seem to miss something here.
> We are talking about backups that run after: alter tablespace XXX
> begin
> backup.
> There are no writes to the tablespace in this situation.
>
>
> Yechiel Adar, Mehish Computer Services
> adary_at_mehish.co.il
>
> > -----Original Message-----
> > From: Thomas B. Cox [SMTP:tbcox23_at_yahoo.com]
> > Sent: Mon, January 28, 2002 6:35 AM
> > To: Multiple recipients of list ORACLE-L
> > Subject: COPY vs. OCOPY on NT
> >
> >
> > Your point is (I believe) that the Oracle data files are
> > opened writeable by Oracle at instance startup time. When
> > you use the NT command "COPY" it will prevent additional
> > writers, but not those writers that are already holding
> > write locks.
> >
> > My comments and questions are:
> >
> > 1. This used to fail with an error in previous versions
> > of Oracle and NT that I've worked with.
> >
> > 2. I'd be curious if multiple DB writers could cause
> > a problem with your setup.
> >
> > 3. If a COPY fails/dies holding its lock, can I re-start
> > either the COPY of Oracle without rebooting or manually
> > clearing the lock?
> >
> > 4. You have demonstrated that the statement "COPY will
> > always fail" is false. But we're not yet at "COPY will
> > always work" -- and that could be a problem.
> >
> > Cheers.
> > -Tom
> >
> >
> > --- Igor Neyman <ineyman_at_perceptron.com> wrote:
> > > Now, from my other message to the list (don't know, if Eric
> forwarded
> > > it to
> > > you), it answers your questions about my experience recovering
> from
> > > online
> > > backup and why I don't like MetaLink Note explanation in regard
> to
> > > advantages of "Ocopy" versus "Copy":
> > >
> > > <quote>
> > > Couple years ago, when we were preparing first release of our
> > > product, I
> > > read of course about "NT Copy" versus "Oracle Ocopy".
> > > Still I decided to test it, because not always I trust what I
> read,
> > > and I
> > > like to get proof myself.
> > > Testing of online ("hot") backup/recovery scenario showed, that
> using
> > > "NT
> > > Copy" command in backup scripts is perfectly fine, when creating
> > > backup set
> > > of files on the disk. And there is no problem restoring from
> this
> > > backup.
> > > Now this "disk backup" set of files could be saved on tape, using
> > > NTBACKUP
> > > (that's the one, that really can not copy file, if it's opened by
> > > some other
> > > program. But that's not the case with prepared in advance "disk
> > > backup").
> > > "NT Copy" has no problems copying files opened already by Oracle,
> and
> > > backup
> > > is consistent, as long of course as I am using "alter tablespace
> > > <name>
> > > begin backup" before copying relevant files and "alter tablespace
> > > <name> end
> > > backup" after finishing files copy.
> > > So, those scripts (using "NT Copy") were put into production, and
> now
> > > have
> > > been used for more than two years on more than hundred
> > > installations/sites
> > > (the number keeps growing).
> > > From time to time, our field engineers are bringing back to me
> sets
> > > of
> > > online (can not use "cold" backup - our systems should run 24*7,
> I'm
> > > not
> > > saying they are, but we are trying to minimize downtime) backed
> up
> > > files (db
> > > files and archived RedoLog files), and I recover them with no
> problem
> > > (we
> > > need this, to test how the upgrade to next release of our product
> > > will run
> > > against "real" customers data).
> > >
> > > Now, about MetaLink Note:139327.1
> > > It says:
> > > <inner_quote>
> > > Ocopy opens the file using CreateFile() with the FILE_SHARE_READ
> and
> > > FILE_SHARE_WRITE flags. This allows writing to continue while we
> > > take the
> > > backup. Inconsistencies in the backup are repaired by applying
> > > archived
> > > redo during recovery. The 'copy' command from NT doesn't use
> these
> > > flags
> > > since it wants to prevent writes to the file while the copy is
> > > taking
> > > place.
> > > </inner_quote>
> > >
> > > I don't think, it's very accurate, and here is why:
> > > When during online backup I run "NT copy" against db file, the
> file
> > > is
> > > already opened by Oracle (at moment, when I "open" the database).
> > > So, even if "NT copy" opens file without FILE_SHARE_READ and
> > > FILE_SHARE_WRITE flags, all it means is that "Subsequent open
> > > operations on
> > > the object will fail" (quote from NT docs). I want you to
> notice, it
> > > says
> > > "Subsequent open operations" not "Subsequent write/read
> operations".
> > > So,
> > > all it does is prohibiting some other program/process from
> "opening"
> > > the
> > > file. But Oracle, as I mentioned, has this file already opened,
> and
> > > it is
> > > perfectly capable of reading/writing this file.
> > > Of course, the image of the saved file will be "fuzzy", and
> that's
> > > why when
> > > recovering from online backup we are applying archived RedoLog
> files
> > > (which
> > > getting written much more intensely during online backup).
> > > </quote>
> > >
> > > And yes, I agree about Oracle (un-)support.
> > >
> > > Igor Neyman, OCP DBA
> > > ineyman_at_perceptron.com
> > >
> > >
> > > ----- Original Message -----
> > > From: "Thomas B. Cox" <tbcox23_at_yahoo.com>
> > > To: <PierceED_at_csus.edu>
> > > Cc: <ineyman_at_perceptron.com>
> > > Sent: Friday, January 25, 2002 3:38 PM
> > > Subject: Re: ORACLE-L Digest -- Volume 2002, Number 025
> > >
> > >
> > > >
> > > > Could one of you forward this to your list? I'm not a
> subscriber.
> > > >
> > > > Also, I'm very curious if Igor can recover from his COPY hot
> > > > backups, and if so, whether Oracle Support might actually be
> > > > wrong.
> > > >
> > > > If nothing else, one might want to use OCOPY in order
> > > > to get Oracle support in the case something goes wrong. I
> > > > doubt they'd be able to help if one used an unsupported backup
> > > > approach...
> > > >
> > > > Thanks.
> > > > -Tom
> > > >
> > > > --- "Thomas B. Cox" <tbcox23_at_yahoo.com> wrote:
> > > > >
> > > > > I gave the right advice for the wrong reasons. My bad. I'll
> > > revise
> > > > > the next release of the paper and credit Igor -- thanks.
> > > > >
> > > > > Here's the word from Oracle Support:
> > > > >
> > > > >
> > > > > Doc ID: Note:139327.1
> > > > >
> > > > > The Differences between Windows NT COPY and Oracle OCOPY When
> > > Doing
> > > > > Backups:
> > > > >
> > > >
> > >
> >
>
>
=== message truncated ===
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
INET: wisernet100_at_yahoo.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
___________________________________________________________________________
This email is confidential and intended solely for the use of the
individual to whom it is addressed. Any views or opinions presented are
solely those of the author and do not necessarily represent those of
SchlumbergerSema.
If you are not the intended recipient, be advised that you have received this
email in error and that any use, dissemination, forwarding, printing, or
copying of this email is strictly prohibited.
If you have received this email in error please notify the SchlumbergerSema Helpdesk
by telephone on +44 (0) 121 627 5600.
___________________________________________________________________________
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: SARKAR, Samir
INET: Samir.SARKAR_at_nottingham.sema.slb.com
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Mon Jan 28 2002 - 09:50:45 CST
