Re: Time estimate for patches from Oracle

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

On 4/21/08, Bill Ferguson <wbfergus_at_gmail.com> wrote:
>
> All -
>
> Thanks for the input so far. This is escalated to a severity 1, as
> the database is completely unusable. It seems to be a combination of
> Undo and the flashback archive (total recall). Not quite sure what the
> 'magic' combination is, but something I'm doing in the database keeps
> generating an error message of "Out of transaction slots in
> transaction table", and once that happens all I can do is a "shutdown
> abort" and then restart again.
>
> The problem with this is that once I do, then most of the undo needs
> to be re-applied back (roughly 35GB, that takes about 6 hours), and
> then the system seems to crash shortly afterwards again. It's also
> generating around 20GB of trace file activity every 6 hours as well.
>
> And even though I'm on Windows, it turns out that this bug was
> originally found and fixed for Linux platforms, as that's what all of
> the previous bug reports were for. Evidently I'm the first to report
> it on Windows, and the guy from Oracle Support said they had to work
> on a backport, which seems to be done. It sounds like what they need
> to do now is figure out how to 'package' it as a patch, etc., but I
> haven't received a timeframe from them yet.
>
> Needless to say the users are getting a bit fed up and I don't know to
> tell them. Things were running fine here on 11g for a bit over 4
> months, so it's a bit difficult trying to figure out how to move back
> to 10.2, besides the lose of 4 months of data. I'm not sure what other
> data problems would occur taking everything back from 11g to 10.2,
> besides the lose of all changes made to the data since we moved to 11g
> (which was the primary reason to do it).
>
> --
> -- Bill Ferguson
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>

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