.
\nIn a previous post I published a test case to show when a cursor is not shared anymore after a rolling invalidation. Basically the dbms_stats marks the cursor as ‘rolling invalid’ and the next execution marks it as ‘rolling invalid executed’. Looking at 12cR2 there is a little enhancement in V$SQL with an additional column displays those states.
\n
\nNote that 12cR2 full documentation is not yet available, but you can test this on the Exadata Express Cloud Service.
I set the invalidation period to 5 seconds instead of 5 hours to show the behavior without waiting
\n\n17:43:52 SQL> alter system set \"_optimizer_invalidation_period\"=5;\nSystem altered.\nI’ll run a statement with dbms_sql in order to separate parse and execute phases
\n\n17:43:53 SQL> variable c number\n17:43:53 SQL> exec :c := dbms_sql.open_cursor;\nPL/SQL procedure successfully completed.\n17:43:53 SQL> exec dbms_sql.parse(:c, 'select (cast(sys_extract_utc(current_timestamp) as date)-date''1970-01-01'')*24*3600 from DEMO' , dbms_sql.native );\nPL/SQL procedure successfully completed.\nHere is the cursor from V$SQL including the new IS_ROLLING_INVALID column:
\n\n17:43:53 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 0 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 N\nStatement is parsed (one parse call + load) but IS_ROLLING_INVALID is N
\nNow I execute it:
\n\n17:43:53 SQL> exec dbms_output.put_line( dbms_sql.execute(:c) );\n0\nPL/SQL procedure successfully completed.\n \n17:43:53 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 1 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 N\nStatement has one execution.
\nI’m now gathering statistics with default rolling invalidation:
\n\n17:43:53 SQL> exec dbms_stats.gather_table_stats(user,'DEMO');\nPL/SQL procedure successfully completed.\n \n17:43:53 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 1 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 Y\nThe cursor is now marked as rolling invalid (IS_ROLLING_INVALID=”Y”) but wait, this is not a “Y”/”N” boolean, there’s another possible value.
\nI execute the statement again (no parse call, only execution):
\n\n17:43:53 SQL> exec dbms_output.put_line( dbms_sql.execute(:c) );\n0\nPL/SQL procedure successfully completed.\n \n17:43:53 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 2 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 X\nCursor is now marked as rolling invalid executed (“X”) and this is where the rolling window starts (which I’ve set to 5 seconds instead of 5 hours)
\nI wait 5 seconds and the cursor has not changed:
\n\n17:43:58 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 2 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 X\n \nI execute it again (no parse call, only re-execute the cursor):
\n\n17:43:58 SQL> exec dbms_output.put_line( dbms_sql.execute(:c) );\n0\nPL/SQL procedure successfully completed.\nFor this execution, a new child has been created:
\n\n17:43:58 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 2 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 X\n 0 1 0 1 2016-09-25/17:43:53 2016-09-25/17:43:57 25-SEP-16 17:43:57 N\nSo rolling invalidation do not require a parse call. Execution can start the rolling window and set the invalidation timestamp, and first execution after this timestamp creates a new child cursor.
\nI’ll now test what happens with parse calls only.
\nI set a longer rolling window (2 minutes) here:
\n\n17:43:58 SQL> exec dbms_stats.gather_table_stats(user,'DEMO');\nPL/SQL procedure successfully completed.\n \n17:43:58 SQL> alter system set \"_optimizer_invalidation_period\"=120;\nSystem altered.\nThe last child has been marked as rolling invalid but not yet executed in this state:
\n\n17:43:58 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTIVE_TIME IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- ------------------ ------------------\n 0 1 1 2 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 17:43:52 X\n 0 1 0 1 2016-09-25/17:43:53 2016-09-25/17:43:57 25-SEP-16 17:43:57 Y\nFrom a new session I open another cursor:
\n\n17:43:58 SQL> connect &_user./demo@&_connect_identifier\nConnected.\n17:43:58 SQL> exec :c := dbms_sql.open_cursor;\nPL/SQL procedure successfully completed.\nAnd run several parse calls without execute, one every 10 seconds:
\n\n17:43:58 SQL> exec for i in 1..12 loop dbms_sql.parse(:c, 'select (cast(sys_extract_utc(current_timestamp) as date)-date''1970-01-01'')*24*3600 from DEMO' , dbms_sql.native ); dbms_lock.sleep(10); end loop;\nPL/SQL procedure successfully completed.\nSo two minutes later I see that I have a new child created during the rolling window:
\n\n17:45:58 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTI IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- --------- ------------------\n 0 1 1 2 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 X\n 0 1 3 1 2016-09-25/17:43:53 2016-09-25/17:43:57 25-SEP-16 Y\n 0 1 9 0 2016-09-25/17:43:53 2016-09-25/17:44:27 25-SEP-16 N\nHere, at the third parse call (17:44:27) during the invalidation window, a new child cursor has been created. The old one is still marked as rolling invalid (“Y”), but not ‘rolling invalid executed’ (“X”) because it has not been executed.
\nSo it seems that both parse or execute are triggering the rolling invalidation, and the IS_ROLLING_INVALID displays which one.
\nAn execute will now execute the new cursor:
\n\n17:45:58 SQL> exec dbms_output.put_line( dbms_sql.execute(:c) );\n \nPL/SQL procedure successfully completed.\n \n17:45:58 SQL> select invalidations,loads,parse_calls,executions,first_load_time,last_load_time,last_active_time,is_rolling_invalid from v$sql where sql_id='61x2h0y9zv0r6';\n \nINVALIDATIONS LOADS PARSE_CALLS EXECUTIONS FIRST_LOAD_TIME LAST_LOAD_TIME LAST_ACTI IS_ROLLING_INVALID\n------------- ---------- ----------- ---------- ------------------- ------------------- --------- ------------------\n 0 1 1 2 2016-09-25/17:43:53 2016-09-25/17:43:53 25-SEP-16 X\n 0 1 3 1 2016-09-25/17:43:53 2016-09-25/17:43:57 25-SEP-16 Y\n 0 1 9 1 2016-09-25/17:43:53 2016-09-25/17:44:27 25-SEP-16 N\nOf course, when new cursors have been created we can see the reason in V$SQL_SHARED_CURSOR:
\n\n17:45:58 SQL> select child_number,reason from v$sql_shared_cursor where sql_id='61x2h0y9zv0r6';\n \nCHILD_NUMBER REASON\n------------ --------------------------------------------------------------------------------\n 0 <ChildNode><ChildNumber>0</ChildNumber><ID>33</ID><reason>Rolling Invalidate Win\n dow Exceeded(2)</reason><size>0x0</size><details>already_processed</details></Ch\n ildNode><ChildNode><ChildNumber>0</ChildNumber><ID>33</ID><reason>Rolling Invali\n date Window Exceeded(3)</reason><size>2x4</size><invalidation_window>1472658232<\n /invalidation_window><ksugctm>1472658237</ksugctm></ChildNode>\n \n 1 <ChildNode><ChildNumber>1</ChildNumber><ID>33</ID><reason>Rolling Invalidate Win\n dow Exceeded(2)</reason><size>0x0</size><details>already_processed</details></Ch\n ildNode><ChildNode><ChildNumber>1</ChildNumber><ID>33</ID><reason>Rolling Invali\n date Window Exceeded(3)</reason><size>2x4</size><invalidation_window>1472658266<\n /invalidation_window><ksugctm>1472658268</ksugctm></ChildNode>\n \n 2\nThe last child cursor has been created at 5:44:28 (invalidation_window=1472658268) because invalidation timestamp (ksugctm=1472658266)
\nWe love Oracle because it’s not a black box. And it’s good to see that they continue in this way by exposing in V$ views information that can be helpful for troubleshooting.
\nRolling invalidation has been introduced for dbms_stats because we have to gather statistics and we don’t want hard parse storms after that.
\nBut remember that invalidation can also occur with DDL such as create, alter, drop, comment, grant, revoke.
You should avoid running DDL when application is running. However, we may have to do some of those operations online. It would be nice to have the same rolling invalidation mechanisms and it seems that it will be possible:
\n\nSQL> show parameter invalid\n \nNAME TYPE VALUE\n------------------------------------ ----------- ------------------------------\ncursor_invalidation string IMMEDIATE\n \nSQL> alter session set cursor_invalidation=XXX;\nERROR:\nORA-00096: invalid value XXX for parameter cursor_invalidation, must be from among IMMEDIATE, DEFERRED\nThat’s interesting. I’ll explain which DDL can use that in a future blog post.
\n", "protected": false } }