St_geometry vs SDEBinary storage requirements in Oracle

TeresaVillena — Wed, 15 Jul 2015 15:36:24 GMT

Does any body knows the st_geometry storage requeriments vs sdeBinary storage requirements in Oracle?

Regards,

Teresa V.

Re: St_geometry vs SDEBinary storage requirements in Oracle

SamuelTompsett — Wed, 15 Jul 2015 15:49:39 GMT

Hi Teresa,

Could you be more specific on what you are looking for when you say "storage" requirements?

Thanks,
Sam

Re: St_geometry vs SDEBinary storage requirements in Oracle

TeresaVillena — Wed, 15 Jul 2015 16:14:27 GMT

Hi Sam,

I want to know if I will need more storage space in Oracle when I migrate from sdeBinary to st_geometry

Thanks,

Teresa

Re: St_geometry vs SDEBinary storage requirements in Oracle

VinceAngelo — Wed, 15 Jul 2015 17:15:51 GMT

In theory, the LONG RAW storage used with SDEBINARY should be about the same as the BLOB space used by ST_GEOMETRY, except:

The storage requirements are in different tables (and, potentially, tablespaces)
LOBs have the option of both inline and out-of-row storage (and the out of row storage can be targeted to a different tablespace)
ST_GEOMETRY always uses HIGH precision, so it will be larger than an equivalent shape stored in BASIC (or HYBRID) precision
Modern default coordinate references use a precision which significantly increases storage over data stored in earlier-generated geometries (higher precision increases the magnitude of the vertex deltas, which increases the bits needed to store vertices)
In-situ migration requires significant additional storage (which is preserved by the table high-water mark), and is likely to fragment the table (increasing storage and hurting query performance.

Given the state of modern disk storage, you could probably store ten times the previous vector data in under $120 of disk (and it might have a faster seek time), so shoehorning datasets into disk shouldn't be a major concern.

Best practice would be create a new table in a new tablespace (tablespaces, if you consider indexes), taking the opportunity to spatially defragment the table(s) by using the Sort (Data Management) tool to optimize the draw performance by using a UL spatial sort option (Advanced [ArcInfo] license only) when populating the new table (Standard and Basic licenses would need to use a spatially correlated attribute, like zipcode, or mgrs, or geohash, or an index grid id to achieve spatial defragmentation).

- V

Re: St_geometry vs SDEBinary storage requirements in Oracle

TeresaVillena — Fri, 17 Jul 2015 14:12:03 GMT

Thanks a lot for your help

topic Re: St_geometry vs SDEBinary storage requirements in Oracle in Geodatabase Questions

St_geometry vs SDEBinary storage requirements in Oracle

Re: St_geometry vs SDEBinary storage requirements in Oracle

Re: St_geometry vs SDEBinary storage requirements in Oracle

Re: St_geometry vs SDEBinary storage requirements in Oracle

Re: St_geometry vs SDEBinary storage requirements in Oracle