ArcGIS Server Banner

Versioned tables in a geodatabase in Oracle

Versioned tables in a geodatabase in Oracle

Release 9.3 E-mail This TopicPrintable VersionGive Us feedback
Note:This topic was updated for 9.3.1.

An enterprise geodatabase must provide support for many users creating and updating large amounts of geographic information. Since many of those users may be required to edit the same data at the same time, a geodatabase must provide an editing environment that supports multiuser concurrent editing without creating multiple copies of the data. In providing this functionality, this editing environment must also support edit sessions that typically span a number of days; the facility to undo or redo changes made to the database; the testing and development of data models and alternative application design proposals without affecting the published database; and the facility to monitor how the data and database have evolved over time.

To meet these requirements, ArcSDE geodatabases can be versioned. To start, register feature datasets, stand-alone feature classes, and tables as versioned. Then create versions of the geodatabase in which to do your editing. These versions are virtual; copies of the geodatabase are not made. The versions are represented by delta tables associated with each versioned dataset and a few system tables to track version states.

For information on versions, see Understanding versioning.

Versioned datasets can also be involved in replicas or enabled for archiving. To help navigate to different subtopics on versioning, replication, and archiving in this topic, use the links below:

Versioned tables in ArcCatalog and ArcMap

Versioned tables in an Oracle DBMS

Versioned tables in an XML document

Replica tables

Replica tables in ArcCatalog and ArcMap

Replica tables in an Oracle DBMS

Replica tables in an XML document

Archiving tables

Archiving tables in ArcCatalog and ArcMap

Archiving tables in an Oracle DBMS

Archiving tables in an XML document

Versioned tables in ArcCatalog and ArcMap

In ArcCatalog, versioned datasets appear the same as unversioned datasets in the Catalog tree. You can find out if a feature class is versioned by opening the Feature Class Properties dialog box. On the General tab, it states whether or not the feature class is registered as versioned.

Additionally, if multiple geodatabase versions exist, you can make two separate spatial database connections—one to the DEFAULT version of the geodatabase and one to a different version of the geodatabase—preview a versioned dataset in DEFAULT and it may look different and contain more or fewer records than the same feature class previewed from the non-DEFAULT version. (To learn how to make a spatial database connection to a version other than DEFAULT, see Creating spatial database connections.)

The same is true in ArcMap. If you view a versioned feature class in one version in ArcMap, then view the feature class in another version in ArcMap, it may look different. That is because a table or feature class viewed in one version contains a certain number of rows, and the same table or feature class in another version may contain a different number of rows. For example, below is the HYDRANTS feature class in the DEFAULT version of the geodatabase in ArcMap:

Data in the DEFAULT version in ArcMap

When you switch to a different version of the geodatabase—version WO2557—the hydrants feature class contains two additional hydrants. This means two hydrants were added to the HYDRANTS feature class while editing with WO2557 as the source geodatabase version.

Data in the edited WO2257 version in ArcMap

This gives the impression that each version is a separate copy of the data. However, instead of creating a new copy of or modifying the original data, the geodatabase leaves the versioned table or feature class in its original form and stores any changes to that data in separate geodatabase system tables. The geodatabase tables that record version changes are referred to as the delta tables. For each table or feature class that has been versioned, two new delta tables—an adds (a) and a deletes (d) table—are created.

Versioned tables in an Oracle DBMS

Internally, versioning is managed by a number of DBMS tables: the dataset tables, version delta tables, and system tables to track versions.

A versioned database typically contains a number of versions, in addition to the DEFAULT version, that might represent a work order, design alternative, disconnected editing session, historical snapshot, and so on. The VERSIONS table contains a descriptive list of these versions with each version identified by a unique name and ID (IDs are automatically generated by ArcSDE). In addition, each version has an owner, description, parent version, associated database state, and level of user access.

When the VERSIONS table is created, the details of the DEFAULT version are automatically recorded in this table. The ArcSDE administrator owns the DEFAULT version, and the initial ID of the corresponding database state is set to 0. The description string reads Instance Default Version, and as the DEFAULT version has been granted Public access, any user can modify it. To support general connections to the geodatabase, the level of access to the DEFAULT version must remain either Public or Protected; if the access level is set to Private, only the ArcSDE administrator can connect to the database.

Versioned tables in an XML document

An entry in XML documents indicates whether or not a dataset is versioned. It is enclosed by Versioned tags. For a versioned dataset, the value will be true.

<Versioned>true</Versioned>

Tables used during replication

You can use geodatabase replication to create copies of data across two or more versioned geodatabases so that changes to the data may be synchronized. A synchronization involves one replica sending data changes and the relative replica receiving changes.

Before you create a two-way or one-way replica, you must add a global ID column to the datasets to be replicated. This gives the rows in the dataset a unique value that will remain constant across geodatabases. (For details on getting a dataset ready for replication, consult Preparing data for replication.)

After changes have been made in one of the replicas, you can synchronize the geodatabases, bringing the changes made in one geodatabase into its relative geodatabase. When a geodatabase is synchronized with its relative geodatabase, a table is created in the user's schema of the replica geodatabase (the one that is sending the changes to the relative geodatabase) to track the lineages of altered datasets.

Replica tables in ArcCatalog and ArcMap

You won't see the table used for synchronization in ArcCatalog or ArcMap; it is used behind the scenes and only during synchronization.

You can, however, identify if a geodatabase is being used as a replica geodatabase by checking its properties in ArcCatalog. Right-click the geodatabase and click Properties. On the General tab, there is a Distributed Geodatabase Status section. If the geodatabase has been replicated or replicated to, the status states, This is a replica geodatabase.

In ArcMap, you know when an MXD file contains one or more layers that have been replicated because most (or even all) of the tools on the Distributed Geodatabase toolbar are active. Also, when you open the Replica Manager, one or more replicas are listed.

Replica tables in an Oracle DBMS

Before datasets can be replicated, they must have a global ID column and be registered as fully versioned (not registered with the option to save edits to base). Therefore, in the database, the business tables of any datasets that will be included in the replication have a GUID column, and delta tables exist for each of these datasets. The following is a versioned feature class, Districts, that has a global ID column.

A versioned dataset with a global ID column

Replicas are tracked in the database using the following ArcSDE geodatabase system tables. Click the table names to link to their descriptions.

GDB_REPLICADATASETS

GDB_REPLICALOG

GDB_REPLICAS

GDB_REPLICASEX

The tables are related as follows:

Replication system tables in Oracle

When synchronization is performed between two geodatabases, the table that is created to track dataset lineages is the SDE_UUID_TEMP$ table. This table can be used by multiple sessions simultaneously. In Oracle, the SDE_UUID_TEMP$ table is created as a global temporary table. The description of this table is below.

SDE_UUID_TEMP$

The SDE_UUID_TEMP$ table is used to discover the lineage of a given object via its global ID value.


Field name Field type Description
REGISTRATION_ID NUMBER(38) The versioned table's registration ID from the TABLE_REGISTRY table
GLOBALID NCHAR(38) The global ID for the altered row in the business table of the versioned dataset

The following shows how one of the replicated datasets is related to the SDE_UUID_TEMP$ table:

Synchronizing one replicated dataset

The SDE_UUID_TEMP$ table is not removed when the session exits because the table will likely be reused in another session.

Replica tables in an XML document

If you choose to replicate to an XML document when you create your replica, information about the replica and replicated datasets are enclosed in <GPReplica> tags as shown below. In this example, the name of the replica is toagency, and it was replicated from geodatabase version PHASE1.

<GPReplica xsi:type="esri:GPReplica">
  <Name>manager.toagency</Name> 
  <ID>-1</ID> 
  <ReplicaVersion>sde.PHASE1</ReplicaVersion> 
  <CreationDate>2007-04-23T12:13:07</CreationDate> 
  <GUID>AFC2DA1A-B751-4096-82DE-7AC9E601A563</GUID> 
  <Role>esriReplicaRoleChild</Role> 
  <AccessType>esriReplicaChildReadOnly</AccessType> 
  <MyGenerationNumber>0</MyGenerationNumber> 
  <SibGenerationNumber>0</SibGenerationNumber> 
  <SibMyGenerationNumber>0</SibMyGenerationNumber> 
  <ReplicaState>esriReplicaStateWaitingForData</ReplicaState> 
  <SibConnectionString>SERVER=liljoe;INSTANCE=5151;VERSION=sde.PHASE1;AUTHENTICATION_MODE=DBMS;ProgID=esriDataSourcesGDB.SdeWorkspaceFactory.1</SibConnectionString> 
 <GPReplicaDescription xsi:type="esri:GPReplicaDescription">
  <ModelType>esriModelTypeFullGeodatabase</ModelType> 
  <SingleGeneration>false</SingleGeneration>
<SpatialRelation>esriSpatialRelIntersects</SpatialRelation> 
 <QueryGeometry xsi:type="esri:EnvelopeN">
  <XMin>-5543912.2421665</XMin> 
  <YMin>3741401.908035</YMin> 
  <XMax>-5538272.6904335</XMax> 
  <YMax>3743452.058665</YMax> 
 <SpatialReference xsi:type="esri:ProjectedCoordinateSystem">
  <WKT>PROJCS["Asia_South_Albers_Equal_Area_Conic",GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Albers"],PARAMETER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meridian",125.0],PARAMETER["Standard_Parallel_1",7.0],PARAMETER["Standard_Parallel_2",-32.0],PARAMETER["Latitude_Of_Origin",-15.0],UNIT["Meter",1.0]],VERTCS["Ha_Tien_1960",VDATUM["Ha_Tien_1960"],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0],UNIT["Meter",1.0]]</WKT> 
  <XOrigin>-21663300</XOrigin> 
  <YOrigin>-10280500</YOrigin> 
  <XYScale>207890747.363998</XYScale> 
  <ZOrigin>0</ZOrigin> 
  <ZScale>1</ZScale> 
  <MOrigin>-100000</MOrigin> 
  <MScale>10000</MScale> 
  <XYTolerance>0.001</XYTolerance> 
  <ZTolerance>2</ZTolerance> 
  <MTolerance>0.001</MTolerance> 
  <HighPrecision>true</HighPrecision> 
  </SpatialReference>
  </QueryGeometry>
<GPReplicaDatasets xsi:type="esri:ArrayOfGPReplicaDataset">
 <GPReplicaDataset xsi:type="esri:GPReplicaDataset">
  <DatasetName>projects.editor.roads</DatasetName> 
  <DatasetType>esriDTFeatureClass</DatasetType> 
  <RowsType>esriRowsTypeFilter</RowsType> 
  <IsPrivate>false</IsPrivate> 
  <UseGeometry>true</UseGeometry> 
  </GPReplicaDataset>

Other dataset definitions

 </GPReplicaDatasets>
  <TransferRelatedObjects>true</TransferRelatedObjects> 
  </GPReplicaDescription>
  <ReconcilePolicy>esriReplicaResolveConflictsNone</ReconcilePolicy> 
</GPReplica>

Tables used for archiving

Beginning with ArcGIS 9.2, you have the ability to track transaction-time history for your data using geodatabase archiving. Transaction time represents the moment in time when an event is represented in the database. It is delimited when the feature is inserted in the database, then modified or logically deleted. Tracking a dataset's history allows you to keep a record of when and how the data has changed. It also allows you to query previous versions of the data.

Archiving tables in ArcCatalog and ArcMap

To use geodatabase archiving, you register the data as fully versioned, then enable it for archiving in ArcCatalog. (For details on how to perform this operation, see Geodatabase archiving and its related topics.) You can tell if a dataset has already had archiving enabled if, when you right-click the dataset in ArcCatalog and click Archiving, the context menu has Disable Archiving enabled but Enable Archiving is disabled.

Archive classes cannot be viewed in ArcCatalog, but you can save a connection to a specific historical version through ArcCatalog. See the section "Connecting to a specific version of the database" in Creating spatial database connections and the topic Working with a historical version for instructions on how to do this. To help you view the changes made at specific times, you can create historical markers that can be used by others to view the state of the data at that specific time. For details on creating historical markers, see Working with historical markers.

Archiving tables in an Oracle DBMS

When a table is enabled for archiving, an archive class is created. This 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. For a description of how these fields are populated, see The archive process.

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 trails is enabled for archiving, an archive class, trails_H, is created in the schema of the owner of the feature class. The archive class table is read-only, stores changes saved or posted to the DEFAULT version of the geodatabase, and is not deleted if its corresponding dataset is unregistered as versioned or deleted. If an archived dataset is unversioned or deleted, the archive class is converted to a temporal table and can still be queried. See Working with the Geodatabase History Viewer for details on viewing different historical versions.

When changes are made to the schema of a dataset that is enabled for archiving—for example, if a field is added or deleted—these changes are automatically added to the corresponding archive class.

NOTE: Never directly alter the schema of an archive class.

Also, when a table is enabled for archiving, a record gets added to the SDE_ARCHIVES table. This record stores the registration IDs of the table that was enabled for archiving and its associated archive class table. For further information on the SDE_ARCHIVES table, see System tables of a geodatabase stored in Oracle.

The following shows a business table—TRAILS—enabled for archiving, its corresponding archive class table, and records in the SDE_ARCHIVES table.

Archive-enabled business table and associated system tables in Oracle

When you create historical markers to view the state of the data at a specific time, the GDB_HISTORICALMARKERS table is populated. For details on creating historical markers, see Working with historical markers.

Archiving tables in an XML document

Archive classes are not exported to XML workspace documents.