Re: quick hot backup question...

It's not fun really... because it all depends on you signing up to use the Resource Manager feature (which is a swine and a half to set up!). In 9i, they supply a resource manager plan that basically says: if SYS or SYSTEM, then 100% of the CPU, otherwise 0% of the CPU. And if you've got no CPU, you can't do any work. So you stay connected to a fully read-write database, and your existing transactions are permitted to finish, but you can't start any new ones.

'alter system quiesce restricted' and 'alter system unquiesce' are the commands (from memory).

But you must have been using resource manager since instance startup and without interruption otherwise it doesn't work.

Regards
HJR

--
------------------------------------------
Resources for Oracle : www.hjrdba.com
============================


"daniel" <test_at_test.com> wrote in message
news:a7rb8g$dn8$1_at_newsg4.svr.pol.co.uk...


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

> > > > > > >

> > > > > > >

> > > > > >

> > > > > >

> > > > >

> > > > >

> > > >

> > > >

> > >

> > >

> >

> >

>

>