imported Feature Class size

491
15
Jump to solution
10-30-2013 11:46 AM
DanielSmith
Occasional Contributor III
Hello,

I have a contour feature class stored in a file geodatabase. when looking at the contents tab of the geodatabase in ArcCatalog i see that the size of the file is 4GB.

I am attempting to store this data in an SDE database (SQL Server Express 2008 R2, so a 10GB limit). When I import the data (either using feature class to feature class, right-click > Import, or creating a blank feature class and loading it) the mdf file bloats to 10 GB and it fails to import.

Why does this 4 GB file bloat and blow up my SDE database? is there a way i can import this contour data set into my SDE instance?

Any thoughts, suggestion, or guidance is greatly appreciated.

-Daniel
0 Kudos
1 Solution

Accepted Solutions
VinceAngelo
Esri Esteemed Contributor
You've got more administration options with Enterprise, which is why I was asking.

You can try changing the default storage type to SDEBINARY, though I don't know
what sort of storage difference it will make (Microsoft uses a compressed integer
representation as well).

Of more significance, with SDEBINARY you can back off the default submillimeter
coordinate resolution to a decimeter and probably reduce the feature storage
significantly (at a precision cost, of course). [You can make that change in
GEOMETRY storage as well,but it doesn't use the coordref to calculate the integer
representation, so that wouldn't have a storage impact.]

- V

View solution in original post

0 Kudos
15 Replies
VinceAngelo
Esri Esteemed Contributor
There are probably a number of things going on here:

  • Databases format differently than file geodatabase

  • Databases index differently than file geodatabase

  • File geodatabase supports compression

But first that are a number of issues to address:

  • Are you using an Enterprise ArcSDE in the SQL-Server Express?

  • What is the default storage format?

  • How is your coordinate reference (specifically xyscale) defined?

  • What is the physical size of the file geodatabase directory (according to Explorer)?

I'd expect a File Geodatabase to be faster (especially after you compress it) than any RDBMS-
based geodata, so I'm wondering why you are even on this path.  Do you really need multi-user
editing on a contours layer?

- V
0 Kudos
DanielSmith
Occasional Contributor III
There are probably a number of things going on here:

  • Databases format differently than file geodatabase

  • Databases index differently than file geodatabase

  • File geodatabase supports compression


yeah, i agree on the formatting, indexing, and compression. I did not expect a > 2x expansion though.


But first that are a number of issues to address:

  • Are you using an Enterprise ArcSDE in the SQL-Server Express?

  • What is the default storage format?

  • How is your coordinate reference (specifically xyscale) defined?

  • What is the physical size of the file geodatabase directory (according to Explorer)?

I'd expect a File Geodatabase to be faster (especially after you compress it) than any RDBMS-
based geodata, so I'm wondering why you are even on this path.  Do you really need multi-user
editing on a contours layer?

- V



  • SQL Server Express

  • i have not modified the storage format for SDE so what ever the default would be. what is the best way to determine storage format?

  • Do you mean the resolution? its defined on import by the input feature class. additionally it has z coordinates stored in the geometry.

  • the entire GDB in explorer is ~8GB but it includes all the individual tiles that comprise the merged data set

  • Its less about the multi-user editing and more about using 1 way replication to subcontractors via geodata services. It is much faster in the file GBD you are correct there. maybe a  better plan would be to host the static data from a file geodatabase and allow extraction of the data instead of using replication and keep the more dynamic data in SDE. There is some data that really wont be edited and some that will be actively edited hence the static/dynamic distinction.

0 Kudos
VinceAngelo
Esri Esteemed Contributor
Are you using Enterprise ArcSDE or Personal/Workgroup ArcSDE in the Express instance?

I think the default is now GEOMETRY storage, which would explain the significant storage
difference.

- V
0 Kudos
DanielSmith
Occasional Contributor III
Are you using Enterprise ArcSDE or Personal/Workgroup ArcSDE in the Express instance?

SQL Server Express 2008 R2

I think the default is now GEOMETRY storage, which would explain the significant storage
difference.

this seems to be the case. i checked an imported data set and the shape data type is GEOMETRY. this matches the result of manually setting config keyword to GEOMETRY when creating a new blank feature class.
0 Kudos
DanielSmith
Occasional Contributor III

I think the default is now GEOMETRY storage, which would explain the significant storage
difference.



just checked the db_tune table and this is the case.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Are you using Enterprise ArcSDE or Personal/Workgroup ArcSDE in the Express instance?

- V
0 Kudos
DanielSmith
Occasional Contributor III
Are you using Enterprise ArcSDE or Personal/Workgroup ArcSDE in the Express instance?

- V


hahahah. sorry. It would be Enterprise, licensed through ArcGIS for Server.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
You've got more administration options with Enterprise, which is why I was asking.

You can try changing the default storage type to SDEBINARY, though I don't know
what sort of storage difference it will make (Microsoft uses a compressed integer
representation as well).

Of more significance, with SDEBINARY you can back off the default submillimeter
coordinate resolution to a decimeter and probably reduce the feature storage
significantly (at a precision cost, of course). [You can make that change in
GEOMETRY storage as well,but it doesn't use the coordref to calculate the integer
representation, so that wouldn't have a storage impact.]

- V
0 Kudos
DanielSmith
Occasional Contributor III
OK cool, I will check out SDEBINARY and mess with the resolution.

Thanks for your help
0 Kudos