Daniel Fink wrote:
> Results from overnight testing...
>
> I did not dump every block (these are some large tables), only a
> selected handful from various spots in the extent listing.
>
> About 60 minutes before the mv refresh, I performed a fts query against
> each table. No errors on the query.
>
> The source database did not receive any 1555s during the mv refresh.
> However (big however), App support is not responding to tell me where
> the 1555 queries are coming from, if users/processes are having
> problems, etc. So, the queries may or may not have run last night.
>
> Anyway...in looking at the block dumps, there are no changes to the
> ITLs to indicate delayed block cleanout. Of course, the issue with dbc
> may be in a block that I did not dump (do I really want to dump almost
> 60,000 blocks and read through them????).
>
> Regards,
> Daniel
>
Which brings it back to my original suggestion. Look for the simple
solution first. Looking at 60,000 block dumps rather than determining
how long the longest running query runs for, and setting undo_retention
to that, is overkill. It's like tearing an engine apart piece by piece
to find out why it stalled instead of checking the gas gauge first.
--
To reply by email remove "_nospam"
Received on Thu Jan 26 2006 - 10:04:27 CST
