Panorama: Handle SQL patches for Oracle-DB

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)',
    name        => 'SQL patch example',
    description => 'Example for applying optimizer-hint to unchanged SQL'
  );
END;
/

From Oracle 12.2 create with package-function sys.DBMS_SQLDiag.create_SQL_patch

DECLARE
  patch_name VARCHAR2(32767);
BEGIN
  patch_name := sys.DBMS_SQLDiag.create_SQL_patch(
    sql_text    => 'SELECT SYSDATE FROM DUAL',
    hint_text   => 'PARALLEL(8)',
    name        => 'SQL patch example',
    description => 'Example for applying optimizer-hint to unchanged SQL'
  );
END;
/

Dictionary objects containing info about SQL patches

  • View DBA_SQL_Patches list existing SQL patches
  • Table sys.SQLObj$ contains match between SQL patch name and signature, category, object_type and plan_id
  • Table sys.SQLObj$Data contains optimizer hint in XML outline structure
Thanks to Jonathan Lewis for his post.

Support for SQL patches with analysis tool 'Panorama'

Panorama can generate SQL patches for every SQL-statement that is in SGA or AWR-history.
Each SQL detail page has as button "SQL patch" that generates a PL/SQL-snippet for SQL patch creation.
You only have to replace your optimizer hint in this snippet and execute it as SYSDBA to create a SQL patch.
This SQL patch generation uses the more expensive alternative with SQL text instead of SQL-ID.
This ensures that SQL patch can be created even some time after the last execution of SQL regardless of wether SQL is still present in SGA.




Existing SQL patches for a SQL-statement are shown in any detail view of that SQL to explicitly prevent misinterpretation of execution plan.






All existing SQL-patches are listed in Panorama via menu 'SGA/PGA-details' / 'SQL plan management' / 'SQL patches':


You may find more about Panorama at http://rammpeter.github.io/panorama.html

See also this post: Panorama: Fix changed execution plan with SQL plan baseline



Comments

Post a Comment

Popular posts from this blog

Oracle-DB: How to check for appropriate sequence caching

Image
A common pitfall while using sequences in Oracle-DB is forgetting to define sequence caching. The default for sequences is cache size = 0. That means, every sequence.nextval operation triggers a single write operation on dictionary table sys.SEQ$. Especially if frequently calling sequence.nextval uncached sequences may cause significant performance degradation. Frequently calling sequence.nextval in parallel sessions may lead to ramdom lock scenarios in library cache. Setting a cache size for a sequence may heavy increase performance of nextval-operations. There's a minimal memory overhead for caching a sequence because all that's needed is a counter to increase in SGA memory and a upper limit. If this limit is reached with the counter, the upper limit is increased by cache size and the new upper limit is written down once to SEQ$. The possible drawback for sequence caching is that you loose all your values between the current value and the highest cached value if yo...
Read more

Common pitfalls using SQL*Net via Firewalls

It's very common that firewalls are terminating idle TCP sessions after a limited time, often after approximately one hour. Possible problem If you have a long running SQL or PL/SQL program and the firewall terminates your apparently idle TCP session this may lead to the following scenario: the database is not able to send result to client. After reaching the TCP-timeout the database server terminates the DB-Session the client program stays in socket read forever waiting for the database response Oracle's full solution: SQLNET.EXPIRE_TIME=x in sqlnet.ora Oracle's solution for this problem is setting parameter SQLNET.EXPIRE_TIME=x in sqlnet.ora where x are the minutes between keep alive packets on idle sessions that inform the firewall that this session is always alive. SQLNET.EXPIRE_TIME hast to be set in the sqlnet.ora of your RDBMS' ORACLE_HOME. Normally $ORACLE_HOME/network/admin. If you have a grid infrastructure setting SQLNET.EXPIRE_TIME in sqlnet...
Read more

Oracle-DB: Identify excessive logon/logoff operations with short-running sessions

Image
Creating and destroying database sessions in loop may lead to significant database load. This blog post contains more about quantifying this load. Applications should use connection pooling at client or database side to prevent excessive session creation. But how can I identify the client processes causing this sessions? Scan DBA_Audit_Trail to identify context info If auditing logon/logoff-operations is activated for your database, scan DBA_Audit_Trail. You can do this by 2 was: Alternative 1: Use my tool "Panorama" to evaluate audit trail Panorama is available here. Go to menu "DBA general" / "Audit Trail": Select start and end time for selection Filter column "Action" for "LOGON" Set "Grouping" to "Minute" Execute selection via button "Show audit trail" Add columns of your choice to diagram by context menu (right mouse button) This way you can identify the machine, DB-user ...
Read more