I have one table backup on which I had applied one trigger upd_trig. Now, I dropped my table and then I checked, whether all the associated trigger/index will also been dropped or will remain there.
As I found some discussion here,and they said Trigger/Index all will be dropped,once we drop our table. But, it seems, trigger still exist. Can anyone explain, what exactly happens, when we drop the table
SQL> drop table backup;
Table dropped.
SQL> select text from user_source;
TEXT
----------------------------------------------------------------------------------------------------
TRIGGER
"BIN$Dg5j/bf6Rq6ugyN5ELwQkw==$0" BEFORE UPDATE ON backup FOR EACH ROW
BEGIN
INSERT INTO BACKUP VALUES(USER,:OLD.ENAME,SYSDATE);
END;
9 rows selected.
SQL> select count(*) from user_triggers;
COUNT(*)
----------
1
SQL> select trigger_name from user_triggers;
TRIGGER_NAME
------------------------------
BIN$Dg5j/bf6Rq6ugyN5ELwQkw==$0
The table has been dropped, but it is in the recycle bin, from which it can be recovered using the flashback commands (flashback ... before drop]. The name showing as BIN$... is a bit of a giveaway. The trigger is also showing with a BIN$... name, indicating that it is in the recycle bin too, and any indexes will be too.
You can empty the recycle bin to permenantly remove the objects in it. To drop a table immediately, without it going to the recycle bin, you can add the keyword purge to the drop command, as explained in the documentation. That will also drop any indexes and triggers immediately.
If it wasn't dropped automatically, then the trigger would be irrelevent anyway, since you couldn't perform any DML on the dropped table, so it could never fire. That's if the table the trigger is against is dropped. Your trigger is weird, it's inserting into the same table. Normally you'd have a trigger on one table insert into your backup table (well, for one use of triggers). In that case, dropping the backup table would invalidate the trigger on the live table, but would not drop it. Only dropping the live table would drop the trigger on the live table.
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 created table t1 in Oracle 12c.
Table has data and it is partitioned on list partition and also has subpartitions.
Now I want to delete whole table and all associated partitions (and subpartitions).
Is this the right command to delete all?
DROP TABLE t1 PURGE;
The syntax is right but not preferable,
just drop without purge so that whenever you need you could have it back, if your flashback option is enabled. If your database's flashback option is in charge, you could issue this command (provided you don't use purge):
SQL> DROP TABLE T1;
SQL> FLASHBACK TABLE T1 TO BEFORE DROP RENAME TO T1_ver_2;
When you run DROP then the table is removed entirely from database, i.e. the table does not exist anymore.
If you just want to remove all data from that table run
truncate table T1 drop storage;
You can also truncate single (sub-)partition if required.
FLASHBACK TABLE to a restore point fails when that restore point was created immediately after a table change. The below code only works if there is a sleep between certain steps.
SQL> DROP TABLE TEST_TABLE;
Table dropped.
SQL> CREATE TABLE TEST_TABLE AS SELECT 1 A FROM DUAL;
Table created.
SQL> ALTER TABLE TEST_TABLE ENABLE ROW MOVEMENT;
Table altered.
SQL> --Sleep required here to prevent error on flashback.
SQL> DROP RESTORE POINT TEST_RESTORE_POINT;
Restore point dropped.
SQL> CREATE RESTORE POINT TEST_RESTORE_POINT;
Restore point created.
SQL> FLASHBACK TABLE TEST_TABLE TO RESTORE POINT TEST_RESTORE_POINT;
FLASHBACK TABLE TEST_TABLE TO RESTORE POINT TEST_RESTORE_POINT
*
ERROR at line 1:
ORA-01466: unable to read data - table definition has changed
Why is a delay required and is there a way to eliminate it?
This oddity might be caused by SMON process which is responsible to keep track between SCNs and timestamps which flashback query relies upon. There is a mapping table SYS.SMON_SCN_TIME where every 5 minutes a new record is inserted SMON.
Internally during the FLASHBACK TABLE executes a command INSERT /*+ APPEND */ into SYS_TEMP_FBT SELECT /*+ FBTSCAN FULL(S) PARALLEL(S, DEFAULT) */ :1, :2, :3, rowid, SYS_FBT_INSDEL FROM "<schema>."TEST_TABLE" as of SCN :4 S (notice a table SYS_TEMP_FBT is created in the same schema) which uses this mapping.
Up to Oracle 10.2 you needed to wait up to whole 5 minutes to succeed with FLASHBACK query on a new/altered object. In 11.1 the TIM_SCN_MAP column was introduced to make the mapping more fine grained. Maximum of 100 mappings is stored in one value which makes roughly 3 seconds precision in timestamp to SCN mapping.
I tried many things but I don't think you can do anything about it but wait around 3 seconds to avoid the error because this is handled asynchronously by background process without any user control.
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.