Comments on: Banner ICGORLDI extract causes stuck thread

By: Astelsaceli

Astelsaceli — Thu, 08 Sep 2011 17:50:53 +0000

Hi.
I am happy that was registered here.
Wished to steer to you,creative Blog..HERE http://digg.com/news/entertainment/scandal_video_celebrity_2. How to you?

By: sneezypb

sneezypb — Fri, 11 Mar 2011 03:33:15 +0000

Not even an index can help a truly inefficient method. Having to check one-by-one whether the value already exists and moving to the next is very inefficient, aka slow. Think of it this way, say you have 3,000 of these already. At a half of second per lookup, it looks at 3,000 of them to get to 3,001 so it takes 1500 seconds. That is 25 minutes to add one rather than a half a second for one which does not already exist. As you enter more cross-listed section, the problem just gets worse. The best optimized index could get you to a tenth of a second per lookup but even then you are still at 5 minutes per item you add and getting worse as you add thousands more.

By: Laura Gekeler

Laura Gekeler — Thu, 10 Mar 2011 15:59:59 +0000

Post-mortem for 3/8/2011 issue:
1. App server resources appeared fine during the entire 48 hour period. No JVM memory concerns per grep “java.lang.OutOfMemoryError” *.log* or grep “Available memory” webct_monitor.log
2. DBA reported two partially full WEBCT_LOBS .dbf files (max on our system is set for 30 gig each). Cursory review of db server .trc files shows nothing.
3. Import files were bigger than 10M. The one which started the transaction rollback errors was 18M in size and composed entirely of the tag which DOES entail creation of those “Cross List Section Group n”.
4. Next line of analysis is to confirm that background jobs have been running successfully. Not sure whether there are index optimization routines which might help.