Sounds like it's been a while since the last server restart.
Edit: If you're running oracle, you could run analyze on the tables.
A quick test: How long does it take to save an AL if the Server Window does NOT show the Active Link Details in the background?
Development Cache Mode?
Do you run ITSM?
It depends on what form. Forms with lots of AL's take longer than a form with none. Make sure you are in Dev cache mode of course and you are not displaying details.
Stop and start the database service
in production this is not uncommon as the tables used aren't cached in memory and therefore take ages to load up
Thanks for the suggestions. No progress as of yet. I've cycled the application (ARS/Remedy) and the database (Oracle 10.2.0.4 on linux).
NEW INFO ON TIMES:
Active Link Save As: 2 min 45 sec
Create Active Link: 1 sec (new first time AL)
Update Active Link: 45 sec
Development Cache Mode? checked
Do you run ITSM? Yes this is an ITSM object
ARS Version? 7.1 PATCH 005
To implement case-insensitive searching a couple of weeks ago I added the login trigger shown below:
create or replace trigger
AFTER LOGON ON SCHEMA
execute immediate('ALTER SESSION SET NLS_COMP=LINGUISTIC');
execute immediate('ALTER SESSION SET NLS_SORT=BINARY_CI');
Other posts have suggested a need to rebuild indexes with NLS options in the DDL. I'm going to try that with the indexes involved in this query and see if that changes things.
It wasn't the log-in trigger that was causing the slowness. And it wasn't the database. Things improveed notably when a BMC patch (7.1) was applied.
Thanks to all for your input -