I’m working thru this issue with vendor software now. The application
installation requires a schema, and there are scripts to run to pre-create the
schema.. so it seems it should not be necessary to grant DBA privileges. I’ve
decided to put tracing/auditing on to see what the application user is trying
to do when it connects, and maybe this way, can grant just the privileges
needed instead of DBA.
If anyone has done this before and is willing to share their scripts, etc.
please contact me? Or post URL
Thank you.
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On ;
Behalf Of Rich J
Sent: Thursday, July 14, 2016 9:31 AM
To: Oracle L
Subject: RE: DBA granted to app schema
On 2016/07/14 07:54, Dimensional DBA wrote:
The reasons are many as I explained yesterday. There are a variety of COTS
vendor software that was written to think they own the database world and need
the access through one administrative user to control other users that are a
part of their application in the database. Normally these applications are
purchased by a specific team in the company in a lot of cases other
infrastructure teams before the DBA team evens knows the app exists and there
is nothing that can be done at that point as the vendor is not changing their
app and it has to be implemented.
I'm going through something similar right now, although I was able to talk the
vendor out of the DML "ANY" privs. Instead of installing their schema into our
ERP DB, I have an auxiliary DB that connects to the ERP DB via links. I
created schemas to mirror the ERP DB, then views over the DB links. The vendor
keeps warning of performance problems of the DB links, as though their views
than generate 70-line explain plans aren't the real issue...
Not that this method will work for every vendor's software, but it might be one
alternative.
Rich
