RE: two instance -- one database
- From: "Brady, Mark" <Mark.Brady@xxxxxxxxxxxxxxxxx>
- To: "rjoralist@xxxxxxxxxxxxxxxxxxxxx" <rjoralist@xxxxxxxxxxxxxxxxxxxxx>, oracle-l <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 24 Sep 2008 12:34:34 -0400
I think that COTS applications always have unique concerns. I should have been
clearer that this is an in-house built app.
But that's a very interesting scenario and approach. Thanks for sharing that. I
have two questions. Do you include SELECT in DML, sometimes it is and.. If you
control INS/UPD/DEL via the view only database, I guess that's fine, but do you
force selects too?
Second, why choose to not create any other schemas in our production? You're
attempting to overcome a security deficiency in the prod database, why not
create the Gatekeeper schema there? Seems like an aesthetic decision more than
a practical one.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Rich Jesse
Sent: Wednesday, September 24, 2008 11:19 AM
To: oracle-l
Subject: Re: two instance -- one database
The reason I use a scenario like the one you describe is that the security
concerns outweighed the negative impact to performance. I'm not sure how
dblinks protect from bad queries...
In any case, we use JD Edwards Enterprise One. The first thing it does
after creating a table in Oracle is "GRANT ALL ON schema.table TO PUBLIC;".
Joy. An auditor's dream.
Instead of hacking with triggers and timing, I chose to not create any other
schemas in our production JDE DB. Instead, we have an ancillary DB where
the DML security is controlled via views over a dblink to the JDE DB. While
more elegant (perhaps), it's not best for performance.
My $.02,
Rich
> I have a friend (no really, this isn't some lame way of telling you about me
> but trying to hide that by ... )
>
>
> I have a friend, and at his company they have an Oracle database with tables
> and data. We'll call it Database A and they have another Database B that has
> views across dblinks to each of the tables in Database A. The data team says
> that this protects Database A from bad queries.
>
> So can anyone think of any possible benefit from this arrangement? Will
> administration be easier, queries faster, performance more predictable?
> Anything?
--
//www.freelists.org/webpage/oracle-l
>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the
addressee. If you are not the intended recipient, do not use the information
in this e-mail in any way, delete this e-mail and notify the sender. CEG-IP2
--
//www.freelists.org/webpage/oracle-l
Other related posts:
