11g upgrade still good

Still looking good.

CPU on the new box is hovering under the 20% mark having been habitually > 80% on the old kit. But it could be a quiet time for the business so we will have to compare the metrics that we capture as a proxy for “business activity”.

Best news is that we were getting a significant number of “ORA-01801: date format too long for internal buffer” errors every day causing the client-server application to crash.

These have been due to cursors being shared when they shouldn’t be, for example due to NLS mismatches.

As hoped (and promised to the business), these have disappeared with the upgrade.


10 Responses to 11g upgrade still good

  1. dombrooks says:

    P.S. I’m not suggesting that CPU is an effective performance monitoring tool and absolutely no good at telling me about the impact the upgrade has had on particular SQL statements

    20% doesn’t mean everything is fine.

    But for a database that was habitually running at 80-100% and suffering erratic performance, it’s a better gain than I expected from just an upgrade.

    There’s bundles of easy win tuning to be done and I still need to push to be given time to tune in order to preserve and even increase that gain before it is eroded by a ramp up in activity and users.

  2. Pingback: Bug in 11g AWR report « OraStory

  3. Hi Dominic,
    your platform is 32 or 64 bit? A customer of us has made an upgrade on new hardware and randomly has an ORA-03137 error that makes crash a server session. They are on AIX 5 64 bit and i’ve found another person with same error but on Windows 64 bit. Your upgrade is still good?


  4. dombrooks says:

    Ciao Cristian,

    Linux 64 bit – upgrade still good, with the exception of the expected bug here and there.

    Don’t believe that we’ve had ORA-03137 – information on that error looks a bit thin, doesn’t it?


  5. Thanks Dominic,
    i’ve not well understood if you mean that i’ve gived you little information about error ORA-03137 or if there is little information about that error by Oracle. I can say that on google there is little information, it seems a really rare error. Our customer has opened a SR with Oracle but there is no test case to reproduce the error,The error happens randomly and Oracle is not able to give an answer, so i’m trying to understand if we are so unlucky.

  6. dombrooks says:

    Sorry Cristian – I meant that there was little on metalink or the internet in general.

  7. dombrooks says:

    You’ve no ora-0600 errors in the alert log or any other trace files produced by the server at the same time?

  8. no, sometimes there is
    ORA-07445: exception encountered: core dump [osnsgl()+0220] [SIGSEGV]
    [ADDR:0x68] [PC:0x106A204C0] [Invalid permissions for mapped o
    bject] []
    Incident details in:
    Tue Jun 24 07:35:33 2008
    Trace dumping is performing id=[cdmp_20080624073533]
    but not near the error and it seems that when there is this error there are no server process crash.

  9. Wayne Phillips says:

    Hi Wayne Phillips from sunny South Africa.

    I am busy upgrading to 11g ( patchset ) on Suse Linux Sles10.
    I am have the usual quries that are having poor performance due to the query plans behaving very differently on 11g.

    I decided to setup a Tuning Set on the 10g DB for a specific SQL_ID. I then exported it and tried to import it into 11g.
    It failed on the Import as the columns for the staging table (actually the Nested table where the PLANS are stored) as it does not have the same column structure.

    Basically what I want to do, is take the Good Query Plan from the 10g Tuning Set and import it into 11g so I can get the 11g DB to use the “correct” Query plan from 10g.

    The query is on 2 Dictionary Views – not user tables:
    SELECT obj.object_type, obj.object_name, obj.owner
    INTO :b0, :b1, :b2
    FROM all_synonyms syn, all_objects obj
    WHERE ( ( ( ( syn.synonym_name = :b1
    AND syn.owner = :b2)
    AND syn.table_name = obj.object_name)
    AND syn.table_owner = obj.owner
    AND obj.object_type IN (‘TABLE’, ‘VIEW’, ‘SYNONYM’)

    Import error:
    Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
    . . imported “WAYNEP”.”TUNING_SET_MDSREP” 17.21 KB 2 rows
    . . imported “WAYNEP”.”TUNING_SET_MDSREP_CBINDS” 9.523 KB 0 rows
    ORA-31693: Table data object “WAYNEP”.”TUNING_SET_MDSREP_CPLANS” failed to load/unload and is being skipped due to error:
    ORA-29913: error in executing ODCIEXTTABLEOPEN callout
    ORA-29400: data cartridge error
    ORA-39786: Number of columns does not match between export and import databases
    Job “WAYNEP”.”SYS_IMPORT_FULL_01″ completed with 1 error(s) at 22:54:44


  10. dombrooks says:

    Hi Wayne,

    Have you tried creating a staging table and then importing the staging table before “unpacking” it?



Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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

%d bloggers like this: