Starting from Oracle Database 19c "O7_DICTIONARY_ACCESSIBILITY" parameter has been de-supported. Now our code creating view on SYS.CDEF$ (from another user )is failing with ORA-01031 insufficient privileges error.
The user has the following privileges SELECT CATALOGUE ROLE, EXECUTE CATALOGUE ROLE, SELECT ANY DICTIONARY, CREATE VIEW and CREATE ANY VIEW.
sample:
create view v_Cdef$ as select * from sys.cdef$
ORA-01031 error while creating view on SYS.CDEF$
Can you give us the full script, I can't reproduce
SQL> conn /#db19_pdb1 as sysdba
Connected.
SQL> drop user demo cascade;
User dropped.
SQL> create user demo identified by demo;
User created.
SQL> grant SELECT ANY DICTIONARY, CREATE VIEW , create session to demo;
Grant succeeded.
SQL> conn demo/demo#db19_pdb1
Connected.
SQL> create view v_Cdef$ as select * from sys.cdef$;
View created.
Related
How to invoke privileges to create a view in oracle 10g enterprise edition from the user scott? I am getting insufficient privilege error message while trying to create a view for an existing table
To give privileges to create a view, You need to grant CREATE VIEW to Scott user from sysdba user as follows:
GRANT CREATE ANY VIEW TO Scott;
-- OR --
GRANT CREATE VIEW TO Scott;
TL/DR: you need CREATE VIEW system privilege and SELECT object privilege on the related table.
Actually any user having been granted CREATE VIEW with admin option can grant CREATE VIEW this include SYSDBA and SYSTEM users but also any user having DBA role. To able to create a view on a table you generally also need SELECT privilege on the table.
Example with CREATE VIEW WITH ADMIN OPTION:
SQL> --
SQL> show user;
USER is "SYS"
SQL> --
SQL> create user scott identified by "tiger";
User created.
SQL> grant create session to scott;
Grant succeeded.
SQL> --
SQL> create user myadmin identified by "myadmin" quota unlimited on users;
User created.
SQL> grant create session to myadmin;
Grant succeeded.
SQL> grant create table to myadmin;
Grant succeeded.
SQL> grant create view to myadmin with admin option;
Grant succeeded.
SQL> --
SQL> connect myadmin/myadmin
Connected.
SQL> grant create view to scott;
Grant succeeded.
SQL> create table t(x int);
Table created.
SQL> insert into t values(4);
1 row created.
SQL> commit;
Commit complete.
SQL> grant select on t to scott;
Grant succeeded.
SQL> --
SQL> connect scott/tiger
Connected.
SQL> create view v as select * from myadmin.t;
View created.
SQL> select * from v;
X
----------
4
Background:
We have database FIN having schema as FIN_DEV.
We have another database APP having schema APP_DEV.
A DB link is created in APP_DEV pointing to FIN_DEV
CREATE DATABASE LINK FINDEV_FIN
CONNECT TO FIN_DEV
IDENTIFIED BY <PWD>
USING 'FIN'
We are able to access the objects in FIN_DEV from APP_DEV using
CREATE OR REPLACE SYNONYM TBL_FINA FOR TBL_FINA#FINDEV_FIN
All good until this point.
Here comes the question:
Another schema INT_DEV in APP database needs to access SYNONYM TBL_FINA from INT_DEV.
Could you please let me know the best way to accomplish this?
Here's how; I don't have your users (and don't feel like creating them), so:
my remote database = orcl (it is your fin database)
user in my remote database = my_remote_user (it is fin_dev in your database)
user in my local database = scott (app_dev in your database)
it'll create a database link and a synonym
another user in my local database = mike (int_dev in your database)
In a remote database, I'm creating a table to mimic your situation:
SQL> create table tbl_fina (id number);
Table created.
SQL> insert into tbl_fina values (1);
1 row created.
SQL> commit;
Commit complete.
SQL>
Connecting to local database, creating a database link & a synonym:
SQL> show user
USER is "SCOTT"
SQL> create database link findev_fin
2 connect to my_remote_user
3 identified by its_password
4 using 'orcl';
Database link created.
SQL> -- Testing, whether the DB link works
SQL> select * From dual#findev_fin;
D
-
X
SQL> -- Creating a snynonym
SQL> create synonym tbl_fina for tbl_fina#findev_fin;
Synonym created.
SQL> select * from tbl_fina;
ID
----------
1
SQL>
So far, so good - this is what you currently have.
Now, let's allow another user - in my local database - to access that synonym. Straightforward solution is to grant select on it, right?
SQL> grant select on tbl_fina to mike;
grant select on tbl_fina to mike
*
ERROR at line 1:
ORA-02021: DDL operations are not allowed on a remote database
SQL>
Whooops! That won't work. A workaround is to create a view (on the synonym) and grant select on that view to mike:
SQL> create view v_tbl_fina as select * from tbl_fina;
View created.
SQL> grant select on v_tbl_fina to mike;
Grant succeeded.
SQL>
That works. Finally, connect as another user and select from the view (i.e. a synonym):
SQL> connect mike/pwd
Connected.
SQL> select * from scott.v_tbl_fina;
ID
----------
1
SQL>
For easier access - to avoid naming view owner (scott) - mike can now create its own synonym:
SQL> create synonym tbl_fina for scott.v_tbl_fina;
Synonym created.
SQL> select * from tbl_fina;
ID
----------
1
SQL>
Certainly, another option is to create a database link in my mike user, but that's kind of dangerous as database link allows its owner to do virtually anything in the remote database, as it is now identified by the remote username and its password.
I have created a user(new_user) with a password.
I have granted create session to that user.
I still cannot connect to database as new_user.
ORA-01017.
I can connect as admin.
I can see the user(new_user) in the other users menu in SQL Developer.
When I go to create a table like CREATE TABLE new_user.SALES, I get ORA-01918: user 'NEW_USER' does not exist.
I can right-click and create a table.
I know I have the right password.
Sounds very much like the double quotes issue.
Here's how it is supposed to be done:
SQL> connect sys as sysdba
Enter password:
Connected.
SQL>
SQL> create user new_user identified by new_user
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
SQL> grant create session, create table to new_user;
Grant succeeded.
SQL> connect new_user/new_user
Connected.
SQL> create table test (id number);
Table created.
This is what I suspect you did: drop the old user first:
SQL> connect sys as sysdba
Enter password:
Connected.
SQL> drop user new_user cascade;
User dropped.
SQL>
Now, start over. Pay attention to all double quotes in the following code:
SQL> create user "new_user" identified by new_user
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
SQL> grant create session, create table to new_user;
grant create session, create table to new_user
*
ERROR at line 1:
ORA-01917: user or role 'NEW_USER' does not exist
SQL> grant create session, create table to "new_user";
Grant succeeded.
SQL> connect new_user/new_user
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
SQL> connect "new_user"/new_user
Connected.
SQL> create table new_user.test (id number);
create table new_user.test (id number)
*
ERROR at line 1:
ORA-01918: user 'NEW_USER' does not exist
SQL> create table "new_user".test (id number);
Table created.
SQL>
See? If you created it using double quotes, every time you reference it, you must use double quotes.
I suggest you get rid of them (double quotes) when working with Oracle. That includes users, table names, column names, procedure names, everything.
I'm creating a USER on Oracle 12 c database, using TOAD.
After creating the TABLESPACE, I'm creating the USER. I'm a little confusing about the many ROLES and PRIVILEGES that can be given to a USER.
What are the minimum/standard roles and privileges a user must be given in order to perform CRUD operation and being able to 'edit' the database (create or delete table, DROP the schema ecc) from TOAD?
Thank you
It depends on what operations are you going to perform. If you want to work only with tables in your own db schema, then the following privileges are usually enough to start:
grant create session to <your_user>;
grant create table to <your_user>;
You have the default rights to insert/update/delete/select tables which you own.
Tablespace quota:
alter user <your_user> quota unlimited on <your_tablespace_name>;
It's better to set the default tablespace for the user. In this case you can omit the tablespace name in a create table statement.
alter user <your_user> default tablespace <your_tablespace_name>;
A link to the documentation - Privileges
Grant the user the following privileges:
CREATE SESSION (in order to allow the user to connect to the database)
INSERT
UPDATE
DELETE
SELECT
Use the below command to grant privileges to the user (you need to login as SYS or SYSTEM or another user that has GRANT privilege):
GRANT CREATE SESSION, SELECT, UPDATE, DETETE, INSERT TO user_name
Here's a suggestion you might (or might not) want to follow.
As a privileged user (such as SYS), check tablespaces available in your database. I'm using 11g XE (Express Edition) which shows the following:
SQL> show user
USER is "SYS"
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP --> temporary
USERS --> my data
Now, create a user:
SQL> create user mdp identified by pdm
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
Quite a long time ago, there were two popular predefined roles named CONNECT and RESOURCE which were granted some of the most frequent privileges so people just loved to grant those roles to newly created users.
Nowadays, you shouldn't be doing that: grant only minimal set of privileges your user might need. The first one is CREATE SESSION; without it, your user won't even be able to establish a connection.
SQL> grant create session to mdp;
Grant succeeded.
Then, you'll want to create some tables so - grant it:
SQL> grant create table to mdp;
Grant succeeded.
OK, let's connect as newly created user and do something:
SQL> connect mdp/pdm#xe
Connected.
SQL> create table test (id number);
Table created.
SQL> insert into test id values (1);
1 row created.
SQL> drop table test;
Table dropped.
SQL>
Nice; I can create tables, insert/update/delete/select from them. For beginning, that's quite enough. However, when it turns out that you'd want to, for example, create a view, it won't work until you grant it that privilege:
SQL> create view v_dual as select * From dual;
create view v_dual as select * From dual
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> connect sys#xe as sysdba
Enter password:
Connected.
SQL> grant create view to mdp;
Grant succeeded.
SQL> connect mdp/pdm#xe
Connected.
SQL> create view v_dual as select * From dual;
View created.
SQL>
And so forth; don't grant anything just because you might need it - grant it if & when you need it. Especially pay attention to system privileges which can potentially be dangerous if you don't know what you're doing.
When I'm querying a table in schema C from schema A, I'm getting ORA-01031: insufficient privileges and when I'm querying the same table from schema B, I'm getting ORA-00942: table or view does not exist. On the table neither of the schemas are having any privileges. Why am I getting different error messages in this case?
You may get ORA-01031: insufficient privileges instead of ORA-00942: table or view does not exist when you have at least one privilege on the table, but not the necessary privilege.
Create schemas
SQL> create user schemaA identified by schemaA;
User created.
SQL> create user schemaB identified by schemaB;
User created.
SQL> create user test_user identified by test_user;
User created.
SQL> grant connect to test_user;
Grant succeeded.
Create objects and privileges
It is unusual, but possible, to grant a schema a privilege like DELETE without granting SELECT.
SQL> create table schemaA.table1(a number);
Table created.
SQL> create table schemaB.table2(a number);
Table created.
SQL> grant delete on schemaB.table2 to test_user;
Grant succeeded.
Connect as TEST_USER and try to query the tables
This shows that having some privilege on the table changes the error message.
SQL> select * from schemaA.table1;
select * from schemaA.table1
*
ERROR at line 1:
ORA-00942: table or view does not exist
SQL> select * from schemaB.table2;
select * from schemaB.table2
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL>
ORA-01031: insufficient privileges happens when the object exists in the schema but do not have any access to that object.
ORA-00942: table or view does not exist happens when the object does not exist in the current schema. If the object exists in another schema, you need to access it using .. Still you can get insufficient privileges error if the owner has not given access to the calling schema.
for ORA-01031: insufficient privileges. Some of the more common causes are:
You tried to change an Oracle username or password without having the appropriate privileges.
You tried to perform an UPDATE to a table, but you only have SELECT access to the table.
You tried to start up an Oracle database using CONNECT INTERNAL.
You tried to install an Oracle database without having the appropriate privileges to the operating-system.
The option(s) to resolve this Oracle error are:
You can have the Oracle DBA grant you the appropriate privileges that you are missing.
You can have the Oracle DBA execute the operation for you.
If you are having trouble starting up Oracle, you may need to add the Oracle user to the dba group.
For ORA-00942: table or view does not exist. You tried to execute a SQL statement that references a table or view that either does not exist, that you do not have access to, or that belongs to another schema and you didn't reference the table by the schema name.
If this error occurred because the table or view does not exist, you will need to create the table or view.
You can check to see if the table exists in Oracle by executing the following SQL statement:
select *
from all_objects
where object_type in ('TABLE','VIEW')
and object_name = 'OBJECT_NAME';
For example, if you are looking for a suppliers table, you would execute:
select *
from all_objects
where object_type in ('TABLE','VIEW')
and object_name = 'SUPPLIERS';
OPTION #2
If this error occurred because you do not have access to the table or view, you will need to have the owner of the table/view, or a DBA grant you the appropriate privileges to this object.
OPTION #3
If this error occurred because the table/view belongs to another schema and you didn't reference the table by the schema name, you will need to rewrite your SQL to include the schema name.
For example, you may have executed the following SQL statement:
select *
from suppliers;
But the suppliers table is not owned by you, but rather, it is owned by a schema called app, you could fix your SQL as follows:
select *
from app.suppliers;
If you do not know what schema the suppliers table/view belongs to, you can execute the following SQL to find out:
select owner
from all_objects
where object_type in ('TABLE','VIEW')
and object_name = 'SUPPLIERS';
This will return the schema name who owns the suppliers table.
try to execute this on sql command line:
connect/ as sysdba;
create user b identified by "password";
grant all privileges to b;
and go create a new connection in SQL Developer;
do the same for schema 'c';
and grant privileges for schema 'a' too:
connect/ as sysdba;
grant all privileges to a;
this method fixed the problem for me.
In SQL Developer: Everything was working fine and I had all the permissions to login and there was no password change and I could click the table and see the data tab.
But when I run query (simple select statement) it was showing "ORA-01031: insufficient privileges" message.
The solution is simply disconnect the connection and reconnect.
Note: only doing Reconnect did not work for me.
SQL Developer Disconnect Snapshot
ORA-01031: insufficient privileges
Solution: Go to Your System User.
then Write This Code:
SQL> grant dba to UserName; //Put This username which user show this error message.
Grant succeeded.