oracle flashback operation application only delete delete operation recovery
1. How to recover after delete statement operation
As an IT system maintainer, I often delete the data that should not be deleted due to the careless delete operation. This is often serious in nature, but in order to reduce the minimum loss, here I have compiled a list for you to delete by mistake. recovery operation. Here I take the ocs_project table as an example. First, I checked the data that exists in the entire table. There are five pieces of data. Here I delete the project_id at the beginning of 2010, and delete it with the delete statement. It should be easier for everyone to understand this operation.
delete * from ocs_project where project_id like '2010%'; 
the picture below shows the operation process of deleting the data inside. 
Now there are only three pieces of data left in the ocs_project table, how can we restore the original two pieces of data?
Here first we use the select sysdate from dual; statement to query the date of the current data; and then query the table 
where our system time can be found
We only need to use select * from table_name as of timestamp to_timestamp('2016-10-20 17:20:22','yyyy-MM-dd HH24:mi:ss') to find out the deleted data.
If we want to find out what data was deleted, we can use
select * from ocs_project as of timestamp to_timestamp('2016-10-20 17:18:22','yyyy-MM-dd HH24:mi:ss') minus select * from ocs_project; At 
this point, we can query the previously deleted data, here we use the flashback table ocs_project to timestamp to_timestamp('2016-10-20 17:18:22','yyyy-MM-dd HH24:mi:ss') statement to restore, but we often encounter
ORA-08189: cannot flashback table because row movement is not enabled
This kind of problem is because row movement is not enabled for any table by default, so row movement needs to be enabled, and the startup statement is alter table ocs_project enable row movement;
Then execute the flashback statement again, as shown in the following figure: 
Finally, we can query the deleted business data in the table again!