Oracle Scratchpad

April 19, 2014


Filed under: Bugs,Oracle — Jonathan Lewis @ 9:22 am BST Apr 19,2014

I had another of those odd timing events today that make me think that Larry Ellison has access to a time machine. I found (yet another example of a) bug that had been reported on MoS just a few days before it appeared on an instance I was running. How is it possible that someone keeps doing things that I’m doing, but just a few days before I do them !

For no good reason I happened to browse through a load of background trace files on an instance and found the following in an “m000” file:

*** SERVICE NAME:(SYS$BACKGROUND) 2014-04-19 08:55:20.617
*** MODULE NAME:(MMON_SLAVE) 2014-04-19 08:55:20.617
*** ACTION NAME:(Auto-Purge Slave Action) 2014-04-19 08:55:20.617

*** KEWROCISTMTEXEC - encountered error: (ORA-06525: Length Mismatch for CHAR or RAW data
ORA-06512: at "SYS.DBMS_STATS", line 29022
ORA-06512: at line 1
  *** SQLSTR: total-len=93, dump-len=93,
      STR={begin dbms_stats.copy_table_stats('SYS', :bind1, :bind2, :bind3, flags=>1, force=>TRUE); end;}

Before trying to track down what had gone wrong I did a quick check on MoS, searching for “copy_table_stats” and “29022” and found bug 17079301 – fixed in 12.2, and, with a patch for (and some back-ports for The description of the bug in the note was basically: “it happens”.

I may get around to looking more closely at what’s gone wrong but as an initial thought I’m guessing that, even though the action name is “auto-purge slave action”, this may be something to do with adding a partition to some of the AWR history tables and rolling stats forward – so at some point I’ll probably start by checking for partitions with missing stats in the SYS schema.

The bug note, by the way, was published (last updated, on second thoughts) on 14th April 2014 – just 5 days before I first happened to spot the occurrence of the bug.


  1. Do you have any suggestions for anyone still using Oracle 11G R2 I have the issue, and it causes the entire system to hang. Is this related specifically to Oracle Enterprise Manager?

    Comment by Chad — October 24, 2014 @ 2:04 pm BST Oct 24,2014 | Reply

    • Which issue, exactly ? As the article says, there are some back-ports for so you could ask for a backport for your platform if it doesn’t exist.

      The dump is from m000 which suggests it’s just standard background processing; I supposed it’s possible that it could be doing a job that appears (more frequently) as a side effect of something that you’re doing with OEM but I doubt if OEM is the (sole) cause.

      Comment by Jonathan Lewis — October 27, 2014 @ 6:28 am BST Oct 27,2014 | Reply

  2. We have this same message on a database. Seems like this is the cause of partitions not being created for the AWR tables during the daily purge job initiated by mmon. As a result the SYSAUX tablespace is growing indefinitely.
    This query on our system shows the matching timing:

    select * from dba_objects where object_name like ‘WRH$%’ order by last_ddl_time desc;

    The partitions for WRH$_FILESTATXS get created and at the very next second the m000 trc file displays the error.
    The result thus seems to be the AWR purging job stops.
    We are now experimenting with this strange workaround to create the partitions manually:

    execute immediate ‘alter session set “_swrf_test_action” = 72’;

    See also these articles:
    WRH$_ACTIVE_SESSION_HISTORY Does Not Get Purged Based Upon the Retention Policy (Doc ID 387914.1)
    anually Purge the Optimizer Statistics & AWR Snaphots to Reduce Space Usage of SYSAUX Tablespace (Doc ID 1965061.1)

    Comment by Koenraad Forrier — March 5, 2015 @ 9:43 am BST Mar 5,2015 | Reply

    • Any news regarding the results of your experiment ? We are facing the same issue ….

      Comment by Daniel GARRIVIER — March 16, 2015 @ 4:36 pm BST Mar 16,2015 | Reply

RSS feed for comments on this post. TrackBack URI

Comments and related questions are welcome.

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Powered by