Peter Ramm's Oracle performance analysis stuff

Update 2023-05:  Checked the above issues against Rel. 19.18 It works much better now than before in Rel. 12.x.  Not completely without the risk of getting migrated rows and not deterministic at all. But with much smaller amount of situations resulting in increasing storage footprint and migrated rows.

Starting with release 10.1 Oracle introduced automatic shared memory management. Setting only SGA_TARGET=x without defining limits for the SGA-components (buffer cache, shared pool, large pool, java pool) allows your database to redistribute SGA memory between components due to current needs. This will work properly in many cases but sometimes there are some pitfalls: A very common problem on Oracle databases are applications without usage of bind variables in their SQL statements. Not using bind variables leads to excessive SGA memory consumption in shared pool and parse effort if you have a large number of SQLs executed with different values in filter conditions stored as literals. For example: SELECT a, b FROM Item WHERE ItemNo = 453612; SELECT a, b FROM Item WHERE ItemNo = 876886; etc. instead of SELECT a, b FROM Item WHERE ItemNo = :ItemNo; In such a situation the DB may resize the SGA. The size of the shared pool will grow thus reducing the size of the buffer cache

SQL-Monitoring records individual executions of an SQL statement in detail if they fulfill one of the following prerequisites: Execution with parallel query CPU- or I/O-activity for more than 5 seconds Optimizer-hint `MONITOR` in SQL statement SQL-Monitoring reports are stored in table v$SQL_Monitor during SQL execution and for a very short period after execution. The precondition for using the monitoring reports is licensing of the Tuning Pack for the Enterprise Edition. Starting with Oracle 12.1, the short-living detailed monitoring reports from v$SQL_Monitor are also available for a longer time within the AWR retention period via DBA_Hist_Reports and DBA_Hist_Reports_Details. This report can be exported as HTML-page which uses Adobe-Flash to render the Database Activity Report for this SQL execution similar to Enterprise manager. To generate the HTML-report from v$SQL_Monitor call: SELECT DBMS_SQLTUNE.report_sql_monitor(

Long time ago Oracle introduced SQL patches as a way to influence execution plan of SQL with optimizer hints without changing the original SQL statement. This allows fixing execution plan issues without any change at the application executing this SQL. SQL patches don't require additional license in contrast to SQL plan baselines and SQL profiles and can also be used with Standard Edition. SQL patches are normally used in workflow of SQL Repair Advisor but can also be created manually. There are two variants to create a SQL patch for a SQL: By SQL-ID and by SQL text. (See also this posts: 1   2  ) I personally prefer SQL patch creation using SQL text because SQL-ID requires existence of SQL-Statement in SGA at SQL patch creation time. For Oracle 11.1 .. 12.1 create with package-method sys.DBMS_SQLDiag_Internal.i_create_patch BEGIN sys.DBMS_SQLDiag_Internal.i_create_patch( sql_text => 'SELECT SYSDATE FROM DUAL', hint_text => 'PARALLEL(8)