A test was conducted. SQL> create table test1 (cola varchar2 (10); the table has been created. SQL> create table test2 (colb varchar2 (10); the table has been created. SQL> select * from test1; SQL> select * from test2; SQL> create or replace trigger trigger1
2 before insert on test1
3 for each row
4 declare
5 begin
6 insert into test2 (colb) values ('trigger1 ');
7 end trigger1;
8/The trigger has created SQL> select object_name, object_id from user_objects where object_name in ('trigger1', 'test1'); OBJECT_NAME
--------------------------------------------------------------------------------
OBJECT_ID
----------
TEST1
101621
TRIGGER1
101623
SQL> col object_name for a20
SQL>/OBJECT_NAME OBJECT_ID
------------------------------
TEST1 101621
TRIGGER1 101623 SQL> insert into test1 (cola) values ('no1'); 1 row has been created. SQL> commit; submitted completely. SQL> select * from test1; COLA
--------------------
No1 SQL> select * from test2; COLB
--------------------
Trigger1 -- this is where everything works. Start deletion and recovery. SQL> drop table test1; the table has been deleted. SQL> select object_name, object_id from user_objects
2 where object_name in ('trigger1', 'test1'); row not selected -- if the purge option is not added, both are deleted to the recycle bin, although the user_object view does not, it can be seen in the underlying table obj $.
SQL> flashback table TEST1 to before drop; flash back complete. SQL> select object_name, object_id from user_objects
2 where object_name in ('trigger1', 'test1'); OBJECT_NAME OBJECT_ID
------------------------------
TEST1 101621 -- after the flash is successful, www.bkjia.com can only see TEST1 for normal objects in the view, but cannot see the trigger. SQL> grant select on obj $ to ncoadev; authorization successful. -- Switch to the sys user to authorize access to the specified object. SQL> select name, obj # from sys. obj $ where obj # in (101621,101623); NAME OBJ #
----------------------------------------------------------------------
TEST1 101621
BIN $ mlTKEo1FAGjgQ38AAAEAaA = $0 101623 -- In the obj $ table, we can see that the trigger with ID 101623 is still present, but its name is marked internally by Oracle. In this case, tools such as pl/SQL dev cannot see the trigger. SQL> select * from test2; COLB
--------------------
Trigger1 SQL> insert into test1 (cola) values ('no2 '); 1 row has been created. SQL> commit; submitted completely. SQL> select * from test2; COLB
--------------------
Trigger1
Trigger1 -- another record is inserted to prove that the trigger is still effective, but it is difficult to manage it. More troublesome: SQL> create or replace trigger trigger1
2 before insert on test1
3 for each row
4 declare
5 begin
6 insert into test2 (colb) values ('trigger2 ');
7 end trigger1;
8/The trigger has been created. If the developer does not see the trigger, the trigger is lost and a new trigger trigger1 with the same name is created. SQL> select * from test2; COLB
--------------------
Trigger1
Trigger1 SQL> insert into test1 (cola) values ('no3'); 1 row has been created. SQL> commit; submitted completely. SQL> select * from test2; COLB
--------------------
Trigger1
Trigger1
Trigger2
Trigger1 -- at this time, both triggers have taken effect. What impact does trigger on the system ?? Isn't that a bug?