The replica activity log

Whenever a replica creation or synchronization process is performed, whether it be connected or disconnected, information is added to a replica activity log. The information in the replica activity log is roughly equivalent to the information that is shown in the progress dialog box when a replica process is running.

The information in the log includes the following:

If any errors or warnings have occurred during a process, information on them will be stored in the replica activity log. This information can be viewed and used to retrieve errors from past processes and to find the operation that was executing when the error occurred.

The Time Completed column can be used to determine the time needed to perform each operation.

The log file is called ReplicaLog.dat and is found in the temp directory (as defined by the temp environment variable) of the machine on which the operation was executed. If using ArcGIS Server, the information is stored in the server activity log and can be accessed through the ArcGIS Server Manager.

By default, information from a replica process is appended to the existing replica activity log. You can change the behavior such that the file is overwritten for each new replica process by setting the Append= dword:1 registry key at the following location in the registry:

[HKEY_CURRENT_USER\SOFTWARE\ESRI\GeoDatabase\Replication\ReplicaLog]

A single replica process may involve more than one computer; therefore, information on the process could be divided between replica activity logs on two or more computers. For example, in a disconnected environment, changes are synchronized by exporting from a data sender and importing into a data receiver. In this case, the export changes information is logged on the computer where the export process took place, while the import changes information is logged on the computer where the import process was performed.

The replica activity log is different from the replica log that is provided for each replica from the replica manager in ArcCatalog and ArcMap. The replica log provided through the replica manager stores information in the geodatabase for synchronization events and includes error information if there are errors. It can be used to keep track of when changes have been sent and received and, like the activity log, it can also be used to retrieve error information. The error information in the activity log is more detailed, since it includes the operation that was executing when the error occurred.

Viewing the log

The contents of the ReplicaLog.dat file can be viewed directly in a text editor. However, the technical article HowTo: Get a formatted view of the ReplicaLog.dat file describes how to get a formatted view of the information in the log. The article can be found at support.esri.com.

The following is an example of a formatted replica activity log:

An example replica activity log

In this case, the activity log contains information about a single replica creation process. The top of the report indicates that there are 0 errors and 0 warnings within the log. The table describes the operations that occurred during the replica creation process as follows:

CheckOutMessage—A replica creation process was started for a replica named MyCheckOut_2 at 3:44:35 PM.

ExtractSchemaAndData—The first step was to extract the schema and data. Extraction involves creating feature classes and tables on the target, then copying data from the source to the target. This is outlined by the next entries in the log for each feature class and table in the replica.

CreateFeatureClass—In this example, only a single feature class, GDB.us_states_3, is being replicated. This row indicates that the feature class was created in the target at 3:44:36.

CopyData—A total of 54 features were copied from the source to the target for the us_states_3 feature class at 3:44:37. By comparing with the previous step, we can see that it took one second to copy the features.

Register CheckOut—The last step was to register the replica on the source and target geodatabases. From the time completed, we can see that it took less than one second to register the replicas.

Related Topics


1/5/2011