Optimizing the Execution Plan in an Oracle Database

Optimizing the Execution Plan in an Oracle Database Alexandru Boicea, Florin Radulescu, Dan Ungureanu Politehnica University of Bucharest, Faculty of Automation and Computer Science Splaiul Independentei Street , No. 313, Bucharest 6, Romania

E-mail: [email protected] Abstract. This paper presents a case study for different methods of optimization the execution plan in Oracle 11g Database for Windows with the view to obtaining the shortest time of execution of stored procedures and functions. The testing was made on application of mobile telephony through execution of stored procedure PL/SQL which is processing telephone invoices on a database with a million recordings. The procedure verifies if the invoices for mobile telephony are in accordance with the type of contract. Some system parameters have greatly influenced the performance of execution times of stored procedures and functions. Keywords: database, instance, session, instruction, index PACS: 07.05.Kf

INTRODUCTION Optimization of the execution plan in Oracle11g Database is a complex problem because of the large number of system parameters, of the model of database selected by the designer and not least due to the design of the application’s procedures and functions. Using Oracle hints can be very complicated and Oracle developers only use hints as a last resort, preferring to alter the statistics to change the execution plan. Oracle contains more than 124 hints, and many of them are not found in the Oracle documentation. The following work presents the manner in which some parameters of system are influenced by the existence of an application following mainly the number of execution of stored procedures and functions and the total time of execution. For this reason the stored procedure Transformation_ Loading was chosen which executes cyclically other stored procedures and functions. The execution diagram is presented in Figure 1. Optimization is starting from the performances presented in the Table 1 which is showing the numbers of executions (Count) of every procedure and function and the average time of executions (Average Time). After modification of the system parameters, specified for every optimization type, were made in average 100 execution tests at different moments in time with maximum 300 simultaneous users connected to the database. A major problem that must be resolved is how to migrate the statistics that were used in SQL testing into the production environment when the SQL is migrated.

However, the DBA must ensure that a migration of statistics from test into production does not adversely affect the execution plans of other SQL that touch the target table. Hence, the DBA will carefully manage the statistics, ensuring that no SQL changes execution plans after it is migrated into production. TABLE 1. The Initial Execution Times Description Start_Opt Transformation_Loading Execute_Begining_Statemens Process_EDI_Data Update_Invoice_Info Execute_Parse_Statements Execute_Level_Two Split_To_Child_New Merge_Bills EmptyTable WriteInLog

Count (exec) 1 1 39 39 39 39 9 220 1124 2043 8838

AverageTime(sec) 628 621 33 534 49 178 354 23 18 35 160

The procedure Start_Opt is monitoring the total time of execution spent from the time of launching an execution until the finalization of the complete cycle, taking into consideration just the execution times over 1 second.

Start_Opt

Transformation_Loading

Execute_Begining_Statemens

Process_EDI_Data

Split_To_Child_New

Update_Invoice_Info

Execute_Level_Two

EmptyTable

Execute_Parse_Statements

Merge_Bills

WriteInLog

FIGURE 1. Execution Diagram of the Stored Procedures and Functions

The optimization will take place at the levels INSTANCE, SESSION and INSTRUCTIONS.

OPTIMIZATION AT THE LEVEL OF INSTANCE Oracle offers several optimizer modes that allow to choose your definition of the "best" execution plan (Garmany, J. et. al., 2008). Optimization at the level of instance is made setting the parameter OPTIMIZER_MODE on the Configuration menu, accessed from the Oracle console. The values of this parameter can be: Optimezer_Mode = CHOOSE – optimization at the level of cost Optimezer_Mode = FIRST_ROWS – optimization of the answering times of interrogation Optimezer_Mode = ALL_ROWS – optimization of the consumption of resources Optimezer_Mode = RULE – optimization at the level of rules There were obtained the following average times of execution in terms of options: • Optimezer_Mode = CHOOSE – 541 sec • Optimezer_Mode = FIRST_ROWS – 537 sec • Optimezer_Mode = ALL_ROWS – 549 sec • Optimezer_Mode = RULE – 504 sec Therefore the optimization based on rules (indifferently of the existence of statistics) has the better performances.

OPTIMIZATION AT THE LEVEL OF SESSION For changing the optimization at the level of session would be using the order: ALTER SESSION SET OPTIMEZER_GOAL = option where option is one of the option presented in the item 2. The all_rows optimizer mode is designed to minimize computing resources and it favors full-table scans. Index access (first_rows) adds additional I/O overhead, but they return rows faster, back to the originating query. The rule and choose modes reflect the obsolete rule-based optimizer, so we will focus here. The following average times of execution were obtained in terms of options: • Optimezer_Goal = CHOOSE – 453 sec • Optimezer_Goal = FIRST_ROWS – 476 sec • Optimezer_Goal = ALL_ROWS – 490 sec • Optimezer_Goal = RULE – 429 sec Optimization based on rules obtained the best time of execution at the session level too. After analyzing the results, it can be observed that optimization at the level of session is always prevalently comparative with the one at the level of instance.

You can use the time performance views: V$Sys_Time_Model and V$Sess_Time_Model. These views gather cumulative stats for either the entire instance, or per session(Burleson, D.K., 2006).

OPTIMIZATION AT THE LEVEL OF INSTRUCTION Let's take a quick look at how hints are used to alter optimized execution plans. A optimizer hint is an optimizer directive placed inside the SQL statement and used in those rare cases where the optimizer makes an incorrect decision about the execution plan. Because hints are inside comments, it is important to ensure that the hint name is spelled correctly and that the hint is appropriate to the query. Changing the optimization at the level of instruction can be made indicating the type of optimization respecting the following syntax: SELECT /* hint_name * / column1,column2,… INTO var1, var2, … FROM table_name WHERE conditions; where hint_name represent the type of optimization and can be CHOOSE, FIRST_ROWS, ALL_ROWS, RULE, COST, INDEX, CACHE, CLUSTER, so on. Because SQL is a declarative language, a query can be written in many different ways, each with a different execution plan. For changing the optimization would be changed the sub application and cursors from procedures and functions, specifying the type of optimization. From all the tested types the smallest average time of execution was obtained using the optimization based on COST – 309 sec.

USING THE INDEXES Using the indexes can bring a meaningful reduction of execution times (sometimes several fold), but can have inverse effects too if a specific strategy is not respected or if sufficient physical resources are not allocated. It’s very important to appreciate the necessary space for saving and how much will be incremented the table allocated to the index (Carr, B. et. al., 2008). For determining the objects founded nearest to the physical limit of stocking because of the maximum number of limited extensions we can use the following command SQL: SELECT owner, segment, name, segment_type, max_extents, sum (extents) FROM dba_segments WHERE owner=’ADMIN’ AND segment_type LIKE ‘INDEX‘ GROUP BY owner, segment_name, segment_type, max_extents ORDER BY segment_name;

In the case of a large number is inserted, updated or deleted from database, the indexes will become fragmented or unbalanced. An unbalanced index will contain parts accessed more frequently than others and can create conflicts when the disk is accessed, inevitably increasing the time of execution. Many times the partitioning of an index is enforced, being assured a bigger flexibility through a faster accessibility. Statistical date concerning indexing can be obtained using the next SQL command: ANALYZE INDEX index_name COMPUTE ESTIMATE STATISTICS; and the results will be founded in the table INDEX_STAT. The smallest average time of execution was 410 sec.

CONCLUSIONS In analyzing the results of testing, it can be observed that the obtained time of execution through optimization at the session level is better than the one obtained through optimization at the level of instance. Nevertheless, optimization at level of instruction (based on costs) has the best results concerning the time of execution of procedures. This fact draws us to the conclusion to obtain higher performance. An Oracle application depends in a higher degree on developers, which can interfere in the instruction level, while the administrator can interfere only in the level of parameters of system. Always the optimal performances can be obtained through the setting of parameters of system correlated with the optimization of applications at the level of instruction, specially in a database with a big number of registrations. A proper and suggestive representation is observed at the AVERAGE TIME in the histogram presented in Figure 2.

700 600 500 400 300 200 100 0 Avg.Tim e(sec)

INIT

INST

SESS

INSTR

INDEX

628

504

429

309

410

FIGURE 2. The Average Execution Times, Initial and After Optimization

The change in system parameters is very dangerous because a single parameter change could adversely affect the performance of an entire enterprise. Changes to critical system parameters such as optimizer_mode, optimizer_index_cost_adj, and optimizer_index_caching should only be made after careful system testing. However, Oracle does not recommend changing the default values for many of these parameters because the changes can affect the execution plans for thousands of SQL statements. Developers must know very well the structure of the database when they intervene in operating the optimizer, therefore the incorrect options can be ignored in the best case, but can diminish dramatically the performances of the optimizer. For example, the optimizer is using very rarely an index in the case of an interrogation which is returning a very big number of lines from a table. In this situation if the index is deactivated we will have better performances. If an SQL instruction is modifying an indexed column, this will make the optimizer not use in execution the indexes that are having the respective column. Modifying the clause WHERE in an SQL instruction, without modifying the result of interrogation, can determine the optimizer to suppress the use of index. The optimization depends on a model and it depends on a number of assumptions about how that model will be had at run-time. Sometimes the model isn’t realistic enough; sometimes the run-time activity doesn’t quite match the model(Lewis, J., 2006). And just to make things that little bit harder to understand, sometimes the model, the run-time action, or both, will change as you upgrade the version of Oracle.

REFERENCES 1. Carr, B., Garmany, J., Karam, S., Hartmann, L.& Jain,V.J. (2008), Oracle 11g New Features, Ed. Rampant TechPress, ISBN 978-0-9797951-0-70-9797951-0-9, USA 2. Garmany, J., Karam,S., Hartmann, L. & Jain, V.J.(2008) Oracle 11g SQL performance analyzer concepts, Oracle Tips by Burleson Consulting January 16th, 2008, USA 3. Burleson, D.K.(2006) Oracle Tuning: The Definitive Reference, ISBN 0-9744486-2-1, Ed. Library of Congress, USA 4. Lewis, J.(2006), Cost Based Oracle: Fundamentals, ISBN 1-59059-636-6, Ed. Apress, USA 5. http://www.oracle.com/technology/products/database/oracle11g/index.html