{"id":14304,"date":"2019-12-21T05:57:52","date_gmt":"2019-12-21T05:57:52","guid":{"rendered":"https:\/\/dbtut.com\/?p=14304"},"modified":"2019-12-23T07:18:36","modified_gmt":"2019-12-23T07:18:36","slug":"sql-profiles-and-baselines","status":"publish","type":"post","link":"https:\/\/dbtut.com\/index.php\/2019\/12\/21\/sql-profiles-and-baselines\/","title":{"rendered":"SQL Profiles and Baselines"},"content":{"rendered":"
Being a DBA we must know the difference between the SQL profile and the baselines. To start with we know that optimizer uses the information like gather stats of objects environments and bind variables to choose the best plan for the SQL execution .<\/p>\n
In some scenarios there are some defects in these inputs or the optimizer choose a not so good plan by it own.<\/p>\n
What is SQL Profiles?<\/h3>\n
SQL profiles contains the information that solve the above problems. When we use gather stats and bind variable with the SQL profile, a SQL profile helps the optimizer to minimize the mistakes and more likely to choose the optimal plan for the SQL execution.<\/p>\n
What is SQL Baselines?<\/h3>\n
A SQL baselines as the name suggests it creates a baseline for the accepted plans. when a query is parsed by the optimizer it will choose the best plan from the accepted baselines. If a different plan is found by the optimizer during the run of the SQL statement it will add the plan to the plan history, but it will not use the execution plan to execute the SQL statement until and unless it is verified to perform better than the existing plan.<\/p>\n
Difference Between SQL Profiles and SQL Baselines<\/h3>\n
SQL profiles only helps the optimizer to choose the better plan providing some additional stats and information but it does not\u00a0 force the optimizer for any specific plan . Because of this, SQL profiles can be shared between the different environment a example for which is given below in the post.<\/p>\n
Where as the SQL baselines constrain the optimizer to choose from the accepted set of plans. The CBO approach will be used but it will only apply to the only accepted plans from the baselines.<\/p>\n
So what we choose SQL Profiles or the Baselines?<\/h3>\n
Well the answer to the above question is based upon the approach and what you want to achieve. You should use SQL profiles if you just want to help the optimizer in its costing process this approach can be very useful in cases where you want to system to adapt quickly to changes like new object stats.<\/p>\n
SQL baselines should be used where you specifically want to control which plans should be used by the optimizer.<\/p>\n
SPM creating SQL plan baselines<\/h4>\n
What is SPM and how it does affect the performance of your environment.<\/p>\n
Suddenly the execution plan for your SQL has been changed and you are facing the slowness, there are many parameters which can affect this like stale stats of the objects or changes in the few optimizer related parameters.<\/p>\n
All a DBA want is that plan should only change when they result in the performance gains else the optimizer should maintain the status quo. In other words, the optimizer should not pick bad plans.<\/p>\n
SQ<\/strong>L Plan Management<\/h4>\n
For a set of SQL statements SPM allows the database to maintain the stable performance these SQL statements which are managed by SPM are called as managed SQL statements. SPM mainly helps in maintaining the two objectives<\/p>\n
\n
Prevent the managed SQL statements from performance degradation in case there are database system changes<\/li>\n
And if there are changes in the database it offers the managed SQL statements to accept the performance improvements gracefully.<\/li>\n<\/ul>\n
SPM can be enabled manually, or it can be left to work automatically. By using the manual mode, we can control if we want to do it partially or wholly. SPM maintains a plan history of these managed SQL statements on disk consisting of different execution plan generated for each SQL statements and SPM helps in enabling the detection of plan changes of these SQL statements.<\/p>\n
A higher version of oracle optimizer is called as SPM aware optimizer who access and manages this information which is stored in the repository called as SQL management base (SBM).<\/p>\n
SPM Aware optimizer uses the information from plan history to determine whether the current execution plan generated by the cost best method is a brand new or not. The brand-new plan might have the potential to cause the performance degradation until and unless its verified. For this very reason the SPM aware optimizer does not chose the brand-new execution plan based upon the cost. It chooses the plan form a set of accepted plans which is verified to not to cause the performance degradation and these set of set of accepted set of plans is called as SQL baselines. SQL plan base lines are the subset of plan history.<\/p>\n
The brand-new plan will be added to the plan history as a not good or non-accepted plan. Later using the SPM utility, we can verify the plan if it shows still bad performance or it provides a performance improvements then it can be added to the plan history as accepted plan.<\/p>\n
There are multiple ways to create the SQL plan baselines. I have described tow which are widely used.<\/p>\n
Creating SQL plan baselines from cursor cache<\/h3>\n
Lets just say we have a query with a SQL_ID = abc123def and the Plan hash value as : 123456789<\/p>\n
The below procedure will create a SQL baseline.<\/p>\n
Creating SQL plan baselines using a staging table<\/h2>\n
Using this method, we can share the SQL baselines from one system to another system as this method loads the profiles in staging and that can be imported to the target environment.<\/p>\n
On the source system where we have the SQL baselines which can be created from the above method, we need to create a staging table so the SQL baselines can be packed into it.<\/p>\n