10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 6 MAKING PCBSThe Old WayBefore we get to the new Parallel Queuing functionality we should probably review how it was done inprevious versions. The best tool we had at our disposal was Parallel Adaptive Multiuser, which providesthe ability to automatically downgrade the degree of parallelism for a given statement based on theworkload when a query executes. It is actually a powerful mechanism and it is the best approach we’vehad prior to 11gR2. This feature is enabled by setting the PARALLEL_ADAPTIVE_MULTI_USER parameter toTRUE. This is still the default in 11gR2 by the way, so this is definitely a parameter that you may want toconsider changing. The downside of this approach is that parallelized statements can have wildlyvarying execution times. As you can imagine, a statement that gets 32 slaves one time and then getsdowngraded to serial execution the next time will probably not make the users very happy.The argument for this type of approach is that stuff is going to run slower if the system is busyregardless of what you do, and that users expect it to run slower when the system is busy. The first part ofthat statement may be true, but I don’t believe the second part is (at least in most cases). The biggerproblem with the downgrade mechanism though is that the decision about how many slaves to use isbased on a single point in time, the point when the parallel statement starts. Recall that once the degreeof parallelism (DOP) is set for an execution plan, it cannot be changed. The statement will run tocompletion with the number of slaves it was assigned, even if additional resources become availablewhile it is running.So consider the statement that takes one minute to execute with 32 slaves. And suppose that samestatement gets downgraded to serial due to a momentarily high load. And say that a few seconds after itstarts, the system load drops back to more normal levels. Unfortunately, the serialized statement willcontinue to run for nearly 30 minutes with its single process, even though on average, the system is notbusier than usual. This sort of erratic performance can wreak havoc for those using the system, and forthose supporting it.The New WayNow let’s compare Parallel Adaptive Multi User (the old way), with the new mechanism introduced in11gR2 that allows parallel statements to be queued. This mechanism separates long running parallelqueries from the rest of the workload. The mechanics are pretty simple. Turn the feature on. Set a targetnumber of parallel slaves using the PARALLEL_SERVERS_TARGET parameter. Run stuff. If a statement thatrequires exceeding the target tries to start, it will be queued until the required number of slaves becomeavailable. There are of course many details to consider and other control mechanisms that can beapplied to manage the process. So let’s look at how it behaves:SYS@EXDB1> alter system set parallel_degree_policy=auto;System altered.SYS@EXDB1> alter system set parallel_servers_target=10;System altered.SYS@EXDB1> @parmsEnter value for parameter: parallel%Enter value for isset:Enter value for show_hidden:153

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!