{"id":8191,"date":"2019-02-28T02:00:51","date_gmt":"2019-02-28T01:00:51","guid":{"rendered":"http:\/\/www.sigterritoires.fr\/?p=8191"},"modified":"2019-02-28T06:45:08","modified_gmt":"2019-02-28T05:45:08","slug":"job-optimizing-with-arc-gis-geodatabases-3-compacting","status":"publish","type":"post","link":"https:\/\/www.sigterritoires.fr\/index.php\/en\/job-optimizing-with-arc-gis-geodatabases-3-compacting\/","title":{"rendered":"Job optimizing with Arc Gis Geodatabases : 3- Compacting"},"content":{"rendered":"\n

Most users are satisfied\nwith the passage of shape files to the ArcGis geodatabase . However\n, they notice a decrease in performance after editing heavy sessions.\nTheir issue is how to correctthis problem.\nWe will discuss in\nthis\narticle the concept of compacting a geodatabase\n. As compression ( see with ArcGis 2- Geodabases Compression <\/a> ),\ncompacting reduces the size of the ArcGIS geodatabase\nin\norder to speed up requests . However , compacting works\ndifferently\ncompared to compression.
\nExcept\nin\nloss compression, the compression, generally, erases\nno\ndata byte from the geodatabase . It re-groups the data bytes\naccording\nto the redundancy of information : if you have\nten lines with the value \u00ab\u00a08\u00a0\u00bb, the compression will keep 10 (8)\ninstead of 8 8 8 8 8 8 8 8 8 8.
\nDuring\ncompacting, the process physically removes\nand\ncleans up the orphan (useless) records .
\nWe\nwill show how to compact, but we must, firstly, understand\nwhat\nhappens when editing the\ngeodatabase . <\/p>\n\n\n\n\n\n\n\n

When you delete\na record , obviously , you could think\nthat these records are,\nfinally,\ndeleted\nand that the sequence of records in the table go is taken to the next level to\nfill the hole . However , this is\nnot exactly what happens; these\nrecords\nare\nsimply\nmarked\nas\nbeing\ndeleted\nin\nthe geodatabase . If it were necessary to\nreset\nall\nthe records at each update the editing would take too much time.\nThis\nis why the software only marks the records as\ndeleted\nand\nignores these recordings in\nall\nfuture requests. So what happens\nwhen you try to locate a record ?\nThe\nprogram must browse all the\nrecords and, if the record is\nmarked as erased it\nadvances to the next , otherwise it checks whether it matches the request or not .
\nAlthough\nthey are deleted , they are ,\nin a way , the reason for the slowing down of the query. <\/p>\n\n\n\n

So how does the compacting\nexactly work? As you\nwill\nhave, already, guessed , compacting performs\nthe removal of these recordings and\nall\nthe others orphans who are not being used\nor\nreferenced\nby others objects . This is why\ncompacting speeds up geodatabases file and personal (access) queries. <\/p>\n\n\n\n

It’s easy to compact a geodatabase file\nor\naccess. It is recommended\nto compact a geodatabase after a heavy\nediting session.
\nTo\ncompact a geodatabase file or access,\nperform the following steps:
\n1.<\/strong> Open<\/strong> ArcCatalog and<\/strong> select<\/strong> the<\/strong>\ngeodatabase<\/strong> to compact.<\/strong>
\n2.<\/strong> Right-<\/strong> click<\/strong> to<\/strong> open<\/strong> the<\/strong>\ncontext<\/strong> menu<\/strong> ,<\/strong> select<\/strong> Administration,<\/strong> then<\/strong>\nclick<\/strong> Compact<\/strong> Geodatabase<\/strong>\n<\/p>\n\n\n\n

There are no counter indications for compacting .\nIt is somehow like the hard disk\ndefragmentation: it does not accelerate if it is\nnot necessary but it\ndoes not slow down the processing.
\nFor\nmore information, please visit the ArcGIs\nOnline Help(ESRI)<\/a> \n\nIn the following (and final) article\nwe will discuss how to perform the compacting and the geodatabases saving with\na single click\nby\nsetting up a processing model with Model Builder.\n\n\n\n<\/p>\n\n\n\n