SYNONYMS' POWER Author JP Vijaykumar Date Sept 14th 2012 In this article, I will explore some of the uses

of synonyms. REMOTE DB: ----------------------------------------------------------------------------------connect "/as sysdba" create table temp_jp1(col1 varchar2(20)); create table temp_jp2(col1 varchar2(20)); insert into temp_jp1 values('rama'); insert into temp_jp2 values('sita'); commit; grant select on temp_jp1 to jp; grant select on temp_jp2 to jp; LOCAL DB: ----------------------------------------------------------------------------------create database link prod_link connect to jp identified by jp using 'proddb.world'; select * from sys.temp_jp1@prod_link; COL1 -------------------rama REMOTE DB: ----------------------------------------------------------------------------------connect jp/jp create or replace synonym temp_jp for sys.temp_jp1; LOCAL DB: ----------------------------------------------------------------------------------SQL> select * from temp_jp@prod_link; <--REMOTE SYNONYM ACCESSED FROM LOCAL DB COL1 -------------------rama REMOTE DB: ----------------------------------------------------------------------------------CREATED A PROCEDURE TO ACCESS PRIVATE SYNONYM ON SYS.TEMP_JP1 OR SYS.TEMP_JP2. THIS PROCEDURE WORKS ONLY, WHEN A PRE-CREATED SYNONYM TEMP_JP EXISTS. THIS PROC CAN BE MODIFIED TO IMPLEMENT A SIMPLE TABLE LEVEL PARTITIONING. (Poor man's partitioning) connect jp/jp set serverout on size 1000000 declare v_str varchar2(20);

begin for c1 in (select synonym_name,table_owner,table_name, case when substr(reverse(table_name),1,1) = 1 then 2 else 1 end tab_n um from user_synonyms where synonym_name='TEMP_JP') loop execute immediate 'create or replace synonym '||c1.synonym_name||' for ' ||c1.ta ble_owner||'.'||c1.synonym_name||c1.tab_num; execute immediate 'select col1 from '||c1.synonym_name into v_str; dbms_output.put_line(v_str); end loop; end; / SQL> / rama SQL> / sita SQL> / rama SQL> / sita MY PROCEDURE IS SWITCHING THE PRIVATE SYNONYM BETWEEN TWO TABLES AND FETCHING DA TA. LOCAL DB: ----------------------------------------------------------------------------------SQL> select * from temp_jp@prod_link; COL1 -------------------rama REMOTE DB: ----------------------------------------------------------------------------------PROCEDURE EXECUTED TO SWITCH PRIVATE SYNONYM SQL> / sita LOCAL DB: ----------------------------------------------------------------------------------SQL> select * from temp_jp@prod_link; COL1 -------------------sita create synonym temp_jp for temp_jp@prod_link; Synonym created. SQL> select * from temp_jp; COL1 -------------------sita <--LOCAL SYNONYM IN LOCAL DB

----------------------------------------------------------------------------------THIS PROCEDURE WORKS WITHOUT A PRE-CREATED SYNONYM. HERE I AM USING A NVL FUNCTION OVER A SELECT QUERY. ----------------------------------------------------------------------------------set serverout on size 1000000 declare v_str varchar2(20); v_num number; begin for c1 in (select nvl( (select substr(reverse(table_name),1,1) from user_synonyms where synonym_name='TEMP_JP'),0) tab_num from dual) loop v_num:=c1.tab_num; if (v_num = 0) then v_num:=1; elsif (v_num = 1) then v_num:=2; else v_num:=1; end if; execute immediate 'create or replace synonym temp_jp for sys.temp_jp'||v_num; execute immediate 'select col1 from temp_jp' into v_str; dbms_output.put_line(v_str); end loop; end; / rama PL/SQL procedure successfully completed. SQL> / sita PL/SQL procedure successfully completed. SQL> / rama PL/SQL procedure successfully completed.

THE ABOVE PROCEDURE CAN BE IMPLEMENTED IN A TRIGGER TO DIVERT ALL UNAUTHORIZED USERS TO NON-SECURE SCHEMA TABLES. TEST CASE CREATING SYNONYM OVER SYNONYM: create user jp1 identified by jp1 account unlock; create user jp2 identified by jp2 account unlock; grant create session to jp1; grant create session to jp2; create table sys.temp_jp (col1 number,col2 varchar2(10)); insert into sys.temp_jp values(1,'rama'); commit; grant select on sys.temp_jp to jp1 with grant option;

Grant succeeded. SQL> connect jp1/jp1 Connected. SQL> select * from sys.temp_jp; COL1 COL2 ---------- ---------1 rama SQL> create synonym temp_jp for sys.temp_jp; Synonym created. SQL> select * from temp_jp; COL1 COL2 ---------- ---------1 rama SQL> grant select on temp_jp to jp2; Grant succeeded. SQL> connect jp2/jp2 Connected. SQL> select * from jp1.temp_jp; COL1 COL2 ---------- ---------1 rama SQL> create synonym temp_jp for jp1.temp_jp; --SYNONYM OVER SYNONYM Synonym created. SQL> select * from temp_jp; COL1 COL2 ---------- ---------1 rama ----------------------------------------------------------------------------------How can you grant select privileges on a remote table to a set of local users? 01 In the remote db, create a user ABC. Grant select ONLY privileges on the required table to user ABC. In the local db, create a public database link, connecting to ABC in the remote db. Any local user can select data from the remote table using the public database link. 02 In the remote db, create a user ABC. Grant select ONLY privileges on the required tables to user ABC.

dbIn the local create a privat db link. On the required remote table, create a local view using private db link. Grant select on local view to all the local users. ----------------------------------------------------------------------------------REMOTE DB: ----------------------------------------------------------------------------------SQL> conn u1/u1 Connected. SQL> select * from test; VALUE ---------1 2 3 4 5 6 SQL> sho user USER is "U1" LOCAL DB: ----------------------------------------------------------------------------------SQL> create user dev1 identified by dev1; User created. SQL> grant create session,create table, create synonym, create database link to dev1; Grant succeeded. SQL> create user dev2 identified by dev2; User created. SQL> grant create session,create table, create synonym, create database link to dev2; Grant succeeded. connect dev1/dev1 SQL> create database link dblink1 connect to u1 identified by u1 using 'prod_vmr ac'; Database link created. --Here u1 is the remote user, whose table is accessed by local users. 1* select * from test@dblink1; VALUE

---------1 2 3 4 5 6 USER is "DEV1" SQL> create synonym test for test@dblink1; --LOCAL PRIVATE SYNONYM Synonym created. SQL> select * from test; VALUE ---------1 2 3 4 5 6 SQL> grant select on test to dev2; grant select on test to dev2 * ERROR at line 1: ORA-02021: DDL operations are not allowed on a remote database SQL> !oerr ora 2021 02021, 00000, "DDL operations are not allowed on a remote database" // *Cause: An attempt was made to use a DDL operation on a remote database. // For example, "CREATE TABLE tablename@remotedbname ...". // *Action: To alter the remote database structure, you must connect to the // remote database with the appropriate privileges. SQL> create public synonym test for test@dblink1 --LOCAL PUBLIC SYNONYM SQL> / Synonym created. SQL> select * from test; VALUE ---------1 2 3 4 5 6 SQL> grant select on test to dev2; grant select on test to dev2 *

ERROR at line 1: ORA-02021: DDL operations are not allowed on a remote database

WORK AROUND: LOCAL DB: ---------------------------------------------------------------------------------connect dev1/dev1 SQL> create view v1 as select * from test; View created. SQL> SQL> sSQL> Select * from v1; VALUE ---------1 2 3 4 5 6 SQL> grant select on v1 to dev2; Grant succeeded.

SQL> conn dev2/dev2 Connected. SQL> select * from dev1.v1; VALUE ---------1 2 3 4 5 6 Inferences: ----------------------------------------------------------------------------------Privileges on remote table/view can not be granted to local users. First create a local view on the remote table/view. Grant privileges on the local table/view to local users. References: ----------------------------------------------------------------------------------http://www.scribd.com/doc/106316680/If-Exists-if-Not-Exists-in-Oracle http://www.scribd.com/doc/21767673/NULLI-SECUNDUS http://www.dbasupport.com/oracle/ora10g/synonyms.shtml

http://www.adp-gmbh.ch/ora/concepts/synonyms.html Acknowledgements: ----------------------------------------------------------------------------------Thanks to Dinesh Tenneti and Chander, for creating the test case scenarios and verifying the discussed solutions.