Query very slow on Windows 2003 Server
Hi,
Our customer is running 10g on Windows 2003 server. Some queries perform badly. I imported the data into a 10g DB on Linux (at our office) to analyze and test. Strange enough the same query takes more than 10 times longer to run on the Windows machine compared to the Linux. The Windows machine is dedicated to Oracle, it is not 'overloaded'.
SELECT
plan_task.id_task,
plan_task.task_id,
plan_task.taskdef_y_n,
plan_task.description,
plan_task.status,
plan_task.team_id,
plan_task.activity_id,
plan_task.task_start_datetime,
plan_task.district_id,
plan_task.task_end_datetime,
plan_task.taskdef_freq_code,
plan_task.taskdef_start_time,
plan_task.taskdef_end_time,
plan_task.order_nr
d,
PREVENT.PLAN_PERSONS_AVAILABLE_SHORT(ID_TASK) PERS_OK,
PREVENT.PLAN_MATERIALS_AVAILABLE_SHORT(ID_TASK) MAT_OK
FROM PREVENT.PLAN_TASK
WHERE (TASKDEF_Y_N='N') AND (TASK_START_DATETIME>=to_date(to_char(SYSDATE,'dd-mm-yyyy'),'dd-mm-yyyy'))
AND (TASK_START_DATETIME<to_date(to_char(SYSDATE,'dd-mm-yyyy'),'dd-mm-yyyy')+1)
ORDER BY DESCRIPTION;
On LINUX (Intel 2 GHz, 2 Gb mem) takes 0,5 seconds to execute (46 rows returned)
================================================================================
Plan
SELECT STATEMENT ALL_ROWSCost: 27 Bytes: 2,436 Cardinality: 29
4 SORT ORDER BY Cost: 27 Bytes: 2,436 Cardinality: 29
3 FILTER
2 TABLE ACCESS BY INDEX ROWID TABLE PREVENT.PLAN_TASK Cost: 26 Bytes: 2,436 Cardinality: 29
1 INDEX RANGE SCAN INDEX PREVENT.PLAN_TASK_START_DATETIME_I Cost: 2 Cardinality: 30
On WINDOWS (Intel 2 GHz, 2 Gb mem) takes 11 seconds to execute (46 rows returned)
=================================================================================
Plan
SELECT STATEMENT ALL_ROWSCost: 35 Bytes: 3,276 Cardinality: 39
4 SORT ORDER BY Cost: 35 Bytes: 3,276 Cardinality: 39
3 FILTER
2 TABLE ACCESS BY INDEX ROWID TABLE PREVENT.PLAN_TASK Cost: 34 Bytes: 3,276 Cardinality: 39
1 INDEX RANGE SCAN INDEX PREVENT.PLAN_TASK_START_DATETIME_I Cost: 2 Cardinality: 40
NOTEs:
- The data is exactly the same on both machines
- I analyzed_schema on both machines/DB's before running the query
- The SGA size en DB_BUFFERS are (almost) set to the same value
- Oracle version is the same: 10g