Re: Time estimate for patches from Oracle

Geez, two months?

If it takes that long, for sure the FileMaker advocates will finally win. I've been battling them for years now. Something like this would give them the ammunition they finally need to drop Oracle.

It's not really flashback, but what they call "flashback archive" (marketing calls it Total Recall), where after I set it up for which tables I want changes tracked, all changes to the data in those tables is recorded. This would save me having to edit a whole slew of triggers.

Anyway, if I now turn that off (and no guarantee that will solve my problem), then I lose all of the table tracking that's been generated this year. But, at least a RMAN backup might save me there.

So it seems I can either:
1. Wait for who knows how long before the database is usable again, possibly with management deciding to finally drop Oracle and go with FileMaker (major Yuck!).
2. Experiment to see if losing all of the data changes this year fixes my the problem.
3. Revert back to 10.2 and lose this years data in case I can't export it back into 10.2.

Not a very heartening set of choices.

Thanks everyone for the input. It's greatly appreciated.

-- 
-- Bill Ferguson

On Mon, Apr 21, 2008 at 1:47 PM, Finn Jorgensen
<finn.oracledba_at_gmail.com> wrote:


> Bill,

>

> The last time I had Oracle create a one-off patch for a bug I encountered it

> took somewhere around 2 months to get it fixed and delivered to me. This is

> despite the fact it was on a production system that crashed every 2 weeks

> due to the problem. This was on 10.2.0.1.

>

> Tell your users the truth, that you can't make it go any faster. It's not

> what they want to hear, but it's not helping anybody that they're banging on

> your door when the problem is off your desk.

>

> Can you workaround the problem a little? You said it was a combination of

> UNDO and flashback. Perhaps you can turn off flashback for the time being?

>

> Finn

>

--
http://www.freelists.org/webpage/oracle-l