Showing posts with label oracle. Show all posts
Showing posts with label oracle. Show all posts

Wednesday, March 9, 2011

Oracle database certifications in Japan or how to make more money from certs

I don't know if this is well-known, but the path to become an OCA/OCP/OCM is a bit different in Japan. First, the naming is different. There are four exams : Bronze, Silver, Gold, Platinium. Yes, one more exam. Before 10g or 11g (I don't remember), certifications in Japan had no relation with OCA/OCP/OCM. Now, Silver=OCA, Gold=OCP and Platinium=OCM. What about Bronze then ? That's where Oracle found a way to get more money from Japanese. Japanese people love exams. There are all sorts of exams in Japan. An exam about a famous manga written by Yokoyama Mitsuteru called sangokushi (very good by the way if you're interested in China's romance of the three kingdoms), an exam about fishes, etc... Moreover, IT companies in Japan are taking certifications very seriously. Certifications are almost must-have career objectives. So many IT employees are aiming at Oracle certifications. Ok, back to the Oracle database certification. Let's compare the path to OCA in Japan and in the US.

Becoming an OCA in Japan


Remember ? OCA is equivalent to Silver, and Bronze is a pre-requisite.

Step1 : Passing Bronze

Pre-requisites for Bronze. You need at least one of the following:

  • 11g SQL Basics I[11g SQLI] : 22260 yens
  • Bronze SQL Basics I[Bronze SQLI] : 22260 yens
Then, you can take the Bronze exam, which costs 22260 yens.

Step 2 : Passing Silver

With Bronze in your pocket, you're ready to go for Silver. This will cost you another 22,260 yens.

Congratulations, you've spent at least 66780 yens, which in the current rate is about 805 US dollars.

Becoming an OCA in the US


You need at least one of the following:
  • Introduction to Oracle9i SQL : 125 US dollars
  • 1Z0-047 Oracle Database SQL Expert : 195 US dollars
  • Oracle Database 11g: SQL Fundamentals I : 125 US dollars
After one of the pre-requisites is cleared, you can take the Oracle Database 11g Administration I, which costs 195 US dollars.

So the cheapest path is 320 US dollars.

How do you call that ?

Different countries, different rates. Yes. Still, 805 dollars vs 320 dollars. How do you call that ? Fraud ? Racket ? Whatever you call it, I only see it as a way to grab more money. Fortunately, most companies in Japan will pay the exam fees if you pass. Let's call it extra motivation then. Thank you Oracle.

Monday, February 7, 2011

Oracle ROWNUM : What it is and what it's not

What is ROWNUM ?

In Oracle, ROWNUM is a pseudocolumn added by Oracle after the data has been selected. The ROWNUM will be incremented only if the selected row satisfies the condition clause. A pseudocolumn does not physically exist, but it behaves like any table column. The first row returned by a query has a ROWNUM of 1, the second row has a ROWNUM of 2, etc... The ROWNUM can be used to retrieve the top n records of a query. For example, to return a maximum of ten cats from an animal table, the query would look like:
SELECT * from animals WHERE type='cat' and ROWNUM < 11

Pitfall 1: Ordered results

The preceding query returned ten cats. But it doesn't mean that the same ten cats will be returned each time we execute that query, because the fetched records are not ordered. However, adding a simple ORDER BY does not work:
SELECT * from animals WHERE type='cat' and ROWNUM < 11 ORDER BY name
because the results will be first fetched and then ordered. To get the first ten results of an ordered query, we have to fetch records and order them first :
SELECT * from ( SELECT * from animals WHERE type='cat' ORDER BY name) WHERE ROWNUM < 11

Pitfall 2: Getting the nth record

We may think that using the ROWNUM allows to fetch the nth record of a query. For example, getting the second cat of the list :
SELECT * from animals WHERE type='cat' and ROWNUM = 2
Unfortunatly, this doesn't work. In the first paragraph of this article, you might have noticed that some words are in bold : the ROWNUM is set after records were fetched and will be incremented only if the selected row satisfies the condition clause. What's the problem with that ? Imagine that there are ten cats in the animals table. After fetching ten cats, oracle will try to assign a ROWNUM to the first record. The first record ROWNUM is 1. But the query fetches only the record whose ROWNUM is 2. The first record will be skipped, but the ROWNUM will still be 1. The ROWNUM will not be incremented. Thus, the second record ROWNUM is 1. And again, the "ROWNUM = 2" condition is not satisfied. Finally, the ROWNUM will never be incremented, and no records will be fetched. The equality condition will only work with the first record (ROWNUM = 1).

Pitfall 3: Getting all records after the nth record

Well, the problem is the same as with getting the nth record. The condition will never be met. Having a condition looking like "WHERE ROWNUM > 10" will never return anything. The first record whose ROWNUM is 1 will not satisfy the condition, so 1 will be used again for the next record, and so on.

Execution plans

It's interesting to look at the difference of execution plan between "ROWNUM < 11" and "ROWNUM = 2". The first condition uses a "COUNT STOPKEY" operation, which means that Oracle performs a count operation where the number of rows returned is limited by the ROWNUM expression in the WHERE clause. Even if there are one billion records in the animals table, only the first ten records will be read.
SELECT * from animals WHERE ROWNUM < 11
------------------------------------------------------------------------------
| Id  | Operation          | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |         |    10 |   850 |     2   (0)| 00:00:01 |
|*  1 |  COUNT STOPKEY     |         |       |       |            |          |
|   2 |   TABLE ACCESS FULL| ANIMALS |    10 |   850 |     2   (0)| 00:00:01 |
------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(ROWNUM>10)
On the other hand, the erronous "ROWNUM = 2" condition produces the following plan:
SELECT * from animals WHERE ROWNUM = 2
-------------------------------------------------------------------------------
| Id  | Operation           | Name    | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------
|   0 | SELECT STATEMENT    |         |    80 |  6800 |     3   (0)| 00:00:01 |
|   1 |  COUNT              |         |       |       |            |          |
|*  2 |   FILTER            |         |       |       |            |          |
|   3 |    TABLE ACCESS FULL| ANIMALS |    80 |  6800 |     3   (0)| 00:00:01 |
-------------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter(ROWNUM=2)
We can see that Oracle goes through all records and tries to filter them using "ROWNUM = 2".

References

Friday, February 4, 2011

Oracle : Primary Keys and Non-Unique Indexes

I was asked by a colleague recently about "Unique and Nonunique Indexes" in Oracle Concepts guide :
Oracle recommends that unique indexes be created explicitly, using CREATE UNIQUE INDEX. Creating unique indexes through a primary key or unique constraint is not guaranteed to create a new index, and the index they create is not guaranteed to be a unique index.

Well, I was as puzzled as she was, by the following two facts:
  1. Creating unique indexes through a primary key or unique constraint is not guaranteed to create a new index.
  2. The index they create is not guaranteed to be a unique index.

Looking at the "PRIMARY KEY Integrity Constraints" of the same guide, it says :
Oracle Database enforces all PRIMARY KEY constraints using indexes. The primary key constraint created for a column is enforced by the implicit creation of:
  • A unique index on that column
  • A NOT NULL constraint for that column
Composite primary key constraints are limited to 32 columns, which is the same limitation imposed on composite indexes. The name of the index is the same as the name of the constraint. Also, you can specify the storage options for the index by including the ENABLE clause in the CREATE TABLE or ALTER TABLE statement used to create the constraint. If a usable index exists when a primary key constraint is created, then the primary key constraint uses that index rather than implicitly creating a new one.

The important part is "If a usable index exists when a primary key constraint is created, then the primary key constraint uses that index rather than implicitly creating a new one". I was under the false impression that set a PRIMARY KEY constraint on a table would create a unique index. Well, no, not necessarily. Oracle will reuse (thus not even create) a non-unique index for the constraint, when the columns on which the index is are the same as those for the primary key. This is also true for indexes having more columns than the primary key. As long as the columns used for the primary are the same as the first columns used for the index, the index will be reused. Unique or not.

Another thing to know is "Deferred Constraint Checking". From the Concepts guide :
You can defer checking constraints for validity until the end of the transaction.
  • A constraint is deferred if the system checks that it is satisfied only on commit. If a deferred constraint is violated, then commit causes the transaction to undo.
  • If a constraint is immediate (not deferred), then it is checked at the end of each statement. If it is violated, the statement is rolled back immediately.
What happens when a PRIMARY KEY is created as being DEFERRABLE ? Until the transaction is committed, it is allowed to have duplicate values. So a unique index cannot be used. Oracle has to use a non-unique index. Again, a primary key constraint is not necessarily ensured by a unique index.

The fun part is that :
  • If a unique index was used by a primary key constraint and that constraint is dropped, the index will also be dropped !
  • If a non-unique index was used by a primary key constraint and that constraint is dropped, the index will not be dropped.

References

Sunday, July 4, 2010

Book review : Beginning Oracle Database 11g Administration: From Novice to Professional

I have finished reading the book "Beginning Oracle Database 11g Administration: From Novice to Professional (APress)", by Iggy Fernandez. First of all, I am not a DBA. I'm using Oracle at work, but, most of the time, I'm only using basic SQL. I have nothing to do with database administration, but recently I wanted to know more about Oracle, and this book is just what I needed. The author doesn't go deeply into details, which that is not the purpose of the book. He introduces the most important topics (installation, monitoring, backups, recoveries, tuning...) in a very understandable manner. I don't think that this book will turn anyone into an Oracle Professional, as the title suggests, but it does cover enough material to make you more than a novice. I recommend it highly to anyone who wants to know the basic notions of the Oracle architecture and administration.

I plan to buy "Expert Oracle Database Architecture: Oracle Database Programming 9i, 10g, and 11g Techniques and Solutions" by Thomas Kyte, which is planned to be published this month. For the moment, I'll start reading the Oracle Concepts PDF file, which is available online.