Re: quick hot backup question...

"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
> ============================
>

Howard,

I absolutely agree. Someone else wrote in another topic, that it's down to us to "keep the application honest". That seems a good practical philosophy.

Paul Received on Tue Mar 26 2002 - 13:49:30 CST