ArcGIS Compress, Compact, and Analyze commands

ArcGIS Compress, Compact, and Analyze commands

(From http://www.gisall.com/html/19/121719-3167.html)

There are two types of ArcGIS Compress commands: one is the compression command for ArcSDE data and the other is the compression command for FileGDB data.

 

Compress usage of ArcSDE data

Usage analogy of the following commands

1: ArcCatalogMethod.

1. In ArcCatalog, click the View menu, point to Toolbars, and click Customize.

2. Check Context Menus in the toolbars list.

3. Click the Context Menus menu.

4. Click the arrow next to the Remote Database Context Menu.

5. Click the Commands tab in the Custom dialog box.

6. Click Geodatabase tools.

7. Click and drag the Compress Database command from the Commands list to the sub-Menu of the Remote Database Context Menu.

This command appears in the pop-up menu.

8. Click the Close button in the Custom dialog box.

2: ArcToolboxMethod

Database-Compress

3: Code Method

IVersionedWorkspace. Compress

4: Command Line

Compress_management 'database Connections \ Connection to deerfoot. sde'

5: Script language

Import arcgisscripting

Gp = arcgisscripting. create ()

Gp. toolbox = "management"

Gp. compress ("Database Connections \ Connection to deerfoot. sde"

 

6: SDECommand

Sdeversion-o compress [-N]

[-U <DB_user_name>] [-p <DB_User_password>] [-q]

[-I <service>] [-s <server_name>] [-D <database>]

 

Brief Introduction to version principles

Use the ArcGIS version to manage and register the version (without the option to move edits to base) A group of Delta tables are generated for A certain element class (Table A is added to table A and table D is deleted). The data editing information is actually recorded in the Delta table, then, the edit status is recorded in the States table in the SDE metadatabase. The State_lineages table records the horizontal changes of one element. State_ID is used to associate these tables. However, during the operation, the user will coordinate and submit multiple times, and delete the sub-version if the sub-version does not submit the Default version, these will generate a large amount of redundant or invalid data in the database. If the time is accumulated, the query and analysis efficiency of the data will be low.

Applicability

Use ArcGIS version principles to manage SDE databases and frequently edit (add, delete, and modify) data)

Preparation before compression

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> coordinates and submits versions as much as possible based on work requirements.

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> delete a coordinated version

The Compress command can also be executed without versioning, submission, and deletion, but the compression efficiency may not be obvious.

Compression target

1: Delete unreferenced status and redundant data (States)

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> operation status of a version after it is deleted

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> duplicate version coordination and submission status.

Reduce storage space

2: transfer data from all versions of the Delta table to the Base table (without the option to move edits to base)

Reduce retrieval time

Compression recommendations

We recommend that you regularly compress version data. If the accumulated time is too long and the data volume is huge, the compression time will also be extended.

Compression considerations

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> only the ArcSDE administrator can perform Compress operations and cannot Compress data of other users.

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> once the database is compressed, the deleted data cannot be restored.

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> after compressing the database, we recommend that you use the Analyze tool for database statistics to accelerate the display and query performance.

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> the user can connect to the file during compression. However, if a user edits the file, the file is locked and does not participate in compression.

 

 

The Compress data type of FGDB data

Supported: Geodatabase, dataset, element class, common table, etc.

Semi-support: Raster Dataset and Raster Catalog can be implemented using the GP Tool.

Unsupported: Schematic, Cadastral fabric, and Survey dataset

Application Scope

Mature data (data that does not need to be edited frequently)

Compression Principle

Compress data into Read-Only format

 

Compression Effect

Reduces the storage space of files.

It can be seen that the query and display performance has been slightly improved, but other operations have slowed down.

Compression restrictions

The compressed data cannot be edited.

Editable: Element Class Name (alias), attribute index, and metadata

Compression description

Compress to lossless without any loss of information

Compression basis

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> mean of element points in element classes

<! -- [If! SupportLists] --> n <! -- [Endif] --> point and simple line have a compression ratio higher than that of multiple points.

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> Field Type

<! -- [If! SupportLists] --> n <! -- [Endif] --> the compression ratio of text, integer, and date types is higher than that of floating point and Double Precision types.

<! -- [If! SupportLists] --> Ø <! -- [Endif] --> resolution (resolution)

<! -- [If! SupportLists] --> n <! -- [Endif] --> high resolution compression ratio higher than low resolution

Compression notes

The compressed data can be created, copied, and pasted. Then the data will include the mixed state of compressed data and uncompressed data. However, to edit the data, decompress the data again.

If one side of the compressed link class cannot be edited. A topology can be created in a hybrid state, but only for uncompressed data.

 

 

Compacting file and personal geodatabases

When the data is loaded to FGDB or PGDB for the first time, the records in the file are arranged in sequence. However, if you delete or add elements in the future, there will be no order of records in the file, there will be a lot of available space, which will increase the space for file storage, making data access very slow.

Function

Compacting sorts and sorts file records to reduce storage space.

Range

If data is often added or deleted, Compact must be implemented on a regular basis, which can reduce the file size and increase the access speed.

Note:

Compact is not supported if data is exclusive.

Analyze Applicability

Dataset

Business table, element table, A table, D table, history table, and grid table

Separate Table Analysis Using Arctoolbox

Analysis Principle

Update the statistical information of tables and the index statistics of these tables

Applicability

Operations such as data loading, data deletion, data update, and Data Compression

Purpose

Improve the efficiency of database search and query

Others

If the element dataset contains a ry network, the table of the network is also updated.

 

Reresearch on ArcSDE version compression (Compress)

(The following is transferred from http://blog.csdn.net/linghe301/article/details/6399036)

My colleagues studied the version and discussed the ArcSDE version compression over the past two days. This version is very simple. Isn't it just the following Compress?

But it's such a simple question. I have also studied related things and there are so many unknown secrets ......

=========================== Version compression principles ======================

Over time, after multiple edits to a geographical database, the incremental table increases and the number of statuses increases. The larger the table is and the more states it has, the more data that ArcGIS must process each time a version is displayed or queried. Therefore, the maximum impact on performance is not the number of versions, but the number of changes included in the incremental table of each version. Therefore, different versions may have different query response times.

Principles of the version: http://wenku.baidu.com/view/7ad2ec7d27284b73f24250fe.html

As described above, we will form a very complex table relationship during the ArcSDE version editing process, therefore, it is necessary to associate these complex table relationships for query or analysis to obtain relevant results. However, after the version is edited, in fact, when the sub-version data has been submitted to the Default version, the sub-version information (mainly including the relevant editing status has no effect), but if the information exists, this information will still be filtered when querying or analyzing data, which will result in lower efficiency after a long time of version editing.

Version compression is performed only by the ArcSDE Administrator (sde Or dbo user)

1: it removes the unreferenced status and its associated incremental table rows.

2: it will move the incremental table entries shared by all versions to the base table, which can reduce the amount of data to be searched by the database each time the version is queried, this improves query performance and reduces system response time.

During use, compression is often unable to be performed. The incremental table data is not moved to the base table or the invalid status table information is not deleted.

So what is the problem?

1: During the compression process, you can maintain a connection with the geographical database. If a user is editing a version, the branch in this status will be locked and will not participate in the compression process. Therefore, it is best to disconnect all users from the geographic database before starting compression to ensure that the entire status tree can be compressed. You do not need to disconnect a read-only SESSION (for example, an ArcIMS session ).

2: A sub-version exists in the database.

This sub-version includes the sub-version created by ArcGIS version management and the version created during synchronization replication (this makes the test very depressing because it is not well estimated ), in fact, the SDE user's Versions table can only have one record, that is, the default version record.

= =

To sum up, if you want to perform Full compression, you need to do the following:

1: ensure that other users except SDE are disconnected from the database.

2: All Sub-version data is submitted to the default version.

3: delete all sub-version data (note the version information created by synchronous replication)

4: delete all lock information or restart the ArcSDE service.

=

1: We recommend that you arrange the compression Frequency Based on your edits.

Users can view the status table information, especially the habit of compressing the data every day. It is strictly prohibited to see that there are tens of millions of Status values in the database, which is too slow to compress, it can only be a few days and nights of stress. Maybe I will report an error to you, and it's too late.

2: If the computer needs to execute other tasks while waiting for the compression operation to complete, you can end the compression operation at any time. This will not cause Database Inconsistency. You can continue the compression later.

3: before and after compression, it is very important to update the statistical data of each versioning element class and table in the geographic database. After you edit and compress the database, the database statistics are no longer accurate. This will adversely affect the query performance.