Ⅰ 資料庫IO邏輯錯誤會直接丟失數據嗎
數據不會丟失，雹喊猛但需要解決硬碟IO錯誤。
具體的步驟如下：1.先下載並解壓軟體打開後，直接雙擊需要恢復的分區，然後右擊軟體圖標選擇《以管理員身份運行》；2.軟體打開後，直接雙擊需要恢復的分區；3.程序掃描到文件後，會放到與要恢復盤同名的目錄中；4.將想要恢復的資料打鉤，右擊選擇《復制勾選的文件》，軟體會將打鉤的文件復制出來；5.最後一步只需要坐等軟體將數據復制完畢就完畢源橋了。
以上幾滲或個步驟完成，資料庫IO錯誤就可以解決。
Ⅱ 資料庫文件丟失的原因有哪些
自然原因 ---- 自然原因主要指由於自然災害造成的數據被破壞，如水災、火災、雷擊、地震等造成計算機系統的破壞，導致存儲數據被破壞或完全丟失，或 由於操作時斷電、意外電磁干擾造成數據丟失或破壞。自然原因造成的數據丟失現象一般表現為硬碟損壞、硬碟無法識別、磁碟讀寫錯誤、找不到所需要的文件、文件打不開、文件打開後亂碼等。
人為原因 ---- 人為原因主要是指由於使用人員的誤操作造成的數據被破壞。如誤格式化或誤分區、誤克隆、誤刪除或覆蓋、環境的潮濕、經常不正常退出、 人為地摔壞或磕碰硬碟等。人為原因造成的數據丟失現象一般表現為操作系統丟失、無法正常啟動系統、磁碟讀寫錯誤、找不到所需要的文件、文件打不開、文件打開後亂碼、硬碟沒有分區、提示某個硬碟分區沒有格式化、硬碟被強制格式化、硬碟無法識別或發出異響等。
硬體原因 ---- 硬體原因主要是指由於計算機設備的硬體故障（包括存儲介質的老化、失效）、磁碟劃傷、磁頭變形、磁臂斷裂、磁頭放大器損壞、晶元組或 其他元器件損壞等造成數據丟失或破壞。硬體原因造成的數據丟失現象一般表現為系統不認硬碟，常有一種"咔嚓咔嚓"或"哐當、哐當"的磁阻撞擊聲，或電機不轉、通電後無任何聲音、磁頭定位不準造成讀寫錯誤等現象。
軟體原因 ---- 軟體原因主要是指由於受病毒感染、零磁軌損壞、硬碟邏輯鎖、系統錯誤或癱瘓造成文件丟失或破壞，對數據的破壞等造成數據丟失或破壞。 軟體原因造成的數據丟失現象一般表現為操作系統丟失、無法正常啟動系統、磁碟讀寫錯誤、找不到所需要的文件、文件打不開、文件打開後 亂碼、硬碟沒有分區、提示某個硬碟分區沒有格式化、硬碟被鎖等。
Ⅲ 築業軟體顯示資料庫邏輯錯誤或丟失是怎麼回事
在恢復的時候，邏輯文件名不可以修改，舉桐你指定的物理文件存放的位置必須存在，你可以使用 restore filelistonly from disk ＝ ss.bak 看看沖並它原來的邏正判坦輯文件名，然後再恢復就沒有問題了。
Ⅳ sqlite SQL logic error or missing database，該怎麼解決
sqlite SQL 邏輯錯誤或資料庫丟失，先檢查資料庫文件是否存在，然後重裝。
Ⅳ paradox資料庫據說容易損壞，那麼是怎麼修復的呢
當數據表邏輯損壞時，如果資料庫引擎報告表索引頭錯誤，通過分析可知多半是表頭中有關塊或記錄的參數不匹配，比如「使用的塊數」大於「總的塊數」，或是記錄數和塊數不匹配。如果只能顯示部分數據，可能是表頭中「總的記錄數」小於實際記錄數，也可能是數據塊鏈表錯亂。
如果只是表頭索引參數出了問題，我們可以通過分析表頭相關信息，用16進制編輯器直接進行參數修改就可解決問題;如果是數據塊鏈表出了問題，一般無法直接修改(比如對有成千上萬條記錄的數據表)。
Ⅵ Oracle資料庫遇到ORA-01578壞塊錯誤的原因是什麼，求解釋
【Oracle數據恢復】ORA-01578錯誤解析
一般認為ORA-1578是 數據塊物理壞塊/損壞的一種，不同於邏輯損壞/壞塊，其錯誤信息如下：
[oracle@oel8 dirdat]$ oerr ora 1578
01578, 00000, "ORACLE data block corrupted (file # %s, block # %s)"
// *Cause: The data block indicated was corrupted, mostly e to software
// errors.
// *Action: Try to restore the segment containing the block indicated. This
// may involve dropping the segment and recreating it. If there
// is a trace file, report the errors in it to your ORACLE
// representative
這個1578一兆跡般 會伴隨ORA-1110出現，一旦ORACLE讀取到存在損壞的塊就會報出:
SQL> select * from scott.emp;
select * from scott.emp
*
ERROR at line 1:
ORA-01578: ORACLE data block corrupted (file # 11, block # 34) 這里的FILE#是 RFN
ORA-01110: data file 6:'/home/oracle/族絕並corrclass.dbf' 這里的是AFN
斷裂的數據塊Fractured Block：
Corrupt block relative dba: 0x0380e573 (file 14, block 58739)
Fractured block found ring buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0380e573
last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04
consistency value in tail: 0x00780601
check value in block header: 0x8739, computed block checksum: 0x2f00
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data
或者錯誤的校驗和checksum
Corrupt block relative dba: 0x0380a58f (file 14, block 42383)
Bad check value found ring buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0380a58f
last change scn: 0x0288.7784c5ee seq: 0x1 flg: 0x06
consistency value in tail: 0xc5ee0601
check value in block header: 0x68a7, computed block checksum: 0x2f00
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0380a58f (file 14, block 42383) found same corrupted data
或者錯誤的塊頭宏陵
Corrupt block relative dba: 0x0d805a89 (file 54, block 23177)
Bad header found ring buffer read
Data in bad block -
type: 6 format: 2 rdba: 0x0d805b08
last change scn: 0x0692.86dc08e3 seq: 0x1 flg: 0x04
consistency value in tail: 0x08e30601
check value in block header: 0x2a6e, computed block checksum: 0x0
spare1: 0x0, spare2: 0x0, spare3: 0x0
***
Reread of rdba: 0x0d805a89 (file 54, block 23177) found valid data
一些可能引起ORA-1578的BUG 列表如下：
如果自己搞不定可以找ASKMACLEAN專業資料庫修復團隊成員幫您恢復!
Ⅶ 資料庫系統中的常見故障有哪些
新增archives 時的狀況：
條件和假設：自上次鏡像備份以來已經生成新的archive log(s); Archivelog Mode; 有同步的datafile(s) 和control file(s) 的鏡像（冷）拷貝；archive log(s) 可用。
恢復步驟：
1. 如果資料庫尚未關閉，則首先把它關閉： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點： 所有Database Files
所有Control Files（沒有archive(s) 或redo(s) 的情況下，control files 的更新無任何意義）
所有On-Line Redo Logs (Not archives) init.ora file（選項）
3. 啟動資料庫： $ svrmgrl
svrmgrl> connect internal
svrmgrl> startup
數據文件, 重作日誌和控制文件同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的所有所失文件的鏡像（冷）拷貝；archive log(s) 可用
恢復步驟（必須採用不完全恢復的手法）：
1. 如果資料庫尚未關閉，則首先把它關閉： $ svrmgrl svrmgrl> connect internal
svrmgrl> shutdown abort
2. 將備份文件抄送回原始地點：
所有Database Files
所有Control Files
所有On-Line Redo Logs(Not archives)
init.ora file（選項）
3. 啟動資料庫然而並不打開：
svrmgrl>startup mount
4. 做不完全資料庫恢復，應用所有從上次鏡像（冷）備份始積累起來的archives：
svrmgrl> recover database until cancel using backup controlfile;
......
......
cancel
5. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
6. 關閉資料庫並做一次全庫冷備份。
數據文件和控制文件同時丟失或損壞：
條件和假設：Archivelog Mode; 有同步的datafile(s) 和control file(s) 的冷拷貝；archive log(s) 可用
恢復步驟：
1. 將冷拷貝的datafiles(s) 和control file(s) 抄送回原始地點:
$ cp /backup/good_one.dbf /orig_loc/bad_one.dbf
$ cp /backup/control1.ctl /disk1/control1.ctl
2. 以mount 選項啟動資料庫：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
3. 以舊的control file 來恢復資料庫：
svrmgrl> recover database until cancel using backup controlfile;
*** 介質恢復完成
（須在應用完最後一個archive log 後cancel ）
4. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
重作日誌和控制文件同時丟失或損壞時：
條件和假設：Control Files 全部丟失或損壞；Archivelog Mode; 有Control Files 的鏡像（冷）拷貝
恢復步驟：
1. 如果資料庫尚未關閉，則首先把它關閉：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> shutdown abort
svrmgrl>exit
2. 以Control File 的鏡像（冷）拷貝覆蓋損壞了的Control File:
$ cp /backup/control1.ctl /disk1/control1.ctl
3. 啟動資料庫然而並不打開：
$ svrmgrl
svrmgrl> connect internal
svrmgrl> startup mount
4. Drop 壞掉的redo log （排除硬體故障）：
svrmgrl> alter database drop logfile group 2;
5. 重新創建redo log:
svrmgrl> alter database add logfile group 2 '/orig_loc/log2.dbf' size 10M;
6. 以舊的control file 來恢復資料庫：
svrmgrl> recover database until cancel using backup controlfile;
（必須馬上cancel ）
7. Reset the logfiles （對啟動而言不可省略）：
svrmgrl> alter database open resetlogs;
8. 關閉資料庫並做一次全庫冷備份
只發生歸檔重作日誌丟失或損壞時：
根據不同環境和情況，選擇下述手段之一：
a. 馬上backup 全部datafiles （如果系統採用一般熱備份或RMAN 熱備份）
b. 馬上正常關閉資料庫並進行冷備份（如果系統採用冷備份）
c. 冒險前進！不做備份而讓資料庫接著跑，直等到下一個備份周期再做備份。這是在賭資料庫在下一個備份周期到來之前不會有需要恢復的錯誤發生。
注意:冒險前進的選擇：如果發生錯誤而需要資料庫恢復，則最多隻能恢復到出問題archive log 之前的操作現場。從另一個角度講，archive log(s) 出現問題時，資料庫若不需要恢復則其本身並沒有任何問題。
Oracle邏輯結構故障的處理方法：
邏輯結構的故障一般指由於人為的誤操作而導致重要數據丟失的情況。在這種情況下資料庫物理結構是完整的也是一致的。對於這種情況採取對原來資料庫的全恢復是不合適的，我們一般採用三種方法來恢復用戶數據。
採用exp/imp工具來恢復用戶數據：
如果丟失的數據存在一個以前用exp命令的備份，則可以才用這種方式。
1. 在資料庫內創建一個臨時用戶：
svrmgrl>create user test_user identified by test;
svrmgrl>grant connect，resource to test_user;
2. 從以前exp命令備份的文件中把丟失數據的表按照用戶方式倒入測試用戶：
$imp system/manager file=export_file_name tables=(lost_data_table_name…) fromuser=lost_data_table_owner touser=test_user constraint=n;
3. 用相應的DML語句將丟失的數據從測試用戶恢復到原用戶。
4. 將測試用戶刪除：
svrmgrl>drop user test_user cascede;
採用logminer來恢復用戶數據：
Logminer是oracle提供的一個日誌分析工具。它可以根據數據字典對在線聯機日誌、歸檔日誌進行分析，從而可以獲得資料庫的各種DML操作的歷史記錄以及各種DML操作的回退信息。根據這些用戶就可以將由於誤操作而丟失的數據重新加入資料庫內。
1. 確認資料庫的utl_file_dir參數已經設置，如果沒有則需要把這個參數加入oracle的初始化參數文件，然後重新啟動資料庫。下面例子中假設utl_file_dir=』/opt/oracle/db01』；
2. 創建logminer所需要的數據字典信息，假設生成的數據字典文本文件為dict.ora：
svrmgrl>execute dbms_logmnr_d.build(dictionary_filename=>'dict.ora'， dictionary_location=>'/opt/oracle/db01』);
3. 確定所需要分析的日誌或者歸檔日誌的范圍。這可以根據用戶誤操作的時間來確定大概的日誌范圍。假設用戶誤操作時可能的日誌文件為/opt/oracle/db02/oradata/ORCL/redo3.log和歸檔日誌』/opt/oracle/arch/orcl/orclarc_1_113.ora』。
4. 創建要分析的日誌文件列表，按日誌文件的先後順序依次加入：
svrmgrl>execute dbms_logmnr.add_logfile(logfilename=>』/opt/oracle/arch/orcl/orclarc_1_113.ora』，options=>dbms_logmnr.NEW);
svrmgrl> execute dbms_logmnr.add_logfile(logfilename=>』 /opt/oracle/db02/oradata/ORCL/redo3.log』，options=>dbms_logmnr.ADDFILE);
5. 開始日誌分析，假設需要分析的時間在』2003-06-28 12:00:00』和』2003-06-28 13:00:00』之間：
svrmgrl>execute dbms_logmnr.start_logmnr(dictfilename=>』 /opt/oracle/db01/dict.ora』，starttime=>to_date(』 2003-06-28 12:00:00』，』YYYY-MM-DD HH:MI:SS』)，endtime=>to_date(to_date(『2003-06-28 13:00:00』，』YYYY-MM-DD HH:MI:SS』));
6. 獲取分析結果：
svrmgrl>select operation，sql_redo，sql_undo from v$logmnr_contents;
7. 根據分析結果修復數據。
8.結束logmnr:
svrmgrl>dbms_logmnr.end_logmnr;
9. 用適當的方法對原資料庫進行資料庫全備份。
利用備份恢復用戶數據：
採用這種方法時並不是在原資料庫進行恢復，而是利用資料庫備份在新的機器上重新建立一個新的資料庫。通過備份恢復在新機器上將資料庫恢復到用戶誤操作前，這樣就可以獲得丟失的數據將其恢復到原資料庫。
1. 在新的機器上安裝資料庫軟體。
2. 對於採用帶庫備份的現場，需要在新的資料庫伺服器上安裝調試相應的備份管軟體。
3. 根據用戶誤操作的時間點進行基於時間點的資料庫恢復操作。對於沒有採用帶庫備份的現場，可以選取用戶誤操作前最近的備份磁帶進行恢復；對於才用帶庫備份的點可以通過基於時間恢復點恢復的rman腳本來進行恢復。
4.重新打開資料庫：
svrmgrl>alter database open resetlogs;
5. 從新的資料庫中獲取丟失的用戶數據，通過DML操作將其恢復到原資料庫中。
6. 用適當的方法對原資料庫進行資料庫全備份。
Ⅷ 哪位朋友能告訴我mysql資料庫中的表頻繁損壞是為什麼
出現表損壞的根本原因是：你的表使用了MyISAM存儲引擎。MyISAM存儲引擎主要用於SELECT,如果用於INSERT, UPDATE, DELETE，由於內部缺陷和異常數據訪問經常造成索引文件損壞，注意是「經常」。
因此解決辦法有二：
1.用myisamchk工具修復或者是經常對數據表優化或檢查。一旦文件損壞只能暫停web訪問，用myisamchk工具修復後可恢復正常。（暫時好睏性，不能解決根本問題）
2.把表轉換為innodb存輪頃儲引擎。對用戶來說是透明的，對程序邏輯不受任何影友桐念響，永久解決索引文件損壞的問題。
可通過以下語句把存儲引擎轉換為innodb
ALTER TABLE `dbname`.`tbname` ENGINE = InnoDB;
Ⅸ oracle在沒有閃回的情況下怎樣找回以刪了的表
多項研究表明，40% 的應用程序故障都是由操作員或用戶的錯誤造成的。人非聖賢，孰能無過？但是，這些錯誤很難避免，而且在沒有事先規劃和使用正確技術的情況下尤其難以恢復。這樣的錯誤會導致「邏輯」數據損壞，或者導致 IT 基礎架構的一個或多個組件停止運行。糾正個別組件的錯誤相對來說簡單，而檢測並糾正邏輯數據的損壞，例如意外刪除了有價值的數據時，所耗費的操作將導致業務產出的巨大損失。典型的用戶錯誤可能包括意外刪除了有價值的數據，錯誤刪除了數據和錯誤刪除了表。避免人為錯誤 Oracle 資料庫體系結構利用了人為錯誤資料庫恢復領域獨有的技術進展。Oracle 閃回技術提供了一組新特性，可及時查看數據並在時間上前後滾動數據。使用閃回特性，可以查詢歷史數據、執行更改分析，以及執行自助修復，以便在資料庫聯機時從邏輯損壞中恢復。利用 Oracle 閃回技術，您完全可以撤銷過去的操作！Oracle9i 引入了閃回查詢，從而提供了可從人為錯誤中恢復的簡單、強大和全面的非破壞性機制。它允許用戶查看過去某個時間點的數據狀態，而無需更改任何資料庫結構。 Oracle 資料庫 10g 擴展了閃回技術，提供了基於資料庫、表、行和事務級別的快速、方便的恢復。閃回技術使恢復過程實現了革命性變化，您只需對更改的數據進行操作。現在，錯誤恢復所需的時間就相當於錯誤發生的時間。Oracle 10g 閃回技術包括閃回資料庫、閃回表、閃回刪除、閃回版本查詢以及閃回事務查詢。 可以輕松地利用閃回技術進行非修復性操作，如使用閃回查詢進行歷史審計、利用閃回資料庫撤銷測試更改。Oracle 資料庫 11g 引進了一個創新的方法，使用閃回數據存檔來管理和查詢長期的歷史數據。該版本還提供了簡單的一步式事務撤銷操作，實現了新的閃回事務功能。 Oracle 資料庫 11g 中的新特性 閃回數據存檔 閃回數據存檔能夠以高度的應用程序透明性、安全性及高效的方式自動跟蹤和維護對所有 Oracle 數據的歷史更改。作為 Oracle Total Recall 選件的組成部分，閃回數據存檔為企業提供了快速、集中和極其高效的解決方案，以滿足管理所有歷史數據的需要。閃回數據存檔自動跟蹤對資料庫中所存儲數據的每個更改，同時維護一個安全、高效和易於訪問的歷史數據存檔。捕獲的歷史數據可以根據業務需要保存任意長的時間，並且可以使用閃回 SQL 查詢方便地進行訪問。在現有表和新建表上均可立即啟用歷史數據跟蹤，更重要的是，以一種完全應用程序透明的方式進行跟蹤。伏輪 閃回數據存檔提供了一唯梁個高性能的、存儲優化的、具有集中管理界面的解決方案，可以滿足組織對數據保留和更改控制的需求。使用閃回數據存檔進行歷史數據跟蹤的主要好處包括： 應用程序透明： 在應用程序沒有更改或更改很小的情況下，可以在一個或多個表缺山信上立即啟用歷史數據捕獲。因此，客戶可以使用該特性捕獲打包應用程序以及自行開發的應用程序的歷史數據。 無縫訪問： 可以使用熟悉的閃回 SQL 結構輕松訪問歷史數據。閃回數據存檔包括對閃回查詢的支持。應用程序可以及時無縫地查詢不同時間點的表歷史數據。無需拍攝特殊快照既可利用該特性。 安全性： 歷史數據一旦生成，任何用戶都不能進行修改。這就實現了即取即用，而無需特殊或額外的設置。對內部歷史表的訪問限制為只讀。不允許用戶（包括管理員）進行 DML 操作。由於通過閃回查詢機制提供了無縫訪問，因此應用程序無需直接查詢內部歷史表。 最小的性能開銷： 常規用戶事務幾乎沒有影響。閃回數據存檔採用輕型機制來標記要存檔的跟蹤表上的 DML 操作。通過稍後介紹的後台進程非同步生成實際歷史記錄並進行存檔。 存儲優化： 在內部對歷史數據進行分區和高度壓縮，以減少佔用的存儲空間。閃回數據存檔採用高效的壓縮模式來壓縮內部歷史表。此外，它還依據范圍分區模式對內部歷史表進行自動分區。閃回數據存檔中的壓縮和分區都是自動管理的，無需特殊管理。 集中管理： 閃回數據存檔提供了一個基於策略的集中管理界面，實現了大量正在進行中的管理任務自動化。使用閃回數據存檔，可以方便地對表進行分組並設置常規保留策略。新表將從所在的閃回數據存檔中自動繼承保留參數。Oracle 將根據指定的保留策略自動清除所有跟蹤表中過期的歷史數據。這就可以將管理員從重復的歷史數據管理中解放出來，避免了與人工維護有關的成本高昂的錯誤（如，錯誤清除了歷史數據）。 閃回事務 大型資料庫應用程序依賴復雜的事務序列，以確保一組插入、更新或刪除的原子性和一致性。如果出現一個「問題」事務，管理員必須向前追溯，了解哪些更改受該事務的影響並確定任何依賴關系（例如，「問題」事務之後修改了相同數據的事務），從而確保撤銷該事務，保留原始的、好的數據狀態和任何相關數據。執行這種事務分析可能很費力，尤其對非常復雜的應用程序。通過閃回事務，使用一個 PL/SQL 操作即可實現單個事務（還可以包含它依賴的所有事務）的閃回，或者使用直觀的 EM 向導來識別並閃回有問題的事務。閃回事務依賴於給定事務及其相關事務的撤銷數據和存檔重做日誌的可用性，以便撤銷更改。Oracle 資料庫 10g 第 2 版中的新特性恢復點 當需要進行 Oracle 資料庫時間點恢復操作時，DBA 必須確定數據必須回滾到的時間或 SCN。Oracle 資料庫 10g 第 2 版用恢復點簡化了時間點恢復。恢復點是用戶定義的一個名稱，與閃回資料庫、閃回表和恢復管理器 (RMAN) 結合使用時可以代替 SCN 或時鍾時間，可以通過企業管理器或者用 SQL*Plus 或 RMAN 以命令行方式創建。使用恢復點，無需調查事務的 SCN 或時間，使用戶能夠收藏資料庫事務事件。有保證的恢復點確保了始終維護足夠的閃回日誌，以便返回到恢復點。這意味著快速恢復區將不刪除閃回日誌，除非當前的保證恢復點不再需要這些日誌。可在進行主要資料庫更改（如資料庫批處理作業或模式升級）之前創建這些特殊恢復點，從而可在需要撤銷更改時使用這些恢復點進行閃回。通過RESETLOGS 閃回資料庫 通過RESETLOGS 閃回資料庫使 RESETLOGS 操作之前創建的閃回日誌可用於閃回資料庫操作。在 Oracle 資料庫 10g 第 2 版中，使用 RESETLOGS 打開資料庫後即保留閃回日誌。如果直到執行了 RESETLOGS 之後才發現長期存在的邏輯錯誤，這種情況下該特性非常有用，需要在 RESETLOGS 之前進行閃回。在 Oracle Data Guard 環境中，該功能允許物理備用資料庫以讀寫方式打開，以便稍後閃回更改並將更改轉換回物理備用資料庫。如果切換操作後發現邏輯錯誤，可以將主資料庫和備用資料庫閃回到切換操作前的 SCN 或時間點。Oracle 資料庫 10g 第 1 版中的新特性閃回資料庫 閃回資料庫可快速地將 Oracle 資料庫倒回至以前的某個時間，以便糾正由邏輯數據損壞或用戶錯誤造成的任何問題。閃回資料庫就像資料庫的「倒退按鈕」。它提供資料庫的時間點恢復，而無需先恢復資料庫備份。當您希望消除從磁帶恢復資料庫備份所花的時間時，資料庫時間點恢復是一種快速方法。 閃回資料庫功能（可使用 FLASHBACK DATABASE 命令從 RMAN 和 SQL*Plus 啟用）與傳統的時間點恢復的效果類似。它允許您將資料庫返回到其近期的狀態。若要啟用閃回資料庫功能，用 DBA 配置閃回恢復區。快速恢復區是 Oracle 資料庫 10g 的一個新特性，它為 Oracle 資料庫中所有與恢復相關的文件和操作提供了統一的存儲位置。除了閃回資料庫日誌外，恢復區還包含存檔重做日誌和 RMAN 備份。有關快速恢復區的詳細信息，請參考 Oracle 備份和恢復文檔。 Oracle 在快速恢復區內自動創建和管理閃回日誌。因為快速恢復區配置了空間定額，閃回日誌要受制於這些磁碟空間限制。閃回日誌的大小區別很大，這取決於在給定的閃回日誌間隔期間資料庫更改的讀/寫速度。舊程序塊版本的副本被寫入到閃回日誌中。如果一天之內更新了 10% 的資料庫程序塊，則 24 小時閃回日誌的大小約為您資料庫大小的十分之一。如果將資料庫恢復到過去較早時期可能要求更多的磁碟空間，則 DBA 可能會動態地更改此磁碟定額。 閃回為 Data Guard 提供了易於使用的方法來糾正用戶錯誤。閃回資料庫既可用在主資料庫上又可用在備份資料庫上，可快速地將資料庫恢復到較早的時間點，從而避免用戶錯誤。同時，如果管理員決定故障切換到備用資料庫，但那些用戶錯誤已被應用於備用資料庫（例如，由於啟用了實時應用特性），則管理員只需將備用資料庫閃回到某個安全的時間點。啟用閃回資料庫的性能開銷不到 2%。您可能不希望犧牲任何生產資料庫的性能開銷，而是實現一種平衡。如果能在數分鍾而不是數小時內恢復資料庫，則可避免公司上百萬美元的收益損失，您願意將 2% 的資源用於閃回資料庫嗎？啟用閃回資料庫功能有以下幾方面好處： 免去了恢復備份的時間。當資料庫因遇到災難性故障而關閉時，公司因無法做生意而導致大量收入損失。 消除了備用資料庫重做應用延遲。 閃回資料庫與 Data Guard 無縫集成。備用資料庫現在可以輕鬆快速閃回到過去的任意時間點，這樣在應用重做過程中就不需要延遲。 意外錯誤糾正。 閃回資料庫提供了 Oracle 資料庫的連續快照。資料庫可以回退到 SCN 或時間戳。 閃回表 當發生人為錯誤或應用程序錯誤時，您可能想將一個或多個表狀態恢復至故障發生以前的時間點。使用閃回表，DBA 能夠將一個或一組錶快速輕松地聯機恢復到指定時間點。閃回表可在恢復表的同時自動保留其相關屬性（如當前索引、觸發器和限制），而無需 DBA 查找和恢復應用程序特有的屬性。閃回表緩解了執行更為復雜的時間點恢復操作的需求。以下命令將 ORDERS 和 ORDER_ITEMS 表閃回到 7 月 7 日下午 2:33。 FLASHBACK TABLE orders, order_items TO TIMESTAMP (JUL-07-2003, 02:33:00);和閃回查詢一樣，閃回表也依靠撤銷數據來恢復表。因此撤銷數據必須可用，這樣閃回表才能成功。自動撤銷管理特性允許您使用 UNDO_RETENTION 初始化參數指定保留撤銷數據的時間。通過使用此參數並適當地規定撤銷表空間大小，DBA 能夠控制使用閃回表的情況下可修復表的回退時間長短。 DBA 可以使用閃回表特性快速地從人為錯誤中恢復，它還可以用作自助式修復工具以便從意外修改或刪除中恢復。應用程序開發人員可以將閃回表功能合並到他們定製的應用程序中。憑借基於時間點對象的恢復可用性、快速恢復和易用性，該工具相比於介質恢復提供更多的好處。閃回表聯機執行恢復操作 將指定表中的所有數據恢復到時間戳或 SCN 描述的先前的時間點。 自動恢復所有的表屬性（如索引、觸發器以及應用程序所必需的內容），這些應用程序利用閃回的表才能發揮作用。 在分布式環境中維護任何遠程狀態。例如，所有應用程序要求的表修改都被閃回。 按照約束規定保持數據完整性。Oracle 保留了所有從屬對象和參考的完整性。 即使在閃回操作以後，仍然能夠將其恢復到最初狀態。 閃回刪除 回收站是一個虛擬容器，所有被刪除的對象都駐留在這里。在回收站中，這些對象占據與創建它們時所佔據的相同空間。如果在 USERS 表空間中創建表 EMP，那麼刪除的表 EMP 保留在 USERS 表空間中。並不移動刪除的表和任一相關對象（如索引、約束、嵌套表和其他相關對象），僅對它們進行重命名，使其前綴為 BIN$$。可以繼續訪問刪除表中的數據，甚至可以依據刪除表使用閃回查詢。在刪除回收站對象前，每個用戶對回收站對象都擁有相同的權利和許可權。可以通過查詢新回收站視圖來查看刪除表。回收站中的對象將保留在資料庫中，直到刪除對象的所有者決定使用新清除命令永久性刪除這些對象。按用戶的定額對回收站中的對象計數。但閃回刪除是一種非破壞性特性。如果發生下面的情況，將通過空間恢復過程自動清除回收站中的對象用戶創建新表或添加導致其超出定額的數據。 表空間需要擴展其文件大小，以適應創建/插入操作。 錯誤刪除了表？沒問題。使用閃回刪除快速撤銷刪除。 閃回查詢 閃回查詢是隨 Oracle9i 一起引入的，它提供了查看存在於以前的數據的能力。默認情況下，資料庫上的操作使用最近提交的可用數據。如果希望查詢過去某個時間的資料庫，那麼，可以使用閃回查詢特性進行此項操作。此特性可以指定時間或系統更改編號 (SCN)，並使用提交的數據從對應時間中進行查詢。當使用自動撤銷管理時，閃回查詢機制最有效。 Oracle 資料庫將撤銷操作當作第一等級的資料庫對象。撤銷操作具有持久性，可使資料庫系統繼續有效，也可導致資料庫系統崩潰或關閉。為獲取更佳性能，它還與其他資料庫對象分享資料庫緩沖存儲器。Oracle 資料庫使用超出事務處理提交范圍的撤銷操作，提供長期運行查詢的讀取一致性，並從邏輯損壞中恢復。 Oracle 資料庫提供了直接指定為保留而進行的撤銷數量的方法。此系統自動回收過期的撤銷操作，以便為新事務生成撤銷提供空間。撤銷保留值的選擇取決於長期運行查詢的長度以及邏輯損壞的恢復需求。然而，用戶可以不選擇指定的撤銷保留，以及允許系統為指定的撤銷空間提供最佳保留。此最佳保留考慮到長期運行查詢以及從邏輯損壞中恢復的最佳可能范圍。並不保證默認的撤銷保留。如果用盡用於現行事務的過期撤銷，那麼，系統可以使用最早的未過期撤銷操作。 如果UNDO_RETENTION 設置為大於 5 天，那麼，Oraclee 資料庫 10g 第 1 版中的一項新功能是可以查詢過去 5 天以前的數據。只要為撤銷表空間數據文件分配足夠的磁碟空間，那麼，Oracle 將維護一段時間內的撤消操作。下面描述了確保資料庫可以使用依賴於撤銷操作的閃回查詢和其他閃回特性所需要的步驟：確保資料庫使用一個撤銷表空間。將 UNDO_MANAGEMENT 初始化參數設置為自動指定。 將UNDO_RETENTION 初始化參數設置為一個可以使撤銷操作保留足夠時間的值，從而可以及時成功返回您的最長查詢或者從人為錯誤中恢復。 為了保證未過期的撤銷不被覆蓋，設置撤銷表空間的 RETENTION GUARANTEE 子句。 閃回查詢的一個獨有特性是可以查看過去的數據，然後正確選擇如何處理此信息。您可以進行分析，然後撤銷更改，或者捕獲更改的數據以供將來處理。閃回查詢機制非常靈活，可以用於很多場合。可用於：查詢過去存在的數據。 將當前數據與過去的數據進行比較。可以比較單獨行或進行更復雜的比較，如查找交集或合並。 恢復已刪除或更改的數據。 閃回版本查詢 閃回版本查詢提供了審計錶行以及檢索有關更改行事務信息的方法。它檢索所有提交的行版本，這些行位於或曾經位於發出查詢的時間和過去某一時間點之間。它利用自動撤銷管理完成此項操作。 閃回版本查詢是 SQL 的擴展，可用於檢索指定表中不同行的版本，此表存在於特定時間段內。對於任一指定的表，每次執行 COMMIT 語句時，都會創建一個新行版本。閃回版本查詢返回存在於指定時間段內的每個行版本的行。使用 SELECT 語句的 VERSIONS BETWEEN 子句調用閃回版本查詢功能。 閃回版本查詢提供了新的附加列，這些列提供了有關行數據事務的詳細信息，此行數據允許 DBA 查明 Oracle 資料庫中數據更改的時間和方式。 VERSIONS_XID — 創建此行版本的事務 id VERSIONS_OPERATION — 創建此行版本的操作（如刪除、插入和更新） VERSIONS_STARTSCN — 此行版本首次中出現時的 SCN VERSIONS_ENDSCN — 此行版本首次進行更改時的 SCN。 閃回版本查詢是 DBA 運行分析和回答「這是怎麼發生的？」問題的強大工具。DBA 不僅可以運行手動分析，而且閃回版本查詢還是應用程序開發人員的強大工具。可以構建用於審計目的的自定義應用程序。並不是每個人都能夠真正解釋他/她的操作。 閃回事務查詢 您可能會發現表中的數據不知何故被不正確地更改了。為了研究該更改，可使用多個閃回查詢及時查看指定點的行數據。更高效的方法是，使用閃回版本查詢特性查看一定時間內對行進行的所有更改以及相關的事務 id。該特性允許將 VERSIONS BETWEEM 子句附加至 SELECT 語句，後者指定 SCN 或希望查看其間行值發生變化的時間戳范圍。 一旦確定錯誤事務，就可使用閃回事務查詢特性識別該事務進行的其他更改，並請求撤銷 SQL 來沖銷這些更改。您可以通過 FLASHBACK_TRANSACTION_QUERY 視圖獲得事務歷史記錄和撤消 SQL。 如果需要將錯誤事務的結果倒退回去，可以手動執行撤銷 SQL 語句，從而可以輕松地從用戶或應用程序錯誤中恢復。閃回事務查詢可以提高對資料庫中問題的聯機診斷能力，並利於執行事務分析和審計。總結 人為錯誤是導致系統故障的主要原因之一。這些錯誤很難避免，而且在沒有事先規劃和使用正確技術的情況下尤其難以恢復。「正確」技術是：Oracle 資料庫 11g。為什麼犯錯誤只需幾秒，而恢復卻要花費數小時或數天？不應如此並且現在也不會如此。閃回通過只在更改數據上運行引發了恢復變革。一條命令即可修復人為錯誤導致的損壞。閃回技術在去除了恢復的復雜性的同時，縮短了從難以預測的人為錯誤恢復的時間。