Home/ Questions/Q 8765697
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T16:21:14+00:00

We have a table called t_reading , with the following schema: MEAS_ASS_ID NUMBER(12,0) READ_DATE

  • 0

We have a table called t_reading, with the following schema:

MEAS_ASS_ID     NUMBER(12,0)
READ_DATE       DATE
READ_TIME       VARCHAR2(5 BYTE)
NUMERIC_VAL     NUMBER
CHANGE_REASON   VARCHAR2(240 BYTE)
OLD_IND         NUMBER(1,0)

This table is indexed as follows:

CREATE INDEX RED_X4 ON T_READING
(
  "OLD_IND",
  "READ_DATE" DESC,
  "MEAS_ASS_ID",
  "READ_TIME"
)

This exact table (with the same data) exists on two servers, the only difference is the Oracle version installed on each one.

The query in question is:

SELECT * FROM t_reading WHERE OLD_IND = 0 AND MEAS_ASS_ID IN (5022, 5003) AND read_date BETWEEN to_date('30/10/2012', 'dd/mm/yyyy') AND to_date('31/10/2012', 'dd/mm/yyyy');

This query executes in less than a second on Oracle 10, and around a minute in Oracle 9.

Are we missing something?

EDIT:

Execution plan for Oracle 9:
enter image description here

Execution plan for Oracle 10:
enter image description here

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    “Are we missing something?”

    Almost certainly, but it’s difficult for us to tell you what.

    There were some performance improvements in the CBO from 9i to 10g but it’s unlikely to make that much difference. So it must be some variation in your systems, which is obviously the hardest thing for us to diagnose, blind and remote as we are.

    So, first things to rule out are general system diffences – disk speeds, i/o bottlenecks, memory sizing, etc. You say you have two servers, do they have different specs? Whilst it will require assistence from an sysadmin type to investigate these things, we can discount them with a single question: is it just this query, or can you reproduce this effect with many different queries?

    If is just the query, there are at least three possible explanations.

    One is data distribution. How was the data populated in the two databases? If the 10g was exported from the 9i database was it sorted in some fashion? Even if it wasn’t it is possible that the ETL process has compacted and organised the data and built the fresh indexes in a way which improves the access times.

    Another is statistics. Are the 10g statistics fresh and realistic, whilst the 9i statistics are stale and misleading?

    A third possibility is a stored execution plan. (You have posted a query with literals, this only applies to queries with bind variables.) Searches on date ranges are notoriously hard to tune. A date range of to_date('30/10/2012', 'dd/mm/yyyy') AND to_date('31/10/2012', 'dd/mm/yyyy') suits one sort of plan, whereas date range of to_date('01/01/2010', 'dd/mm/yyyy') AND to_date('31/10/2012', 'dd/mm/yyyy') may well suit a different approach. If the extant plan on the 9i database suits a broader range then queries for a narrow range may take a long time.

    While I’ve been typing this you have published the explain plans. The killer detail is at the bottom of the 9i plan:

    Note: rule-based optimization

    You haven’t got any stats for the table or the index, so the optimizer is applying the dumb defaults of the RBO. You should really address this, but it’s not a simple task. You may need to gather stats for all your tables. You may need to change the OPTIMIZER_MODE in the init.ora file. You may need to undertake a regression test of all the queries on your database. So, it’s not something you shoudl do lightly.

    In the meantime, if this query is bugging you, you’ll need to wrnagle the Rule-Based Optimizer the old-fashioned way. Find out more.

    • 0