• Article Type: General
• Product: Aleph
• Product Version: 20, 21, 22, 23
• Relevant for Installation Type: Dedicated-Direct; Direct; Local; Total Care

Desired Outcome Goal:
Diagnosis/correction of slow Aleph system

Procedure:

1. If the slowness is limited to a particular batch job or a particular online function (item list, loan, return, etc.), search the CKC for knowledge articles relating to slowness in that particular job or function.

2. Has the slowness persisted over several days -- or did it just start today?  If just today, then do the unix "top" command. Is
    "Cpu(s): .. %us" greater than 50%?  If so, check which processes shown in "top" are using large amounts of CPU and MEMory.
    ".. %wa (i/o wait)" greater than, say, 30%?    This could indicate that a backup is running, disk slowness, or other items from below.

High CPU values or %wa can confirm CPU or I/O as causes of the slowness.

  2a.  If the above look fine but the user is seeing slow response and, especially, if slowness is seen in typing on the Web or GUI screens, this could be a communication problem.  See article " PC connection to server extremely slow " in this regard.  

3. If the slowness has persisted over several days, but Aleph has not been restarted since the slowness started, then run aleph_shutdown followed by aleph_startup.  (You may want to also restart Oracle at this point, as suggested in step 6 below.)

4. If the slowness persists or returns after restart, and the above haven't helped, then perform the SQL commands described in the article How to tell if Oracle indexes for a particular library are present & VALID .  Missing Oracle indexes are the most common cause of severe slowness. 

5. Do util a/8 ("List Analyzed Tables/Indexes"). The result should not show any local library XXXnn znn tables. (Aleph Demo library tables are less of an issue.)

6. If the above don't apply or haven't helped, then run aleph_shutdown, followed by a restart of Oracle, followed by aleph_startup. 

7. Check articles Aleph is slow ***MASTER RECORD***  and System/search slowness **MASTER RECORD**  for specific conditions which might apply. 

8. If the slowness is seen after going to version 22 (or 23), the Oracle SGA (System Global Area) might be too small.  (Version 22-up seems to require more.)   See the article:  Multi-process, I/O intensive jobs slow in Aleph 22/Oracle 11r2 . 

9.  Potential for slower-than-normal access times in TWO_TASK environment.  See article Slow response in TWO_TASK caused by distance between App server <-> Firewall <-> DB server .

10.  If the SGA is already OK or if increasing it doesn’t help, then an analysis will need to be performed by your DBA or the Ex Libris DBA Team to pinpoint the cause of the slowness, using tools such as:

*  ASH (Active Session History) - useful only if done as the problem is occurring

11. If none of the preceding has helped, then reboot the server:  there can be performance problems which are resolved only by server reboot.