本文共 2499 字,大约阅读时间需要 8 分钟。
arcgis10.0+sde10.0,从生产导一个sde表导测试库,发现用arcmap打开报错
尝试对比测试和生产库的state_id值,先备份表,再update成一致,但结果还是报错。原因不在此。以前出现该错误的时候可能impdp的时候就报了很多错误,重导,或者重新导入整个sde用户的所有对象,就能解决。头一次只导单个大表。
SQL> select table_name FROM USER_tab_columns where column_name='STATE_ID';
TABLE_NAME
------------------------------ MVTABLES_MODIFIED STATES STATE_LOCKS VERSIONSSQL> select table_name FROM USER_tab_columns where column_name like '%STATE_ID';
TABLE_NAME
------------------------------ MVTABLES_MODIFIED STATES STATES STATE_LOCKS VERSIONSSQL> select * from MVTABLES_MODIFIED;
no rows selected
SQL> select * from STATES;
STATE_ID OWN CREATION_TIME CLOSING_TIME PARENT_STATE_ID LINEAGE_NAME
---------- --- ------------------- ------------------- --------------- ------------ 0 SDE 2020-07-09 22:27:19 2020-07-09 22:27:19 0 0SQL> select * from STATE_LOCKS;
no rows selected
SQL> select * from versions;
NAME OWN VERSION_ID STATUS STATE_ID DESCRIPTION ---------- --- ---------- ---------- ---------- ------------------------------------------------------------------------------------ DEFAULT SDE 1 1 0 Instance default version.SQL>
继续分析发现该表不被认为是要素表,而是普通表。由于导入的过程也没有任何报错,所以认为表数据是不可能有问题的。数据量太大超2亿,导入也费劲。感觉没有重导的理由。
经过和开发沟通,arcgis地图数据比较特殊的地方:需要先用catalog创建要素集表和要素表(创建和导入的同名的要素表,这时会提示对象已存在,那么先把之前导入的表重命名为其它,等创建出要素表了,再drop掉同名表,最后把重命名表改回来即可)。
同时由于加载地图慢,可以考虑充分利用多cpu的优势,把表修改为并行,经测试明显提升打开速度。
select table_name,degree from user_tables; --查看表并行度alter table table_name parallel(degree 4); ---4是修改该表并行度alter table table_name parallel ; ---修改并行度为默认值
总结:
基本可以认为:通过arcgis桌面工具创建要素集和表的时候,在sde自身的字典表记录里做了记录。所以产生上述现象。后续有时间再研究到底存放在什么表的字段值里。
跟踪方法参考:
打开arcmap,连接sde--在数据库中使用sys登录---- SQL> conn /as sysdbaConnected.SQL> set linesize 150;SQL> select sid,serial#,username from v$session where username is not null; SID SERIAL# USERNAME---------- ---------- ------------- 33 167 SYS 39 390 JACKSQL> select pid, spid from v$process p, v$session s where p.addr = s.paddr and s.sid=39; PID SPID---------- -------- 25 6886--指定跟踪SESSION的SPID(OS process) SQL> oradebug setospid 6886Oracle pid: 25, Unix process pid: 6886, image: oracle@yft (TNS V1-V3)SQL> oradebug unlimitStatement processed.SQL> oradebug event 10046 trace name context forever,level 12Statement processed.操作创建要素集和表--关闭10046事件----SQL> oradebug event 10046 trace name context off;Statement processed.SQL> oradebug tracefile_name/u01/app/oracle/diag/rdbms/yft/yft/trace/yft_ora_6886.trc
转载地址:http://szsof.baihongyu.com/