Today submitted to the client side a SQL script to go with the new historical data, the result of the client side of the deployment personnel made a mistake, directly take the system account to deploy, the result of the first code did not succeed, the second code is executed successfully, and has been submitted, .... Since there is no prior backup of the second Update table data, resulting in the recovery of the underlying data is very difficult, online search for half a day, will now find the method summarized as follows:
1. Execute the following SQL to restore the data from the Test_temp table to July 7, 2016, which is the point in time before the script is executed.
Note that it is important to delete all data first, otherwise it may result in duplication of data
1 SELECT * from 2as of TIMESTAMP to_timestamp ('2016-07-07 00:00:00'3 'yyyy-mm-dd hh24:mi:ss' );
Delete from Test_tmp;insert to test_tmp select * from test_tmp as of timestamp to_timestamp (' 2014-05-28 11:00:00 ', ' Yyyy-mm-dd Hh24:mi:ss ') commit;
Or get Sync node time, the basic and the first method is consistent.
1 SelectTIMESTAMP_TO_SCN (To_timestamp ('2014-05-27 11:00:00','YYYY-MM-DD HH:MI:SS')) 2 fromdual;3OrSelect * fromSys.smon_scn_timeOrder byTime_dpdesc;4Get results71547785then5 Insert intoTest_tmpSelect * fromTest_tmp as ofTC)71547785
Attention:
The data after truncate is unrecoverable.
TRUNCATE TABLE test_temp;
2. See the third (this method requires a higher administrative authority, or can not query the reply data)
The data found through this statement is limited because some users may have disconnected the Oracle connection
If you see the above method can solve your problem, do not hesitate, do it quickly, because if the hands of late, the previous operation of the data record may be overwritten, because the storage of small words to be recycled
(Many of the above blogs are quoted from http://vvv-110.iteye.com/blog/2072702)
Oracle method for recovering a data table