Sometimes even Oracle itself just can’t cope with the 30 character limit
This from a M000 trace file
*** 2013-08-29 15:27:46.316
*** SESSION ID:(1020.7527) 2013-08-29 15:27:46.316
*** CLIENT ID:() 2013-08-29 15:27:46.316
*** SERVICE NAME:(SYS$BACKGROUND) 2013-08-29 15:27:46.316
*** MODULE NAME:(MMON_SLAVE) 2013-08-29 15:27:46.316
*** ACTION NAME:(Remote-Flush Slave Action) 2013-08-29 15:27:46.316
*** KEWROCISTMTEXEC – encountered error: (ORA-12899: value too large for column "SYS"."WRH$_SEG_STAT_OBJ"."OBJECT_NAME" (actual: 31, maximum: 30)
*** KEWRAFM1: Error=13509 encountered by kewrfteh
I’ve had a couple peers ask me about this recently- They’ve attempted to discover targets on a host and experienced failures. This commonly occurs for the following reasons:
1. Incorrect information regarding the target exists at the target host level.
2. The OMS has an unresolved issue, status in pending state, etc.
If one is seeing waits for enq: TX – row lock contention then there could be a lot of reasons. One distinguishing factor is the lock mode. If the lock mode is exclusive (mode 6) then it’s most likely a classic row lock where two sessions are trying to modify the same row. On the other hand if the lock mode is share (mode 4) it’s typically going to be
This post is about log writer (lgwr) IO.
It’s good to point out the environment on which I do my testing:
Linux X64 OL6u3, Oracle 18.104.22.168 (no BP), Clusterware 22.214.171.124, ASM, all database files in ASM.
In order to look at what the logwriter is doing, a 10046 trace of the lgwr at level 8 gives an overview.
A way of doing so is using oradebug. Be very careful about using oradebug on production environments, it can/may cause the instance to crash.
This is how I did it:
SYS@v11203 AS SYSDBA> oradebug setospid 2491 Oracle pid: 11, Unix process pid: 2491, image: email@example.com (LGWR) SYS@v11203 AS SYSDBA> oradebug unlimit Statement processed. SYS@v11203 AS SYSDBA> oradebug event 10046 trace name context forever, level 8 Statement processed.
Of course 2491 is the Linux process id of the log writer, as is visible with “image”.
One thing that I have found sorely missing in the performance pages of Enterprise Manager is latency values for various types of I/O. The performance page or top activity may show high I/O waits but it won’t indicated if the latency of I/O is unusually high or not. Thus I put together a shell script that shows latency for the main I/O waits
Currently there is an interesting thread on the oracle-l mailing list about OEM 12c support for database 12c Release. Unlike previous OEM generations this time OEM was not lagging behind. I am using OEM 126.96.36.199.0 with the database plugin 188.8.131.52.0 and yes, I can see PDBs!
The above snapshot is from the database targets overview page. As you can see there is a Container Database (CDB1) and it has exactly 1 PDB. When you click on the CDB you get to the main page:
Anyone who has been around Oracle performance over the years knows the grief that hard parsing SQL queries can cause on highly concurrent applications. The number one reason for hard parsing has been applications that don’t use bind variables. Without bind variables queries that would otherwise be shared get recompiled because their text is different and Oracle treats them as different queries. Oracle addressed this issue with a parameter called cursor_sharing. The parameter cursor_sharing has three values
Here is what the load looks like going from the default, exact, to the value force on a load of the same query but a query that doesn’t use bind variables:
It has been a few weeks since my last blog post but don't worry I am still interested to blog about Oracle 12c database security and indeed have nearly 700 pages of notes in MS Word related to 12c security....[Read More]
Posted by Pete On 28/08/13 At 05:04 PM