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 quite 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 so far ↓
dombrooks // April 30, 2008 at 7:59 am |
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.
Bug in 11g AWR report « OraStory // May 16, 2008 at 9:53 am |
[...] Contact ← 11g upgrade still good [...]
Cristian Cudizio // September 15, 2008 at 9:25 am |
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?
Regards,
Cristian
dombrooks // September 15, 2008 at 9:51 am |
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?
Cheers,
Dominic
Cristian Cudizio // September 15, 2008 at 1:24 pm |
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.
dombrooks // September 15, 2008 at 3:00 pm |
Sorry Cristian – I meant that there was little on metalink or the internet in general.
dombrooks // September 15, 2008 at 3:01 pm |
You’ve no ora-0600 errors in the alert log or any other trace files produced by the server at the same time?
Cristian Cudizio // September 15, 2008 at 4:08 pm |
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:
/u01/app/oracle/diag/rdbms/sid/SID2/incident/incdir_116257/ora_1232974_1_i116257.trc
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.
Wayne Phillips // November 11, 2008 at 7:46 am |
Hi Wayne Phillips from sunny South Africa.
I am busy upgrading to 11g (11.1.0.7 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
WP
dombrooks // November 11, 2008 at 9:00 pm |
Hi Wayne,
Have you tried creating a staging table and then importing the staging table before “unpacking” it?
http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/sql_tune.htm#CHDEBDFC
Cheers,
Dominic