Re: quick hot backup question...

> I'd have to question why anybody who can guarantee that no further
> transactions are taking place because 'user activity stops at close of
> business hours' is bothering to take hot backups in the first place!

well I want the database up so as to do batch work, i have a system where the days statement runs are done over night and the printing process of the statements need to do a select on the database, also i refresh a business reporting database over night by selecting from said database... thus i need the database up and need to back it up!

the users can be stopped from changing any data after a certain time via the application untill the next day...

> In principle, if the database is hot, then you cannot "know" that the log
> contains the last transaction,

yes you can... well maybe not the last tx but the last business user tx at least

> because anybody suffering from a bout of
> insomnia could log on and start doing DML.

as above this is handled and enforced via the app

> You might get away with it 99.9% of the time, but the principle is not
sound.

disagree...

--
Regards,

Daniel.


"Howard J. Rogers" <dba_at_hjrdba.com> wrote in message
news:a7o81g$389$1_at_lust.ihug.co.nz...


> Comment below.

> HJR

> --

> ------------------------------------------

> Resources for Oracle : www.hjrdba.com

> ============================

>

> "daniel" <test_at_test.com> wrote in message

> news:a7o6m5$nap$1_at_news7.svr.pol.co.uk...

> > > Lots of people do it, and I've never really understood why.

> >

> > maybe they want to differentiate between the two types of redo that can

be


> > written? just a guess...

> >

> > however sometimes in a system where user activity stops at close of

> business

> > hours then it would be really easy to recover to that log seq num

knowing


> it

> > contains the last business tx's, but no overnight stuff like batch etc

> > etc...

>

> I'd have to question why anybody who can guarantee that no further

> transactions are taking place because 'user activity stops at close of

> business hours' is bothering to take hot backups in the first place!

>

> In principle, if the database is hot, then you cannot "know" that the log

> contains the last transaction, because anybody suffering from a bout of

> insomnia could log on and start doing DML. You might get away with it

99.9%


> of the time, but the principle is not sound.

>

> HJR

>

>

> >

> > it is also very handy to refresh a test system from this without the

need


> > for time based or scn based recovery, again knowing its a capture of the

> > data at close of play.

> >

> > > The other thing that mystifies me about forcing a log switch in order

to


> > get

> > > an archive of the current log is that it only makes another log the

> > current

> > > log.

> >

> > agreed, but it can be used as an easy marker and/or punting it off to

the


> > standby server if thats the setup, there's a stack more reasons why you

> may

> > want to do it but i won't bore you with them...

> >

> > :O)

> >

> >

> > --

> > Regards,

> >

> > Daniel.

> >

> >

> > "Howard J. Rogers" <dba_at_hjrdba.com> wrote in message

> > news:a7o4ju$vfn$1_at_lust.ihug.co.nz...

> > > If you're doing O/S online backups, then there's no need for a

> preliminary

> > > checkpoint, because that's precisely what the 'begin backup' command

> > forces

> > > (at least for the datafiles of the tablespace involved).

> > >

> > > The one about a preliminary log switch (presumably because you are

about


> > to

> > > copy the archives) is always a curious one.  Lots of people do it, and

> > I've

> > > never really understood why.  Usually the justification is that

without


> > it,

> > > you are short of the current redo log, so you may lose data.  There's

> > > something to that, I suppose.  But it's also usually (so I find)

because


> > > people view a backup as an isolated event, whereas the truth of the

> matter

> > > is, of course, that what you don't backup tonight you will backup

> > tomorrow.

> > > So if there's a bit of current redo left unbacked up, who cares??

> You'll

> > > get it when tomorrow's backup is performed, and in the meantime

there's


> no

> > > possible risk of data loss because you've multiplexed your online redo

> > logs,

> > > and then mirrored them with hardware RAID.  Haven't you?? ;-)

> > >

> > > The other thing that mystifies me about forcing a log switch in order

to


> > get

> > > an archive of the current log is that it only makes another log the

> > current

> > > log.  So you can *never* really be completely and utterly up-to-date

> with

> > > redo copies, unless you stop all your users doing things: there'll

> always

> > be

> > > a new piece of current redo which you haven't backed up today.  Hence

> cold

> > > backups, of course.

> > >

> > > That said, a log switch does no real harm -except induce a

> > > performance-hitting checkpoint.

> > >

> > > Regards

> > > HJR

> > > --

> > > ------------------------------------------

> > > Resources for Oracle : www.hjrdba.com

> > > ============================

> > >

> > > "Glen A Stromquist" <gstromquist_at_nospamyahoo.com> wrote in message

> > > news:jpMn8.11561$EV.366849_at_news1.telusplanet.net...

> > > > In my online backup scripts I don't do a logfile switch or force a

> > > > checkpoint before copying the datafiles.

> > > >

> > > > Is this  recommended by Oracle?

> > > >

> > > > I'm wondering if I overlooked something when writing my scripts, I

> have

> > > used

> > > > my online backups on occasion to create a clone db, so I know they

> > "work"

> > > > the way I'm doing it now, but I guess  it can't hurt to build in a

> > logfile

> > > > switch and/or force a checkpoint as part of the script as well.

> > > >

> > > > Curious to hear what others do regarding this....

> > > >

> > > >

> > > > cheers!

> > > >

> > > >

> > >

> > >

> >

> >

>

>