In this Document

Applies to:

Symptoms

Executing DBMS_STATS fails with either of the following error messages:

SQL> set serveroutput on
SQL> exec dbms_stats.gather_table_stats(ownname=> 'SCHEMA',tabname=>
'TABLE_NAME', degree=>4 , cascade=>TRUE, estimate_percent=>25);

BEGIN dbms_stats.gather_table_stats(ownname=> 'SCHEMA',tabname=> 'TABLE_NAME', degree=>4 , cascade=>TRUE, estimate_percent=>25); END;
*
ERROR at line 1:
ORA-20003: Specified bug number (5099019) does not exist
ORA-06512: at "SYS.DBMS_STATS", line 13474
ORA-06512: at "SYS.DBMS_STATS", line 13494
ORA-06512: at line 1

or

SQL error -20003 at location stats_tab_collect-21, SQL statement:
'BEGIN DBMS_STATS.GATHER_TABLE_STATS (OWNNAME => '"SCHEM"', TABNAME => '"TABLE_NAME"', ESTIMATE_PERCENT => NULL, METHOD_OPT => 'FOR ALL COLUMNS SIZE 1', DEGREE => NULL, CASCADE => TRUE, NO_INVALIDATE => FALSE); END;'
ORA-20003: Specified bug number (16470836) does not exist
ORA-06512: at "SYS.DBMS_STATS", line 24301
ORA-06512: at "SYS.DBMS_STATS", line 24352
ORA-06512: at line 1

Changes

An upgrade may have occurred, but this is not necessary to trigger this issue.

Cause

This issue is caused by a mismatch between the DBMS_STATS package and the binary executable. If one has been updated and the other has not then errors will occur. The cause of the issue is one of:

1) Problems with validity of the dictionary objects upon which DBMS_STATS package depends.  This is documented in the following bug:

Post installation steps should install / validate these packages. If this was not done then this can cause the issue.

2) Relinking of the binary executable files has not occurred following a patch application. This can occur when multiple patches are applies and the -no_relink flag has been used on the opatch command to avoid linking every time. If this option is used on all the applications then necessary relinking will not occur. See opatch help:

opatch apply -help

-no_relink
             The nolink option does not perform any make operations.
             This option can be used during multiple patch
             applications and perform the linking step only once.
             OPatch does not keep track of the make operations it
             did not perform. It is the job of the OPatch users to
             make sure the execute OPatch without this option at
             the end, so that compilation happens once

Solution

The following have resolved the issue:

1) Recreate DBMS_STATS package by running the following scripts:

We recommend running these scripts during maintenance window while database in restricted mode to avoid problems that can be caused when other sessions access the same objects.

2) If a patch or an upgrade has been performed, relink the binaries after applying the patch. See the following for details:

References