1.7.1

What's Changed

• Fix #115 WorkloadViewer shows queries twice by @Silent1984 in #147

Full Changelog: v1.7.0...v1.7.1

v1.7.0

What's Changed

• Performance Improvement by @a-teece in #142
• Fix #139 - Incorrect application name in replays by @a-teece in #143
• Fix #144 StreamXEventDataReader should never stop reading Events unle… by @Silent1984 in #145

New Contributors

• @Silent1984 made their first contribution in #145

Full Changelog: v.1.6.5...v1.7.0

v1.6.5

• Many performance and replay enhancements by @a-teece.
• New setup build for msi and exe.

Regex are sorcery

Bug in a regex in SqlNormalizer

The future is flawed

• Whoops! Corrected a bug in WorkloadSummary

Back to the Future

Incorporating many changes from @mcflyamorim (thanks man!)

• Use sp_reset_connection RPC events to control connection pooling

• Login event is also captured by default to be able to identify physical (non-pooled) connections and properly close/refresh the connection.
  This improvement should reduce the number of failed events in a replay.

• Capture sql_batch_starting and rpc_starting commands to be able to run the commands in the correct order and preserve executions that may take more time than the workload record.

• Some commands may not be possible to replay, hence they are skipped. An example is the insert bulk command.

• Adds the ability to record a WorkloadSummary in addition to WorkloadDetails. Writing data to each table can be controlled with the properties WriteDetail and WriteSummary in AnalysisConsumer

Long time no see

Pre release 1.5.18

You can dust it off and try again

The replay consumer now supports two properties to retry the same command multiple times when it times out (maybe it's just some cold cache, give it another go) or fails for any other reason.

• FailRetryCount
• TimeoutRetryCount

Set this to a any positive number to retry the command that many times.

Serial Killer

SqlWorkload can now replay workloads in Serial mode: all the events can be executed on a single thread.
This is particularly useful when replaying a workload to catpure regressions in migration projects: you're not really interested in mimicking the source workload closely, but all that you want is that all queries are run against the target SQL Server, so that you can capture the execution plans with Query Store and the execution statistics with WorkloadTools.
The property that controls this behavior is ReplayConsumer.ThreadingMode and it accepts 4 possible values:

• 1 - ThreadPools
• 2 - Tasks
• 3 - WorkerTask
• 4 - Serial

The default is 3 (WorkerTask), but you can use the other multithreaded implementations if you prefer, even if they are not as stable as the WorkerTask. If you want to use a single threaded implementation you can use 4 (Serial).

This makes sense when working with a FileWorkloadListener, but it makes no sense when working with the other listeners, especially for a real-time replay. You also probalby want to disable SynchronizationMode in the file listener.

Example:

{
    "Controller": {

        "Listener":
        {
            "__type": "FileWorkloadListener",
            "Source": "c:\\temp\\capture.sqlite",
            "SynchronizationMode": false // you probably want to disable synchronization mode in this case
        },

        "Consumers":
        [
            {
                "__type": "ReplayConsumer",
                "ConnectionInfo": 
                {
                    "ServerName": "(local)",
                    "DatabaseName": "test"
                },
                "ThreadingMode": 4 // Serial synchronization
            }
        ]
    }
}

v1.5.15

untagged-b00a07e50f59f28b07a4

Update README.md