From: mccmx on
Oracle 10.2.0.3 EE on RHEL 4

I am considering using the following method for application upgrades
in the future:

(N.B. Flashback Logging is Disabled)
1. Shutdown DB
2. Create Guaranteed Restore Point
3. Upgrade application
4. Test application
5. Drop Restore point

I am proposing to use the above method instead of doing a cold backup
before the application upgrade. This will significantly reduce the
downtime required for maintenance and will allow us to restore the
database to a point in time very quickly.

My concerns are:

1. Flashback database is very 'black box'. How can I be 100% sure
that it has flashed back every block consistently. With a cold backup
I am 100% sure that I can copy the files back to the original location
and everything is exactly as it was before the change. If I use
flashback database I am effectively relying on a relatively new
feature that could potentially have bugs. For example, flashback
database failed to reverese a temporary tablespace resize operation on
one of our development databases.

2. Does flashback also reverse changes to all data dictionary
blocks. i.e. can you reverse (or flashback) an Oracle patch..?

From: mccmx on
Anyone actually using flashback database out there....? Or did I
chose a boring topic..?

Matt
From: joel garry on
On Jun 19, 7:25 pm, mc...(a)hotmail.com wrote:
> Anyone actually using flashback database out there....?  Or did I
> chose a boring topic..?
>
> Matt

A very interesting topic, actually. I personally don't have any
experience with it, so I'm not qualified to comment. I certainly
agree with the sentiment about looking at new features with a critical
eye, but I wouldn't want to stop anyone from gaining experience with
it. Just because a gazillion people have used something doesn't mean
your particular configuration won't have issues, either.

I suspect the answer to #2 is that Oracle patches also include
executable components, so you might have issues. Don't the patches
have a documented unpatch?

My own view is paranoia isn't enough. Always have a way out when you
are responsible for production upgrades, preferably so you can fix
stuff before anyone notices you screwed up.

jg
--
@home.com is bogus.
"We were supposed to have 3 days of vendor demos, but so many pulled
out it's just one day now. JDE called and said 'we don't have
anything for your requirements'" - overheard in fast casual
restaurant. I don't know how I keep quiet.
From: DA Morgan on
joel garry wrote:
> On Jun 19, 7:25 pm, mc...(a)hotmail.com wrote:
>> Anyone actually using flashback database out there....? Or did I
>> chose a boring topic..?
>>
>> Matt
>
> A very interesting topic, actually. I personally don't have any
> experience with it, so I'm not qualified to comment. I certainly
> agree with the sentiment about looking at new features with a critical
> eye, but I wouldn't want to stop anyone from gaining experience with
> it. Just because a gazillion people have used something doesn't mean
> your particular configuration won't have issues, either.
>
> I suspect the answer to #2 is that Oracle patches also include
> executable components, so you might have issues. Don't the patches
> have a documented unpatch?
>
> My own view is paranoia isn't enough. Always have a way out when you
> are responsible for production upgrades, preferably so you can fix
> stuff before anyone notices you screwed up.
>
> jg
> --
> @home.com is bogus.
> "We were supposed to have 3 days of vendor demos, but so many pulled
> out it's just one day now. JDE called and said 'we don't have
> anything for your requirements'" - overheard in fast casual
> restaurant. I don't know how I keep quiet.

I use flashback database frequently and often.

Not for Oracle patches ... but rather for application patching and
maintenance.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damorgan(a)x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
From: mccmx on
>
> I use flashback database frequently and often.
>
> Not for Oracle patches ... but rather for application patching and
> maintenance.
> --
> Daniel A. Morgan

thanks for the feedback. Do you have a way of sanity checking that
everything has been 'flashed back'. Are there any v$ views that
contain a list of changed blocks for example.

Do you enable flhasback logging or just rely on guaranteed restore
points...?

Matt