{ "date": "2015-12-27T20:42:01", "slug": "phantom-session-environment-in-multitenant", "link": "https://www.dbi-services.com/blog/phantom-session-environment-in-multitenant/", "title": { "rendered": "Phantom session environment in multitenant?" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nIn multitenant a session can switch from one container to another. There are a few restrictions such as a transaction cannot span multiple containers. But how do sessions parameters behave? It seems that there is a small inconsistency.
\n
\nI was looking at some adaptive plan and SPM behavior (see this tweeter conversation) and played with the optimizer environment to reproduce the plan I wanted, and then came to a strange behavior. I can understand that a session keep its parameter settings when switching to another container. But not when closing and re-opening the pluggable database. The default values should come then.

\n

Here is an example.

\n

Change in memory value of optimizer parameter

\n

This is in 12.1.0.2 latest PSU. I connect to PDB

\n
\n19:13:10 SQL> alter session set container=PDB;\nSession altered.\n
\n

and check parameter optimizer_index_cost_adj from memory:

\n
\n19:13:10 SQL> show parameter optimizer_index_cost_adj;\n \nNAME                                 TYPE        VALUE\n------------------------------------ ----------- ------------------------------\noptimizer_index_cost_adj             integer     100\n
\n

It’s the default.

\n

then I set it to one in memory only:

\n
\n19:37:17 SQL> alter system set optimizer_index_cost_adj=1 scope=memory;\nSystem altered.\n
\n

And I run a query and check that the optimizer used that value

\n
\n19:37:18 SQL> select * from dual;\n \nD\n-\nX\n \n19:37:19 SQL> select * from table(dbms_xplan.display_cursor(format=>'+outline'));\n \nPLAN_TABLE_OUTPUT\n--------------------------------------------------------------------------\nSQL_ID  a5ks9fhw2v9s1, child number 0\n-------------------------------------\nselect * from dual\n \nPlan hash value: 272002086\n \n--------------------------------------------------------------------------\n| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |\n--------------------------------------------------------------------------\n|   0 | SELECT STATEMENT  |      |       |       |     2 (100)|          |\n|   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |\n--------------------------------------------------------------------------\n \nOutline Data\n-------------\n \n  /*+\n      BEGIN_OUTLINE_DATA\n      IGNORE_OPTIM_EMBEDDED_HINTS\n      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')\n      DB_VERSION('12.1.0.2')\n      OPT_PARAM('optimizer_index_cost_adj' 1)\n      ALL_ROWS\n      OUTLINE_LEAF(@\"SEL$1\")\n      FULL(@\"SEL$1\" \"DUAL\"@\"SEL$1\")\n      END_OUTLINE_DATA\n  */\n \n
\n

Si this is expected, my custom value has been used to optimize the cursor.

\n

close and re-open the PDB

\n

I close and restart my PDB:

\n
\n19:37:19 SQL> shutdown immediate\nPluggable Database closed.\n19:37:21 SQL> startup\nPluggable Database opened.\n
\n

As the value was set in memory, it’s now back to default:

\n
\n19:36:48 SQL> show parameter optimizer_index_cost_adj;\n \nNAME                                 TYPE        VALUE\n------------------------------------ ----------- ------------------------------\noptimizer_index_cost_adj             integer     100\n \n
\n

and of course, my cursor is not there anymore:

\n
\n19:36:48 SQL> select sql_id,child_number,first_load_time,con_id from v$sql where sql_id='a5ks9fhw2v9s1';\n \nno rows selected\n
\n

So now I run again my query and expect the default optimizer environement:

\n
\n19:36:48 SQL> select dummy from dual;\n \nD\n-\nX\n \n19:36:48 SQL> select * from table(dbms_xplan.display_cursor(format=>'+outline'));\n \nPLAN_TABLE_OUTPUT\n---------------------------------------------------------------------------\nSQL_ID  4au7rzs3y6kzn, child number 0\n-------------------------------------\nselect dummy from dual\n \nPlan hash value: 272002086\n \n--------------------------------------------------------------------------\n| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |\n--------------------------------------------------------------------------\n|   0 | SELECT STATEMENT  |      |       |       |     2 (100)|          |\n|   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |\n--------------------------------------------------------------------------\n \nOutline Data\n-------------\n \n  /*+\n      BEGIN_OUTLINE_DATA\n      IGNORE_OPTIM_EMBEDDED_HINTS\n      OPTIMIZER_FEATURES_ENABLE('12.1.0.2')\n      DB_VERSION('12.1.0.2')\n      OPT_PARAM('optimizer_index_cost_adj' 1)\n      ALL_ROWS\n      OUTLINE_LEAF(@\"SEL$1\")\n      FULL(@\"SEL$1\" \"DUAL\"@\"SEL$1\")\n      END_OUTLINE_DATA\n  */\n
\n

And my new cursor has used the optimizer_index_cost_adj=1 which is not what I expected at all.
\nDoes that mean that session parameters remain across PDB close/start?
\nNo according to ‘show parameter’:

\n
\n19:37:07 SQL> show parameter optimizer_index_cost_adj;\n \nNAME                                 TYPE        VALUE\n------------------------------------ ----------- ------------------------------\noptimizer_index_cost_adj             integer     100\n \n
\n

but yes according to V$SES_OPTIMIZER_ENV:

\n
\n19:37:07 SQL> select sid,name,value from v$ses_optimizer_env where name='optimizer_index_cost_adj' and sid=sys_context('userenv','sid');\n \n       SID NAME                                     VALUE\n---------- ---------------------------------------- -------------------------\n        35 optimizer_index_cost_adj                 1\n \n
\n

Conclusion

\n

I’ve reproduced the same when re-connecting (instead of changing session container) and even when connecting to another PDB.
\nIn my opinion, this is a bug. The session parameters should be reinitialized when re-connecting. So be careful.

\n

Update 12-JUL-2016

\n

See Maciej Tokar post about this issue (my case being only one effect)

\n", "protected": false } }