其實并不希望用戶都來瀏覽這篇文章，如果是自己學習還好，如果是出現問題了，可能就比較麻煩了。 經常會有用戶咨詢我們，我不小心刪除了ArcSDE里面的相關表，或者刪除了相關記錄，導致ArcSDE服務、連接、編輯等出現的相關問題，先不說這些問題怎么解決， 對
其實并不希望用戶都來瀏覽這篇文章，如果是自己學習還好，如果是出現問題了，可能就比較麻煩了。
經常會有用戶咨詢我們，我不小心刪除了ArcSDE里面的相關表，或者刪除了相關記錄，導致ArcSDE服務、連接、編輯等出現的相關問題，先不說這些問題怎么解決，對出現這種現象就應該堅決杜絕，老有許多用戶屬于那種不知道事大事小，什么都敢親身實踐，雖然他們知道“實踐是檢驗真理的唯一途徑”，但是如果你不了解數據庫或者ArcSDE的相關原理，你就自認為的操作，出現問題負責任的肯定是自己。之所以說這些還是希望用戶不要擅自操作，數據庫一旦掛了，前端再高效再炫的客戶端也是白搭啊。
雖然這篇文章的題目是恢復ArcSDE的要素類和要素，但是我并沒有真正的在ArcSDE里面做例子，或者但是我以oracle的刪除表和刪除記錄為例作測試，至于ArcSDE，那么就需要用戶了解ArcSDE的表結構之后，做相關的解決了，我也會給用戶進行相關的說明。
刪除記錄的恢復
測試場景：我刪除sde用戶下table_locks里面的若干記錄，然后恢復
操作步驟：
需要用戶以管理員身份登錄
1：查看table_locks，然后刪除，提交
SQL> select * from sde.table_locks; SDE_ID REGISTRATION_ID LO ---------- --------------- -- 2031 179 S 2031 192 S 2010 179 S 2010 192 S SQL> delete from sde.table_locks where sde_id=2010; 已刪除2行。 SQL> commit; 提交完成。 SQL> select * from sde.table_locks; SDE_ID REGISTRATION_ID LO ---------- --------------- -- 2031 179 S 2031 192 S
SCN: System Change Number
SCN是順序遞增的一個數字，在Oracle 中用來標識數據庫的每一次改動，及其先后順序。SCN的最大值是0xffff.ffffffff。
Oracle對SCN的管理（RAC環境就由DBA來管理吧）
單節點的instance中，SCN值存在SGA區，由system commit number latch保護。任何進程要得到當前的SCN值，都要先得到這個latch。
SCN的機制
數據庫運行時的SCN
我們先看下oracle事務中的數據變化是如何寫入數據文件的：
1、 事務開始；
2、 在buffer cache中找到需要的數據塊，如果沒有找到，則從數據文件中載入buffer cache中；
3、 事務修改buffer cache的數據塊，該數據被標識為“臟數據”，并被寫入log buffer中；
4、 事務提交，LGWR進程將log buffer中的“臟數據”寫入redo log file中；
5、 當發生checkpoint，CKPT進程更新所有數據文件的文件頭中的信息，DBWr進程則負責將Buffer Cache中的臟數據寫入到數據文件中。
Redo log中的high scn和low scn
Oracle的Redo log會順序紀錄數據庫的各個變化。一組redo log文件寫滿后，會自動切換到下一組redo log文件。則上一組redo log的high scn就是下一組redo log的low scn。在current log中high scn為無窮大。
可通過查詢v$log_history查看 low scn和 high scn。
更多了解：
http://czmmiao.iteye.com/blog/1010267
http://www.cnblogs.com/daduxiong/archive/2010/08/19/1803764.html
2：通過SCN的方法來恢復
--獲得當前的SCN SQL> select current_scn from v$database; CURRENT_SCN ----------- 19078853 --select * from sde.table_locks as of scn 19078843; --確定刪除的數據是否存在，如果存在，則恢復數據；如果不是，則繼續縮小scn號 SQL> select * from sde.table_locks as of scn 19078830; SDE_ID REGISTRATION_ID LO ---------- --------------- -- 2031 179 S 2031 192 S 2010 179 S 2010 192 S --將table_locks閃回到前面的scn SQL> flashback table sde.table_locks to scn 19078830; flashback table sde.table_locks to scn 19078830 * 第 1 行出現錯誤: ORA-08189: cannot flashback the table because row movement is not enabled --這個命令的作用是，允許Oracle 修改分配給行的rowid。在Oracle 中，插入一行時就會為它分配一個rowid，而且這一行永遠擁有這個rowid。閃回表處理會對EMP 完成DELETE，并且重新插入行，這樣就會為這些行分配一個新的rowid。要支持閃回就必須允許Oracle 執行這個操作 SQL> alter table sde.table_locks enable row movement; 表已更改。 SQL> flashback table sde.table_locks to scn 19078830; 閃回完成。 SQL> select * from sde.table_locks; SDE_ID REGISTRATION_ID LO ---------- --------------- -- 2031 179 S 2031 192 S 2010 179 S 2010 192 S
3：使用時間恢復刪除數據
以下信息僅供參考
1、查詢當前系統時間
select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') from dual;
2、查詢刪除數據的時間點的數據
select * from 表名 as of timestamp to_timestamp('2013-05-29 15:29:00','yyyy-mm-dd hh24:mi:ss'); (如果不是，則繼續縮小范圍)
3、恢復刪除且已提交的數據
flashback table 表名 to timestamp to_timestamp('2013-05-29 15:29:00','yyyy-mm-dd hh24:mi:ss');ArcSDE的建議：
我們上面演示的只針對單個表的記錄刪除的恢復，那么對ArcSDE來說
1：如果是非版本數據的編輯，就可以完全結合上面的例子直接恢復
2：如果是版本編輯的話，這個就需要用戶去了解ArcSDE的版本表了。
至少用戶需要對：基表、增量表、版本表（States、State_lineages、Versions等）進行閃回，而且如果是多用戶并發編輯的話，狀態表里面的數據就不僅僅是一個版本的信息，所以這個就比較麻煩。
可能有用戶來說，其實版本編輯，誤刪除了，大不了重新編輯，或者不要這個版本的信息，反正我的default版本的數據并沒有變化，恭喜你，如果你想到這一點，說明你對版本原理比較了解。
刪除表的恢復
測試場景：drop一個數據庫中的表對象，然后進行恢復
操作步驟：
對誤刪的表，只要沒有使用PURGE永久刪除選項，那么從flash back區恢復回來希望是挺大的。
1：刪除一個表對象
SQL> select count(*) from test.a; COUNT(*) ---------- 33769 SQL> drop table test.a; 表已刪除。 SQL> commit; 提交完成。 SQL> select count(*) from test.a; select count(*) from test.a * 第 1 行出現錯誤: ORA-00942: ？？？？？？？
原理：在Oracle數據庫，用戶刪除的對象會存儲在一個類似回收站的表里面，這些信息會在這個表里面進行存儲，但是如果用戶的刪除操作比較多，這個表里面的信息會類似非歸檔日志，重新寫入新的信息，如果那樣的話就不好恢復了，所以出現問題，趕緊解決才是正道。
用戶需要連接test用戶，因為刪除的表a屬于該用戶，查看回收表信息
SQL> select original_name,operation,type from recyclebin; ORIGINAL_NAME OPERATION TYPE ---------------------------------------------------------------- ------------------ -------------- D138 DROP TABLE D138_IDX1 DROP INDEX D138_PK DROP INDEX KEYSET_1247 DROP TABLE KEYSET_1300 DROP TABLE KEYSET_1301 DROP TABLE KEYSET_1316 DROP TABLE ARCGIS_SECURITY_USER_ROLE DROP TABLE SYS_C0018056 DROP INDEX ARCGIS_SECURITY_ROLES DROP TABLE SYS_C0018067 DROP INDEX ORIGINAL_NAME OPERATION TYPE ---------------------------------------------------------------- ------------------ -------------- ARCGIS_SECURITY_USER_ROLE DROP TABLE SYS_C0018070 DROP INDEX ARCGIS_SECURITY_ROLES DROP TABLE SYS_C0018074 DROP INDEX ARCGIS_SECURITY_USER_ROLE DROP TABLE SYS_C0018077 DROP INDEX A DROP TABLE BIN$3fw3ulkOXtPgQKjApdwLHg==$0 DROP INDEX SYS_LOB0000094656C00018$$ DROP LOB SYS_IL0000094656C00018$$ DROP LOB INDEX
SQL> flashback table test.a to before drop; 閃回完成。 SQL> select count(*) from test.a; COUNT(*) ---------- 33769
但注意oracle（ Release 10.2.0.1.0）回收站不支持系統表空間，如果刪除的這個在系統表空間，這個表是不能閃回的
對表數據更新一段時間后，只有在初始化參數UNDO_RETENTION設置的時間內才可以查詢到表flashback_transaction_query的數據更改記錄。而且，只有初始化參數UNDO_MANAGEMENT設置為AUTO后才能使用閃回查詢。
ArcSDE的建議：對ArcSDE來說也是一樣
1：如果沒有注冊版本，如果使用ArcGIS客戶端對要素類進行刪除，我們可以看到數據庫里面有
SQL> select original_name,operation,type from recyclebin where droptime='2013-05-31:12:25:41'; ORIGINAL_NAME OPERATION TYPE ---------------------------------------------------------------- ------------------ -------------- A DROP TABLE SYS_LOB0000094656C00018$$ DROP LOB SYS_IL0000094656C00018$$ DROP LOB INDEX BIN$3fxefjQC5+rgQKjApdwUEQ==$2 DROP INDEX
2：如果是注冊版本
還是老樣子，基表、增量表，ArcSDE的其他表的管理信息需要恢復記錄（比如sde用戶下table_regisertry會注冊SDE庫里面存儲的要素類），那么使用數據庫的方法閃回刪除的要素類的同名表，類似這些注冊信息的表的記錄也需要進行操作。
也就是說，需要用戶考慮基本和增量表的回復，其他的可以通過sdetable -o register將數據注冊到ArcSDE中，通過Register as geodatabase將數據注冊到Geodatabase中。
以上方法都是根據數據庫的方式對ArcSDE的誤操作進行一些簡單的補救措施，僅供參考！
-------------------------------------------------------------------------------------------------------
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com
Copyright ? 2019-2025 www.polareal.com 版權所有
違法及侵權請聯系：TEL:177 7030 7066 E-MAIL:11247931@qq.com 本站由北京市萬商天勤律師事務所王興未律師提供法律服務
