Replicating the audit log
It is optional whether the audit logs for the database and security file are replicated. The audit logs for the database and security data are replicated separately.
The audit logs are optionally replicated:
If the audit data for the database and security file is replicated, authorized users at any site can review all activities.
If the audit data for the database and security file is not replicated, the audit logs records activity for the local database and security file only. The main effect of this is incomplete information on how conflicts between entity and link records, and in the security data were resolved. For example, log entries for the Conflict Viewer are only recorded in the audit log for the publication database (if the audit level is set to 4 or 5).
Note: The dates and times that are shown in the audit log are local to the server on which the user was working.
Filtering the audit log for the database
In a replicated audit log, the best way of filtering the log entries for a specific site depends on how user names and locations are defined in your organization:
Filter by | Description |
|---|---|
User name | The user name might be a useful way of filtering the audit log if each user name contains an element to identify the site at which the user works. |
Network Login | If users are restricted to logging on to the database on the local server, then the network login can indicate the location of the user. |
Location | Locations can be a useful way of filtering the audit log if all user accounts have a location and that the location names are consistent. |
Note: Filtering by location does not identify the records, which a user owns (if you are using owner hyperlink fields), only those records that they create or update.
Viewing log entries for conflict resolution
There are two actions for the Conflict Viewer: Conflict Detected and Conflict Resolved. These are recorded if the audit level of the publication database is set to 4 or 5.
Two examples showing the audit trail for these actions are included in the following information.
Note: All dates and times for the Conflict Detected/Resolved records are the SQL Server date/time on the Publisher as conflicts are always detected and resolved in the publication database.
Viewing the audit log for the security file
In addition to the standard entries for non-replicated databases, the audit log for the security file records changes to group and user names that results from resolving duplicate names in the Security Manager.
The site to which a user belongs is identified by the name of the user that created it.
The site to which a group belongs is identified by the group ID which contains the database identifier.
The first site to create the user or group keeps that user or group with the permissions they defined. The user or group at the second site is treated as a duplicate and loses any defined permissions.
For example:
Date/time | User | Action | Detail |
|---|---|---|---|
09:35:09 | Sub1Admin | Create User | User SmithT created |
10:06:04 | PubAdmin | Create User | User SmithT created |
16:00:00 | Sub2Admin | Change User | User SmithT renamed to ***1*** (Note: The user Sub2Admin displayed the Security Manager which detected this duplicate and automatically renamed it.) |
17:05:06 | PubAdmin | Change User | User ***1*** renamed to 03SmithT (Note: The SmithT created by Sub1Admin is kept with permissions assigned by Sub1Admin. The other SmithT is treated as a duplicate and its permissions are ignored.) |
Archiving audit log files
You can archive audit log files in the usual way. It is not necessary to stop or disable replication to do this. However, notice that although the entries you delete are deleted from the audit log at all sites, the archive file is not replicated.
To make the archived entries available to all sites, you should load the archive file into the database by using the replication File Manager.