Whenever a replica creation or synchronization process is performed with ArcGIS for Desktop, whether it be connected or disconnected, detailed information about the process is recorded in a replica activity log. You can use this information to troubleshoot errors or to examine replica creation and synchronization performance.
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. This can include the following:
- ERRORS—Errors that occurred while running a process
- WARNINGS—How many warnings occurred while running a process
- Operation Name—The name of the process that was run
- Time Completed—The date and time when the process finished
- Operation Info—General information about the process
You can choose between five levels of detail to record, as well as where to create and update the log on your machine. You make these settings within ArcMap:
- In the Distributed Geodatabase toolbar, click Distributed Geodatabase.
- Click Options.
- Click the General tab.
- Specify the path and name to the replica activity log. If you go with the default, the log file is called ReplicaLog.dat and resides in the Application Data folder.
- Specify the log level.
- Click OK.
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 grows over time as information from each new replica process is appended to the file.
If you perform replication through ArcGIS for Server, the information is not recorded in the replica activity log. Instead it is recorded in the server activity log and can be accessed through the ArcGIS for Server Manager.
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:
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.