Feature Classes QUADRUPLES in size when imported to SDE

[Anonymous User]

We have SQL Express and Enterprise workgroup.  When I import a feature class from a file geodatabase into a new or an existing enterprise geodatabase the file triples in size - on import alone.  I'm connection with Esri support but so far they have only been able to replicate my problem, not give me any answers.

The workflow is so basic, all I am doing is moving data from a file gdb to an SDE.  Nothing else is happening and my data goes from 118 MB to 585 MB.  Compressing has no effect.

sde problem‌ #file size increase‌

[JoshuaBixby]

It is worrisome that Esri Support could not provide you with a clear-cut answer because from the little you have shared here, I think the answer is straightforward.

SQL Server, even the Express edition, is much more complex than file geodatabases.  Additionally, you appear to be creating enterprise geodatabases (not a good idea, I am not even sure Esri supports using Express for enterprise geodatabases).

If you look at the Create a geodatabase in SQL Server—Help | ArcGIS Desktop documentation, you will see that the default size for a new SQL database containing an enterprise geodatabase is at least 625 MB:

The Create Enterprise Geodatabase tool makes it easy to set up a geodatabase because it creates the database objects and grants required privileges for you. To achieve this, the tool uses the following default settings and creates the following database objects:

• * It creates the database files (MDF and LDF) in the default SQL Server location on the server.
• * It sets the SQL Server database options READ_COMMITTED_SNAPSHOT and ALLOW_SNAPSHOT_ISOLATION to ON.
• * It uses the default database file sizes you have defined for the SQL Server model database or 500 MB for the MDF file and 125 MB for the LDF file, whichever is greater.
• * If you choose to create a geodatabase in a schema named sde, the tool creates an sde database-authenticated login in the SQL Server instance, creates an sde user in the database and maps it to the sde login, creates an sde schema in the database, and grants the sde user privileges to create a geodatabase and kill connections to the SQL Server instance.
• * It creates the geodatabase objects inside the SQL Server instance.

If you take your roughly 75 MB of file geodatabase data and add it to the new, empty geodatabase of 625 MB, you get roughly 700 MB in total size.

[Anonymous User]

Well shoot!  You may have figured it out! Is this something that would have changed when Esri moved from ArcServer to ArcGIS Enterprise?  Our old databases were fine and when we upgraded I just kept on with the same workflows I had been doing all along at my old job.  Though now that I think about it, we had technical support for installing ArcServer at my old job and when I got my new job our IT guy handled everything for the upgrade to ArcGIS Enterprise.  I believe, and I may be wrong, but at my old job we just had SQL server express.

Do you have any recommendations for improving our back end structure to accommodate our needs?  We are a firm with about 50 GIS users.  We have ArcGIS Enterprise so that I can publish basemap\authoritative services to our internal users to view and extract data from without corrupting the source data or locking each other out.  As soon as the ArcGIS for AutoCAD plugin is able to communicate with our Portal our services will reach another 50-75 users in AutoCAD. 

Our server is federated and we don't publish to AGOL unless its for a client or field work - our field devices will eventually have a secure connection back to our office but that's not on the table yet.  

If you have any other advice or guidance I am all ears.  Thank you very much!

[JoshuaBixby]

I can't answer your question with certainty because there are still gaps in the information.  From what I could gather, you were using Workgroup geodatabases before and then migrated to Enterprise geodatabases.  Could that alone explain the difference?  Not sure. Esri's documentation for Desktop and Workgroup geodatabases doesn't give similar information as for Enterprise geodatabases.  It could also be someone like a DBA overrode the defaults on your previous geodatabase and made the system files smaller.

In terms of size, I wouldn't worry about the sizes you are seeing since 1 GB is practically nothing in terms of storage server or DMBS running on servers.

Deploying ArcGIS Enterprise is quite involved, or can be, and I don't have any general recommendations beyond one.  If you are deploying Enterprise geodatabases, move to SQL Server Standard at a minimum. 

[Asrujit_SenGupta]

Honestly, I am not sure if that is the case.

• They were already using SDE Workgroup geodatabases, so basically they are not creating new geodatabase using 'Create Enterprise GDB' tool.

• I expand the Database Servers icon.  Under my arcserver_sqlexpress.gds I right click and select "New Geodatabase"

  They are connecting using 'Database Server' option in ArcCatalog  and creating new geodatabase. Not creating connections under 'Database Connections'.
• The Default database size, of roughly 700 MB shrinks to something around 4 MB for a new Enterprise geodatabase, if you perform a Shrink operation on the database in SQL Server.

Did you try running the SQL provided by George above to find the actual size of the Tables in the database?

[JoshuaBixby]

I agree that some of the terms and actions described didn't/don't line up.  Did the OP mean enterprise geodatabase when stating "enterprise" or ArcGIS Enterprise, which also covers workgroup geodatabases. 

[Todd_Metzler]

My experience is with ArcGIS Enterprise Advanced not ArcGIS workgroup.  But I'll suggest a simple solution that may work.

Terminology first.  File Geo Data Base (FGDB); Enterprise Geo Data Base (EGDB).  EGDB is often used synonomously with SDE.  These terms are not the same.  In a Relational Database Management System that supports native geometry and geography types (just about every main stream RDBMS these days) you may create EGDB that is not SDE schema.

Now, provided your ArcGIS workgroup deployment creates keycodes like an ArcGIS Enterprise deployment does and you don't violate your Esri license agreement in any way and you have enough resources to deploy multiple SQL Express RDBMS then you've solved your space limitations because each SQL Express instance will have it's own upper limit.  When determining if you have enough resources to try this, note that we have observed that a "fresh" SQL Express deployment will consume about 1GB of RAM sitting idle doing nothing without any data.