Oracle recovers data that has been accidentally deleted or misoperated.
In daily work, it is inevitable that you or others misuse, delete, or modify the data in the database. How do we recover the data at this point?
1. We can use Flashback Query to query past data
The feature of Flashback Query is most often used to repair mishandled data. Note that this does not mean that Flashback Query can recover data. Flashback Query itself will not restore any operation or modification, nor can it tell you what operation or modification has been done. In fact, when the Flashback Query feature is actually applied, it is based on the extension of the standard SELECT. With this feature, users can query the data at a specified time point. The records in the table are equivalent to having the ability to see the past. As for recovery, the results of SELECT are all out. Don't you know how to execute INSERT?
Note:
Flashback Query
querying past data is only valid for delete and other dml statements. If the data is changed through truncate,
Flashback Query cannot be used to query past data
Here is an example:
First, I prepared a table with two pieces of data in it.
At this point we execute the delete statement to delete the data.
Query using flashback query
select * from O_MCHT_KEY_API_BAK as of timestamp to_timestamp('2020-03-13 11:00:57', 'yyyy-mm-dd hh24:mi:ss');
We can see that the time point specified by the flashback query is 2020-03-13 11:00:57, and the data at that time can be queried. At this time, we can re-copy these two data and insert them into the table. This completes the data recovery.
Note: The flashback query is time-sensitive, and the data that is too long ago will be cleared.
If we drop the table, how to restore it?
Here we drop the table first, and we can see that the table no longer exists by using the query
2. We can apply Flashback table to restore the table that was operated by drop
At this time, we cannot query the original data of the table by using flashback query. At this time, we can use flashback table.
flashback table O_MCHT_KEY_API_BAK to before drop;After executing the query again, we can see that the data has been restored successfully.
Of course, flashback tabloe can also be used to restore deleted data.
At this point we first delete a row of data, and then execute
flashback table O_MCHT_KEY_API_BAK to timestamp to_timestamp('2020-03-13 11:00:57', 'yyyy-mm-dd hh24:mi:ss');It can be seen that the recovery error is reported at this time, prompting [72000][8189] ORA-08189: because the row movement function is not enabled, the table cannot be flashed back
Here you only need to enable the row movement function for the corresponding table.
//开启表行移动功能
alter table T_TERM_MCHT_INFO enable row movement;
execute again
flashback table O_MCHT_KEY_API_BAK to timestamp to_timestamp('2020-03-13 11:00:57', 'yyyy-mm-dd hh24:mi:ss');You can see that a deleted record has been restored successfully.
3. We can use Flashback table to restore the table operated by drop (the data is deleted, and the new field table structure is changed!!!)
After deleting the data, we added a column, and then executed flashback quert and flashback table
Both the flashback query and the flashback table can be restored here, but the newly added columns are filled with nulls.
second execution
4. When the data in the table is deleted, and! ! Delete
field - - - -
table structure is changed! ! !
To simulate this situation, first we restore the table to its original state and insert two records.
After 5 minutes, we delete a column in the table, and then restore according to flashback query or flashback table. System error after execution: [72000][1466] ORA-01466: cannot read data - table definition has changed
Because the data flashed back by the system is inconsistent with the current state table.
At this time, if you want to restore the previous data, you can only use the rename method, that is, restore the previous data to another new table according to the previous table structure. The specific operations are as follows:
--将O_MCHT_KEY_API_BAK闪回并将数据转存到另一张表：O_MCHT_KEY_API_BAK_1
flashback table O_MCHT_KEY_API_BAK to before drop rename to O_MCHT_KEY_API_BAK_1;
We can see that the original data has been restored to a new table after we rename.
5. When the data in the table is truncate, it can only be recovered through flashback database
If the table is truncate, then flashback query and flashback table are useless
Restore directly through the flashback database
To use the flashback database, you must first ensure that FLASHBACK is turned on, that is, your statement below should return YES
、
On the premise that FLASHBACK is turned on, use the following command to restore it at this time. If flashback is not turned on, and you have already truncate table, then congratulations, find a DBA, this is an excellent opportunity for you to enhance your relationship with him!
flashback database to timestamp to_timestamp('2020-03-13 14:31:26', 'yyyy-mm-dd hh24:mi:ss');