You are here: > ESRI Forums > arcsde (9.1 and older) users online discussion forum > Thread Replies

ArcSDE (9.1 and older) Users Online Discussion Forum

ArcSDE: Oracle forum

ArcSDE Oracle ST_Geometry   Gustavo Pagani Jul 30, 2009
Re: ArcSDE Oracle ST_Geometry   A.J. Romanelli Jul 30, 2009
Re: ArcSDE Oracle ST_Geometry   Gustavo Pagani Jul 31, 2009
Re: ArcSDE Oracle ST_Geometry   A.J. Romanelli Jul 31, 2009
Re: ArcSDE Oracle ST_Geometry   Vince Angelo Jul 31, 2009
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject ArcSDE Oracle ST_Geometry 
Author Gustavo Pagani 
Date Jul 30, 2009 
Message Hi,

We have a geodatabase in Oracle with the default settings for ArcSDE geometry storage parameters (which is the default? SDEBinary?).
Now we need to use SQL functions such as ST_Area.
But we have several applications developed in ArcObjects that we do not want to stop working.

What are the suggestions of you for this case?

What steps should I follow?

1) Setting the standard geometry storage parameters from the database to ST_Geometry.
2) Recreate my dataset and all my feature classes with the standard ST_Geometry.
3) Load the data from older feature class to feature class with the new standard.


This will degrade the performance of my applications ArcObjects?
We have to do some maintenance on these applications?

What advantages would the Oracle Spatial for this case?

Thanks in advice. 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: ArcSDE Oracle ST_Geometry 
Author A.J. Romanelli 
Date Jul 30, 2009 
Message The default is different depending on what version of SDE you are using. At 9.3 ST_Geometry became the new default geometry storage type (before that it was sde binary).

Your ArcObjects applications don't have any knowledge of the underlying storage format (SDE hides that tid-bit from client apps as one of its core pieces of functionality). Your ArcObjects app (or any sde api client based app) functionality doesn't need to change at all if you migrate the underlying data storage to a spatial data type.

You can either migrate your data storage in place, or dump and reload. I'd lean towards the dump and reload option, but technically either will work.

In theory the st_geometry should be faster than sde binary (since it doesn't require the table joins that sde binary does), but you'll have to test that yourself (and oracle tuning parameters come into play). Be sure your statistics are up to date!

The only advantage of SDO over ST is that some of your sql developers might be more familiar with the sdo functions than the st functions. Also, many 3rd party tools can read/write SDO geometry, there may be a smaller subset that read/write ESRI's ST geometry. 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: ArcSDE Oracle ST_Geometry 
Author Gustavo Pagani 
Date Jul 31, 2009 
Message I read in the ArcGIS Help that SDEBinary:

"Provides high performance, scalability, and reliability."

"Compressing the geometry offers efficient storage and retrieval of spatial data by reducing the space required to store data by as much as 40 percent."

But did not find any comparison of performance between the SDEBinary and ST_GEOMETRY. I will test.

I dump my database in ArcSDE 9.2 SDEBinary and reload in database ArcSDE 9.3. It automatically changed to ST_GEOMETRY.

Thanks!

http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=ArcSDE_Compressed_Binary_storage

http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=An_overview_of_feature_geometry_and_raster_data_storage
 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: ArcSDE Oracle ST_Geometry 
Author A.J. Romanelli 
Date Jul 31, 2009 
Message note, the topic http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=An_overview_of_feature_geometry_and_raster_data_storage is slightly misleading (implying that sdebinary is only/always stored as longraw on oracle). Prior to 9.3 sdebinary was the default storage format for sde on oracle. The sdebinary format itself can be stored in either longraw (which is a holdover from the sde 2.x days) or blob within the database (controlled by the GEOMETRY_STORAGE paramater in the dbtune file/table, sdelob=blob storage of sdebinary data, sdebinary=longraw storage of sdebinary data) . Most folks have moved away from long raw due to implications with RAC and the limitation that there can only be a single longraw column per table.

see http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=About_geometry_storage_types and/or http://webhelp.esri.com/arcgisdesktop/9.3/index.cfm?TopicName=ArcSDE_Compressed_Binary_storage for a better/more accurate description 
   
Report Inappropriate Content • Top • Print • This Forum is closed for replies.    
Subject Re: ArcSDE Oracle ST_Geometry 
Author Vince Angelo 
Date Jul 31, 2009 
Message Actually, SDEBINARY *does* only use LONG RAW, and it's been
consistently faster than the LOB storage form (SDELOB storage),
mostly because the LOBs are slower than LONG RAW. Of course,
that's not an option at 11g, and even some 10gR2 sites have
Oracle issues with LONG RAW reliability.

All three forms (SDEBINARY/SDELOB/ST_GEOMETRY) use the
same basic internal format for the geometry (using integer
compression). The ST_GEOMETRY difference is on the custom
index-organized table for the spatial index, as well as the
ability to store the geometry in the business table row
(vice the external F table).

It's hard to make a generic comparison between *all* data
in a specific format, but ST_GEOMETRY has often been close
to SDEBINARY performance, for all that it's based on LOB
storage.

Then again, the coordinate reference parameters used have
the same or larger impact as changing storage methods --
The research below indicates that changing the coordref
and storage method for 1218Mb of US "Data and Maps"
shapefiles (59 files) into ArcSDE can cause overall
storage in Oracle 10gR2 with ArcSDE 9.2 (SP6) to vary by
one third, but that keeping ~11cm precision in either
BASIC or HIGH layer precision with ST_GEOMETRY actually
uses less total space (in 1Mb extents) than the old
BASIC storage standard for WGS84 geographic data.

- V 
 
Storage  	X/Y Coordref         Precision	-aall	-anone	Total%	Geom%
SDEBINARY	-210,-120,1000000	BASIC	1339	1261	-	-
SDEBINARY	-210,-120,1000000	HIGH	1339	1261	0.0	0.0
SDEBINARY	-400,-400,1000000000	HIGH	1540	1464	15.0	16.1
SDELOB   	-210,-120,1000000	BASIC	1585	1509	18.4	19.7
SDELOB  	-210,-120,1000000	HIGH	1588	1509	18.6	19.7
SDELOB  	-400,-400,1000000000	HIGH	1826	1748	36.4	38.6
ST_GEOMETRY	-210,-120,1000000	BASIC	1309	1224	-2.2	-2.9
ST_GEOMETRY	-210,-120,1000000	HIGH	1313	1224	-1.9	-2.9
ST_GEOMETRY	-400,-400,1000000000	HIGH	1548	1461	15.6	15.9