Oracle maxes out CPU in v20; slowdowns from 2-4 pm

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 20

Description:
We've been having some problems with Oracle since upgrading to Aleph version 20/Oracle 11. The symptoms we're seeing is the Oracle will seem to run away with the CPU, eventually maxing out the CPU cycles, and grinding everything to a halt.

I'm not sure if this is related, or a separate problem, but I am seeing the following error in the alert_aleph20.log:

Errors in file /exlibris/app/oracle/diag/rdbms/aleph20/aleph20/trace/aleph20_ora_5930.trc (incident=30289):
ORA-00600: internal error code, arguments: [kksfbc-wrong-kkscsflgs],

Incident details in: /exlibris/app/oracle/diag/rdbms/aleph20/aleph20/incident/incdir_30289/aleph20_ora_5930_i30289.trc

This specific error seems to be related to running p_manage_18 on ABC60 (we're attempting to overlay the 856 fields for a bunch of records). In the past we've been able to run this job on thousands of records with no problems, but since upgrading we can't seem to run more than a few hundred records at a time without this problem cropping up. It's happened three times now in the last two weeks.

I'm not sure if this error is what is causing Oracle to max out the CPU cycles, or if this error is *caused* by Oracle maxing out, or if they're coincidental but unrelated problems. In any case, once Oracle maxs out the CPUs, the only resolution is to completely stop and restart Oracle, which causes a major disruption for our libraries. Yesterday, when this happened again, I couldn't even stop Oracle; it completely hung up during the shutdown and I had to reboot the server to get things back.

Also, we have noticed that every afternoon, from 3:00 to 4:00 edt, there is another unknown job "ora_j001_aleph20" running. This job takes 10-20% of the cpu and we are unable to do database work at that time also. I am still investigating from 2-3pm when there is another slowdown. Are these jobs that could be scheduled during non-peak times? We get complaints from users when indexing is either turned off or very slow.

Resolution:
util a/8 ("List Analyzed Tables/Indexes") shows "437 rows selected".

See KB's 16384-29537 and 8192-3980.

[From site:]
We have moved to the new servers and followed the instructions that were provided in the KB's for disabling these statistic gathering processes. Our response time and run times for services have improved dramatically.

Article last edited: 10/8/2013