RE: Database Links

Can I give a suggestion ,

how about create a unique user which will have all the link db , so much so that we will know where is the link come from , and it seen easily to manage ? Will it be a solution to this ?

-----Original Message-----
Sent: Thursday, May 31, 2001 2:46 PM
To: Multiple recipients of list ORACLE-L

Tracy,

Allowing developers to muck around in your production system is not generally a good idea. If you create db links for them, that's what they will be doing.

In addition, have you ever managed an environment like that? I have and it's not pretty.

How will you administer the privileges?

Will it be a public database link ( dangerous ) or lots of private database links (messy )?

Will the connection be to their own account on the production system ( that you must create ) or an account that has all the needed privs?

Managing this is something of a headache. And when your developers do a cartesian join on your production database, you will be scrambling to determine which session is causing it, and determining if you can safely kill it.

etc, etc, etc. :)

Jared

On Wednesday 30 May 2001 16:09, Tracy Rahmlow wrote:
> 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: Jared Still
  INET: jkstill_at_cybcon.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: Raymond Lee Meng Hong
  INET: RAYMOND_at_infopro.com.my

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).