Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Database Links

RE: Database Links

From: Hawkins Family <jhawkins_at_primary.net>
Date: Thu, 31 May 2001 08:11:15 -0700
Message-ID: <F001.003157FA.20010531060057@fatcity.com>

Tracy,

I have a similar deal going on here. If you are on version 8.1.x and the lookup tables are large, you can use Materialized Views, and since they are lookup tables that shouldn't change much, you should only have to refresh them every once in a while. If they are really small tables, however, you can just use database links. What I do is create a view across a database link on top of the lookup tables. I then create a synonym on the view that is the same as the lookup tables' name. The users, then, have no idea the tables don't exist locally.

Jim

Jim Hawkins
Lead SAPR/3 Oracle DBA
MEMC Electronic Materials, Inc.
St. Louis, MO
(636) 474-7832

jhawkins_at_memc.com (work)
jhawkins_at_primary.net (personal)
-----Original Message-----
Rahmlow
Sent: Wednesday, May 30, 2001 6:10 PM
To: Multiple recipients of list ORACLE-L

We have several large "look-up" tables that we use in development as well as in
production environments. The data is the same in both environments. I am looking for some comments regarding whether or not we store duplicate data in
each environment or should we allow the development users to access the table
in production through a database link. Below, I have listed some issues with
both of these processes and am looking for further input. Thanks

Duplicate table in production and development (either through export/import or
snapshots):

   Cons

        additional storage is need
        process needed to keep tables in sync
   Pros
         reduced network traffic


Access table in production through a database link in development:

   Cons

        additional network traffic
        possibility of poorly tuned adhoc sql executing in a production
        environment
   Pros
        only one copy of table
        do not need an ongoing process to keep the tables in sync


--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Tracy Rahmlow
  INET: Tracy.Rahmlow_at_aexp.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L

(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Hawkins Family INET: jhawkins_at_primary.net Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Thu May 31 2001 - 10:11:15 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US