Gopal,
As mentioned by Rachel and I agree with her, I do not mess with
"underscore" parameters as a rule. The few exceptions are
parameters like _trace_files_public (to provide read access of
trace files to everyone) and _db_block_hash_buckets (if there is
evidence of cache buffer chain latch contention).
I will most definitely not mess with anything related with "log
block" as it has the "potential" to jeopardise recoverability,
given the right circumstances. One has to research the
dependencies of any "underscore" parameter with other related
parameters before modifying it. It is a risk I am unwilling to
take, unless I absolutely know what the impact of the change is.
Best Regards,
Gaja.
- kgopalakrishnan <kgopalakrishnan_at_mantraonline.com> wrote:
>
> Hi All !
>
>
> Why are we missing the behind the scene parameter
> '_log_block_during_backups=TRUE'?
>
> Is it just because undoc??
>
>
> K Gopalakrishnan
> Bangalore, INDIA
>
>
>
>
> At 11:59 AM 6/20/00 -0800, Gaja Krishna Vaidyanatha wrote:
> >Steve,
> >
> >Yes, I have been involved in an EMC TimeFinder
> implementation.
> >And you are absolutely right on, what you have outlined is
> >exactly what occurs, i.e. put the tablespace in hot backup
> mode,
> >break mirror, end hotbackup mode for tablespace, copy mirror,
> >then resilver broken mirror with other 2 members.
> >
> >The amount of time it takes to re-silver is obviously a
> function
> >of the amount of change that is going on in the database.
> Given
> >that backups are usually done in relatively "lean periods",
> the
> >resilvering should occur very quickly. I have seen
> resilvering
> >time ranging from 45 secs. - 15 minutes, based on write
> volume
> >during the backup.
> >
> >If at all possible, you might want to consider a backup
> solution
> >that deploys triple mirroring and uses RMAN backups. That
> then
> >makes the resilvering time of the mirrors a moot point - at
> >least wrt to hot backups.
> >
> >The 3rd mirror would provide the additional security for a
> true
> >highly available environment, if one of the mirrors fail, and
> >can also be used to support a "read-only reporting database"
> if
> >there is a need for that. This provides segregation of
> >"reports" from online transactions, if needed.
> >
> >Obviously, if you have a "read-only database" supported by a
> 3rd
> >mirror and you resilver on a nightly basis, the time to
> resilver
> >may take longer. But that is not a big deal, as the mirror
> >which was just resilvered, would be broken immediately after
> the
> >resilvering, to prepare for that night's batch report run.
> >
> >You are also right in your comment that the "split-block"
> >problem goes away with RMAN. This is because RMAN reads and
> >writes in "db_block_size" blocking-factor, and thus the
> >split-block problem never occurs. It also performs
> block-level
> >checksumming and verification to ensure that the image of the
> >block it read, is the image that it is actually writing. If
> the
> >block has changed since it read it, it will re-read it and
> this
> >process occurs upto 'n' times for each block read. It is my
> >understanding that the value of n is 16 (trying to remember
> from
> >something I saw 3 years ago). At any rate, that is enough
> >number of iterations to ensure read-and-write-integrity for
> the
> >backups.
> >
> >Plus, the fact that tablespaces are not put into hot backup
> mode
> >while backing them up using RMAN, eliminates the extra redo
> >generation which is now relevant only to hot backups.
> >
> >Best Regards,
> >
> >Gaja.
> >
> >--- Steve Orr <sorr_at_arzoo.com> wrote:
> >> > That's why it is recommended to keep the file in the
> >> hotbackup mode for
> >> the > shortest possible time.That is one tablespace at a
> time.
> >>
> >> Or you can avoid split blocks altogether by using RMAN.
> It's
> >> an on-line
> >> backup vs. the hot backup.
> >>
> >> Regarding reducing the window for tablespaces in backup
> mode,
> >> has anyone
> >> used EMC's TimeFinder? It's a triple mirror where you
> toggle
> >> all the
> >> tablespaces into backup mode, break the mirror, and
> retoggle
> >> the tablespaces
> >> out of backup mode. Supposedly this only takes a few
> seconds.
> >> Then you
> >> backup the broken mirror and resilver it. Any ideas as to
> how
> >> long the
> >> resilvering takes? I'm thinking about using this stuff.
> >>
> >>
> >> Steve Orr
> >>
> >>
> >>
> >> -----Original Message-----
> >> Sanjeev
> >> Sent: Tuesday, June 20, 2000 9:36 AM
> >> To: Multiple recipients of list ORACLE-L
> >>
> >>
> >> I fully agree with this explanation expect that the redo
> >> increases by 100%.
> >> Redo increase depend on the changes made to the block.When
> a
> >> block is
> >> copied to the backup and somebody else make a change to a
> part
> >> of that block
> >> oracle has to write the complete block again because the
> block
> >> is fractured
> >> and
> >> oracle cannot construct the entire block in the advent of
> >> failure, so
> >> whenever a
> >> block gets changed during the hot backup oracle has to
> write
> >> the entire
> >> block to
> >> keep the consistency of the block. So the redo can be
> >> increased by 100% or
> >> can be
> >> by 1000% depending on the type of activity goinig on.
> That's
> >> why it is
> >> recommended
> >> to keep the file in the hotbackup mode for the shortest
> >> possible time.That
> >> is one
> >> tablespace at a time.
> >>
> >> Cheers
> >>
> >> -----Original Message-----
> >> Sent: Tuesday, June 20, 2000 11:25 AM
> >> To: Multiple recipients of list ORACLE-L
> >>
> >>
> >> Well, I will disagree with all of you to a point.
> >>
> >> When a tablespace is put into hot backup mode with the
> "begin
> >> backup"
> >> command
> >> the file headers of all datafiles comprising the tablespace
> >> have their SCN's
> >> locked (if you want to confirm that, take a very quite DB,
> >> alter one
> >> tablespace
> >> and take a look at the datafile date/time stamps. They
> will
> >> be different
> >> from
> >> all other datafiles in the database, very current, and
> equal
> >> to that of the
> >> control file.). If you remember the SCN is Oracle's
> internal
> >> clock used for
> >> insuring a consistent state within the database. This SCN
> >> lock gets
> >> released &
> >> the SCN updated to the current one by the "end backup"
> >> command. Now during
> >> the
> >> intervening time period, dbwr continues to write to the
> file
> >> as normal, but
> >> the
> >> use of redo does increase by 100% since both before and
> after
> >> images of the
> >> data
> >> blocks are being saved. Now, depending on what redo files
> >> your saving it
> >> may
> >> well be a good idea to switch logfiles before starting a
> >> backup. In my case
> >> we
> >> save all of them for one week longer than we save the
> datafile
> >> backups as a
> >> safety net.
> >>
> >> Now, if you need to restore from this hot backup the locked
> >> SCN's will
> >> guarantee
> >> you an inconsistent database, especially if you follow the
> >> Oracle book and
> >> backup the control file LAST (it's SCN never gets locked).
> >> This is why you
> >> always have to roll a hot backup forward, at least until
> the
> >> datafile SCN's
> >> match that of the control file.
> >>
> >> Does the IO load on the computer increase, you bet. But if
> >> you've wisely
> >> chosen
> >> the time of your backup or the size of your backplane/io
> ports
> >> it should not
> >> be
> >> noticeable. Anyway, what's the bother. IO loading is a SA
> >> problem (or so
> >> my SA
> >> tells me).
> >>
> >> Dick Goulet
> >>
> >> ____________________Reply Separator____________________
> >> Author: "William Beilstein" <BeilstWH_at_obg.com>
> >> Date: 6/20/00 5:57 AM
> >>
> >> The following is a quote from my favorite Oracle reference
> >> boot titled
> >> "Oracle
> >> Unleashed, Edition 2" by SAMS Publishing.
> >>
> >> When you place a tablespace in backup mode, the Oracle
> >> instance notes that a
> >> backup is being performed and internally compensates for
> it.
> >> As you know, it
> >> is
> >> impossible to make an authentic copy of a database file
> that
> >> is being
> >> written
> >> to. Upon receipt of the command to begin the backup,
> however,
> >> Oracle ceases
> >> to
> >> make direct changes to the database file. It uses a complex
> >> combination of
> >> rollback segments, buffers, redo logs, and archive logs to
> >> store the data
> >> until
> >> the end backup command is received and the database files
> are
> >> brought back
> >> to
> >> sync. .... What you should understand is that the trade-off
> >> for taking a hot
> >> backup is increased use of rollback segments, redo logs,
> >> archive logs, and
> >> internal buffers within the SGA.
> >>
> >> You must be running the database in Archive mode to perform
> a
> >> hot backup.
> >> Archive logs assure data consistency when backing up only
> >> pieces of a
> >> database
> >> at a time.
> >>
> >> >>> "Eric Lansu" <eric.lansu_at_quicknet.nl> 06/20/00 09:11AM
> >>>
> >> Am I wrong, or am I wrong?
> >>
> >> But as far as I know you have to do a log-switch BEFORE
> >> starting the
> >> HOT-backup, and one AFTER the HOT-backup. The tape
> containing
> >> the
> >> database-files should also contain the archive-log-files
> >> created between the
> >> log-switches. This way you can roll-forward (recover) the
> >> database to the
> >> point-in-time after completion of the backup, and thus
> >> bringing it all in a
> >> consistent state. ( yes, yes, not from a book.... )
> >>
> >> Still the question remains; how can the OS make a copy of a
> >> datafile if
> >> Oracle is still writing in it? Better, how does Oracle know
> >> what to update
> >> after recovery?
> >>
> >> Eric Lansu
> >>
> >> ----- Original Message -----
> >> To: "Multiple recipients of list ORACLE-L"
> >> <ORACLE-L_at_fatcity.com>
> >> Sent: Tuesday, 20 June 2000 11:03
> >>
> >>
> >> > Wow! your explanation is wonderful.
> >> >
> >> > Thanks Rachel.
> >> >
> >> >
> >> > Bhat
> >> >
> >> > -----Original Message-----
> >> > Sent: Tuesday, June 20, 2000 4:19 AM
> >> > To: Multiple recipients of list ORACLE-L
> >> >
> >> >
> >> > Lisa,
> >> >
> >> > I'm sorry but you are wrong. Writes to the datafiles
> >> continue during hot
> >> > backup.....
> >> >
> >> > take a hypothetical situation:
> >> >
> >> > you have 3 redo logs
> >> > you have put every tablespace in your database into hot
> >> backup mode
> >> > you do a LARGE dataload (enough to cycle through all your
> >> redo logs
> >> several
> >> > times)
> >> >
> >> >
> >> > so... if Oracle does NOT write to the datafiles, then the
> >> changes you have
> >> > been making to the blocks get overwritten in the redo
> logs
> >> after the logs
> >> > are archived. Once you take the tablespaces out of backup
> >> mode, given your
> >> > thinking, Oracle would have to then write all the blocks
> to
> >> the database
> >> > files at once. But where would it get them from? The
> >> archived redo logs
> >> are
> >> > NOT re-read, nor are the redo logs.
> >> >
> >> > So...... writing continues to the database files.
> >> >
> >> > Rachel
> >> >
> >> > >From: Lisa_Koivu_at_gelco.com
> >> > >Reply-To: ORACLE-L_at_fatcity.com
> >> > >To: Multiple recipients of list ORACLE-L
> >> <ORACLE-L_at_fatcity.com>
> >> > >Subject: Re: I/O activity during HOT backups
> >> > >Date: Mon, 19 Jun 2000 11:50:37 -0800
> >> > >
> >> > >No! The command below stops all writes to the datafiles
> in
> >> the
> >> tablespace
> >> > >for
> >> > >the duration of the backup, to ensure consistency.
> >> > >
> >> > >The i/o overload I see during backups is the data being
> >> copied out to our
> >> > >backup
> >> > >server. And it is usually very high: like 80% of all
> >> current activity.
> >> > >
> >> > >Lisa
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >Dan.Hubler_at_midata.com on 06/19/2000 01:18:14 PM
> >> > >
> >> > >Please respond to ORACLE-L_at_fatcity.com
> >> > >
> >> > >To: Multiple recipients of list ORACLE-L
> >> <ORACLE-L_at_fatcity.com>
> >> > >cc: (bcc: Lisa Koivu/GELCO)
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >Please settle a discussion amongst our DBA team:
> >> > >
> >> > >Is there ANY I/O that takes place to the database files
> >> (*.DBF)
> >> > >during a HOT backup? (That is, ALTER TABLESPACE BEGIN
> >> BACKUP).
> >> > >
> >> > >If not, how does the process work?
> >> > >
> >> > >Thanks.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >???
> >> > >
> >> > >also send the HELP command for other information (like
> >> subscribing).
> >>
> >> --
> >> Author: Steve Orr
> >> INET: sorr_at_arzoo.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).
> >
> >
> >=====
> >Gaja Krishna Vaidyanatha | gajav_at_yahoo.com
> >Brio Technology | (972)-304-1170
> >
> >"Opinions and views expressed are my own and not of Brio
> Technology"
> >
> >__________________________________________________
> >Do You Yahoo!?
> >Send instant messages with Yahoo! Messenger.
> >http://im.yahoo.com/
> >--
> >Author: Gaja Krishna Vaidyanatha
> > INET: gajav_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).
> >
>
> --
> Author: kgopalakrishnan
> INET: kgopalakrishnan_at_mantraonline.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
Received on Wed Jun 21 2000 - 10:44:49 CDT
