RE: two instance -- one database

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_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] 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?

--
http://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

--
http://www.freelists.org/webpage/oracle-l