"Tanel Põder" <change_to_my_first_name_at_integrid.info> wrote in
news:411bc081$1_2_at_news.estpak.ee:
>> 4 rows with state = "RECOVERING". When I look at the sessions that
>> are doing all the block changes in the database, they are the 4 PQ
>> slaves and they tie back to SMON as the parent process. The problem
>> is that they generate far more redo during this rollback than any
>> transaction that
> takes
>> place on the database. It almost appears as if they are looping and
>> spitting out redo. Eventually the archived log filesystem fills and
>> the
>
> What do you see from v$fast_start_transactions?
> Rolling back huge transactions do generate redo for each datablock
> change plus also for rollback segment blocks when their contents have
> been applied, so this might be normal..
>
> Tanel.
>
>
>
It looks like the problem was being caused by an application that was
recurively calling triggers and never committing. The app's session would
eventually die, and the huge rollback would begin. At first we thought we
were encountering an Oracle bug but it looks like it was the application
instead. It would fire a trigger on t1, that would insert t2, that inturn
update t1, which fired the trigger again. Or at least that's the way the
developer has described the problem. We fixed it by disabling the
triggers for now until the app can be fixed.
--
Chuck
Remove "_nospam" to reply by email
Received on Fri Aug 13 2004 - 10:11:32 CDT
