Why would a perfectly good SQL based application which has been running well for years suddenly start to run slowly?

It’s easy for us iSeries users to forget about database administration because the OS/400 or i5/OS does such a good job of managing this for us.

From time to time an AS/400 (for that is still what I like to call it) logical file (index) can become invalidated.  This typically happens if a job is using it when the subsystem goes down for some reason.

Doing a little research what I’ve found is that if an RPG program with the table specified on an F Spec tries to opens a damaged logical it triggers the system to rebuild the logical during the file open.  This isn’t the case when you run an SQL statement.  The SQL processor only considers currently valid access paths when it builds its access plan, therefore skipping damaged logical (indexes).

In my case, this was causing the SQL processor to drop back to a full table scan rather than an indexed lookup.  This changed the usual runtime of the SQL statement from less than a second to several minutes.

Using OpsNav and the Visual Explain tool you can view the SQL statement and see exactly what it’s doing but it may still not be obvious why it didn’t use the logical view that you know exists.

The tip is to have your System Operator run the EDTRBDAP (Edit Rebuild of Access Paths) command which will list any damaged access paths.  The system gives you an estimated time for the fix which so far we’ve found to be quite accurate. It’s best probably to plan to fix the access path out of normal operational hours. This screen does get displayed during an attended IPL but most SysOps I’ve spoken to say they were taught to just press Enter – because the system will sort the problem out later – which is obviously no longer true if you’re using SQL.