Shulou(Shulou.com)06/01 Report--

Have nothing to do today, test the process of mistakenly deleting data and using SCN to recover.

I don't like the long introduction to theory, so I start the experiment directly:

First check the current SCN value, if the SCN value is not checked after deletion. You can debug forward according to the current value of scn, as long as you make sure. There is no other action in between after your delete is deleted.

SELECT dbms_flashback.get_system_change_number FROM dual

SELECT CURRENT_SCN FROM V$DATABASE

I know the current SCN number. SCN is growing all the time, and it doesn't matter, then look at some table data:

Select * from zjw.AA

Then delete the table and commit:

Delete from zjw.AA

Let's check this table again: select * from zjw.AA

There's no data. Then look at the data of this table corresponding to the SCN value at that time according to SCN.

Select * from ZJW.AA as of scn 12637719

If you have data, you can, and then use insert to insert it. Insert this data into the current AA table:

Insert into zjw.AA select * from zjw.AA as of scn 12637719

Then look at the table data:

Select * from zjw.AA

Ok

Successful recovery.

Let me explain here. It doesn't matter that the SCN I used in the first two times is not the same as the SCN I used in the last time. This SCN value has been rising again, so as long as it is my SCN value before delete. Any SCN from my operation to delete can be used.

For example, I can insert two random ones according to SCN now. I'll use the SCN that was found first.

Such as:

Select from ZJW.AA as of scn 12637321

Select from ZJW.AA as of scn 12637366

See? the result is the same.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.