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.
Related
I am not able to run any query to change to CDB or PDB in SQL plus it shows the above error.
For instance I tried running the query
Alter pluggable database open
and got this error.
ERROR at line 1:
ORA-65090: operation only allowed in a container database
The correct command to change Container is
ALTER SESSION SET CONTAINER = containername;
If you are getting error then you must not be a privileged user
follow up this link for more information
https://docs.oracle.com/database/121/ADMIN/cdb_pdb_admin.htm#GUID-E73BCAED-FF57-474A-A8C5-207D3F465413
I solved it. Though the solution is not a preferable one but it worked for me as of now. I used Database configuration assistant and deleted the pdb in which I getting connected to when logging using sqlplus. I would appreciate some proper solution to this.
is there any way to drop objects and packages of a schema in ORACLE DB without generating archive logs?
i have a huge schema that is decommissioned. i want to drop all its objects first but it generates a lot amount of archive logs which filled my Fast Recovery Area.
please help if you know any solution to the objects of a schema without generation of archive logs.
i tried to use drop for example:
drop package xyz it generated a lot of archive logs.
note:
the database server is holding both active and non active schemas all what i need is to drop the old non active schemas without generating archive logs.
Thank you in advance,
Wissam.
If the system is really going to be decommissioned then you can alter the system and set off archive mode at first place and then start dropping the objects.
The method for disabling archive log mode is:
Shutdown edit pfile / spfile (spfile when instance is up ofcourse) to say log_archive_start = false.
startup mount
alter database noarchivelog;
alter database open;
Read more at here.
I'm looking to get Flyway migrations setup with Oracle 12C, however running the 'flyway baseline' I received the following error on schema_table creation.
Message : ORA-01950: no privileges on tablespace 'USERS'
The end-goal here with this setup is to get a CI and CD process that can create an Oracle Database (with DBCA) then run flyway migrate to migrate the database to the latest version.
With that in mind, how can I get passed this issue? Do i need to create the scheme and Tablespace configuration outside of Flyway before I do anything?.
Edit: Moudiz has suggested ALTER USER quota 100M on USERS, whilst that does get me passed the issue. I'd be more interested in a solution in the area of dbca/flyway configuration. Any extra 'tweak' script i need to run for deployment is not ideal.
this statement should help you.
ALTER USER <user> quota 100M on USERS
We're having issues with a table that is locking up in our system, so we decided to put a tracefile so we can gather more info about it. Here's what we've done:
alter session set tracefile_identifier='10046USERLOGINNR';
alter session set timed_statistics = true;
alter session set statistics_level=all;
alter session set max_dump_file_size = unlimited;
alter session set events '10046 trace name context forever,level 12';
//UPDATE SQL STATEMENTS
alter session set events '10046 trace name context off';
However, and for some reason that we can't identify yet, the trace file 10046USERLOGINNR does not get created.
Anything we're missing?
It looks to me like what you're doing should be working. The things I can think of to check are:
Are you looking in the right place? The trace file should go into the directory indicated by the USER_DUMP_DEST database parameter.
Does the Oracle OS account have write privilege on the directory? If not creation of the trace file will silently fail.
If you're on Windows, you could use Process Explorer to check all the open file handles for oracle.exe after activating tracing. If the file is going to an unexpected location for some reason, you'll find it this way. Presumably there's some way you could check the same thing on other operating systems as well.
Daft theory, but double check the udump_dest_dir setting. Might be getting created somewhere unexpected. (on that, also check bdump for shared server connections).
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.