Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: quick hot backup question...

Re: quick hot backup question...

From: Connor McDonald <connor_mcdonald_at_yahoo.com>
Date: Wed, 27 Mar 2002 22:09:07 +0000
Message-ID: <3CA24303.71F2@yahoo.com>


Howard J. Rogers wrote:
>
> 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!
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >

"which is a swine and a half to set up!"...

ah yes - nice little things like 'startup mount' giving ora-600's when I was trying to upgrade from 8i to 9i - and voila - comment out res mgr in init.ora and hey presto - all is solved!

Cheers
Connor

-- 
==============================
Connor McDonald

http://www.oracledba.co.uk

"Some days you're the pigeon, some days you're the statue..."
Received on Wed Mar 27 2002 - 16:09:07 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US