Oracle Tips  by Burleson Consulting

The Data Warehouse Development Life Cycle

SQL*Net For Oracle Distributed Data Warehouses

Let's take a closer look at the database link. In this simple example, no mention is made of the user ID used to establish the connection on the remote database. Because Scott is the user connecting to SQL*Plus, Scott will be the user ID when the remote connection is established to the London database. Therefore, Scott must have SELECT privileges against the employee table in London in order for the query to work properly. Scott's privileges on the initiating Oracle have no bearing on the success of the query.

Note: If you are using the Oracle Names facility, you must be sure that your database service names are the same as the global_databases_names and the DOMAIN init.ora parameter.
In cases where SELECT security is not an issue, you can enhance the database link syntax to include a remote connect description, as follows:

CREATE DATABASE LINK london USING 'london'
CONNECT TO scott1 IDENTIFIED BY tiger1;

This way, all users who specify the london database link will connect as Scott1 and will have whatever privileges Scott1 has on the London system.

Once you establish a communications pathway to the remote database, it is often desirable to implement location transparency. In relational databases such as Oracle, you can obtain location transparency by creating database links to the remote database and then assigning a global synonym to the remote tables. The database link specifies a link name and an SQL*Net service name. You can create database links with a location suffix that is associated with a host name (in this example, london).

If you like Oracle tuning, you may enjoy the book Oracle Tuning: The Definitive Reference , with over 900 pages of BC's favorite tuning tips & scripts.  You can buy it directly from the publisher and save 30%, and get instant access to the code depot of Oracle tuning scripts.