Heim  >  Artikel  >  Datenbank  >  使用Oracle的IMP/IMPDP迁移ArcSDE数据库常见问题

使用Oracle的IMP/IMPDP迁移ArcSDE数据库常见问题

WBOY
WBOYOriginal
2016-06-07 15:50:511542Durchsuche

在使用Oracle数据泵来进行ArcSDE数据的逻辑迁移时,有时候会报如下错误: C:\impdp map/map tables=buildings directory=exp_imp_dir dumpfile=buildings.dmpImport: Release 10.2.0.2.0 - Production on Tuesday, 22 January, 2008 16:38:00 Copyright (c)

在使用Oracle数据泵来进行ArcSDE数据的逻辑迁移时,有时候会报如下错误:

C:\>impdp map/map tables=buildings directory=exp_imp_dir dumpfile=buildings.dmp


Import: Release 10.2.0.2.0 - Production on Tuesday, 22 January, 2008 16:38:00

 
Copyright (c) 2003, 2005, Oracle.  All rights reserved.

 
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.2.0 - Production

With the Partitioning, OLAP and Data Mining options

Master table "MAP"."SYS_IMPORT_TABLE_01" successfully loaded/unloaded

Starting "MAP"."SYS_IMPORT_TABLE_01":  map/******** tables=buildings directory=exp_imp_dir dumpfile=buildings.dmp

Processing object type TABLE_EXPORT/TABLE/TABLE

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

. . imported "MAP"."BUILDINGS"                           1.005 MB    3149 rows

Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX

Processing object type TABLE_EXPORT/TABLE/INDEX/TABLE

Processing object type TABLE_EXPORT/TABLE/INDEX/TABLE_DATA

. . imported "MAP"."S1_IDX{1}quot;                             157.5 KB    4205 rows

Processing object type TABLE_EXPORT/TABLE/INDEX/DOMAIN_INDEX/INDEX

ORA-39083: Object type INDEX failed to create with error:

ORA-20091: Import SRID does not match ST_Spatial_References SRID

Failing sql is:

BEGIN

SDE.st_type_export.validate_spref(1,-1196.334263,-1028.576111,1000000,0,1,0,1,4267);COMMIT; END;

Job "MAP"."SYS_IMPORT_TABLE_01" completed with 1 error(s) at 16:38:04


提示用户导入的空间投影信息SRID与系统的SRID不一致。

空间的引用的元数据存储在 sde.st_spatial_reference 表中。Sde.st_spatial_reference 表中的每个条目都有唯一的 SRID 值和定义的空间参考属性的附加属性。为确保正在导入的空间索引的有效性,导出文件中的元数据要对比正在执行导入的数据库中的空间引用元数据。如果空间参照不存在,就会提示以上ORA-20091和ORA-39083错误。

也是也就是说你导入数据的包含的SRID这个值,并没有与 sde.st_spatial_reference里面SRID对应或者说该表中根本就没有导入数据的投影信息。


那么这种情况怎么办呢?那我们就需要将我们往数据库的文件的投影信息注册到ArcSDE库里面。其实注册很简单,假如说我们需要导入的数据的投影信息为NAD_1983_StatePlane_Ohio_South_FIPS_3402_Feet,但是Sde.st_spatial_reference并没有该投影信息,那么我们就可以在该用户下创建一个该投影的数据集或者要素类即可,创建完毕之后,该投影信息就注册到ArcSDE里面了,而且也有自己的SRID,那么我们就可以将刚才创建好的对象删除掉,但是注册到ArcSDE里面的SR信息并不会删除掉。


根据上面的错误,我们将索引表(S1_IDX$)删除掉

Processing object type TABLE_EXPORT/TABLE/TABLE_DATA

. . imported "MAP"."BUILDINGS"                           1.005 MB    3149 rows

Processing object type TABLE_EXPORT/TABLE/GRANT/OWNER_GRANT/OBJECT_GRANT

Processing object type TABLE_EXPORT/TABLE/INDEX/INDEX

Processing object type TABLE_EXPORT/TABLE/INDEX/TABLE

Processing object type TABLE_EXPORT/TABLE/INDEX/TABLE_DATA

. . imported "MAP"."S1_IDX{1}quot;
SQL> DROP TABLE s1_idx$;



Table dropped.

然后我们查看一下刚才注册的投影信息

SQL> SELECT srid, sr_name FROM sde.st_spatial_references

  2  WHERE sr_name = 'NAD_1983_StatePlane_Ohio_South_FIPS_3402_Feet';



      SRID SR_NAME

---------- -----------------------------------------------

        65 NAD_1983_StatePlane_Ohio_South_FIPS_3402_Feet


因为我们每一个以ST_Geometry存储的属性表在查看数据库都会有一个SRID,而且我们已经将新的投影信息注册到我们导入的新库中,所以我们需要更新一下出错的那张表所有记录的SRID

SQL> UPDATE buildings t SET t.shape.srid = 65;



3149 rows updated.



SQL> COMMIT;

更新完毕后,我们再重新创建空间索引即可

SQL> CREATE INDEX buildings_shape_idx

  2  ON buildings (shape) INDEXTYPE IS sde.st_spatial_index

  3  PARAMETERS ('st_srid=65 st_grids=200');



Index created.


特别注意:一般都不建议使用Oracle的IMP/IMPDP来对ArcSDE数据进行导出导出做迁移,因为这样对数据库技术要求比较高,特别是因为某些版本问题、字符集问题、序列问题、触发器问题、ArcSDE本身的问题导致的迁移出错,一般是很不好处理的,建议使用ArcGIS的迁移方式,数据源1-FGDB,FGDB-数据源2,是不是非常简单,而且不会出错!



 -------------------------------------------------------------------------------------------------------

QQ群:              78773981
Blog:               http://blog.csdn.net/linghe301
Weibo:            http://www.weibo.com/linghe301

-------------------------------------------------------------------------------------------------------

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn