WorkloadTools Versions Save

Bug in a regex in SqlNormalizer

• Whoops! Corrected a bug in WorkloadSummary

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

Pre release 1.5.18

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.

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
            }
        ]
    }
}

Managed Instances want a totally different way of capturing CPU. Sigh.

WorkloadViewer now shows dates on the x axis when you are analyzing a workload. When comparing two workloads it shows the offset in minutes instead.

Thanks to @thed000d you can now configure the MaxPoolSize in a SqlConnectionInfo object. This property can be set in the .json configuration files.