I am trying to drop a tablespace in oracle 10g , using my application .
A bit about my application -- In my application I can create tablespaces.
Now what happens in oracle is that when you create a tablespace , then a new user automatically gets created and is attached to the database.
When you have to drop a tablespace what one has to do is to , first drop the user connected to the database and then the database.
When I try to drop a user associated with a tablespace.
An exception is thrown by the database which is the System.Data.OracleClient.OracleException
The details of the exception are as follows - ORA - 01904 (Can Not drop a user that is currently connected)
The thing is I have closed all the connections.Pretty sure about this.
Still oracle is throwing this exception.
Any suggestions???
Still it is not able to drop the user and throws the exception.
It can happen that you closed applications but did not ended Oracle sessions for that user. Log in as sysdba and query active sessions:
SQL> select sid, serial#, username from v$session;
SID SERIAL# USERNAME
---------- ---------- ------------------------------
122 2557 SYS
126 7878 SOME_USER
If you find your user in this list then kill all his sessions:
SQL> alter system kill session 'sid,serial#';
Seems to be your error code is ORA-01940 and not ORA-01904 which says -
ORA-01940: cannot DROP a user that is currently logged in
Cause: An attempt was made to drop a user that was currently logged in.
Action: Make sure the user is logged out, then re-execute the command.
Hope the below link might help you -
http://www.dba-oracle.com/t_ora_01940_cannot_drop_user.htm
We do following and works..
ALTER TABLESPACE "OUR_INDEX" OFFLINE NORMAL;
DROP TABLESPACE "OUR_INDEX" INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS;
Please be sure that the user you're trying to drop is not currently connected. I did encounter this problem last year. My workaround was to restart the database. Once the database is up i drop the user.
Another workaround i haven't tried was to restart the listener. This too (logically) can ensure that the 'to be dropped' user is not connected when the listener is down.
This workaround (of course) cannot be used in production database.
A user does NOT automatically get created when you create a tablespace.
A user does get assigned a default tablespace. They may (or may not) create objects in that tablespace. They may (or may not) create objects in other tablespaces too.
Generally, rather than dropping the user, I would drop the user's objects. Then lock the account so they can't log in again. Then revoke any privileges they have.
If desired, you can then drop the 'unused' users after month or so.
Related
Basicly i have an java application that uses oracle as a data source. Now my application connects with a user and uses connected user's schema for table creation and etc...
Now i have a requirment that my application also should work under another schema.
So i have to alternatives.
1 - Change my table names with a prefix like
select * from other_schema.table
2 - Altering the session before running any query like
alter session set current_schema=other_schema
I am curios about is there any possibilty that alter session privilege can be revoked by dba's.
Oracle documentation says that
You do not need any privileges to perform the other operations of this statement unless otherwise indicated.
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_2012.htm
Please note that my app user will have all privileges for other_schema.
My application will be running many envoriments.
So going with first appoach, it looks like more safe but it can take long time.
Second one is faster but seems like tricky.
Yes they do. There is a role called CONNECT. This role usually (depending on version) gives you two system privileges:
create session
alter session
when your user has only create session privilege granted directly then you can not use any alter session ... statement.
Se Oracle docs:
Addressing The CONNECT Role Change
Note that the ALTER SESSION privilege is required for setting events.
Very few database users should require the alter session privilege.
SQL> ALTER SESSION SET EVENTS ........
The alter session privilege is not required for other alter session
commands.
SQL> ALTER SESSION SET NLS_TERRITORY = FRANCE;
So it really depends on Oracle version.
The CONNECT role was changed in 10gR2. It used to have most of the permissions of RESOURCE, but these were revoked in 10gR2.
I just tried ALTER SESSION with a user that only had CREATE SESSION and much to my surprise it worked, at least in 11.2.0.4.
I am trying to create new User from my SYSDBA account, but when I run the Query it is not responding even after long time. Same issue also occurs when I try to IMPDP.
here is my Query.
create user USER_NEW
identified by USER_NEW
default tablespace MY_TABLESPACE;
I am not getting any error in Alert Log file, also tablespace has 99% free space (100MB).
I want to create the user and the database within that user. But when I tried to create database its giving the warning message as
ERROR at line 1:
ORA-01501: CREATE DATABASE failed
ORA-01100: database already mounted
Then I tried
STARTUP NOMOUNT;
Its giving the warning message for insufficient privileges even I have given all the permission to that particular user.
Can any one please help in finding the solution for this?
You don't create a database under a user in Oracle; I believe you're using terminology from another database poduct. The equivalent is a schema, which is a logical container for a group of objects. User and schema are essenentially synonymous in Oracle - when you create a user is automatically has its own schema.
You create the database once (which you already seem to have done, or had done for you), then create as many schemas/users as your application needs. You don't ever rerun the create database under normal circumstances - you certainly wouldn't as a normal user.
If you connect as that user you will be able to create tables, views, packages etc., assuming it has really been granted all the necessary privileges.
I have created Global Temporary table in oracle and inserting the data through my application, and its working fine for me when i connect to database with "system" as the username. Where as i have created one more user in the database with "user1" and have given "Grant all" privileges to this user also. Now when am connecting to database with "User1" as the username and running the application, the data is not inserting into Global temporary table.
But when i try to insert data from sql developer tool its inserting.
With system user through application also working, whereas with user1 its not inserting. Am not getting whats behind going as am not that much DB expert.
Please have any idea suggest me. I have all privileges also. Thanks in advance.
Fist, the table MUST be in other schema than SYS or SYSTEM. Create it on "User1".
Second, you must be sure that you select from the same table. Prefix the table with the schema when inserting and also when reading.
Also be sure that you are not in the situation of table created with ON COMMIT DELETE ROWS and some AUTOCOMMIT ON in Sql Developer.
I have an Oracle instance with 8 users/schemas already but since late last week I am unable to create any new users on that instance. When I run the create user script it just keeps running....
This is a development box and I have full access to it. I am not a DBA so how do I troubleshoot to find out what the issue could be? and what could the issue be?
Here is the create user script:
create user usr_ARCHIVE identified by usr_ARCHIVEpw
default tablespace USERS
temporary tablespace TEMP
profile DEFAULT
quota UNLIMITED on USERS;
Please have a look at the user tablespace to see whether it has enough free space or not. I have faced similar issues in the past.
It's probably waiting or trying to obtain a lock. To determine what is going on you need to enable tracing. Before executing the create user statement, execute the following command:
alter session set events '10046 trace name context forever, level 12';
This will create a trace file in the trace directory. By default this is the same directory where the alert.log file is stored. Analyze the trace file and especially check for the lines that start with WAIT.
The problem was with another 10G TNSListener that was running. Once the 10G TNSListener was stopped and 11G Listener restarted the issue was resolved.