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.
Related
How to rename the table which is under other schema? For example, my user is A, I want to rename table_1 to table_1_temp which both supposed to be under the same schema, let's say schema B. Is that possible?
I tried this:
RENAME B.table_1 TO B.table_1_temp
and
RENAME B.table_1 TO table_1_temp
but got this error:
ORA-01765: specifying owner's name of the table is not allowed
ALTER statement is also doesn't work:
ALTER TABLE B.table_1 RENAME TO table_1_temp
got this error:
ORA-01031: insufficient privileges
and this
ALTER TABLE B.table_1 RENAME TO B.table_1_temp
ORA-14047 ALTER TABLE|INDEX RENAME may not be combined with other operations
"Insufficient privilege" is the keyword here. You can't modify other users' objects unless you're allowed to; of course you can't - how would it look like if anyone messes up with your schema?
Owner itself can't grant that privilege; it is a strong one and user - who is granted such a privilege - must be trustworthy as it can alter any other user's tables.
Have a look at the following example. There are two users in my database: mike (who owns a table) and scott (who should rename mike's table).
Mike and his table:
SQL> show user
USER is "MIKE"
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
BEDIENSTETER TABLE
Connect as scott and try to rename mike's table (rename won't work here; it is supposed to be used in your own schema):
SQL> connect scott/tiger
Connected.
SQL> alter table mike.bediensteter rename to test;
alter table mike.bediensteter rename to test
*
ERROR at line 1:
ORA-01031: insufficient privileges
Right; insufficient privileges. What privilege is it? ALTER ANY TABLE. So let's grant it, connected as a privileged user (such as SYS in my XE database):
SQL> connect sys as sysdba
Enter password:
Connected.
SQL> grant alter any table to scott;
Grant succeeded.
OK; back to scott, repeat the action:
SQL> connect scott/tiger
Connected.
SQL> alter table mike.bediensteter rename to test;
Table altered.
Succeeded! Let's see what we've done:
SQL> connect mike/lion
Connected.
SQL> select * from tab;
TNAME TABTYPE CLUSTERID
------------------------------ ------- ----------
TEST TABLE
SQL>
Right; table is now renamed.
Rename Oracle Table or View
as you can see on this post based on Pop's answer, the RENAME statement only works for table in the same schema.
The ALTER TABLE B.table_1 RENAME TO table_1_temp looks to be the best solution, have you tried giving your user account more privileges ?
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 am trying to create new user in PL/SQL. I am getting an error as follows:
User you use to create another user doesn't have required privileges.
In Oracle, such a "privileged" user is SYS. For example:
SQL> connect sys as sysdba
Enter password:
Connected.
SQL> select tablespace_name from dba_tablespaces;
TABLESPACE_NAME
------------------------------
SYSTEM
SYSAUX
UNDOTBS1
TEMP
USERS
SQL> create user brisime identified by blabla
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
SQL>
If I try to do the same as a non-privileged user (i.e. the one that doesn't have create user privilege), it'll fail:
SQL> drop user brisime;
User dropped.
SQL> connect scott/tiger
Connected.
SQL> create user brisime identified by blabla
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
create user brisime identified by blabla
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL>
But, if SYS grants create user to scott, Scott will also be able to do that:
SQL> connect sys as sysdba
Enter password:
Connected.
SQL> grant create user to scott;
Grant succeeded.
SQL> connect scott/tiger
Connected.
SQL> create user brisime identified by blabla
2 default tablespace users
3 temporary tablespace temp
4 quota unlimited on users;
User created.
SQL>
Therefore, make sure to acquire required privileges before trying to create user.
The same goes for altering the user - you need to have those privileges.
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.
I have a problem where I am creating a table using the execute immediate command in the stored procedure. However I get the error of "insufficient privileges". I checked other threads and made sure that the user has "CREATE TABLE" privilege granted to it. However I still keep seeing the same error.
SQL> select * from USER_SYS_PRIVS;
USERNAME PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
MYUSER CREATE VIEW NO
MYUSER UNLIMITED TABLESPACE NO
SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE CLUSTER
CREATE VIEW
CREATE SEQUENCE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE
CREATE OPERATOR
CREATE INDEXTYPE
11 rows selected.
The Dummy procedure I created is :
create or replace procedure sp_dummy
as
begin
execute immediate 'Create table Dummy99_99 (Dummy_Field number)';
end sp_dummy;
/
Detailed error :
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "MYUSER.SP_DUMMY", line 4
ORA-06512: at line 1
Is there something wrong I am doing ?
You only have create view granted directly to your user. The other system privileges you can see are coming from a role, and roles are disabled in definer's-rights stored procedures. Look in user_role_privs to see while roles you've been granted, and you can see which privileges each role gives you in role_sys_privs (with the role name as the grantee). There could be several layers of roles too.
You would see the same error if you did set role none before trying to create a table statically. Demo with minimal set-up:
create role myrole;
grant create session, create table, create procedure to myrole;
create user myuser identified by mypasswd;
grant myrole to myuser;
grant create view, unlimited tablespace to myuser;
Then as that user:
SQL> connect myuser/mypasswd
Connected.
SQL> select * from user_sys_privs;
USERNAME PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
MYUSER UNLIMITED TABLESPACE NO
MYUSER CREATE VIEW NO
2 rows selected.
SQL> select * from session_privs;
PRIVILEGE
----------------------------------------
CREATE SESSION
UNLIMITED TABLESPACE
CREATE TABLE
CREATE VIEW
CREATE PROCEDURE
5 rows selected.
SQL> Create table Dummy99_99 (Dummy_Field number);
Table created.
SQL> drop table Dummy99_99 purge;
Table dropped.
SQL> set role none;
Role set.
SQL> Create table Dummy99_99 (Dummy_Field number);
Create table Dummy99_99 (Dummy_Field number)
*
ERROR at line 1:
ORA-01031: insufficient privileges
And with your stored procedure version:
SQL> connect myuser/mypasswd
Connected.
SQL> create or replace procedure sp_dummy
2 as
3 begin
4 execute immediate 'Create table Dummy99_99 (Dummy_Field number)';
5 end sp_dummy;
6 /
Procedure created.
SQL> exec sp_dummy;
BEGIN sp_dummy; END;
*
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "MYUSER.SP_DUMMY", line 4
ORA-06512: at line 1
To be able to create the table dynamically from a stored procedure, your DBA will need to grant create table directly to your user:
grant create table to myuser;
Then trying the procedure again:
SQL> connect myuser/mypasswd
Connected.
SQL> select * from user_sys_privs;
USERNAME PRIVILEGE ADM
------------------------------ ---------------------------------------- ---
MYUSER UNLIMITED TABLESPACE NO
MYUSER CREATE TABLE NO
MYUSER CREATE VIEW NO
SQL> exec sp_dummy;
PL/SQL procedure successfully completed.
SQL> desc Dummy99_99
Name Null? Type
----------------------------------------- -------- ----------------------------
DUMMY_FIELD NUMBER
Notice that user_sys_privs now shows that create table has been granted directly, which it didn't before, or in the question.
However, it is very unlikely you would ever really want to create objects dynamically, as the schema should be well defined and stable - changes of this type should be controlled and be part of a release process. But as an exercise, you need the direct grant.
When using execute immediate, procedure must explicitly tell oracle that it must run with privileges of a particular user.
AUTHID CURRENT_USER, to use the privileges of user running the procedure.
AUTHID DEFINER, to use the privileges of owner of the procedure.
This is done using AUTHID option while creating a procedure.
CREATE OR REPLACE PROCEDURE PROC_NAME AUTHID CURRENT_USER
IS
.....
I faced a similar issue and got the understanding from:
Execute Immediate within a stored procedure keeps giving insufficient priviliges error
If you are connected as myuser user, you should be able to create the procedure, and execute it to create the table.
The only privileges required to do the task are:
CREATE SESSION
CREATE TABLE
CREATE PROCEDURE
And then execute the procedure after connecting to the user:
SQL> CREATE USER TEST IDENTIFIED BY TEST;
User created.
SQL> GRANT CREATE SESSION, CREATE TABLE, CREATE PROCEDURE TO TEST;
Grant succeeded.
SQL> conn TEST/TEST#pdborcl;
Connected.
SQL> show user
USER is "TEST"
SQL> CREATE OR REPLACE PROCEDURE sp_dummy
2 AS
3 BEGIN
4 EXECUTE immediate 'Create table Dummy99_99 (Dummy_Field number)';
5 END sp_dummy;
6 /
Procedure created.
SQL> EXEC sp_dummy;
PL/SQL procedure successfully completed.
SQL> select * from dummy99_99;
no rows selected
The necessary concessions are as follows:
GRANT CREATE TABLE TO "USER";
GRANT EXECUTE ANY PROCEDURE TO "USER" ;