I f you have not done a RUNSTATS on the table, that can cause a table scan. Also, you where clause is the main factor in determining how a table is accessed. If you have done RUNSTATS and you have an index on the column in the where clause, as it appears you have, and you are still getting table scans, it is probably because DB2 thinks it is still more prudent to do that anyway. Lets take you query for an example of this. I will assume you have done RUNSTATS and they are current. Your where clause is asking for all rows where the timestamp is less than or equal to a particular value. Now if the stats show that vast majority of the rows in the table would qualify, as I suspect they will for your query, and the fact that you have asked for columns not in the index, DB2 thinks it would be better just to scan the table instead of using the index. To make this a little clearer, suppose your table is using 100 pages for the data and the index uses 5 pages. It looks like the index would be the best way to access the data, but if DB2 thinks that 95% of the rows will be returned, then doing a table scan is clearly the way to go. To use the index in this case, DB2 will read the 5 index pages and still have to read the 95 data pages for a total of 100 pages which is the same as a table scan. So it might just think to do a table scan anyway.
HTH
Andy