I have the following query that takes 4 seconds to execute:
SELECT TX.* FROM TABLE_X TX
INNER JOIN TABLE_Y TY
ON TY.VALUE_ID = VALUE_ID_IN
AND TY.PROD_ID = TX.PROD_ID
WHERE (TX.PLACE_ID1 = VAR_PLACE_ID OR TX.PLACE_ID2 = PLACE_ID)
AND (TX.DATE > TY.FIRST_DATE)
AND (TX.TYPE_ID != VAR_TYPE_ID1_IN AND TX.TYPE_ID != VAR_TYPE_ID2_IN)
AND (TX.COL1 != COL1_IN OR TX.COL2 != COL2_IN)
However, I want to store it in a TEMPORARY TABLE
. When I execute the following query it takes 50 seconds:
INSERT INTO SESSION.TEMP_TABLE_X /*new line to store result*/
SELECT TX.* FROM TABLE_X TX
INNER JOIN TABLE_Y TY
ON TY.VALUE_ID = VALUE_ID_IN
AND TY.PROD_ID = TX.PROD_ID
WHERE (TX.PLACE_ID1 = VAR_PLACE_ID OR TX.PLACE_ID2 = PLACE_ID)
AND (TX.DATE > TY.FIRST_DATE)
AND (TX.TYPE_ID != VAR_TYPE_ID1_IN AND TX.TYPE_ID != VAR_TYPE_ID2_IN)
AND (TX.COL1 != COL1_IN OR TX.COL2 != COL2_IN)
TABLE_X = 300 000 rows
TABLE_Y = 90 000 rows
How can I reduce the 50 seconds running time?
The server is running DB2 v9.5.
Best Answer
I'll put this as an answer as it is easier to comment on.
Generally you need to run RUNSTATS on every table (I'd vote for at least once a week). This tells the optimizer the number of records (and if specified, which I do recommend) the distribution of data across the records. With this information the optimizer can make better decisions regarding access paths.
The optimizer also uses packages as well. REBINDING the packages essentially alters the packages (ie, their access paths) based on the RUNSTATS found.
In your case you could run RUNSTATS on the tables you care about
If you have a lot of tables, then I'd recommend hunting for them dynamically
You can then read this in to your database and execute it
REBIND
s I find the easiest to do using thedb2rbind
utility. It beats having to know all the specific package names. Since we are a small shop I just tend to use the following syntax each time.If there are errors, you will see it in the log.
So generally you would want to issue the
RUNSTATS
first, then issue aCOMMIT
to release any locks. Then you can run theREBIND
s throughdb2rbind
. If you have not run these in a while you may wish to throw adb2 flush package cache dynamic
in between theRUNSTATS
and thedb2rbind
.