That’s Me
|
Oracle Certified Professional
|
|
7.3, 8i, 9i,10g, 11g
|
|
11i Apps DBA OCP
|
|
10g RAC OCE
|
|
Certified GoldenGate Implementation Specialist
|
|
10g OCM
|
|
11g OCM
|
Feedback
1,650,000 hits
Thanks A MILLION for your support!
Please send me your valuable feedback and suggestions
|
In one of my earlier posts, I had illustrated a use case of DBMS_ADVANCED_REWRITE and its use in cases where we cannot change the code, but can still influence and change the way the optimizer executes the same SQL statement.
In case of many vendor provided and packaged applications, we do not have access to the SQL code and we cannot rewrite the SQL statements.
So there could be cases where even though indexes are present on the table, they are not being used by the optimizer and one way we can force the optimizer to use an index is via the INDEX hint.
So how we change the execution plan of the optimizer for a particular statement without changing the original SQL statement that the application is executing?
We do it using the powerful new feature introduced in 10g called DBMS_ADVANCED_REWRITE or “tuning without touching the code”.
To illustrate this, let us create
Continue reading Using DBMS_ADVANCED_REWRITE with an HINT to change the execution plan
In some cases we may find that gathering fresh statistics has led to the optimizer executing sub-optimal execution plans and we would like to restore the statistics as of a date when we had good performance.
REMEMBER – we gather statistics to ensure that the optimizer chooses the optimal execution plans, but gathering statistics invalidates the parsed representation of the SQL statement and reparsing the statement post gather stats can make the optimizer choose an execution plan which is different (and less optimised) than the original plan.
In Oracle 10g and above, we can also restore table statistics to a previous point in the past by using the DBMS_STATS.RESTORE_TABLE_STATS package.
Note: we can also export and import the statistics using the DBMS_STATS.CREATE_STATS_TABLE to create a statistics table which we can use to export and import statistics using the DBMS_STATS.EXPORT_*_STATS and DBMS_STATS.IMPORT_*_STATS procedures.
We can check how far back in time we can go to
Continue reading Restoring Optimizer Statistics
We can use the DBMS_MVIEW.EXPLAIN_REWRITE package (which was first introduced in Oracle 9i if memory serves me right) to diagnose why Query redirection to a materialized view is not happening.
We can redirect the output to a table called REWRITE_TABLE which is created via the utlxrw.sql script located under $ORACLE_HOME/rdbms/admin.
Let us take a simple example to see how this works.
We have created a materialized view SALES_MV which is based on the following query in the SH schema:
create materialized view sales_mv
build immediate
enable query rewrite
as
SELECT p.prod_name, SUM(amount_sold)
FROM sales s, products p
WHERE s.prod_id = p.prod_id
AND prod_name > ‘B%’
AND prod_name < 'C%'
GROUP BY prod_name;
We will now run the EXPLAIN_REWRITE procedure to see if a particular query will be redirected to the MV instead.
EXECUTE DBMS_MVIEW.EXPLAIN_REWRITE -
(‘SELECT p.prod_name, SUM(amount_sold)-
FROM sales s, products p -
WHERE s.prod_id = p.prod_id -
AND prod_name > ”B%”-
AND prod_name < ''C%''-
GROUP BY prod_name',-
'SALES_MV','SH');
PL/SQL procedure successfully completed.
SQL> SELECT message FROM rewrite_table ORDER BY sequence;
MESSAGE
——————————————————————————–
QSM-01150: query
Continue reading Using TUNE_MVIEW and EXPLAIN_REWRITE to enable us to tune MV Fast Refreshes and Query Rewrites
One of the major concerns a DBA has related to performing a database upgrade to Oracle 11g is ‘Are Execution Plans Going To Change Post-Upgrade?’
I am quite sure we would have experienced some queries having different execution plans when we did earlier upgrades to both 9i as well as 10g. This is due to optimizer and kernel differences in every Oracle version which causes the execution plan of some SQL statements to change.
It is not as if all SQL statements have different execution plans after a database upgrade is performed. It maybe just a case where only SQL statement is now performing a full table scan or sub-optimal join as compared to the pre-upgrade plan and that query is one is which is used a great deal by the application.
So we may have taken all steps to perform an upgrade with just a few hours of application downtime, but
Continue reading Upgrade to 11g and ensure Optimizer Plan Stability using SQL Plan Baselines
The Cost Based optimizer peeks at the values of user-defined bind variables on the first invocation of a cursor. Based on this, the optimizer determines the selectivity of the WHERE clause condition as if literals have been used instead of bind variables. On subsequent invocations of the cursor, no bind peeking takes place, and the cursor is shared even if subsequent invocations use different bind values.
If the data is skewed in the table especially in the columns used in the WHERE clause, based on the first value ‘peeked’, the optimizer may make a wrong choice of a full table scan or index range scan when the opposite would have been more optimal for the execution of that particular SQL statement.
To force a hard parse (by invalidating the cursor) so that the CBO does another fresh ‘peek’ at the bind variables chosen for a query (and so that a new execution
Continue reading Solving a 10g Bind Variable Peeking problem by granting and revoking privileges
Very often we run AWR, ASH and ADDM reports which does highlight the Top SQL statements by disk reads, CPU usage and elapsed time. But an important piece of information is missing which is the Explain Plan.
Using GUI tools like Enterprise Manager will enable us to drill down to the Explain Plan from an individual SQL statement, but how do we do it from the command line?
The answer is simply using DBMS_XPLAN.DISPLAY_AWR and provide to it as a parameter the SQL_ID in question (which can be picked up from the AWR or ASH report).
For example in the ASH report we see this section related to the Top SQL
Top SQL with Top Events DB/Inst: FILESDB/filesdb (Jul 19 13:23 to 13:38)
Continue reading Using DBMS_XPLAN.DISPLAY_AWR to obtain the EXPLAIN PLAN of a SQL Statement
In the Part 1 of this post, we saw how we can use the AWR history tables to compare the top wait events between two different time periods.
We will now use the history tables to track and identify problem SQL statements.
Suppose we have been informed that there was a I/O performance issue early in the morning around 4.30 AM …
1) We obtain the SNAP_ID for the period in question
SQL> select snap_id,begin_interval_time,end_interval_time
2 from dba_hist_snapshot where to_char(begin_interval_time,’DD-MON-YYYY HH24:MI’)=’28-JUL-2009 04:00′;
SNAP_ID BEGIN_INTERVAL_TIME
———- —————————————————————————
END_INTERVAL_TIME
—————————————————————————
10951 28-JUL-09 04.00.08.054 AM
28-JUL-09 05.00.58.732 AM
2) We then obtain the Top 5 SQL statements executing during that period – we can sort on a number of variables like disk reads, buffer gets, I/O waits, Cpu time etc. We will sort it by disk reads to find the top 5 SQL statements with the most disk reads.
SQL> select
Continue reading Using the AWR History Tables to compare performance – Part 2
Using the DBA_HIST AWR history tables, we can compare the top wait events between different days or different time periods.
Let us assume that we find that batch jobs which are executed at night particularly between 1 and 2 AM are experiencing performance issues.
In this case we are comparing performance of a particular database on the 20th and 21st of July for the time periods 01:00 to 02:00.
SQL>
1 select snap_id,to_char(BEGIN_INTERVAL_TIME,’DD-MON-YY HH24:MI:SS’) “Runtime”
2 from dba_hist_snapshot
3* where trunc(BEGIN_INTERVAL_TIME)=’21-JUL-2009′ order by snap_id;
SNAP_ID Runtime
———- ——————
10781 21-JUL-09 00:00:14
10782 21-JUL-09 01:01:01
10783 21-JUL-09 02:00:27
10784 21-JUL-09 03:00:42
……..
Since the snapshots are collected every hour, for the same time period on the previous day we substract 24 – so the snap_ids for the 20th of July
Continue reading Using the AWR History Tables to compare performance – Part 1
One of the critical aspects of any database upgrade is to ensure optimizer plan stability where tried and tested execution plans are not altered in any way by the Oracle optimizer after a database upgrade has taken place.
One of the 11g new features which is SQL Plan Management and SQL Plan baselines enables us to ‘lock in’ proven execution plans and ensure that the optimizer only chooses different execution plans to those which have been baselined if they are found to offer better performance as compared to existing plans.
In the example below, we will see how execution plans can potentially change after an upgrade to 11g and how by using SQL Plan Management feature of 11g, we can ensure that only existing 10g plans are still used even after the upgrade.
In the 10g database, the optimizer_mode parameter has been set to RULE and we see for this particular SQL statement,
Continue reading 11g Optimizer Plan Stability
In Oracle 11g, we can ensure that the same proven execution plans are used by the Optimizer regardless of any change which can effect the optimizer like a version change, index drop or recreate, init.ora parameter change etc.
Once plans are marked as enabled and accepted, the optimizer will not use any new plans unless there is proven performance benefits of adopting a new plan. Plans can also be manually adopted or “evolved”.
One of the dangers of upgrading from 10g to 11g (or between any release) is that execution plans may change in the new version which could affect application performance.
But with this new 11g feature, if we have tried and trusted 10g execution plans in place, we can ensure that the same plans will be used by the optimizer even after the migration unless new 11g plans are found to offer better performance. This can be achieved by capturing 10g
Continue reading 11g Optimizer Plan Stabilty using SQL Plan Baselines
|
That’s Us
|
|
24x7 Remote/Onsite DBA Support
|
|
Performance Auditing
|
|
Security Auditing
|
|
High Availability Solutions
|
|
Disaster Recovery
|
|
Database Upgrades & Migrations
|
|
Data Migration using GoldenGate
|
|
More about our services ...
|
|
Popular Posts