A transaction is a logical operation between the Mirage server and the Mirage client. You can use the transaction log to monitor the progress of updates coming from and to the server.

Each transaction is built from a collection of sub-transactions, each representing a network session between the client and server. Sub-transactions are reported only when a session is either complete (succeeded) or terminated (failed due to a network disconnect or other specified reason).

Table 1. Transaction Types in the Transaction Log

Transaction Type

Description

Centralize Endpoint

First time upload of the end user machine to the server.

Upload Incremental Changes

Synchronizing ongoing changes from the end user machine to the server.

Update Base Layer

End user machine is updated with the assigned base layer

Update App Layer

End user machine is updated with the assigned app layer.

Base Layer Caching

The branch reflector downloads a base layer.

Base Layer Verification

Base layer download is verified prior to being applied.

Restore Prefetch

Client downloads the minimum file set required from the CVD to allow the endpoint to boot the restored CVD and allow network access to complete restore through background streaming.

Restore Streaming

Client streams the remainder of the restored CVD to the endpoint while the user works normally online.

Note:

More than one sub-transaction appears when one or more attempts to complete the parent transaction failed. The sub-transaction status reported is final and does not change.

Transaction Entry Properties

Table 2. Transaction Log Information for Each Entry

Parameter

Description

CVD

Number of the CVD

CVD Name

Name of the CVD

Type

Type of operation being performed, such as Centralize Endpoint or Upload Incremental Changes

Status

Status of the transaction, for example Success.

Layer

Base Layer ID and version, if applicable

Changed Files

Total number of changed files

Unique Files

Total number of files to be transferred, after duplicate files are eliminated

Size (MB)

Total Data size of the files to be transferred, after duplicate files are eliminated

Size After File Dedup (MB)

Data Size After Dedup, meaning the total size of file and metadata to be transferred after it is reduced by intra-file and inter-file block level deduplication, but before LZ compression

Size After Block Dedup (MB)

Before Compression size, which is the total network transfer as seen over WAN, before applying LZ compression

Data Transferred (MB)

The total network transfer that took place.

Branch Reflector Transfer (MB)

The amount of data that was sent from the branch reflector to the endpoint (instead of from the Mirage server directly to clients).

Savings

Transfer Savings, meaning the ratio of the total size of the changed files and actual transfer size

Start Time

Start time of the transaction

End Time

End time of the transaction

Duration

Duration of the transaction

Search and Filter Results Specification

Whenever a search or filter query is initiated in any list window, the first page of results appears in the view area. The number of pages of qualifying records appears under the Search text box and you can scroll to the next or previous page by clicking arrow icons. For improved query response time, when the number of records retrieved is very large, the associated page count is not calculated and is replaced by three dots (...).

Total Transaction Record Limits

The system implements transaction record limits to prevent log files from becoming too large:

Table 3. Transaction Record Limit by Record type

Transaction Record Type

Cleaned up after:

Steady State (SS) transactions

30 days

Layer transactions

180 days

All other transactions

365 days