ArcSDE for Oracle怎么恢复误删除的要素类和要素
其实并不希望用户都来浏览这篇文章，如果是自己学习还好，如果是出现问题了，可能就比较麻烦了。 经常会有用户咨询我们，我不小心删除了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相关原理：SCNSCN: 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: ？？？？？？？2：使用闪回方法来恢复原理：在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我们可以看到有A名称的表，然后进行恢复即可
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所以说，使用ArcMap删除不仅仅是要素类，还包含相关的索引对象还有其他，所以使用上面的方法可以只恢复同名表A，对ArcGIS10.1是没有问题的，完全可以通过桌面进行注册即可，对10版本之前的可能就有点小问题了，但是最主要的同名表恢复过来，我们可以通过sdelayer -o register方法注册也可以。
2：如果是注册版本
还是老样子，基表、增量表，ArcSDE的其他表的管理信息需要恢复记录（比如sde用户下table_regisertry会注册SDE库里面存储的要素类），那么使用数据库的方法闪回删除的要素类的同名表，类似这些注册信息的表的记录也需要进行操作。
也就是说，需要用户考虑基本和增量表的回复，其他的可以通过sdetable -o register将数据注册到ArcSDE中，通过Register as geodatabase将数据注册到Geodatabase中。
以上方法都是根据数据库的方式对ArcSDE的误操作进行一些简单的补救措施，仅供参考！
-------------------------------------------------------------------------------------------------------