When you connect to an enterprise geodatabase from an ArcGIS client or through an ArcGIS for Server web service, you interact with the datasets that you or other databases users have added to the geodatabase. To track that data and to implement geodatabase behavior, enterprise geodatabases use system tables.
The system tables and their contents should not be altered using anything other than ArcGIS software or SDK. However, you can view the contents of the system tables using SQL.
Core system tables
Core geodatabase system tables enforce geodatabase behavior, store information about the geodatabase, and keep track of the user data stored in the geodatabase.
When you query a Microsoft SQL Server database that contains an enterprise geodatabase, you'll see the following core system tables in either the sde user's schema or the dbo schema:
- SDE_compress_log—Created the first time you compress the geodatabase.
The following tables are present in the geodatabase but are no longer used. They may be removed in a future release.
Tables that implement enterprise geodatabase functionality
Information for some geodatabase functionality is stored in core system tables only. For example, information for the following functionality is stored in core system tables, and no additional tables are created in the database when you define or enable this functionality on user data:
- Domains—Stored in the GDB_ITEMS system table. A field in the GDB_ITEMTYPES system table identifies the object as a domain.
- Geodatabase replicas—Tracked in the database in the GDB_ITEMS, GDB_ITEMRELATIONSHIPS, GDB_ITEMTYPES, and GDB_REPLICALOG system tables.
- Relationship classes—Stored in the GDB_ITEMS and GDB_ITEMRELATIONSHIPS system tables.
The geodatabase functionality described in the following sections, however, creates additional internal tables when you enable or make use of the functionality.
You can track transaction time history for your data using geodatabase archiving. Transaction time represents the moment in time when the feature was added to, deleted from, or updated in the database.
When you enable geodatabase archiving, an archive class is created. An archive class is a copy of the business table and contains all the same fields plus three new fields: GDB_FROM_DATE, GDB_TO_DATE, and GDB_ARCHIVE_OID. When you enable archiving on a table or feature class that participates in a traditional version, a record is also added to the SDE_archives system table. This record stores the registration IDs of the table that was enabled for archiving and its associated archive class table.
The name of the archive class table is the same as the original business table name with an underscore and H appended to it. For example, if a feature class named buildings is enabled for archiving, an archive class, buildings_H, is created. This archive class table is stored in the same schema as the business table.
When you register a feature class or table to participate in traditional versions, two tables are created to track edits to the data: the adds table and the deletes table. Collectively, these are referred to as delta tables.
The adds table (a_<registration_id>) maintains information about each inserted or updated record (feature) in a versioned business table and is queried to identify which records have been added or modified at a particular geodatabase state.
The deletes table (d_<registration_id>) maintains information about the rows that were deleted or updated in a versioned table and is queried to identify which rows have been deleted or modified at a particular state. When a row is deleted, the record is not physically removed; it's flagged as deleted and never returned in subsequent database queries.
The registration_id in the adds table and deletes table names is the value for the versioned table in the SDE_table_registry system table.
These tables are created in the same user schema as the table or feature class that is registered as versioned.
In addition to the delta tables, the core system tables that track versioned tables and edits are the SDE_states, SDE_state_lineages, SDE_mvtables_modified, and SDE_versions tables.
Keyset tables are used by ArcGIS clients to improve query performance. Keyset tables store a list of selected rows when an ArcGIS client executes a geodatabase relationship query that joins tables using attributes that are type integer, number, date, or string. They accommodate joins using attributes other than the Object ID field.
No keyset tables are present in the geodatabase until you perform one of the following operations:
- Select more than 99 records from a feature class in a map in ArcGIS Pro or ArcMap, and the feature class is involved in a relationship class.
- In ArcGIS Pro or ArcMap, open the attribute table of a feature class that is involved in a relationship class and retrieve the related table.
- Begin an edit session in ArcMap.
One keyset table is created as a global temporary table per connection per session. Because it is a temporary table, the keyset table is deleted when the user disconnects from the geodatabase.
Keyset table names are formatted as follows:
<user_schema>.##keyset_<process_id>_sde, where <schema_name> is the schema of the user who caused the table to be created, and <process_id> is the process identification number of the user's session that caused the table's creation.
Log file tables
Log file tables are used by ArcGIS clients to improve query performance by storing lists of selected rows. Log file tables use joins based on Object ID attributes.
Geodatabases in SQL Server use session-based, local temporary tables for log file tables. Each client session that requires a log file table will have one dedicated log file table. The table name is SDE_session<sde_ID>, where <SDE_ID> is the unique session ID from the SDE_process_information table, and <DBID> is the database ID from SQL Server.