Does SYSDATE change affects table stats in Oracle?

Question

One of our dbas said that after changing system date in Oracle (we need to do this in order to test our software) we need to collect all the statistics for our tables - is this true? If yes, then why? I couldn't firn anything in Oracle docs. One thing that comes to my mind is that the job which automatically collects stats may hung on waiting for next run date that was jumped off.

Any other ideas?

Answer 1

Changing the system date probably does not require regathering statistics. The table statistics do not contain the actual SYSDATE. Even when the execution plan is extremely sensitive to the SYSDATE, Oracle appears to handle the date change very well.

However, it wouldn't surprise me too much if there was some weird error somewhere related to changing the date. But you should ask the DBA for specific details, including an Oracle Support bug number.

Below is an example of the optimizer handling a change to the operating system date perfectly.

1: Remove all current cached SQL, just in case.

alter system flush shared_pool; 

2: Create a table with a skewed column. There are many values for today but only a few for tomorrow.

drop table test1;
create table test1(a date, b varchar2(100));
create index test1_idx on test1(a);
insert into test1 select trunc(sysdate), 'common value' from dual
  connect by level <= 100000;
insert into test1 select trunc(sysdate)+1, 'rare value' from dual
  connect by level <= 10;
--Workload to generate histograms.
select max(b) from test1 where a = trunc(sysdate);  
begin
    dbms_stats.gather_table_stats(user, 'TEST1');
end;
/

3: Selecting the common data, from today, correctly uses a full table scan.

select to_char(sysdate, 'YYYY-MM-DD') current_date from dual;

CURRENT_DATE
------------
2014-01-05

explain plan for select b from test1 where a = trunc(sysdate);
select * from table(dbms_xplan.display(format => '-cost -bytes -predicate'));

Plan hash value: 4122059633

------------------------------------------------------
| Id  | Operation         | Name  | Rows  | Time     |
------------------------------------------------------
|   0 | SELECT STATEMENT  |       |   100K| 00:00:01 |
|   1 |  TABLE ACCESS FULL| TEST1 |   100K| 00:00:01 |
------------------------------------------------------

4: Selecting the rare data, from tomorrow, correctly use an index range scan.

explain plan for select b from test1 where a = trunc(sysdate)+1;
select * from table(dbms_xplan.display(format => '-cost -bytes -predicate'));

Plan hash value: 1226949

----------------------------------------------------------------------------
| Id  | Operation                           | Name      | Rows  | Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |    10 | 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TEST1     |    10 | 00:00:01 |
|   2 |   INDEX RANGE SCAN                  | TEST1_IDX |    10 | 00:00:01 |
----------------------------------------------------------------------------

5: Change the operating system clock to tomorrow. SYSDATE is instantly updated.

select to_char(sysdate, 'YYYY-MM-DD') current_date from dual;

CURRENT_DATE
------------
2014-01-06

6: Re-run step #3. This query previously returned a large amount of data, now it returns only a small amount of data. The plan should and does change from a full table scan to an index range scan.

explain plan for select b from test1 where a = trunc(sysdate);
select * from table(dbms_xplan.display(format => '-cost -bytes -predicate'));

Plan hash value: 1226949

----------------------------------------------------------------------------
| Id  | Operation                           | Name      | Rows  | Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT                    |           |    10 | 00:00:01 |
|   1 |  TABLE ACCESS BY INDEX ROWID BATCHED| TEST1     |    10 | 00:00:01 |
|   2 |   INDEX RANGE SCAN                  | TEST1_IDX |    10 | 00:00:01 |
----------------------------------------------------------------------------