Posted by Alex Fatkulin on Nov 27, 2007
This will be the final post in my series on Result Caches. In my previous article, I had already got almost everything. Almost — four CPUs (cores) were still not enough to saturate the single latch. As you’ve probably already guessed, today we are going with an eight-way test.
Please note that today’s numbers are different since I’m using an entirely different hardware platform. While the four-way tests were done on a 2.4GHz Core 2 Quad box, today’s eight-way tests were done using four dual core Itanium 2 CPUs running at 1.1GHz.
Let’s take a look at the results:
| # of processes |
Buffer Cache |
% linear |
Result Cache |
% linear |
| 1 |
15085 |
100% |
15451 |
100% |
| 2 |
26745 |
88.65% |
28881 |
93.46% |
| 3 |
39144 |
86.5% |
40628 |
87.65% |
| 4 |
52342 |
86.75% |
52625 |
85.15% |
| 5 |
63922 |
84.75% |
62767 |
81.25% |
| 6 |
76336 |
84.34% |
69549 |
75.02% |
| 7 |
88844 |
84.14% |
74208 |
68.61% |
| 8 |
100959 |
83.66% |
76768 |
62.11% |
I made a nice-looking graph from this:
Read the rest of this entry . . .
Posted by Alex Fatkulin on Nov 12, 2007
In my previous blog entry, I explained why I would expect Result Cache not to scale well. Unfortunately, at the time that blog entry was written, I had no access to hardware with more than two cores. That left me in an everything-but-the-proof state. “Theory without practice is sterile.” ©Albert Einstein.
Since then, I got a chance to re-run my test cases on a quad-core CPU, moving one step forward.
I re-executed my test cases with one to four processes against the Buffer Cache and the Result Cache in order to capture the number of lookups per second. I raised number of iterations to 1M to make the results more stable though.
Here is what I got: Read the rest of this entry . . .
Posted by Christo Kutrovsky on Nov 8, 2007
Thinking I had something new, I wrote this article about recovering deleted files. However, it turns out Frits Hoogland had already blogged about recovery of deleted files on linux, as Frits pointed out in a comment on my blog, where he also mentioned a metalink note on this matter.
The note ID is: 444749.1 “Retrieve deleted files on Unix / Linux using File Descriptors”. I went and looked into it and the procedure it describes.
Although it does explain how to recover the deleted file, this procedure will leave the database in an inconsistent state. It will corrupt your database. Queries will produce the wrong results randomly, depending on cache usage, how busy the database is, et cetera.
(Before you read the details, I would like to point out that this metalink note is not fully reviewed, as it states in the very beginning of the note:)
“This document is being delivered to you via Oracle Support’s Rapid Visibility (RaV) process, and therefore has not been subject to an independent technical review.”
Read the rest of this entry . . .
Posted by Alex Fatkulin on Sep 13, 2007
In the previous article, I described my observations of RC Enqueue. Now it is time to take a look at the RC latches.
Latches, being serialization devices, are scalability inhibitors. Not that they inherently prevent you from scaling, quite the opposite is true. Serialization is a must if you expect your system to produce anything apart from GIGO (Garbage In Garbage Out). Concurrency is essentially made possible through serialization of shared resources. That being said, I would expect Result Cache to beat Oracle’s buffer cache on read-only workloads, since that is what RC was designed for. That is, Result Cache should perform faster and scale better.
Read the rest of this entry . . .
