nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

SDE Compress triples size of geodatabase

TimAnderson3

My plan is to load roughly 400gb of vector data into an enterprise geodatabase. I just recently got started, and let "compress geodatabase" run over night. When I came back in, my SDE had grown from 4gb to about 16gb after the compress completed. I am using Desktop 10.6 and Oracle 12.2. If compressing increases size 2-3x this is going to give me problems. any suggestions on what may be broken?

Najděte více příspěvků označených jako

Accepted answers

All comments

midettra

Hello Tim,

I know this is an old post, but I am facing the same problem you had. The enterprise database size was 5.5 GB before compress and after compress it reached 6.3 GB and I did not figure out why did this happen and also would this have any negative impact on the performance ?!

I am using Arcmap 10.7 with SQL server 2014. The state_id number was around 7,000 and ended up to 14 after compress. I walked through all the procedures for a full compress starting with posting changes and deleting versions reaching to disconnecting all users.

Kindly your response is much appreciated if you found a reason for this issue.

Thank you,

Mohamed Salah

TimAnderson3

thanks! i will give this a shot in the morning. Our Oracle guru should be back to work by then as well. Hopefully he can help me sort this out, as I am a novice with Oracle at best.

George Thompson

One thing that I just thought of is this: If the tablespace is on auto growth and during the compress or another operation, it needed that space. The TBS files will NOT compress back down to the smaller level when completed. The tablespace will stay the larger size and not grow till it is needed again.

Run the following SQL to see how much of the tablespace is actually being used:

clear breaks
 <SPAN class="keyword token">SET</SPAN> linesize <SPAN class="number token">130</SPAN>
 <SPAN class="keyword token">SET</SPAN> pagesize <SPAN class="number token">60</SPAN>
 <SPAN class="keyword token">break</SPAN> <SPAN class="keyword token">ON</SPAN> tablespace_name skip <SPAN class="number token">1</SPAN>
 col tablespace_name format <SPAN class="number token">a15</SPAN>
 col file_name format <SPAN class="number token">a50</SPAN>
<SPAN class="keyword token">select</SPAN> <SPAN class="operator token">*</SPAN> <SPAN class="keyword token">from</SPAN> dba_tablespace_usage_metrics <SPAN class="keyword token">order</SPAN> <SPAN class="keyword token">by</SPAN> used_percent <SPAN class="keyword token">desc</SPAN><SPAN class="punctuation token">;</SPAN>‍‍‍‍‍‍‍‍‍‍‍‍‍‍<SPAN class="line-numbers-rows"><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN><SPAN>‍</SPAN></SPAN>

That will help determine what may be going on.

TimAnderson3

Thank you for your replies. To be clear, I do understand that I have no real need to compress at this point. We are moving to a new version of Oracle and I just took it as an opportunity to make sure things are still working as they should be, and it seems as if we have a glaring issue! To answer your questions, all data is going to the SDE tablespace, and there was no data being loaded during the compression. That was my first thought, but the problem is persistent even if I just import a very small dataset that only takes a few seconds to load. I am not in the office at the moment so I cannot look at the compress log for specifics, but it did reduce the states from "several" to 1, which was expected, and reported it as a success in the table. I did see that the undotbs.dbf is growing very large in addition to the sde tablespace, and I feel like figuring that part out may lead me to a resolution.

George Thompson

If there is no versioned editing, then there is not a need to compress the Oracle geodatabase. I have also not seen it grow from a compress when finished.

Compresses an enterprise geodatabase by removing states not referenced by a version and redundant rows.
Under the tool usage: This tool is not applicable for enterprise geodatabases that do not use versioning.

Compress—Help | ArcGIS Desktop

The compress operation and geodatabases—ArcGIS Help | ArcGIS Desktop

Do you have everything in a single tablespace (i.e. SDE, DATA, etc.)?

Was there any other data being loaded into the geodatabase during that same time?

What does the sde_compress table report back for that process?

TimAnderson3

there is no versioned editing right now. I am building what will eventually become the parent database

TimAnderson3

I am basing it off of the size of the sde tablespace

George Thompson

Agree with Asrujit and do you have lots of versioned editing happening?

Asrujit_SenGupta

How are you checking\calculating the size of the database?

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.