㈠ oracle針對truncate截斷表之後要如何恢復數據急啊！
你可以試試PRM for Oracle。
ParnassusData Recovery Manager(以下簡旦薯稱PRM)是企業級ORACLE數據災難恢復軟體，可直接從Oracle9i,10g,11g,12c的資料庫數據文件(datafile)中抽取還原數據表上的數據，而不昌遲族需要通過ORACLE資料庫實例上執行sql來拯救數據。ParnassusDataRecovery Manager是一款基於JAVA開發的綠色軟體，無需安裝，下載解壓後便可直接使用。
恢復場景1 誤Truncate表的常規恢復
D公司的業務維護人員由於誤將產品資料庫當做測試環境庫導致錯誤地耐弊TRUNCATE了一張表上的所有數據，DBA嘗試恢復但是發覺最近的備份不可用，導致無法從備份中恢復出該數據表上的記錄。 此時DBA決定採用PRM來恢復已經被TRUNCATE掉的數據。
由於該環境中 所有資料庫文件均是可用且健康的，用戶僅需要 字典模式下載入SYSTEM表空間的數據文件以及被TRUNCATED表的數據文件即可，例如：
create table ParnassusData.torderdetail_his1 tablespace users as
select * from parnassusdata.torderdetail_his;
SQL> desc ParnassusData.TORDERDETAIL_HIS
Name Null? Type
----------------------- -------- --------------
SEQ_ID NOT NULL NUMBER(10)
SI_STATUS NUMBER(38)
D_CREATEDATE CHAR(20)
D_UPDATEDATE CHAR(20)
B_ISDELETE CHAR(1)
N_SHOPID NUMBER(10)
N_ORDERID NUMBER(10)
C_ORDERCODE CHAR(20)
N_MEMBERID NUMBER(10)
N_SKUID NUMBER(10)
C_PROMOTION NVARCHAR2(5)
N_AMOUNT NUMBER(7,2)
N_UNITPRICE NUMBER(7,2)
N_UNITSELLINGPRICE NUMBER(7,2)
N_QTY NUMBER(7,2)
N_QTYFREE NUMBER(7,2)
N_POINTSGET NUMBER(7,2)
N_OPERATOR NUMBER(10)
C_TIMESTAMP VARCHAR2(20)
H_SEQID NUMBER(10)
N_RETQTY NUMBER(7,2)
N_QTYPOS NUMBER(7,2)
select count(*) from ParnassusData.TORDERDETAIL_HIS;
COUNT(*)
----------
984359
select bytes/1024/1024 from dba_segments where segment_name='TORDERDETAIL_HIS' and owner='PARNASSUSDATA';
BYTES/1024/1024
---------------
189.71875
SQL> truncate table ParnassusData.TORDERDETAIL_HIS;
Table truncated.
SQL> select count(*) from ParnassusData.TORDERDETAIL_HIS;
COUNT(*)
----------
0
啟動PRM ，並選擇 Tools => Recovery Wizard
點擊Next
在此TRUNCATE場景中並未採用ASM存儲，所以僅需要選擇 《Dictionary Mode》字典模式即可：
㈡ sql truncate talbe 刪除數據 還能恢復嗎
如果沒纖族有毀如弊再操作表橡顫是可以的。
alter
table
AGENT_SERV_MSG
enable
row
movement
--truncate
閃回
flashback
table
AGENT_SERV_MSG
to
timestamp
to_timestamp('2010-05-13
17:00:00','yyyy-mm-dd
hh24:mi:ss')
--drop
閃回
flashback
table
AGENT_SERV_MSG
to
before
drop
㈢ 怎麼恢復昨天被Truncate過的表的數據
不小心Truncate表的事情也是有的, 其中大部份時因為工具連錯了庫, 從兒跑錯了角本. 遇到這種事情而沒有備份時怎麼辦呢? 首先要停止資料庫, 將這個表所在的表空間的文件拷貝出來, 因為Oracle在Truncate只時將相應Segment的第一個塊格式化掉了, 而後面的都還存在, 到下次用時到才真正地重新格式化. 下面來講一個Truncate表後進行恢復的例子: SQL> CREATE TABLE T_TRUNCATE AS SELECT * FROM TAB;
Table created.
SQL> SELECT COUNT(*) FROM T_TRUNCATE;
COUNT(*)
----------
14
SQL> ALTER SYSTEM CHECKPOINT;
System altered.
SQL> TRUNCATE TABLE T_TRUNCATE;
Table truncated.
SQL> ALTER SYSTEM CHECKPOINT;
System altered.
在Truncate時只是Segment Header格式化了, 並將Data Object ID換成一個新的值, 我們可以在AUL中用DESC命令來查看:
AUL> desc anysql.t_truncate
Storage(OBJ#=9976 OBJD=9977 TS=4 FILE=4 BLOCK=5235 CLUSTER=0)
No. SEQ INT Column Name Type
--- --- --- ----------------------------- ----------------
1 1 1 TNAME VARCHAR2(30) NOT NULL
2 2 2 TABTYPE VARCHAR2(7)
3 3 3 CLUSTERID NUMBER
要恢復這個表的數據, 首先要在AUL中運行SCAN EXTENT命令, 因為Segment Header被格式化了, 所以Extent Map也可能丟失, 而Scan Extent則將掃描整個數據文件並將Extent分配信息寫入AULEXT.TXT文件:
AUL> SCAN EXTENT FILE 4
2006-12-18 21:32:10
2006-12-18 21:32:24
恢復的關鍵是要獲得這個表原來的Data Object ID, 在這個例子中我在Truncate表後什麼也沒有做就關閉資料庫進行恢復了. 從上面的DESC命令可以看出表的Segment Header是(4,5235), 而新的Data Object ID是9977, 老的Data Object ID我們可以從Segment Header的後面一個數據塊中得到, 如果這個表有幾個Free List Group, 則可能還要再後面幾個塊. 用AUL的ORADUMP命令來看一下後面一個塊:
AUL> ORADUMP FILE 4 BLOCK 5236
RDBA=0x01001474(4/5236)=16782452,type=0x06,fmt=0xa2,seq=0x02,flag=0x04
seg/obj=0x000026f8=9976,csc=0x0000.0006caf5,itc=3,typ=1 - DATA
FLG=0x32, fls=0, nxt=0x01001471(4/5233)=16782449
......
可以看到原來的Data Object ID是9976, 現在可以恢復了, 先不指定原來的Data Object ID試試?
AUL> unload table anysql.t_truncate;
2006-12-18 21:33:37
Unload OBJD=9977 FILE=4 BLOCK=5235 CLUSTER=0 ...
2006-12-18 21:33:37
接下來指定原來的Data Object ID, 再試試?
AUL> unload table anysql.t_truncate object 9976;
2006-12-18 21:33:45
Unload OBJD=9976 FILE=4 BLOCK=5235 CLUSTER=0 ...
P_MV_FACT_SALES|TABLE
TIME_DIM|TABLE
FACT_SALES|TABLE
MV_FACT_SALES|TABLE
SEG$|TABLE
NUMTEST|TABLE
T_OBJECTS|TABLE
T_LOBTEST|TABLE
T_INCLOB|TABLE
CF_XXK|TABLE
T_TESTDMP|TABLE
T_CLOBDEMO|TABLE
T_BLOBDEMO|TABLE
T_TRUNCATE|TABLE
2006-12-18 21:33:45
可以看到14條數據全回來了, 當然資料庫是復雜的, 如果是一個很大的表, 還是不能保證可以100%恢復的.
最近至少看到二次錯誤地截斷(Truncate)表的例子, 並在網上詢問如何恢復, 在這兒我給出AUL/MyDUL的解決方案, 下面是我用的一個測試表:
ASQL> DESC TRUNCDEMO
NO# NAME NULLABLE TYPE
--- ----------------- -------- ------------
1 COL1 VARCHAR2(20)
ASQL> SELECT * FROM TRUNCDEMO;
COL1
-----
ROW 1
ROW 2
2 rows returned.
接下來我們來截斷表, 其實這個操作只是重新格式化了段頭塊(Segment Header), 並分配一個新的數據對象號(Data Object ID), 當然空間分配信息也改了, 除非加了重用空間選項(Reuse Storage). 來看一下這個操作的前後變化:
ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS;
DATA_OBJECT_ID OBJECT_NAME
-------------- -----------
13676 TRUNCDEMO
1 rows returned.
ASQL> truncate table truncdemo;
Truncate Table Succeed.
ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS;
DATA_OBJECT_ID OBJECT_NAME
-------------- -----------
13677 TRUNCDEMO
1 rows returned.
由於在System表空間中已經記錄了新的信息, 因此用當前的System信息是不能恢復過來的,在AUL/MyDUL中可以當作沒有System時的情況來處理,在下面的命令中, 我們用Truncate後的數據對象號就不能進行恢復, 而使用Truncate以前的就可以, 當然空間不能被重新利用了是恢復的前提.
AUL> unload object 13676 column varchar file 4;
2006-09-18 22:38:58
ROW 1
ROW 2
2006-09-18 22:39:04
AUL> unload object 13677 column varchar file 4;
2006-09-18 22:39:10
2006-09-18 22:39:10
AUL>
因此在意外發生Truncate後, 如果沒有備份可以恢復, 首先要做的事是備份一下當前的文件, 免得空間被重用. 而Truncate之前的數據對象號在AUL/MyDUL中是很容易找出來的. 到此已經說明了如何恢復Truncate表了.
㈣ 在Sql里我不小心用Trunk語句把表刪掉了，想問一下有辦法恢復么
這個數據沒有辦法恢復，因為Truncate刪除數據時是不保留日誌的。只能用你最後一次的備份看一看能不能還原出來一點。
㈤ sql server TRUNCATE TABLE 的數據能恢復嗎
分析問題：如果沒有再操作表是可以的。就是上一次操作是清空了數據，那就是可以恢復的
解決方法：
具體操作如下：
alter table TRUNCATE TABLE enable row movement
--truncate 閃回
flashback table TRUNCATE TABLE to timestamp to_timestamp('2010-05-13 17:00:00','yyyy-mm-dd hh24:mi:ss')
--drop 閃回
flashback table TRUNCATE TABLE to before drop
㈥ sql server 2005使用truncate刪除表中內容如何恢復
sqlservertruncate表只要mdf中沒有覆蓋，是可以恢復的，具體可以把mdf文件發給我們，我們對其進行分析恢復評估網頁鏈接
㈦ 誤執行了 TRUNCATE TABLE 數據還能恢復嗎
看你資料庫設置，如果選擇了歸檔模式的話，應該吵畢是可以從歸檔日誌中恢復部分數據的，但是只能恢復到歸納碰滑檔的時候的樣洞臘子，而不是執行TRUNCATE語句前的樣子。
㈧ SQL三種恢復模式有什麼區別
一、定義不同答州仔
Simple簡單恢復模式，Simple模式的舊稱叫」Checkpoint with truncate log「。Full完整恢復模式，和Simple模式相反，Full模式的舊稱叫」Checkpoint without truncate log「。Bulk-logged 大容量日誌恢復。
二、功能不同
完整sql server恢復模式：
資料庫引擎把清汪所有操作都記錄到事務日誌上，並且資料庫引擎絕對不會截斷日誌，完整恢復模式能使資料庫恢復到故障時間點。
簡單sql server恢復模式：
資料庫引擎最低限度地記錄大多數操作，並在每個檢查點之後截斷事務日誌。它不能備份或還原事務日誌，也不能還原單獨的數據頁。
大容量日誌模式：
資料庫引擎對大容量操作(select into和bulk insert)進行最小記錄。如果一個日誌備份包含任何大容量操作，就可以使資料庫恢復到日誌備份的結尾，但不能恢復到某個時間點，它僅用於大容量操作期間。
三、好處不同
在Simple模式下，SQL Server會在每次checkpoint或backup之後自動截斷log，也就是丟棄所有的inactive log records，僅保留用於實例啟動時自跡磨動發生的instance recovery所需的少量log，這樣做的好處是log文件非常小，不需要DBA去維護。
Full模式SQL Server不主動截斷log，只有備份log之後，才可以截斷log，否則log文件會一直增大，直到撐爆硬碟，因此需要部署一個job定時備份log。Full的好處是可以做point-in-time恢復，最大限度的保證數據不丟失，一般用於critical的業務環境里。
Bulk-logged是針對以下Bulk操作，會產生盡量少的log：
1、Bulk load operations (bcp and BULK INSERT).
2、SELECT INTO.
3、Create/drop/rebuild index 通常bulk操作會產生大量的log，對SQL Server的性能有較大影響，bulk-logged模式的作用就在於降低這種性能影響，並防止log文件過分增長。
㈨ truncate table 如何恢復
不小心Truncate表的事情也是有的, 其中大部份時因為工具連錯了庫, 從兒跑錯了角本. 遇到這種事情而沒有備份時怎麼辦呢? 首先要停止資料庫, 將這個表所在的表空間的文件拷貝出來, 因為Oracle在Truncate只時將相應Segment的第一個塊格式化掉了, 而後面的都還存在, 到下次用時到才真正地重新格式化. 下面來講一個Truncate表後進行恢復的例子: SQL> CREATE TABLE T_TRUNCATE AS SELECT * FROM TAB;
Table created.
SQL> SELECT COUNT(*) FROM T_TRUNCATE;
COUNT(*)
----------
14
SQL> ALTER SYSTEM CHECKPOINT;
System altered.
SQL> TRUNCATE TABLE T_TRUNCATE;
Table truncated.
SQL> ALTER SYSTEM CHECKPOINT;
System altered.
在Truncate時只是Segment Header格式化了, 並將Data Object ID換成一個新的值, 我們可以在AUL中用DESC命令來查看:
AUL> desc anysql.t_truncate
Storage(OBJ#=9976 OBJD=9977 TS=4 FILE=4 BLOCK=5235 CLUSTER=0)
No. SEQ INT Column Name Type
--- --- --- ----------------------------- ----------------
1 1 1 TNAME VARCHAR2(30) NOT NULL
2 2 2 TABTYPE VARCHAR2(7)
3 3 3 CLUSTERID NUMBER
要恢復這個表的數據, 首先要在AUL中運行SCAN EXTENT命令, 因為Segment Header被格式化了, 所以Extent Map也可能丟失, 而Scan Extent則將掃描整個數據文件並將Extent分配信息寫入AULEXT.TXT文件:
AUL> SCAN EXTENT FILE 4
2006-12-18 21:32:10
2006-12-18 21:32:24
恢復的關鍵是要獲得這個表原來的Data Object ID, 在這個例子中我在Truncate表後什麼也沒有做就關閉資料庫進行恢復了. 從上面的DESC命令可以看出表的Segment Header是(4,5235), 而新的Data Object ID是9977, 老的Data Object ID我們可以從Segment Header的後面一個數據塊中得到, 如果這個表有幾個Free List Group, 則可能還要再後面幾個塊. 用AUL的ORADUMP命令來看一下後面一個塊:
AUL> ORADUMP FILE 4 BLOCK 5236
RDBA=0x01001474(4/5236)=16782452,type=0x06,fmt=0xa2,seq=0x02,flag=0x04
seg/obj=0x000026f8=9976,csc=0x0000.0006caf5,itc=3,typ=1 - DATA
FLG=0x32, fls=0, nxt=0x01001471(4/5233)=16782449
......
可以看到原來的Data Object ID是9976, 現在可以恢復了, 先不指定原來的Data Object ID試試?
AUL> unload table anysql.t_truncate;
2006-12-18 21:33:37
Unload OBJD=9977 FILE=4 BLOCK=5235 CLUSTER=0 ...
2006-12-18 21:33:37
接下來指定原來的Data Object ID, 再試試?
AUL> unload table anysql.t_truncate object 9976;
2006-12-18 21:33:45
Unload OBJD=9976 FILE=4 BLOCK=5235 CLUSTER=0 ...
P_MV_FACT_SALES|TABLE
TIME_DIM|TABLE
FACT_SALES|TABLE
MV_FACT_SALES|TABLE
SEG$|TABLE
NUMTEST|TABLE
T_OBJECTS|TABLE
T_LOBTEST|TABLE
T_INCLOB|TABLE
CF_XXK|TABLE
T_TESTDMP|TABLE
T_CLOBDEMO|TABLE
T_BLOBDEMO|TABLE
T_TRUNCATE|TABLE
2006-12-18 21:33:45
可以看到14條數據全回來了, 當然資料庫是復雜的, 如果是一個很大的表, 還是不能保證可以100%恢復的.
最近至少看到二次錯誤地截斷(Truncate)表的例子, 並在網上詢問如何恢復, 在這兒我給出AUL/MyDUL的解決方案, 下面是我用的一個測試表:
ASQL> DESC TRUNCDEMO
NO# NAME NULLABLE TYPE
--- ----------------- -------- ------------
1 COL1 VARCHAR2(20)
ASQL> SELECT * FROM TRUNCDEMO;
COL1
-----
ROW 1
ROW 2
2 rows returned.
接下來我們來截斷表, 其實這個操作只是重新格式化了段頭塊(Segment Header), 並分配一個新的數據對象號(Data Object ID), 當然空間分配信息也改了, 除非加了重用空間選項(Reuse Storage). 來看一下這個操作的前後變化:
ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS;
DATA_OBJECT_ID OBJECT_NAME
-------------- -----------
13676 TRUNCDEMO
1 rows returned.
ASQL> truncate table truncdemo;
Truncate Table Succeed.
ASQL> SELECT DATA_OBJECT_ID, OBJECT_NAME FROM USER_OBJECTS;
DATA_OBJECT_ID OBJECT_NAME
-------------- -----------
13677 TRUNCDEMO
1 rows returned.
由於在System表空間中已經記錄了新的信息, 因此用當前的System信息是不能恢復過來的,在AUL/MyDUL中可以當作沒有System時的情況來處理,在下面的命令中, 我們用Truncate後的數據對象號就不能進行恢復, 而使用Truncate以前的就可以, 當然空間不能被重新利用了是恢復的前提.
AUL> unload object 13676 column varchar file 4;
2006-09-18 22:38:58
ROW 1
ROW 2
2006-09-18 22:39:04
AUL> unload object 13677 column varchar file 4;
2006-09-18 22:39:10
2006-09-18 22:39:10
AUL>
因此在意外發生Truncate後, 如果沒有備份可以恢復, 首先要做的事是備份一下當前的文件, 免得空間被重用. 而Truncate之前的數據對象號在AUL/MyDUL中是很容易找出來的. 到此已經說明了如何恢復Truncate表了.
㈩ oracle資料庫中的表被truncate掉了，怎麼恢復
如果是重要的表，且不允許丟任何數據，則先根據 truncate 的枝橋大概時間點，（可從 dba_objects 中的 last_ddl_time 做為一個參考。） 然後，使用 logminer 從歸檔日誌（如果是剛 truncate 不久，則為從相應的在滑搭吵線日誌）中找到 truncate 命令執行的 scn 值。 在另一個環境中，從物理備份，恢復 system表空間，undo 表空間，含被 truncate 的表空間的數據文件，並 recover 至前面查出的 truncate 執行時的 scn 值 -1 的 scn 值。這樣，則恰好修復至執行 truncate 動作前一點。接著，從恢復出的環境中 export 表, 再 import 入生產庫即可。 如果是不重要的表，則從歷史備份信侍中導出，導入即可。