Comments on: Exadata Offload – The Secret Sauce

By: Fun with _SERIAL_DIRECT_READ « ORAganism

Fun with _SERIAL_DIRECT_READ « ORAganism — Mon, 27 Jun 2011 20:33:31 +0000

[...] getting a reasonable amount of attention since 11g was released. Doug Burns, Dion Cho (and here), Kerry Osborne and Miladin Modrakovic have all written on the subject. Tanel Põder also covered it in his [...]

By: Exadata « Oracle Scratchpad

Exadata « Oracle Scratchpad — Tue, 14 Sep 2010 19:00:32 +0000

[...] Offloading [...]

By: osborne

osborne — Thu, 08 Jul 2010 15:57:09 +0000

Yes SPARC. We’ve loaded up about a 1T database and run a batch process that takes 4-5 hours on the Sun in about 45min on a quarter rack. That’s without doing anything other than loading the data and running it (across both nodes of course). But in general, I was just talking about how it feels. Everything on the Sun feels like it runs at a glacial speed vs. what we’ve gotten used to on the Exadata.

By: Kevin Closson

Kevin Closson — Thu, 08 Jul 2010 15:49:15 +0000

>32 cpu Solaris

I presume SPARC? No, 32 SPARC anything compared to a Database Machine (112 Nehalem EP cores) is not fair :-)

By: osborne

osborne — Thu, 08 Jul 2010 02:58:28 +0000

Thanks for stopping by Kevin.

1. I guess I should have been more specific on the “full scans” comment. I meant full scans of indexes and tables. That’s why I didn’t say “full table scans”. ;) I edited the post to say “index range scans” instead of “index access” as well.

2. The storage indexes are awesome!

By the way, I’ve been working on 32 cpu Solaris box with SSD for the past week and I can’t believe how slow it feels.

Kerry

By: Kevin Closson

Kevin Closson — Wed, 07 Jul 2010 21:05:08 +0000

Two points if I may…

> Statements using index access are not off-loadable (the optimizer has to pick a plan with a full scan). Check put the statement commented “test index” for an example.

…Index Fast Full Scans is also serviced by Smart Scan. Smart Scan has to be access method full and direct (serial direct or PQ direct all the same).

>Yes, it’s using the storage index. I was frankly amazed at how fast it was though

…That’s because there is nothing faster than not doing something. Unlike on-disk Indexes, which are optimized to decrease the time it takes to *find* something, Storage Indexes are there only to quickly determine whether or not anything needs to be done. To that end it is like comparing reduced I/O to eliminated I/O.

…sounds like your Exadata testing is moving right along! Good to hear.

By: osborne

osborne — Fri, 18 Jun 2010 16:46:01 +0000

Your welcome, I’ll try to keep them coming. I’ve got a whole list of things I’d like to write about on the Exadata front, but there are never enough hours in the day to get it all done. On the music front, I never cease to be amazed at how many techies are also musicians. I think there are a number of similarities in thought processes (particularly between programming and musical improvisation). Some day I’ll get around posting on that topic as well.

Kerry

By: Eric Guyer

Eric Guyer — Fri, 18 Jun 2010 13:37:29 +0000

Thanks for the update! Keep those Exadata-related posts coming :-D

By the way, we should compare notes on guitar playing sometime…

By: osborne

osborne — Wed, 16 Jun 2010 13:17:16 +0000

Nigel,

Of course, I’m sure you’re right about the block overhead and free space. I haven’t yet had a look at the blocks to see if there are any differences in how they are stored, but I expect that in the absence of HCC they are the same as non-Exadata.

Kerry

By: osborne

osborne — Wed, 16 Jun 2010 13:13:47 +0000

Timur,

“Of course it’s not that :)”

Yes, it’s using the storage index. I was frankly amazed at how fast it was though. I will save the details for a later post, but it appears that the storage index knows precisely where to look for nulls. Dealing with nulls has traditionally been a sore spot, so this optimization is pretty interesting.

Kerry