Replaying Workloads to a different Database


One of the features I was asked to implement for WorkloadTools is the ability to replay commands to a database name different from the one recorded in the source workload.

This is something that I had been planning to implement for a while and it totally makes sense. Usually, you have two identical environments for the workload capture and replay, both with the same databases. Sometimes it makes sense to have two different databases as the source and target for the workload, for some particular reasons: resources constraints, ease of testing and so on.

WorkloadTools now supports replaying commands to a different database, using the DatabaseMap property of the ReplayConsumer.

DatabaseMap is a Dictionary of strings, so it can be expressed in the .json file as a key/value pair, where the key is the original database and the value is the new target database for the command.

Here is an example:

{
    "__type": "ReplayConsumer",
    "ConnectionInfo": {
        "ServerName": "somedatabase.database.windows.net",
        "DatabaseName": "mario",
        "UserName": "itsame",
        "Password": "itsamario"
    },
    "DatabaseMap": {
        "Mario": "Luigi",
        "Peach": "Bowser"
    }
}

In this case, whenever a command from the database “Mario” is found, it is replayed against the database “Luigi”. Similarly, when the database “Peach” is found, the command gets replayed on “Bowser”.

Please note that DatabaseMap only changes the database context and does not substitute any reference to the original database name in the code. For instance, if you had something like EXEC Mario.sys.sp_executesql 'SELECT 1' ,this would not be intercepted by DatabaseMap and would remain unchanged in your code.

Happy benchmarking with WorkladTools!

Posted on March 31, 2020, in SQL Server and tagged , . Bookmark the permalink. 9 Comments.

  1. It is possible to compare the responses too?

    In the sense: i have a the DB on an SQL 2008 – Server and the same DB on an SQL 2017 server and do an action in the enduser-application that sends the SQL-queries to SQLworkload and from there to the 2 DBs. The DBs returns their data to SQLworkload. SQLworkload builds a checksum of the returned data and writes an error in the logfile if the checksums are different…

    • Sorry, this is not one of the abilities of SQLWorkload, nor this is one of the intended features. You could easily fork WorkloadTools and add the feature, but I’m not really planning to add anything like this to the toolset right now.

    • Awesome job on adding the feature to replay to a different named database. It’s something that was on my wish list for Distributed Replay. I need to dedicate some time to try out your toolset.

  2. Thanks for your quick response!
    Unfortunately i am not a good coder, so i cannot enhance your great tool.

    One day i will try your tool for performance comparision, thanks for your work!

  3. Really a cool toolset!
    How much costs a developer certificate?

  4. Everything was working fine until I got the following error when I reply the workload. Is there something I can change on JSON file or target Server to avoid this error.

    error message
    Warn – WorkloadTools.Consumer.Replay.ReplayWorker : Worker [296] – Sequence[5324610] – Error: Execution Timeout Expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

    • Hey there! This error indicates a query timeout. The statement that generated the timeout is the one found in the source SQLite file in the events table with sequence_id = 5324610
      Hope this helps!

  1. Pingback: Replaying Workloads to a Different Database with WorkloadTools – Curated SQL

Leave a comment