I'm new to Oracle and would like to know the way how to get more statistics in the case i'll describe below. I'm using SQL Developer.
First, I execute this:
SET autotrace on;
SELECT NAME
FROM PASSENGER
WHERE ID_PSG IN (
SELECT ID_PSG
FROM PASS_IN_TRIP PIT JOIN TRIP T on T.TRIP_NO = PIT.TRIP_NO
WHERE UPPER(TOWN_FROM) = 'MOSCOW'
)
In Script Output I can see info about the query from PLAN_TABLE table and after that there's the text:
Unable to gather statistics please ensure user has correct access. The
statistic feature requires that the user is granted select on
v_$sesstat, v_$statname and v_$session.
I've tried to find a solution here already, there's a link:
SQL Developer : Unable to gather system statistics : insufficient privileges
So I executed the same commands and the grants were all succeded:
GRANT CREATE session TO PRACTICE;
GRANT GATHER_SYSTEM_STATISTICS TO PRACTICE;
GRANT CONNECT TO PRACTICE;
Then I disconnected, closed SQL dev, opened it, connected again as it was described in the solution from the link, ran
execute dbms_stats.gather_system_stats ('START');
and got this:
PL/SQL procedure successfully completed.
Then I thought everything is fine and tried to execute the code from the very beginning and its Script Output was still the same as before.
Do I have to grant anything else or this statistics can be found in the other place or I just did everything wrong?
That error is about sqlplus autotrace, it's not about gathering system statistics like your linked post seems to be about.
There is a role created specifically for these grants called plustrace https://docs.oracle.com/database/121/SQPUG/ch_eight.htm#SQPUG535
To use this feature, you must create a PLAN_TABLE table in your schema
and then have the PLUSTRACE role granted to you. DBA privileges are
required to grant the PLUSTRACE role. For information on how to grant
a role and how to create the PLAN_TABLE table, see the Oracle Database
SQL Language Reference.
I have two users on windows server
Administrator
devUser
Both can use SQL Developer to connect to Oracle 11g Server (Oracle e-Business suite) but in the same query (from synonym) they got the difference result: devUser got the correct result and Administrator got null in first three columns.
SELECT * from XXAUTO.XXFND_OU_COMPANY_V
where ou_name like 'ASL%'
Query Result from Administrator(Windows User)
Seems like the view has some form of VPD in place. Oracle supports Fine-Grained Access Control through its DBMS_RLS package, which despite the name allows us to implement security policies on columns as well as rows (since 10g). Find out more.
The common model is, when users connect to the database a LOGON trigger populates an application context with details about them. These details are used to generate as additional filters on tables and views which have security policies in place. You can confirm this by using the pertinent views: start with ALL_POLICIES and drill down depending on what you find.
It's possible the view implements a hand-rolled version of this (FGAC is an Enterprise Edition feature) but if you're using EBS that seems unlikely.
Another option is that your database is protected by Oracle Database Vault. This product is a chargeable extra to the EE license. It is a very powerful tool, and one of its uses is to prevent super users like sysadmins or DBAs abusing their privileges to look at sensitive data. It seems unlikely that an organisation would put Database Vault in place on a server that developers have access to but I offer this suggestion for completeness. Find out more.
Thank you for all.
Now I found the problem that is both user set the different Windows locale.
For our application we're using outsorced Oracle administration. Now we'd like to prevent external oracle administrator from changing our data (DELETE, INSERT, UPDATE).
Is there any way how to do it?
Is there possible to REVOKE eg. UPDATE ANY TABLE to SYS account and is this sufficient?
I have read the Oracle Security Guide but haven't found anything. Only a statement: Do not use a DBA role which contains eg. the UPDATE ANY TABLE privilege.
I see I also should REVOKE GRANT ANY PRIVILEGE ...
Simply I'd need a complex guide how to do it and I'm not able to find any document about it.
Thanks
I have to install an application server that requires an user to write to the database, possibly create new schemes and such. However, I've always used the "work around" to assign the DBA Role to that user.
I have some questions, as I am not that deep into Oracle security.
Has the DBA role a level of privileges that can affect the whole Oracle installation?
Where can I find what privileges the DBA role exactly have?
How do I create an alternative role?
Thanks,
1) Yes, the dba role should have enough privileges to screw up a database beyond fixing.
2)
select *
from role_sys_privs
where grantee = 'DBA';
3) Unless you plan on having several user with similar privileges, I recommend creating a user and grant all needed privileges explicitly to this user instead of via a role.
You can read more about the topic in
Oracle Database Security Guide chapter 11, Administering User Privileges, Roles, and Profiles
First look into Ronnis' solution. If this is not sufficient create a package, owned by SYSTEM, and grant EXECUTE to the user or users that need it. Add procedures that perform the needed operations taking care to limit their power as much as possible.
...and how should those permissions be granted. I work in a large IT dept with 70+ applications, some in SQL server and most in oracle. Each system has a prod, QA and Dev instance. We (I'm a developer) have readonly access to prod/qa, which I'm fine with. In SQL server development instances devs are given db_owner, which works totally fine. The debate is over what permissions I should have in the DEV oracle databases.
I recognize that best case would be to have each dev run their own instance on their workstation for development, but because of the size of the databases this has not been considered an option.
I'm also interested in HOW these permissions should be applied. In oracle permissions granted via a role are not active during PL/SQL execution so roles (even the "dba" role) are not useful. That leaves using a built in account (system) or creating dozens of users accross dozens of database and directly granting dozens of permissions to each.
In my mind just letting the devs login as system is making a lot of sense, but our DBAs claim that's a bad idea.
We used to just give developers access to the application account. This works for small shops but rapidly gets out of hand as the number of developers increase.
Here's what we do now:
the Application has it's own account (aka schema).
Developers have their own accounts
Data resides in the application schema
We have an ant build script to build code into whatever schema you want.
code includes views, packages, objects etc..
the build script includes a step to run a stored procedure to grant explicit rights to developers to the application data
Developers make changes in their own schema
When happy they check that into subversion
The Application's dev schema is built from the new subversion build.
Developers can check out and rebuild their own environments.
DDL changes to table structures are done via the DBA
these can be scripted as well
This has the benefit of ensure any front end application is not broken by database developers constantly rebuilding everything.
I assume that there are a relatively small number of application accounts that own the actual objects. So one or more logical applications are comprised of tables owned by a particular Oracle user. This would not by SYSTEM or SYS, it would not be any of the accounts that Oracle the company delivers. It would be an account that your DBAs created. If you are familiar with the Oracle sample schemas, the HR user owns all the tables in the HR schema which comprise the back end for an HR application.
Starting from the principle of "the simplest thing that could possibly work," my first thought would be to see if the developers could log in directly to those application accounts. This isn't the securest possible configuration, and you are opening up the possibility that a developer accidentally or intentionally does some damage that may be difficult to track or easily resolve. But it can work reasonably well depending on the organization. Privilege management is trivial-- the application owner account already has all the privileges it needs most likely.
The next step up would be giving every developer a separate schema to develop in, presumably in conjunction with a load of public synonyms in the database and an absence of schema qualifiers in the application code, so that any object created in the developer's schema automatically overrides the shared version of that object. This provides much better isolation. Permissions are generally granted by either creating scripts that contain all the grants a developer needs or by creating a script that copies all the privileges from a "known good" account to the new account. Neither is particularly difficult to write-- you just have to make sure that all the developers end up with the same set of privileges, which is generally just another script that gets run when a new privilege is granted.
If you are developing stored PL/SQL objects, then the schema owning those objects needs, as you mentioned, explicit grants on the objects used. If you have a single 'data' schema but are developing code in your own individual schemas then you should get the ability to grant access on the data schema objects to your development schemas. Normally I'd expect username/password for the data schema.
In regards to system privileges (eg CREATE), I'd expect CREATE TABLE, TYPE, VIEW, PROCEDURE TRIGGER, SYNONYM. Others may be appropriate (eg CONTEXT) depending on what you do. The DBA may rule out CREATE DIRECTORY as that could be damaging if mis-used. Ditto for privileges with ANY in them (eg SELECT ANY TABLE, DELETE ANY TABLE)
For performance tuning / system monitoring, on a dev database SELECT_CATALOG_ROLE is good. If the DBA is risk-averse, you may have to negotiate grants on individual views. Go through the REFERENCE guide for your version and ask for any you may use.
One of the DBA's jobs is to manage user privileges. I don't think system is a good idea for a few reasons, not the least being the ability to drop an entire schema which I am sure you don't want. That being said, I think it is perfectly fine to grant all to your users and let the DBAs manage these permissions no matter how many dozens of accounts there may be. Most DBAs will have scripts they can use to manage these permissions anyway.
Listen to your DBAs, they generally know what they are talking about.
If it's just a dev instance; i'd have all users have individual accounts added to the admin role. That way you can still log activity on a per-user basis; but give the devs enough breathing room to do their thing.
My group supports about 100 apps with about 20 of them having their own Oracle schema. We have gone down the road of every developer has the password to the schema and it is convenient. However, in hindsight I would recommend that each developer use their own Oracle account to develop. The main reason is auditing.
I recognize that best case would be to
have each dev run their own instance
on their workstation for development,
but because of the size of the
databases this has not been considered
an option.
Is there a way to deal with this, maybe by reducing the amount of data in your personal copies? This seems like the ideal solution, since it would allow you to make any changes you need. Then you could submit them to the DBA when you're ready, and have him update the shared development server.