As a DBA, developer, and more importantly the creator of SQLWATCH.IO, I need the ability to rapidly deploy and test different SQL Server configurations or test different upgrade variations from one version of SQLWATCH to another. This is quite laborious, time-consuming tasks as I either have to build a new SQL Server instance of a specific configuration, collation etc or use snapshots which increases complexity and flexibility. Docker makes this very easy and quick. Introduction to Docker In a very simplified language, Docker is a container (sandbox) platform and it virtualises the Operating System. Container, however, is a packaged image of an application, in our case, this will be SQL Server. Images run in isolation and each can have different resource allocation i.e. different memory, CPU and disk space. Docker uses the internal network to allow containers to communicate with each other and with the external world. We can start and stop containers on demand. The main difference between running the application as Container vs natively installed is the isolation and lack of package dependencies. We could have two applications using let’s say different versions of Python in isolated containers. If both applications were natively installed, we would have to also install
I often help improve the performance of a SQL Server or an application. Performance metrics in SQL Server are exposed via Dynamic Management Views (DMVs). However, DMVs only provide a view of the current state and no history. This is important as it makes it particularly difficult to draw a bigger picture of how the system is behaving over time and what problems are occurring during overnight batch processing or during peak operational times, for example when users log in to the system at 8 am or when they leave for lunch at 1 pm. To address this deficiency I have built a simple yet comprehensive SQL Server Performance Dashboard in PowerBI.