KScope 11: Managing Parallel Execution without Tuning in 11gR2

I've gotten to see Jean-Pierre Djicks speak a couple of times over the last month or so, and he doesn't disappoint.

Last month at the BI Forum, it was Big Data: Achieve the Impossible in Real-Time, which was really cool because he talked about the fusion of data capture/mining/whatever in regards to sailing, specifically the BMW-ORACLE sailing team.

It wasn't quite as exciting as that, but some pretty cool nuggets came out of it.

As a pseudo dba, or someone who's never had to manage some of the massive systems that many of you have to manage, memory management has been...well, intimidating (theme for the week, month and year).

Throw parallel into the mix and I'm pretty much a lost cause.

Now I can enable parallel, I have rudimentary knowledge of it...but you don't want me managing that on my own.

Enter Managing Parallel Execution without Tuning in 11gR2 (if I find the presentation, I'll link it up).

The one item that really stuck out at me was the idea of queueing. Prior to 11gR2, if all other resources were taken up by other SQL statements, your SQL statement would run serially. That's no longer the case (if enabled). Now, Oracle will queue up your SQL statement to run with the amount of resources that has been designated for it. In my experience, that's a good thing.

Prior to this release (and again, if you have it enabled), your SQL statement would run at the same exact time at the others, but since there are no resources for it, it would be slow as...well, slow. Now, you may have to wait a little bit for it to actually run, but it will run with the parallel resources that were intended (excuse my lack of articulation, I'm sure someone will correct me).