The last time an index was used

Question

Hi to all, 
I would like to know, if there is a way of knowing  the last time an index was used, or what indexes have never been used.
Regards
Eduardo Barrios
Compañía Cervecera de Canarias S.A.
Tfno.     922 568 246
Fax.      [phone]
Correo   [email protected]

Answer 1

Hi Eduardo,
reading through the updates from Thomas and Volker, I was wondering if there was a bug in i5/OS that causes the "Last used date" information in the file description not to be updated properly for indexes. If you have the plan cache dump or database monitor active (i.e. quite current data in ST04), you could do the following to find out if indexes have been used by the SAP system without a proper update in the file description:
1. List all indexes into a temporary output file:
    DSPFD FILE(R3<sid>DATA/ALL) TYPE(MBR) OUTPUT(*OUTFILE)
          FILEATR(*LF) OUTFILE(QTEMP/DSPFD)
2. Compare output with database monitor data using STRSQL or SQLUTIL:
    SELECT T1.MBFILE, T1.MBUDAT, T2.QQTIME, T2.QQLIFN
      FROM QTEMP/DSPFD T1, R3<sid>DATA/SQ3001_DB4 T2,
           R3<sid>DATA/SYSINDEXES T3
     WHERE T1.MBFILE = T3.SYSTEM_INDEX_NAME
       AND T3.INDEX_NAME = T2.QQLIFN
     ORDER BY T1.MBUDAT
If you find indexes, where the "Last Used Date" is smaller than the QQTIME value, you know that the
file statistics are not updated properly. You could then open a PMR at IBM for that.
On one of our internal systems I did not see a discrepancy, so it seems to me that the information is correct. Volker's experiences could be explained by the fact that indexes are not just used to implement SQL statements, but also for table statistics. I assume that the "Last used date" is not updated when the index was only used to obtain table statistics. With incomplete statistics, the optimizer may choose a different join order or access method, which can result in poor performance. So there is some risk involved when dropping an index that has a very old "Last used date", and you can only decide it by trying (with care!).
Kind regards,
Christian Bartels.