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.
Related
Forgive me to ask a silly question.
Would a temporary table be dropped automatically in Oracle (12c)?
Yesterday I have executed the following DDL to create a temporary table:
Create global temporary table my_1st_t_table on commit preserve rows as
select
*
from
other_table
where
selected_col = 'T';
After that I have executed following statements:
commit;
select count(*) from my_1st_t_table;
Yesterday, the last select statement returned 2000 rows.
After that I disconnected my VPN and also switched off my client laptop.
Today I rerun the last select statement after restarted my computer and reconnected to the VPN.
It returned 0 rows. So this means the table was still there but just all rows being deleted after my session.
However, may I ask when will my temporary table be dropped?
Thanks in advance!
A temporary table in Oracle is much different than a temp table in other database platforms such as MS SQL Server, and the "temporary" nomenclature invariably leads to confusion.
In Oracle, a temporary table just like other tables, and does not get "dropped". However, the rows in the table only exist within the context of the session that inserted the rows. Once the session is terminated, assuming the session did not delete the rows, Oracle will delete the rows in the table for that session.
So bottom line, the data is temporary, the table structure is permanent, until the table is dropped.
I am new to Oracle and for practice I have created some tables (customer, drivers, payment, booking, location, area, job, job_history) in Oracle 11g and upon select * from cat statement I have found a strange table with other created tables named "BIN$c+eOnMB3RbKSEfg/rsxtAQ==$0".I don't know why this table is created.
I tried to remove this table through
drop table BIN$c+eOnMB3RbKSEfg/rsxtAQ==$0;
but it gives error:
drop table BIN$c+*eOnMB3RbKSEfg/rsxtAQ==$0
ERROR at line 1: ORA-00933: SQL command not properly ended
what should I do to remove it?
What you see is a deleted table in the RECYCLEBIN
You may get the original name of the table with this query
SELECT original_name FROM RECYCLEBIN where OBJECT_NAME = 'BIN$c+eOnMB3RbKSEfg/rsxtAQ==$0';
Note that (with your parameter setting) if you DROP a table it is not completely removed, but moved in the recyclebin.
You may ommit this using the PURGE option.
DROP TABLE xxx PURGE;
To remove the table from the recyclebin you must qoute the name with double quotes (as this is not a valid name) and use the PURGE statement (not a DROP - which would trigger ORA-38301: can not perform DDL/DML over objects in Recycle Bin).
PURGE TABLE "BIN$c+eOnMB3RbKSEfg/rsxtAQ==$0"
Alternatively you may use the original_name obtained with the query above:
PURGE TABLE {your_original_name};
To clean up the recyclebin completely use this statement (with the propper table user)
PURGE RECYCLEBIN;
I was using Navicat for Oracle to backup an entire Schema. I mistakenly selected the Execute SQL File instead of the Backup file option and All previous data has been changed/lost. I tried using the Oracle Undo feature but it says the table definition has changed. Please i am not skilled in oracle, i only used it for a project cause it was required so i just use it to store the data. I need all the help i can get right now to recover the entire schema to how it was 24 hours ago else i am so screwed...(forgive my language)
From your description you ran a script that dropped and recreated your tables. As you have flashback enabled and your dropped table is in the recycle bin, you can use the 'Flashback Drop' feature to get the dropped table back.
Here's an example with a single table:
create table t43 (id number);
drop table t43;
create table t43 (id2 number);
show recyclebin;
ORIGINAL NAME RECYCLEBIN NAME OBJECT TYPE DROP TIME
-------------------------------- ------------------------------ ------------------------- -------------------
T43 BIN$/ILKmnS4b+jgQwEAAH9jKA==$0 TABLE 2014-06-23:15:38:06
If you try to restore the table with the new one still there you get an error:
flashback table t43 to before drop;
SQL Error: ORA-38312: original name is used by an existing object
You can either rename the restored table:
flashback table t43 to before drop rename to t43_restored;
... which is useful if you want to keep your new table but be able to refer to the old one; or probably more usefully in your situation rename the new table before restoring:
alter table t43 rename to t43_new;
table T43 altered.
flashback table t43 to before drop;
table T43 succeeded.
desc t43
Name Null Type
---- ---- ------
ID NUMBER
You can undrop all of your tables, and as referential constraints still work with tables in the bin you don't have to worry too much about restoring parent tables before child tables, though it's probably neater to do that if you can.
Note that the bit in the documentation about retoring dependent objects - that index names won't be preserved and you'll need to rename them after the restore with alter index.
You can't undrop a sequence; those don't go into the recycle bin. If you need to reset a sequence so it doesn't repeat values you already have, you can get the highest value it should hold (from the primary keys on your restored table, say) and use temporarily change the increment value to skip over the used numbers.
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.
I have read that one should not analyze a temp table, as it screws up the table statistics for others. What about an index? If I put an index on the table for the duration of my program, can other programs using the table be affected by that index?
Does an index affect my process, and all other processes using the table?
or Does it affect my process alone?
None of the responses have been authoritative, so I am offering said bribe.
Does an index effect my process, and all other processes using the table? or Does it effect my process alone?
I'm assuming we are talking of GLOBAL TEMPORARY tables.
Think of a temporary table as of multiple tables that are created and dropped by each process on the fly from a template stored in the system dictionary.
In Oracle, DML of a temporary table affects all processes, while data contained in the table will affect only one process that uses them.
Data in a temporary table is visible only inside the session scope. It uses TEMPORARY TABLESPACE to store both data and possible indexes.
DML for a temporary table (i. e. its layout, including column names and indexes) is visible to everybody with sufficient privileges.
This means that existence of the index will affect your process as well as other processes using the table in sense that any process that modifies data in the temporary table will also have to modify the index.
Data contained in the table (and in the index too), on the contrary, will affect only the process that created them, and will not even be visible to other processes.
IF you want one process to use the index and another one not to use it, do the following:
Create two temporary tables with same column layout
Index on one of them
Use indexed or non-indexed table depending on the process
I assume you're referring to true Oracle temporary tables and not just a regular table created temporarily and then dropped. Yes, it is safe to create indexes on the temp tables and they will be used according to the same rules as a regular tables and indexes.
[Edit]
I see you've refined your question, and here's a somewhat refined answer:
From:
Oracle® Database Administrator's Guide
10g Release 2 (10.2)
Part Number B14231-02
"Indexes can be created on temporary tables. They are also temporary and the data in the index has the same session or transaction scope as the data in the underlying table."
If you need the index for efficient processing during the scope of the transaction then I would imagine you'll have to explicitly hint it in the query because the statistics will show no rows for the table.
You're asking about two different things, indexes and statistics.
For indexes, yes, you can create indexes on the temp tables, they will be maintained as per usual.
For statistics, I recommend that you explicitly set the stats of the table to represent the average size of the table when queried. If you just let oracle gather stats by itself, the stats process isn't going to find anything in the tables (since by definition, the data in the table is local to your transaction), so it will return inaccurate results.
e.g. you can do:
exec dbms_stats.set_table_stats(user, 'my_temp_table', numrows=>10, numblks=>4)
Another tip is that if the size of the temporary table varies greatly, and within your transaction, you know how many rows are in the temp table, you can help out the optimizer by giving it that information. I find this helps out a lot if you are joining from the temp table to regular tables.
e.g., if you know the temp table has about 100 rows in it, you can:
SELECT /*+ CARDINALITY(my_temp_table 100) */ * FROM my_temp_table
Well, I tried it out and the index was visible and used by the second session. Creating a new global temporary table for your data would be safer if you really need an index.
You are also unable to create an index while any other session is accessing the table.
Here's the test case I ran:
--first session
create global temporary table index_test (val number(15))
on commit preserve rows;
create unique index idx_val on index_test(val);
--second session
insert into index_test select rownum from all_tables;
select * from index_test where val=1;
You can also use the dynamic sampling hint (10g):
select /*+ DYNAMIC_SAMPLING (3) */ val
from index_test
where val = 1;
See Ask Tom
You cannot create an index on a temporary table while it is used by another session, so answer is: No, it cannot affect any other process, because it is not possible.
An existing Index affects only your current session, because for any other session the temporary table appears empty, so it cannot access any index values.
Session 1:
SQL> create global temporary table index_test (val number(15)) on commit preserve rows;
Table created.
SQL> insert into index_test values (1);
1 row created.
SQL> commit;
Commit complete.
SQL>
Session 2 (while session 1 is still connected):
SQL> create unique index idx_val on index_test(val);
create unique index idx_val on index_test(val)
*
ERROR at line 1:
ORA-14452: attempt to create, alter or drop an index on temporary table already in use
SQL>
Back to session 1:
SQL> delete from index_test;
1 row deleted.
SQL> commit;
Commit complete.
SQL>
Session 2:
SQL> create unique index idx_val on index_test(val);
create unique index idx_val on index_test(val)
*
ERROR at line 1:
ORA-14452: attempt to create, alter or drop an index on temporary table already in use
SQL>
still failing, you first have to disconnect session 1 or table has to be truncated.
Session 1:
SQL> truncate table index_test;
Table truncated.
SQL>
Now you can create the index in Session 2:
SQL> create unique index idx_val on index_test(val);
Index created.
SQL>
This index of course will be used by any session.