Oracle

It’s a little over a month before I start a run of four PL/SQL Masterclasses in the Asia Pacific region.

• Singapore (14-15 October)
• Syndey (18-19 October)
• Melbourne (21-22 October)
• Hong Kong (25-26 October)

If you are interested, contact Oracle and get booked on. The details are here: APAC Seminars.

Cheers

Tim…

I expect we’ll see some announcements at Oracle Open World in a couple of weeks (I don’t know if they will really call it V3 yet by the way).

DISCLAIMER: This is all complete conjecture on my part. I don’t work for Oracle and I have not had any conversations with any Oracle employees about official future directions or plans. (I probably would have had to sign a non-disclosure before I could have any of those discussions and then I wouldn’t be able to do this post).

text

Anyway, here’s the list of things I am thinking we might see:

Bigger Database Servers - I mean physically bigger, with open slots, so we can put HBA’s in them to attach to external storage for migration and backup purposes. Sun 4275’s perhaps since they are already using them as storage servers. The only real issue is that we’d run out of space on a full rack configuration, but if the machines are beefier, perhaps we wouldn’t need as many DB servers anyway.

Bigger Database Servers - I mean more memory and more processing power. Faster chips and bigger DIMMs are a no-brainer. Just put them in the existing 4170 boxes. But how about different models altogether. M series perhaps (which also means a change in O/S). Should be fairly easy to do actually as the DB already runs on Solaris. Might make the Sun shops really happy as well. ;-)

More Options - I expect we’ll see a little more flexibility in the configurations, because “One Size Fits All” really doesn’t (or at least many people think that it doesn’t). Anyone want a 2/3 rack?

OK, this one might be contentious, but what the heck – somebody has to say it. Let’s start with a question:

Raise your hand if you have a feeling, even a slight one, that storage arrays suck?

Most DBAs and sysadmins that I speak to certainly have this feeling. They cannot understand why the performance of this very large and expensive array is nearly always lower than they achieve from the hard drive in their desktop computer. OK, so the array can do more aggregate IOPs, but why is it that 13ms, for example, is considered a reasonable average response time? Or worse, why is that some of my I/Os take several hundred milliseconds? And how is it possible that my database is reporting 500ms I/Os and the array is reporting that they are all less than 10ms? These are the questions that are lodged in the minds of my customers.

Storage Arrays do some things remarkably well. Availability, for example, is something that is pretty much nailed in Storage Array Land, both at the fabric layer and the actual array itself. There are exceptions: I think that large Fibre Channel fabrics are a High Availability disaster, and the cost of entry with director-class switches makes no sense when small fabrics can be built using commodity hardware. I have a more general opinion on Fibre Channel actually – it is an ex-format, it is pushing up the lillies. More on that in another blog post, though, I’m not done with the array yet!

In my post entitled OpenWorld 2010 Unconference Open For JavaOne And/Or Oracle Develop Registrants Only I quoted the Unconference policy which, at the time, stated Unconference attendance was only open to JavaOne and Oracle Develop folks. I just received email stating that the policy has changed and that the new wording is as follows: Now, [...]

It has come to my attention that the Unconference offered during this year’s OpenWorld can only be attended by registered JavaOne or OracleDevelop attendees as per the following quote: Participation and attendance is reserved to JavaOne and Oracle Develop attendees. You have to be registered to JavaOne or Oracle Develop 2010 to attend any of [...]

As Oracle OpenWorld is just around the corner and you are probably getting your session schedule together, I thought I’d pass on this (nearly complete) list of sessions of which one or more of the presenters is an OakTable member. There is no doubt in my mind that these sessions will contain some of the best technical content presented at OpenWorld so be sure and pre-register for these sessions today. Hope to see you there!

So, which number takes more bytes inside an Oracle row?

A: 123

B:  1000000000000000000000000000000000000

And the correct answer is … (drumroll) … A! The “big” number 1000000000000000000000000000000000000 actually takes less space than the “small” 123!

Let’s verify this:

SQL> select vsize(123) A, vsize(1000000000000000000000000000000000000) B from dual;

         A          B
---------- ----------
         3          2

WTF? Why does such a small number 123 take more space than  1000000000000000000000000000000000000 ?

Well, the answer lies in how Oracle stores numbers. Oracle NUMBER datatype doesn’t store numbers in their platform-native integer format. Oracle uses it’s own format which stores numbers in scientific notation, in exponent-mantissa form. More details about this here.

You can use the DUMP sql function to see the actual binary value of the number data stored:

select dump(123) from dual;

DUMP(123)
---------------------
Typ=2 Len=3: 194,2,24

SQL> select dump(1000000000000000000000000000000000000) from dual;

DUMP(10000000000000
-------------------
Typ=2 Len=2: Typ=2 Len=2: 211,2

So, although the number 1000000000000000000000000000000000000 is bigger than 123, when stored in base-10 exponent form, it really carries much less information in it than 123 (1 x 10^36 vs 123 x 10^0). Oracle doesn’t need many bits for keeping the precision of this large value as it happens to be a power of 10.

See what happens when I store a number only slightly bigger or smaller than the original large number, now the stored number requires much more storage for keeping the required precision:

Here’s the list of events where I’ll speak this year:

Michigan OakTable Symposium 2010
Ann Arbor, MI
16-17 September 2010

Considering the concentration of OakTable members there, this will be an awesome event!

I will be delivering my “Back to Basics: Choosing The Entry Point to Performance Troubleshooting Wisely” and “Understanding LGWR, log file sync waits and commit performance” sessions there.

Promo video:
http://www.oaktable.net/media/michigan-oaktable-symposium-2010-promo

Agenda & Registration:
http://michigan.oaktable.net/

Oracle Open #ff0000;">Closed World
San Francisco, CA
19-22. September

Note that I won’t be speaking at the official Oracle Open World conference, but I will be speaking at a secret underground event there, about some really fun stuff, like deep internals, hacking, kernel tracing and of course advanced troubleshooting ;-) And rest of the time I’ll be in some bar.

NYOUG Fall 2010 Training Session
Manhattan, NYC, NY
16 November 2010

Here’s some white Exaddata text

Well, I guess it’s official. A couple of weeks ago I committed to write an Exadata book for Apress, along with my intrepid co-author Randy Johnson. For those of you who don’t know Randy, he’s a very experienced Oracle Guy with a wealth of knowledge, particularly around RAC. I think the two of us make a pretty good team - making up for each others weaknesses (oh wait, I should say we have “Complimentary Skill Sets” - yeah that sounds better).

Anyway, it turns out that writing a book is a lot of work! The way Tom Kyte turns them out I thought it must be pretty easy, but I’ve always been a little overconfident. So I’m starting to realize that I may not have time to do as many blog posts as I might like. But I must say that I am really excited about the subject matter! So I think it will be worth the effort. By the way, that’s not the official cover art (or even the official title as far as I know). I just hacked that together with a Adobe Illustrator. ;-)

I’d like to direct readers to an important blog update/correction. In my post entitled An Intel Xeon 5400 System That Outperforms An Intel 5500 (Nehalem EP) System? Believe It…Or Know It I blogged about an erroneous conclusion I had drawn about a test performed on these two processor models. I think the update does the blog [...]