Can anyone help me understand how large an archive feature class could become over time? We've been exploring collector and archiving feature classes and some are very large even prior to archiving. Before I get a nasty-gram from our DBA's I thought I would do some research. I would also appreciate any workflows related to archiving data and versioning. Our production environment is a versioned SDE but our collector data will be living in another SDE instance that isn't versioned. If my question needs clarification please let me know.
Best,
Brandon
I generally don't start to worry about tables until they have more than 20-25 million rows in them. 150K is only barely large enough to manifest signs of spatial fragmentation.
GIS > Managing Data seems like a good fit for data management Qs.
- V
Hi Vince,
What is your favorite way to monitor the table sizes? Is there a way that Brandon Keinath and I could keep an eye on that without having oracle sys access?
Funny. I'll focus on other more pressing fears then. Thanks for your help.
Thanks for the reply. Some of the feature classes we would be interested in archiving have in excess of 150,000 records currently. Is the archive feature class something that our DBA's or J L would be able to view in the database and monitor the size while we test?
Do you have a place suggestion for the discussion?
How many features are you adding? Archiving storage is purely based on data volume. If you're really headed into "very large" space, then using partitioning to lop off "oldest" data might need to be part of your maintenance design.
PS: If you post questions "In a Place" rather in you own discussion, then you'll get a broader set of viewers. You can move questions using the Move choice to the right of the discussion page.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
