Posts by Alex Fatkulin
Recently I’ve been puzzled with the performance difference observed between 11GR1 and 11GR2. As part of the investigation I’ve decided to compare session stats from both 11GR1 and 11GR2 and found that there is a big difference for session cursor cache hits. But the number of session cursor cache hits I’ve been observing in 11GR2 just didn’t made any sense while being absolutely fine in 11GR1. An overflow was certainly a possibility, though in 2010, it’s not like someone should be counting every bit especially if they didn’t in 11GR1! Anyway it was worth a shot so I’ve decided to check it out…
There has been a recent thread on ORACLE-L where the poster asked why there is an extra filter predicate which appears when functions are being used in the where clause. We can observe the behavior using the following test case.
I’ve hit a bug in Oracle 18.104.22.168 when working with deferrable constraints which I think is worth sharing as it may have profound consequences under certain scenarios.Here it is.
This is the third post in Oracle GoldenGate Extract Internals series (links to part I and part II). In this post, we’re going to take a closer look at various queries that the Extract process uses against the database. As before, we will start by examining the strace output.
Today we continue looking at various aspects of how the Oracle GoldenGate extract process works. One of the follow up questions to part I was about the way the Extract process reads from ASM storage. I’ve provided the answer, however, today we’re going get a detailed look at how the Extract process interacts with an ASM instance and what kind of implications may result. Let’s take a look at what changes in the Extract process loop when it reads from ASM storage:
Since GoldenGate has been declared as a strategic direction for replication technology by Oracle, it sounds like it’s time to get up to speed with various aspects of how this technology works and performs. Let’s see what kind of techniques they were able to utilize in order to achieve their goals. I did a simple replication setup between two different databases with the Extract, DataPump and Replicat processes. I’m planning to take a look at all of these but today is the Extract’s process turn.
It is somewhat timely that we’ve been doing some Oracle Golden Gate testing which in turn made me curious to take a closer look at Oracle Streams in 11GR2 and see where all the performance is coming from. I’ve setup a simple replication for table t1 from schema src to schema dst, changed Apply Server parallelism to 1 and did a simple test with inserting 100 rows while performing a sql trace. Let’s get started.
In my previous post, I described the most common cause for unstable plans due to bind peeking — histograms. It is now time to move forward and take a look at another case, namely range-based predicates. Strictly speaking, the cases I’m going to describe can appear without range-based predicates as well, you just need to remember that a range-based operation doesn’t necessarily imply a range-based predicate.
As some of you probably already noticed, there was a thread on AskTom discussing the scalability tests I did back in 2007. You are welcome to read the entire thread, but in a nutshell, Tom Kyte claimed that my tests did not reflect how one would use the result cache in the real world. What is “real world?”
I wrote this post because I feel there is a great need for it. The number of people struggling with unstable query plans due to bind peeking in Oracle 10G is enormous, to say the least. More than that, solutions like disabling bind variable peeking are driving us away from understanding the root cause of the problem and applying the right fix to it.