File geodatabase is getting fat extremely

[AhmadSALEH1]

Hi,

File geodatabase are getting fat extremely.

I have a FGD with a name “U.gdb”, I have noticed that this DB has a size of 10 G.B, despite the fact that my data is not that big in size, so I decided to copy the F.C’s inside the U.gdb to a newly created geodatabase with a name “U2.gdb” the size of the newly created db decreased immediately to 148 MB.

The same data  are in both GDBs while the size is extremely different. Compact and Compress File Geodatabase Data fails to reduce the size of the geodatabase.

 

The source of this issue might be because I have an enterprise geodatabase (U.mdf) and regularly I used to delete all F.Cs from U.gdb and copy the mdf F.Cs  to U.gdb in order to update my data.

What should I do to maintain the same gdb size and avoid the over growing size if the GDB.   

Thanks

Ahmad

[NathanHeickLACSD]

After reading the solution, I think it was the case that the one file geodatabase that was not tied to a service used to be in the past.  Maybe, DeleteFeatures creates a new empty table and repoints the FGDB to the new file, leaving the old file in place.  I was able to run TruncateTable on the locked feature class.  I think I tested this a few years ago and it didn't work on 10.6.1.

[CalenDaugherty]

Thanks for the reply. In reviewing some of the instances where I have encountered this behavior, I have noticed something similar to what you describe . . . many .gdbtable files that don't seem to be removed during Compact. If the database size has grown and there is a single large .gdbtable, Compact seems to work well in shrinking it. But it does not seem to get rid of the "extra" .gdbtable files. Copying the data to a new geodatabase seems to only bring along the needed files, so it effectively reduces to size of the data. This issue does not always occur, so I have still have not isolated the scenarios that would cause it.

[NathanHeickLACSD]

From what I can tell, it appears to be the DeleteFeatures tool that creates the extra gdbtables.  It may only happen when the table is locked by a service.  I reclaimed so much space yesterday by copying the data to new file geodatabases that I cut the file size by 95%.  The FGDBs were getting really large during development when I was writing and testing the scripts a lot.  Databases that I thought were inherently large were only large from running the scripts hundreds of times during debugging.

Another interesting side note is that the scripts run significantly faster now.  The run times were cut by 2/3.