Note The "Maintain Trends database record" request is executed as part of a database move initiated due to resource balancing initiated by the Activity Trends tool.
Check access for move replica creation
Carried out on: The source server.
Carried out: Immediately
Result: The Administration Process checks that the administrator initiating the request has Manager with "Delete documents" access to the database being moved and that the destination server has Reader access to the database being moved.
Carried out on: The destination server (the server to which the database is being moved).
Result: The Administration Process checks that the administrator and the source server have Create Replica access to the destination server. If so, the Administration Process creates a replica. The replica is populated with documents the first time any server with the complete replica replicates with the destination server. If the Activity Trends tool is running on the source server, posts the administration request "Maintain Trends database record." If Activity Trends is not running on the source server, posts the administration request "Monitor replica stub."
This request is generated only when there is an agent on the source server that needs to be signed by the destination server prior to running the agent.
Carried out on: The destination server.
Result: If all access checks succeed, the agent is signed by the destination server and can be run according to normal processing.
Carried out on: The source server for the database being moved.
Result: Copies the database record from the source server to the destination server. If appropriate, it retires the database record on the source server.
Carried out: According to the "Interval" setting for the Administration Process in the Server document.
Result: The Administration Process monitors the replica. When it detects that the replica is initialized (another server has begun replicating to it), it posts a "Delete original replica after move" request.
Result: The Administration Process marks the original database for deletion. The Cluster Database Directory Manager on the source server then monitors the database for usage. When all user connections to the database have closed, the Cluster Database Directory Manager pushes changes to another replica in the cluster and deletes the database.