This content has been marked as final. Show 8 replies
you can query ctx_user_index_errors (or bigger ctx_index_errors).
Herald ten Dam
SELECT err_timestamp, err_text FROM ctx_user_index_errors ORDER BY err_timestamp DESC;
There are no errors associated with the index.
Theer are no errors in ctx_user_index_errors for the index
You can get the logging to log every rowid it processes - but it does make for very large log files.
I wonder if the problem is becuse of some bug when the DR$PENDING gets to zero rows. Apparently this causes the query on CTX_USER_PENDING to take a long time. I use that view to determine the partitions to pass to SYNC_INDEX procedure.
This takes about 5 seconds for tow rows with 335 and 13 rows.
select pnd_partition_name ,count(*) from ctx_user_pending where pnd_index_name = '<index_name>' group by pnd_partition_name /
Tables DR$INDEX, DR$INDEX_PARTITION and DR$PENDING have had Statistics gathered
This query has taken over 45 minutes.
As an aside, we went back from parallel 8/16 to 1 and for now the sync index works a lot better. We are also "loading" at 1000 rows per cycle (10 seconds). Dont see any TX: row contention waits either.
But would still like to know which exact row is currently being processed by SYNC_INDEX.
use CTX_OUTPUT.START_LOG. That will log the rowid of the record syncing.
Can the Logging be done after the sync-Index has been initiated?