Peter Ramm's Oracle performance analysis stuff

The release 19.19 of the Oracle DB got the long awaited populating of Access_Predicates and Filter_Predicates in DBA_Hist_SQL_Plan (as backport from 21c). So far so good, after decades of complaints. But as the execution plans already stored in the AWR before 19.19 are without a time reference, Access_Predicates and Filter_Predicates for SQLs are not filled, as long as the plans from before 19.19 still exist. These plans are independent of the AWR retention time and therefore remain in the old state without Access_Predicates and Filter_Predicates forever as long as the SQLs are still contained in upcoming AWR snapshots. A solution for that behaviour is, to manually remove the old plans to trigger storage of current plans from SGA again. If executed once as SYSDBA, this script deletes all the execution plans saved in the AWR for which the Access_Predicates and Filter_Predicates columns are not filled. These plans will be saved again from SGA with the next AWR snapshots, but then ...

Some times a SQL execution includes all partitions of a partitioned table or index into processing, although there are filter conditions used that contain also the partition key of that partitoned table or index. There are several possible reasons why the optimizer does not recognize that access could be reduced to one or less partitions (a.k.a. partition pruning): The partition key can be obfuscated behind a conversion function The partition key can be compared to a function result that is known only at execution time Being able to use partition pruning can make a huge difference for execution time of the SQL. Imagine you only need to scan one partition of a table instead of several thousands. Often only a small change in the SQL statement can drive the optimizer to use partition pruning. A small example where all partitions are scanned due to comparison of the partition key with a function result: Get the sum of order value for a table interval partitioned by day. SELE...

What does the database really do with your optimizer hints in SQL statements? Starting with Oracle 19c the column 'OTHER_XML' of V$SQL_Plan rsp. DBA_Hist_SQL_Plan or Plan_Table was extended by a section 'hint_usage'. This gives information about the state of optimizer hint usage correlated with the line in the execution plan. Example for section 'hint_usage' of OTHER_XML Lets take this simple but useless SQL as example: SELECT /*+ FULL(c) QB_NAME(Outer) NONSENS(c) */ * FROM cust.Customer c WHERE ID_Company IN ( SELECT /*+ USE_NL(cp) QB_NAME(Inner) */ 12 FROM sysp.Company cp WHERE RowNum < 5 ) AND RowNum < 20; The section 'hint_usage' in PLAN_TABLE.OTHER_XML looks like for this example: <hint_usage> <q> <n><![CDATA[INNER]]></n> <h o="EM"> <x><![CDATA[QB_NAME(Inner)]]></x> </h> ...