The intent of this post is a quick reference guide based on the recommendation made in “Architecting Microsoft SQL Server on VMware vSphere” April 2019 version. The target audience for this blog post is for SQL Server DBAs introducing them to the most impactful configurations and settings for running SQL Server in VMware.
For the explanations for each of these settings and how to configure the base VMware infrastructure, please read the “Architecting Microsoft SQL Server on VMware vSphere” guide and consult with your VMware administrators and experts.
This post will walk you through setting file permissions on database files copied into a container. The SQL Server process sqlservr running in containers runs as the non-privileged user mssql. The appropriate permissions on files are needed, so the SQL Server process has the proper access to any database files, log files, and backup files.
Start up a container First up, let’s start up a container. Here’s we’re starting up SQL Server 2019 CU11 and attaching a Docker data volume for our persistent data.
In this blog post, we will walk through a few examples of configuring SQL Server in Kubernetes. First, we will create a Deployment for SQL Server, override the container’s command, and specify a Database Engine Service Startup Option. Second, we will create a Deployment for SQL Server using a ConfigMap to inject an mssql.conf configuration file.
Creating a SQL Server Deployment and Overriding the Container’s Command and Arguments First up, let’s create a Deployment for SQL Server and override the container’s command specify a Database Engine Service Startup Option.
In this blog post, we will walk through a few examples of how to configure SQL Server in Docker Containers. First, we will configure a container at runtime by overriding the default docker command for the container and setting Database Engine Service Startup Options. Second, we’re going to inject a configuration file into our container to configure SQL Server. Let’s go!
Starting a Container with a Trace Flag First up, let’s configure a container at runtime using Database Engine Service Startup Options.
I’m super proud to announce that Ben E. Weissman and I have published SQL Server on Kubernetes – Designing and Building a Modern Data Platform available now at Apress and your favorite online book sellers! Buy the book now…or keep reading below if you need to be more convinced :)
A couple of notes about the book, I saw Kubernetes showcased at a Microsoft event a few years back. I immediately saw the value and dedicated time to learning how Kubernetes and SQL Server on Kubernetes works.
Limits in Containers Docker gives you the ability to control a container’s access to CPU, Memory, and network and disk IO using resource constraints, sometimes called Limits. You define limits as parameters when creating containers. In its default configuration, a container will have no resource constraints for accessing resources of the host operating system. This post will look at how to configure resource constraints in Docker and look at how SQL Server sees the resources when CPU and Memory resource constraints are in place.
I want to start by saying thank you to all who submitted, and an amazing collection of people submitted some fantastic content. Also, thanks to Steve for asking me to host and being patient with me for mixing up the dates and the hashtag. It’s #tsql2sday and it’s on Tuesday not Wednesday :P
Now, onto the posts in submission order.
Rob Farley – On containers
Rob discusses how he uses containers to quickly spin up SQL Server instances without installing them on his local OS, replacing the virtual machine-based environments he used in the past.
In recent years containers have come into the data platform world, exposing new technologies to data professionals. Microsoft put SQL Server in Linux, and shortly after that, SQL Server made its way into containers. SQL Server in Containers has become the foundation for things like Big Data Clusters and Azure Arc-enabled Data Services
My invitation to you for this month’s #tsql2sday is…
I want to invite you to share your experiences using containers and not just SQL Server in containers…
Recently I needed to take a look at all of the SQL Server Agent Jobs and their Jobs Steps for a customer. Specifically, I needed to review all of the Jobs and Job Steps for Ola Hallengren’s Maintenance Solution and look at the Backup, Index Maintenance and Integrity Jobs to ensure they’re configured properly and also account for any customizations and one-offs in the Job definitions. This customer has dozens of SQL Server instances and well, I wasn’t about to click through everything in SSMS…and writing this in TSQL would have been a good candidate for a Ph.
In this post, we will explore how a Pod name is generated, Pod Name lifecycle, how it’s used inside a Pod to set the system hostname, and how the system hostname is used by SQL Server to set its server name metadata.
Pod Naming in Deployments When deploying SQL Server in Kubernetes using a Deployment, the Pod created by the Deployment Controller will have a name with a structure of <DeploymentName>-<PodTemplateHash>-<PodID> for example, mssql-deployment-8cbdc8ddd-9n7jh.
