This question is related to the one I posted yesterday but with further implications.
The situation is: I'm unable to drop ANY table. Here's an example:
SQL> CREATE TABLE FOO (BAR NUMBER) TABLESPACE SYSTEM
/
Table created.
SQL> SELECT COUNT(1) FROM FOO;
COUNT(1)
----------
0
SQL> DROP TABLE FOO;
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-00942: table or view does not exist
ORA-06512: at line 19
So, the table seems to exist but I'm not capable of dropping it.
Notice the error ORA-00604: error occurred at recursive SQL level 1. If I try to drop a non existing table, this error does not appear:
SQL> DROP TABLE NON_EXISTING_TABLE
ERROR at line 1:
ORA-00942: table or view does not exist
Somehow, the system is unable to find the table at dropping time.
The oracle installation and the DB itself is new (one day old).
EDIT - I retried this test using another tablespace and user (I just created ones) and I got a slightly different behaviour: using SYS, after I got the DROP error I can still SELECT from the table. However, using this new user, after I got the DROP error, I no longer can SELECT from the table.
Solution
We found the problem: the MDSYS.SDO_GEOR_SYSDATA_TABLE was missing, preventing the drop operation.The solution is to restore that table. Here is the complete solution, by Gaurav Soni (by the way, many thanks).
Run the script catmd.sql (located in $ORACLE_HOME/md/admin dir).
The catmd.sql script is the script that loads all objects needed by Oracle spatial in the database. Then drop the user.
you can also refer to oracle metalinks
Steps for Manual Installation of Oracle Spatial Data Option
Dropping user results in ORA-942 against SDO_GEOM_METADATA_TABLE
I'd suggest that you activate SQL tracing (ALTER SESSION SET SQL_TRACE=TRUE;) and try the drop again. This will generate a trace file on the server (in the udump directory) that will show all the SQL the session executed, including recursive statements. This should show you the recursive SQL statement that is failing.
I think the problem is that you created the table on system tablespace. You should create it on the user tablespace or create one to store your data.
Related
I worked on an App using my personal workspace. Exported the same and later installed it on a Developer Team workspace.
Several of my pages are getting the ORA-00942: table or view does not exist while running, which doesn't make sense since the tables do exist (I tested this using the 'SQL Commands' option).
Funny thing is that the same code I'm using is actually applied on a different app within the same workspace and it runs perfectly.
Is this normal behavior? Might be due to workspace's configuration?
Thanks!
It could be a "permissions" issue:
http://www.dba-oracle.com/sf_ora_00942_table_or_view_does_not_exist.htm
Answer: There are several common operations that cause a ORA-00942
error:
Table owner name not specified when logged-in as a non-creator of the table.
ORA-00942 on table import (imp or impdp).
ORA-00942 on materialized view refresh.
...
This ORA-00942 error on insert is common when the user you are
signed-on as does not have permission to see the table!
Either make the table public and grant DML privileges:
connect myuser/mypass
create public synonym testtable for myuser.testtable
grant insert, select, update, delete on mytable to public;
Also, review the various replies to this thread. For example:
https://stackoverflow.com/a/36165446/421195
Because this post is the top one found on stackoverflow when searching
for "ORA-00942: table or view does not exist insert", I want to
mention another possible cause of this error (at least in Oracle 12c):
a table uses a sequence to set a default value and the user executing
the insert query does not have select privilege on the sequence. This
was my problem and it took me an unnecessarily long time to figure it
out.
First thing I would check is the parsing schema for the application - see Shared Components -> Security Attributes.
If this is not the same between the two instances of your application, that's the likely explanation.
I exported a database and it created a sql file for me with create and insert but I get an error saying ORA-02199: missing DATAFILE/TEMPFILE clause
in sql plus I run the sql script and get a bunch of ORA-00942: table or view does not exist Then i noticed when it creates a table it has TABLESPACE "LOCALDEV" ; So I enter CREATE tablespace LOCALDEV
Prior to all that I enter create user localdev identified by localdev;
and
grant ALTER SESSION, CREATE SESSION, CREATE DATABASE LINK, CREATE MATERIALIZED VIEW, CREATE PROCEDURE, CREATE PUBLIC SYNONYM, CREATE ROLE,CREATE SEQUENCE, CREATE SYNONYM, CREATE TABLE, CREATE TRIGGER, CREATE TYPE, CREATE VIEW, UNLIMITED TABLESPACE to localdev;
SQL> create tablespace localdev datafile '/u01/app/localdev.dbf'
size 100m;
ERROR at line 1:
ORA-01119: error in creating database file '/u01/app/localdev.dbf'
ORA-27040: file create error, unable to create file
Linux-x86_64 Error: 13: Permission denied
Additional information
: 1
I get no error until I run the sql script. If I had a BDA to ask I would but do not. Any advice will be greatly appreciated.
I exported a database and it created a sql file for me with create and
insert but I get an error saying ORA-02199: missing DATAFILE/TEMPFILE
clause (bla bla bla)
In my opinion, the very first step you did was wrong. If you wanted to export the "database" (I presume it is, actually, a "schema" (i.e. "user")), then you should have done that. Oracle offers Data Pump utility, export and import.
If you performed export, you'd take the DMP file with you and import it into another database using import data pump with the REMAP_TABLLESPACE parameter which accepts two values: the old, "source" tablespace and the new, "target" tablespace, separated by colon. For example:
impdp scott/tiger#new_database REMAP_TABLESPACE=localdev:users DIRECTORY=dump_dir DUMPFILE=scott.dmp
Alternatively, as you currently have a textual file that contains CREATE & INSERT statements, why didn't you open it in any text editor and replaced the old tablespace name (localdev) with a tablespace name used in your new database (that would be "users" in my IMPDP example)?
It takes a few seconds, you run it, everything gets created and you don't have to reinvent the wheel by doing everything you did after the first sentence (that would be bla bla part).
My Oracle DB version is 12.1.0.2.0.
I'm having a hard time removing the column identity. Also tried to drop the column and dropping the table with purge command, but every time I'm getting the same Oracle error:
ORA-00600: internal error code, arguments: [12811], [96650], [], [], [], [], [], [], [], [], [], []
Just can't touch the identity column. I tried below commands but no luck:
ALTER TABLE DYS_CATEGORY MODIFY CATEGORY_ID DROP IDENTITY;
ALTER TABLE DYS_CATEGORY DROP COLUMN CATEGORY_ID;
DROP TABLE DYS_CATEGORY PURGE;
I can drop any other column from the table, but the problem is with identity column.
Identity columns are new to Oracle, just introduced in 12c.
This is a problem with Oracle 12.1.0.2.0. At least one other person has reported it (on Windows, which may be relevant).
The error you have is an ORA-00600, which is Oracle's default message for unhandled exceptions i.e. Oracle bugs. The correct answer is to raise a Service Request with Oracle Support; they will be able to provide you with a patch or a workaround if you have a corrupted table you need to fix. If you don't have a Support contract you may be out of luck.
For future reference dropping identity columns is a two-stage process:
alter table t42 modify id drop identity;
alter table t42 drop column id;
As it happens, this is not a problem on the very latest version of the product. In Oracle 18c we can just drop the column without modifying it first. LiveSQL demo.
As William said above it looks like there is/was a system generated the sequence for the identity column that was deleted but the record in idnseq$ remains intact.
I would not recommend this to anyone, but I created a new sequence called junk in the same schema. I then found the object_id for the table and the sequence I created and updated idnseq$ manually changing the seqobj# to the object_id of my new sequence for the object# of the table in question.
I was then able to drop the table and purge the recyclebin successfully.
Really don't recommend hacking oracle system tables, but this was a test system that didn't really matter and it worked.
after lots of search and hard work if the table stil showing error ORA-00600: internal error code, arguments:
Do the below step.
Take a backup of original tables
syntax: Create table original_table_back as select * from original_table;
Rename original table to some new table name
syntax: Rename original_table to original_table_1;
Rename backup to the original table
syntax: Rename Original_table_back to original_table.
How can I stop a SQL statement from running if it's missing a schema qualifier? Most of these issues are caught by a development process, but is there a way to stop the ones that slip through the cracks?
For example, this statement should work:
create table jheller.test_table(a number);
This statement should fail:
create table test_table(a number);
Most of these problems are easily caught during development. Usually a lack of privileges will cause an error like ORA-00942: table or view does not exist. Or if the statement runs successfully on the wrong schema it will cause an obvious error that will be caught during testing.
But inevitably some bad statements still make it into deployments that are promoted to the upper environments. This leads to broken deployments and invalid objects created in schemas like SYS. (We shouldn't be running so many deployments as SYS but that's beyond our control.)
It's not necessary to catch 100% of these issues. But catching 99.9% instead of 99% would make a significant difference.
SQL statements without schema qualifiers can be prevented by:
Creating a fake, empty schema on all databases.
Creating a database trigger to prevent creating objects in that schema.
Setting the session variable CURRENT_SCHEMA to that schema at the beginning of deployment scripts.
Installation - run once per database.
--Create a user. It won't be used so lock it and don't grant it any privileges.
create user schema_qualifier_required identified by "[SOME RANDOM PASSWORD HERE]";
alter user schema_qualifier_required account lock;
--Create trigger to prevent any other user from creating objects on it.
create or replace trigger schema_qualifier_required.no_objects_on_schema_qualifier
before ddl on database
/*
Purpose: SCHEMA_QUALIFIER_REQUIRED exists only to help prevent statements
without schema qualifiers. This trigger ensures no objects can be created in
the schema.
Run this command in a session to help ensure schema qualifiers are used:
alter session set current_schema=schema_qualifier_required;
To drop or modify the schema this trigger must be dropped like this:
alter system set "_system_trig_enabled"=false;
drop trigger schema_qualifier_required.no_objects_on_schema_qualifier
alter system set "_system_trig_enabled"=true;
*/
begin
if ora_dict_obj_owner = 'SCHEMA_QUALIFIER_REQUIRED' then
raise_application_error(-20000, 'You cannot create objects in this schema. '||
'Did you forget to use a schema qualifier in your statement?');
end if;
end;
/
Non-qualified statements initially work.
SQL> create table test1(a number);
Table created.
SQL> select * from test1;
no rows selected
ALTER SESSION to prevent future non-qualified statements from running.
SQL> alter session set current_schema=schema_qualifier_required;
Session altered.
Non-qualified statements no longer work.
SQL> create table test2(a number);
create table test2(a number)
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-20000: You cannot create objects in this schema. Did you forget to use a
schema qualifier in your statement?
ORA-06512: at line 3
SQL> select * from test1;
select * from test1
*
ERROR at line 1:
ORA-00942: table or view does not exist
I have not used this method in production yet. If anyone sees problems with this approach or knows of a better way please edit, comment, or add another answer.
In Unix, connecting to oracle server, I create a temp table on commit preserve rows. I then first truncate the table then I go to drop the table. Trying to drop the table I receive the following error:
ORA-14452: attempt to create, alter or drop an index on temporary table already in use (DBD ERROR: error possibly near <> indicator at char 11 in 'drop table <>temp01')
I cannot end session using Kill through commands because I do not have permission.
Seems to me, the error is pretty clear:
$ oerr ora 14452
14452, 00000, "attempt to create, alter or drop an index on temporary table already in use"
// *Cause: An attempt was made to create, alter or drop an index on temporary
// table which is already in use.
// *Action: All the sessions using the session-specific temporary table have
// to truncate table and all the transactions using transaction
// specific temporary table have to end their transactions.
So, make sure that all sessions are not using the table. If even one other session is using the table, You will get this error, and won't be able to drop it.