how to resolve SQL Error: ORA-14411 - oracle

I am trying to alter a table by adding a column, but it's giving the following error:
ALTER TABLE TUSER
ADD CREATED_BY VARCHAR2(250)
SQL Error: ORA-14411: The DDL cannot be run concurrently with other DDLs
How to unlock the resource which is causing this error?

A little old question, but found another solution.
Looks like this error also can occur due to deadlock in the table (many users working on the same table, etc.)
So you can kill sessions via then menu: Tools --> Monitor Sessions --> Choose selection.
There you should see a table with all running commands, the command, the user and more.
Right click --> Kill session.
Link to Oracle documentation

My colleague had the same problem in the Oracle SQL developer, he executed a DDL statement and the machine was taking forever. Somehow it was not reachable, and after some time it responded again. No idea what happened and my colleague called me for help.
After the machine answered again he tried to execute the same statement which returned an ORA-14411.
The solution was to just click rollback in the same prompt-frame, and after that we were able to re-execute the same statement successfully.

try this:
ALTER TABLE TUSER
RENAME TO new_TUSER;
ALTER TABLE new_TUSER
ADD (CREATED_BY VARCHAR2(250));
ALTER TABLE new_TUSER
RENAME TO TUSER;

Related

ora-65090: operation only allowed in a container database

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.

How do I work around the Oracle DBLinks limit in Entity Framework?

I am creating an MVC application using Oracle's Entity Framework, and am writing a bit of code to iterate through all relevant DBLinks and testing them out, returning a grid of results (success/fail). My problem is that after using the fourth DBLink, I get an error "ORA-02020: too many database links in use".
I have tried to explicitly close each DBLink after using it ("alter session close database link LinkName"), but I then receive an error "ORA-02080: database link is in use".
I have tried issuing "COMMIT" statement before attempting to close the DBLink, but that doesn't change the error ("database link is in use").
I have tried to closing the database connection, but I still receive the "database link is in use" error when I create a new connection and try to close the DBLink.
Unfortunately, increasing the number of DBLinks available (open_links, open_links_per_instance) is not an option.
Has anyone seen this with Entity Framework and discovered a solution? Does anyone have any ideas of what else to try?
VICTORY! I found that if I set "Pooling=false" in my connection string, then this error goes away in all of the offending scenarios. This is viable for me since this is just used to test the DBLinks on demand, so I can safely turn off pooling in this scenario. Thanks so much for your responses. I was ready to turn in the towel and admit defeat
To see how many db links are open i syour session use the GV$DBLINK view
select DB_LINK from GV$DBLINK;
DB_LI
-----
LEDRP
YDO
To close a db link you must do two things.
First commit or rollback the transaction. Note that even if you do not change anything a transaction is open due to the use of the DB LINK.
Second you must CLOSE DATABASE LINK using the ALTER SESSION statement.
rollback;
ALTER SESSION CLOSE DATABASE LINK LEDRP;
You see, that link is closed and appears not in the view:
select DB_LINK from GV$DBLINK;
DB_LI
-----
YDOV

Oracle Database Copy Failed Using SQL Developer

Few days ago while i tried perform database copy from remote server to local server i got some warnings and one of them was like this
"Error occured executing DDL for TABLE:MASTER_DATA".
And then i clicked yes, but the result of database copy was unexpected, there were only few tables has been copied.
When i tried to see DDL from SQL section/tab on one of table, i got this kind of information
-- Unable to render TABLE DDL for object COMPANY_DB_PROD.MASTER_DATA with DBMS_METADATA attempting internal generator.
I also got this message and i believe this message showed up because there's something wrong with DDL on my database so tables won't be created.
ORA-00942: table or view does not exist
I've never encountered this problem before and i always perform database copy every day since two years ago.
For the record before this problem occurred, i have removed old .arch files manually not by RMAN and i never using any RMAN commands. I also have removed old .xml log files, because these two type of files have made my remote server storage full.
How to trace and fix this kind of problem? Is there any corruption on my Oracle?
Thanks in advance.
The problem was caused by datafile has reached its max size though. I have resolved the problem by following the answer of this discussion ORA-01652: unable to extend temp segment by 128 in tablespace SYSTEM: How to extend?
Anyway, thank you everyone for the help.

How to copy a JOB, PROGRAM, SCHEDULE definition to run it in another Oracle 11g DB?

I need to copy some Jobs, Schedules and Programs from an Oracle 11g DB to another one, but when I try to look for the SQL of the Job/Schedule/Program on SQL Developer 4.1.3, the SQL tab shows nothing on Edit mode.
When I open a table and I click on the SQL tab, the SQL for create the table is showed up. I was expecting a similar behavior for a Job/Schedule/Program.
How can I copy a JOB/PROGRAM/SCHEDULE definition to run it in another Oracle 11g DB?
The easiest way for Jobs is to use DBMS_METADATA:
select dbms_metadata.get_ddl('PROCOBJ', job_name)
from user_scheduler_jobs;
I'm not 100% sure about schedules / programs, though.
I think you can also use expdp utility and use include=PROCOBJ. All schedules are objects type PROCOBJ. The you should have all jobs which are owned by schema you are exporting. (If you want DDL you can use impdp with sqlfile= to write dump into SQL file. Or use method suggested by Frank Schmitt)
Unfortunately I think if you use this method or method suggested by Frank Schmitt I think you won't be able to get schedules owned by SYS.

How do I track down what's re-enabling triggers during my SQL*Loader load?

I seem to be seeing a lot of messages like this in my log:
Trigger DEV."MBR_TRG" was disabled before the load.
Trigger DEV."MBR_TRG" was re-enabled by another process.
SQL*Loader-951: Error calling once/load initialization
ORA-00604: error occurred at recursive SQL level 1
ORA-00054: resource busy and acquire with NOWAIT specified
This is on my local dev machine, so there shouldn't be anything else trying to insert into these tables. How can I track down the cause of this? And is there any way to prevent the triggers from being re-enabled (at least to see if I get an error anywhere in my script)?
If this is your local dev machine you can drop the trigger and recreate it later.
Or you can change the trigger code to something that will not mess with your data but will only log execution so you can see when it was enabled.
It looks like the type of trigger can have an impact on how sqlloader deals with the trigger. As far as tracking the cause I would try a DDL trigger
I was seeing these errors in direct path loads. The problem was not 'another process' as the error message suggested, but lack of the proper permissions for the user to disable the trigger. You must have permission to alter the table AND the trigger. Which means you must own the table, or have alter permission on the table, or have alter any table permission. Also, you must own the trigger, or have alter any trigger permission.

Resources