Hi Bret and Simon,
>>It sounds like it is simply reading the data into cache.
>>I agree with Simon that the most likely cause is data not being in cache.
I agree as well, but we can't always have the results in cache, since there are too many accounts that users may run these reports for. The report is not very complex, but users may decide to run it for a wide date range, sometimes six months to a year or more. They will always enter an account id, and order date range. Should we create a new index based on the account id and date range? Currently we have indexes created on the individual columns (acct_id, order_date).
>>When you say the first retrieve is slow, what do you mean by first?
It's usually the first one of the day, or after a period when none were done for <x> hours. Also, when the account or date range changes, it appears to be slower - if the results were not included in prior query results.
So apart from getting faster hard drives for the server, would running an 'update statistics', or re-indexing the tables help? If so, how often should we update the statistics or re-index the table?
I appreciate your help.
Queue
COMMAND:
SELECT products.beq_resq,
orders.code1, orders.code2,
orders.code3, orders.qty_ord,
orders.order_date,
orders.cost, orders.prod_id
FROM orders, products
WHERE ( orders.acct_id = 185746 )
AND ( orders.order_date >= '1/1/12 00:00:00' ) AND ( orders.order_date <= '1/31/12 23:59:59' )
AND ( orders.prod_id = products.prod_id ) and ( orders.qty_ord > orders.qty_can )
QUERY PLAN FOR STATEMENT 1 (at line 1).
STEP 1
The type of query is SELECT.
FROM TABLE
orders
Nested iteration.
Index : idx_acct_id
Forward scan.
Positioning by key.
Keys are:
acct_id ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.
FROM TABLE
products
Nested iteration.
Index : idx_prod_id
Forward scan.
Positioning by key.
Keys are:
prod_id ASC
Using I/O Size 2 Kbytes for index leaf pages.
With LRU Buffer Replacement Strategy for index leaf pages.