Submitted by rleishman on Wed, 2014-07-02 06:04
After more than 20 years of working with Oracle databases, I have recently found myself using SQL Server for the very first time. Until now, I have been a passive observer in the My-Database-Is-Better-Than-Yours wars, so it’s a pleasant change to be able to finally contribute.
Submitted by rleishman on Thu, 2013-05-30 01:34
(with apologies to Robert Ludlum and Eric Van Lustbader)
Oracle performance tuning is an excellent source of myths. The very best ones have a group of adherents who continue to support the myth even when presented with counter-examples. Who’s heard of these?
- Joins are faster than sub-queries
- Sub-queries are faster than joins
- Full Table Scans are bad
Those ones have been around as long as I can remember. Probably the single greatest concentration of Oracle performance tuning myths centres on Bitmap Indexes. Are these familiar?
- Bitmap indexes are good for low-cardinality columns, whereas B-Tree indexes are good for high-cardinality columns.
- Bitmap indexes are slow to update.
- Bitmap indexes don't support concurrent updates.
Submitted by rleishman on Thu, 2013-05-30 01:12
This is first post of the four-part epic - The Bitmap Conspiracy - detailing the structure and behaviour of Bitmap Indexes. Later in the series we will cover the internal structure of Bitmap Indexes, how Oracle uses them, and finally we will expose some of the myths surrounding them. But before we get there let’s just get a clear understanding of what a Bitmap Index actually is.
Submitted by rleishman on Thu, 2013-05-30 00:46
I’ve been tuning Oracle database applications for a long time now. I started out recognising some simple patterns and applying template fixes (Got a full table scan? Use an index!) but such a collection of “Do this; don’t do that” anecdotes will only take you so far. If you are curious (I was), you can uncover the reasons why one method is faster than another; i.e. what is the computer doing to make slow code so slow. I found that a good understanding of the internals meant that you didn’t always need to know how to tune a specific example because you could work it out for yourself.
In a database application, these investigations frequently lead to data structures; how does the database store its information and how does it retrieve it? Good information on the internals of Bitmap Indexes is hard to piece together, so in Part 2 of this Bitmap Indexing epic we will look more closely at the internals of Bitmap indexes.
Submitted by rleishman on Thu, 2013-05-30 00:31
This is Part 3 of The Bitmap Conspiracy, a four part epic on Bitmap Indexes.
In Part 1 we touched briefly on how Oracle can use Bitmap Indexes to resolve queries by translating equality and range predicates into bitmap retrievals. Now that we know more about how they are stored (see Part 2), let’s look closer at some of the operations that Oracle uses to access Bitmap Indexes and manipulate bitmaps.
Submitted by rleishman on Thu, 2013-05-30 00:16
Submitted by rleishman on Mon, 2010-11-08 17:29
Submitted by rleishman on Tue, 2010-09-14 01:50
Submitted by rleishman on Tue, 2008-02-19 20:29
I was at the supermarket the other day waiting my turn at the checkout behind another guy. The checkout-chick (I'm sure there is a more PC term, I just don't know what it is) just finished scanning his groceries and he asked her to wait until his wife returned with a few last-minute items. I've done it before, so steam didn't start coming out of my ears - yet. Fifteen seconds later she ran up - sorry, sorry - and checked out the last few items, so I wasn't really inconvenienced.
Submitted by rleishman on Wed, 2007-06-06 03:01
Aside from a nine month excursion to Sybase IQ, I've spent my entire career working with Oracle, so I don't profess too much expertise - indeed any! - about other RDBMS technologies. So in a weak attempt at self-education, I recently accepted an invitation to listen to a Teradata presentation directed at application developers.