Re: quick hot backup question...

you think my junior dba has the system password? ;o)

> I also get a bit queasy about such important database management matters
> (who can connect and/or when) being left to the tender mercies of
> application code (and the developers who have to write it).

good point, i guess in this circumstance people could bounce db and startup restrict after the lsnr is down, but yes malicious stuff could get in... could always stop dba's from drinking?

> or use the 9i quiescing feature.

hmm that sounds fun tell me more...

--
Regards,

Daniel.


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


> I don't know how you can disagree, since it's not a matter of opinion but

> basic physics!  If the database is up and running, one cannot 100%

guarantee


> that an extra transaction or three will not take place.  The database is

> open, therefore it can accept connections.

>

> Now you might prevent those connections by locking your application down

as


> you describe, but I, as a disgruntled employee, have been taking evening

> classes in SQL*Plus.  How are you going to stop me connecting?  Database

> logons and security?  Well, I happened to get your Junior DBA drunk the

> other night, so I know what SYSTEM's password is.  And so on: you get the

> point, I hope.  Yes, you can build all sorts of protections in to say 'I

> know that no-one can do transactions', but the only way you can be 100%

> sure, under all circumstances and all situations, is for the database not

to


> permit connections by not actually running.  Even killing the Listener

won't


> do it, because whilst the junior DBA was nursing his hangover, I happened

to


> lift his security pass to the Server Room.

>

> So I don't doubt that *you* have things locked down, and get the

reassurance


> you need about the state of play on the database, but that's you and your

> specifics, which no doubt are perfectly valid for you in your specific

> environment:  but *in principle* if the database is up, one cannot

guarantee


> that no further transactions are permissible or have not occurred or can

be


> prevented.

>

> Not unless you want to make it read only, of course, or use the 9i

quiescing


> feature.

>

> I'm trying to be as generic as possible here, because you weren't the one

> asking the original question, so the specifics of how specifically you

(and


> your app, of course) gain the assurances you need might not necessarily

> apply in all cases.

>

> I also get a bit queasy about such important database management matters

> (who can connect and/or when) being left to the tender mercies of

> application code (and the developers who have to write it).

>

> Regards

> HJR

> --

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

> Resources for Oracle : www.hjrdba.com

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

>

>

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

> news:a7oaca$h2g$1_at_newsg4.svr.pol.co.uk...

> > > 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 th

e


> > > > 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!

> > > > > >

> > > > > >

> > > > >

> > > > >

> > > >

> > > >

> > >

> > >

> >

> >

>

>