{ "date": "2014-12-28T18:59:38", "slug": "create-schema-synonym-in-oracle-unsupported-feature", "link": "https://www.dbi-services.com/blog/create-schema-synonym-in-oracle-unsupported-feature/", "title": { "rendered": "Creating a schema synonym in Oracle – an unsupported feature" }, "content": { "rendered": "

By Franck Pachot

\n

.
\nIvica Arsov (@IvicaArsov) has made an interesting comment about AUDIT_ACTIONS object link table. I’ll blog about it soon, but in the meantime when checking its definition in cataudit.sql it came upon the following:

\n
/* SCHEMA SYNONYMS will be added in 12g */\n-- insert into audit_actions values (222, 'CREATE SCHEMA SYNONYM');\n-- insert into audit_actions values (224, 'DROP SCHEMA SYNONYM');\n
\n

which caught my attention.

\n

So this blog post is not about mulitenant but about Schema Synonyms. There are a lot of internal references to 12g’ written when the ‘c’ was not yet decided. But that feature is not yet supported: its implementation has probably been postponed again. But that’s not a reason not to try it – in lab only of course.

\n

Let’s give a try to the syntax:

\n
SQL> create schema synonym DEMO2 for DEMO;\ncreate schema synonym DEMO2 for DEMO\n              *\nERROR at line 1:\nORA-00901: invalid CREATE command\n
\n

Undocumented parameter

\n

Doesn’t work. But there is an undocumented parameter:

\n
SQL> select ksppinm, ksppstvl from x$ksppi a, x$ksppsv b where a.indx=b.indx and ksppinm like '%schema%synonym%';\n\nKSPPINM                   KSPPSTVL\n------------------------- ----------\n_enable_schema_synonyms   FALSE\n
\n

Ok, let’s go:

\n
SQL> connect sys/oracle as sysdba\nConnected.\n\nSQL> alter system set \"_enable_schema_synonyms\" = true scope=spfile;\nSystem altered.\n\nSQL> startup force;\n
\n

So I have a DEMO schema:

\n
SQL> select user_id,username from dba_users where username like 'DEMO%';\n\n   USER_ID USERNAME\n---------- --------------------\n       111 DEMO\n
\n
which is type 1 in user$ (type 0 is for roles):
\n
SQL> select user#,name,type#,ctime from sys.user$ where name like 'DEMO%';\n\n     USER# NAME               TYPE# CTIME\n---------- ------------- ---------- ---------\n       111 DEMO                   1 09-NOV-14
\n

And I create a synonym DEMO2 for it:

\n
SQL> create schema synonym DEMO2 for DEMO;\nSchema synonym created.\n
\n

It’s not a user:

\n
SQL> select user_id,username from dba_users where username like 'DEMO%';\n\n   USER_ID USERNAME\n---------- --------------------\n       111 DEMO\n
\n

but it’s another entry in user$ with type 3 which is for schema synonyms:

\n
SQL> select user#,name,type#,ctime,spare2 from sys.user$ where name like 'DEMO%';\n\n     USER# NAME            TYPE# CTIME         SPARE2\n---------- ---------- ---------- --------- ----------\n       111 DEMO                1 09-NOV-14\n       159 DEMO2               3 28-DEC-14        111\n
\n

I’ve selected the SPARE2 because this is where the link to the target schema of the synonym is stored.

\n

Usage

\n

I can create a table using the schema synonym:

\n
SQL> create table DEMO2.MYTABLE as select * from dual;\nTable created.\n
\n

and query it from both:

\n
SQL> select * from DEMO2.MYTABLE;\n\nD\n-\nX\n\nSQL> select * from DEMO.MYTABLE;\n\nD\n-\nX\n
\n

the execution plan show the schema synonym DEMO2 as the object owner:

\n
SQL> explain plan for select * from DEMO2.MYTABLE;\nExplained.\n\nSQL> select operation,object_owner,object_name,object_type from plan_table order by id;\n\nOPERATION            OBJECT_OWN OBJECT_NAM OBJECT_TYP\n-------------------- ---------- ---------- ----------\nSELECT STATEMENT\nTABLE ACCESS         DEMO2      MYTABLE    TABLE\n
\n

and the rowid shows that data comes from the DEMO table:

\n
SQL> select rowid, dbms_rowid.rowid_object(rowid),MYTABLE.* from DEMO2.MYTABLE;\n\nROWID                   DBMS_ROWID.ROWID_OBJECT(ROWID) D\n------------------ ------------------------------ -\nAAAXaYAAGAAAuGbAAA                            95896 X\n\nSQL> select owner,object_name,object_id,data_object_id from dba_objects where object_name = 'MYTABLE';\n\nOWNER           OBJECT_NAM  OBJECT_ID DATA_OBJECT_ID\n---------- ---------- ---------- --------------\nDEMO           MYTABLE           95896          95896\n
\n

The locks are acquired on the base object:

\n
SQL> select * from DEMO2.MYTABLE for update;\n\nD\n-\nX\n\nSQL> select object_id,locked_mode from v$locked_object;\n\n OBJECT_ID LOCKED_MODE\n---------- -----------\n     95896           3\n\nSQL> select owner,object_name,object_id from dba_objects where object_name = 'MYTABLE';\n\nOWNER      OBJECT_NAM  OBJECT_ID\n---------- ---------- ----------\nDEMO         MYTABLE       95896\n
\n

Limits

\n

We can use the schema synonym as the default prefix:

\n
SQL> alter session set current_schema=DEMO2;\nSession altered.\n
\n

and we cannot drop it when the underlying user is connected:

\n
SQL> connect DEMO/demo;\nConnected.\nSQL> drop schema synonym DEMO2;\ndrop schema synonym DEMO2\n*\nERROR at line 1:\nORA-42297: cannot drop a schema synonym for a schema of a user who is currently\nconnected\n
\n

we cannot create synonyms for system schemas:

\n
SQL> create schema synonym ROOT for SYS;\ncreate schema synonym ROOT for SYS\n                               *\nERROR at line 1:\nORA-42288: may not create a schema synonym for the specified schema\n
\n

and schema synonyms is in the same namespace as users and roles:

\n
SQL> create role DEMO2;\ncreate role DEMO2\n            *\nERROR at line 1:\nORA-42294: role name conflicts with another user, role or schema synonym name\n
\n

Those new error messages include ‘or schema synonym name’ when the “_enable_schema_synonyms” is enabled.

\n

Don’t use it!

\n

Now playing with undocumented stuff comes with unexpected behaviour:

\n
SQL> truncate table DEMO2.MYTABLE;\nTable truncated.\n
\n

I’ve truncated the table using the synonym, then let’s select from it though the synonym or with the real schema:

\n
SQL> select * from DEMO2.MYTABLE;\nno rows selected\n\nSQL> select * from DEMO.MYTABLE;\nselect * from DEMO.MYTABLE\n*\nERROR at line 1:\nORA-08103: object no longer exists\n
\n

Ok it seems that some invalidations didn’t follow the synonyms…
\nLet’s try to flush the shared pool:

\n
SQL> alter system flush shared_pool;\nSystem altered.\n\nSQL> select * from DEMO.MYTABLE;\nno rows selected\n\nSQL> select * from DEMO2.MYTABLE;\nno rows selected\n
\n

This is what happens when we use features that are not totally implemented…

\n

That feature is not yet totally implemented. Do you have a need for it? then maybe create an OTN database idea.

\n", "protected": false } }