Here’s a little note that came about after I tweeted an idle thought on Twitter yesterday
How to use (almost) the same column definition for two indexes on the same table:
Whilst waiting for a new version of Cloud Control, which will hopefully include my job scheduler enhancement requests, I decided to see if I could solve my problem using the command line interface (EMCLI). That spawned this very basic article.
I was initially really excited by the EMCLI, planning to pretty much replace my job creation with EMCLI scripts, but there seem to be a bunch of discrepancies with the EMCLI compared to the regular Cloud Control interface. Now I admit I’m a newbie at this, but here’s what I’ve seen so far.
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 188.8.131.52 (no BP), Clusterware 184.108.40.206, 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: firstname.lastname@example.org (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
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:
When running the same query multiple times, several questions come to mind:
All of this can be answered from data in Active Session History or ASH.
The following query finds the maximum, minimum and average execution times in seconds as well as the time of the slowest execution which is given by start time and end time of the slowest exectuiton:
Sorted Hash Clusters have been around for several years, but I’ve not yet seen them being used, or even investigated in detail. This is a bit of a shame, really, because they seem to be engineered to address a couple of interesting performance patterns.
The basic concept is that data items that look alike are stored together (clustered) by applying a hashing function to generate a block address; but on top of that, if you query the data by “hashkey”, the results are returned in sorted order of a pre-defined “sortkey” without any need for sorting. (On top of everything else, the manuals describing what happens and how it works are wrong).
There are 3 kinds of CPU in the Oracle stats.
Starting in 10g Oracle records both the CPU used by the instance as well as the load on the system in v$sysmetric. This is awesome as we can see how busy the system is and how much of the CPU Oracle is responsible for: