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.
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.]
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?
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.
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.
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.]
