Configurar e personalizar contêineres do SQL Server no Linux

Aplica-se a:SQL Server no Linux

Este artigo explica como você pode configurar e personalizar contêineres do SQL Server no Linux usando o Docker. Você pode persistir seus dados, mover arquivos de contêineres e para contêineres e mudar configurações padrão.

Criar um contêiner personalizado

Você pode criar seu próprio Dockerfile para criar um contêiner personalizado do SQL Server. Para obter mais informações, confira uma demonstração que combina o SQL Server com um aplicativo do Node. Se você criar seu próprio Dockerfile, esteja ciente do processo em primeiro plano, pois esse processo controla a vida útil do contêiner. Se ele for encerrado, o contêiner será desligado. Por exemplo, se você quiser executar um script e iniciar o SQL Server, verifique se o processo do SQL Server é o comando mais à direita. Todos os outros comandos são executados em segundo plano. O comando a seguir ilustra isso dentro de um Dockerfile:

/usr/src/app/do-my-sql-commands.sh & /opt/mssql/bin/sqlservr

Se você inverter os comandos no exemplo anterior, o contêiner será desligado quando o script do-my-sql-commands.sh tiver sido concluído.

Manter seus dados

Sua configuração do SQL Server muda e os arquivos de banco de dados são mantidos no contêiner mesmo que você reinicie o contêiner com docker stop e docker start. No entanto, se você remover o contêiner com docker rm, tudo no contêiner será excluído, incluindo o SQL Server e seus bancos de dados. A seção a seguir explica como usar volumes de dados para persistir seus arquivos de banco de dados mesmo que os contêineres associados sejam excluídos.

Montar um diretório de host como volume de dados

A primeira opção é montar um diretório em seu host como um volume de dados em seu contêiner. Para fazer isso, use o comando docker run com a flag -v <host directory>:/var/opt/mssql, onde <host directory> é qualquer caminho especificado. Por exemplo: C:\SQL no Windows ou ~/sqlvolumes no Linux. Isso permite que os dados sejam restaurados entre as execuções do contêiner.

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 \
-v <host directory>/data:/var/opt/mssql/data \
-v <host directory>/log:/var/opt/mssql/log \
-v <host directory>/secrets:/var/opt/mssql/secrets \
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 `
-v <host directory>/data:/var/opt/mssql/data `
-v <host directory>/log:/var/opt/mssql/log `
-v <host directory>/secrets:/var/opt/mssql/secrets `
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 ^
-v <host directory>/data:/var/opt/mssql/data ^
-v <host directory>/log:/var/opt/mssql/log ^
-v <host directory>/secrets:/var/opt/mssql/secrets ^
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 \
-v <host directory>/data:/var/opt/mssql/data \
-v <host directory>/log:/var/opt/mssql/log \
-v <host directory>/secrets:/var/opt/mssql/secrets \
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 `
-v <host directory>/data:/var/opt/mssql/data `
-v <host directory>/log:/var/opt/mssql/log `
-v <host directory>/secrets:/var/opt/mssql/secrets `
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 ^
-v <host directory>/data:/var/opt/mssql/data ^
-v <host directory>/log:/var/opt/mssql/log ^
-v <host directory>/secrets:/var/opt/mssql/secrets ^
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 \
-v <host directory>/data:/var/opt/mssql/data \
-v <host directory>/log:/var/opt/mssql/log \
-v <host directory>/secrets:/var/opt/mssql/secrets \
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 `
-v <host directory>/data:/var/opt/mssql/data `
-v <host directory>/log:/var/opt/mssql/log `
-v <host directory>/secrets:/var/opt/mssql/secrets `
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 ^
-v <host directory>/data:/var/opt/mssql/data ^
-v <host directory>/log:/var/opt/mssql/log ^
-v <host directory>/secrets:/var/opt/mssql/secrets ^
-d mcr.microsoft.com/mssql/server:2022-latest

Essa técnica também permite que você compartilhe e exiba os arquivos no host fora do Docker.

Usar contêineres de volume de dados

A segunda opção é usar um contêiner de volume de dados. Você pode criar um contêiner de volume de dados especificando um nome de volume, em vez de um diretório de host com o parâmetro -v. O exemplo a seguir cria um volume de dados compartilhado denominado sqlvolume.

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 \
-v sqlvolume:/var/opt/mssql \
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 `
-v sqlvolume:/var/opt/mssql `
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 ^
-v sqlvolume:/var/opt/mssql ^
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 \
-v sqlvolume:/var/opt/mssql \
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 `
-v sqlvolume:/var/opt/mssql `
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 ^
-v sqlvolume:/var/opt/mssql ^
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 \
-v sqlvolume:/var/opt/mssql \
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 `
-v sqlvolume:/var/opt/mssql `
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 ^
-v sqlvolume:/var/opt/mssql ^
-d mcr.microsoft.com/mssql/server:2022-latest

Essa técnica para criar implicitamente um volume de dados no comando executar não funciona com versões mais antigas do Docker. Nesse caso, use as etapas explícitas descritas na documentação do Docker, Como criar e montar um contêiner de volume de dados.

Mesmo que você pare e remova esse contêiner, o volume de dados persiste. Você pode exibi-lo com o comando docker volume ls.

docker volume ls

Se você criar outro contêiner com o mesmo nome de volume, o novo contêiner usará os mesmos dados do SQL Server contidos no volume.

Para remover um contêiner de volume de dados, use o comando docker volume rm.

Backup e restauração

Além dessas técnicas de contêiner, você também pode usar as técnicas padrão de backup e restauração do SQL Server. Você pode usar arquivos de backup para proteger seus dados ou mover os dados para outra instância do SQL Server. Para obter mais informações, confira Fazer backup e restauração de bancos de dados do SQL Server no Linux.

Habilitar backup e restauração de VDI em contêineres

As operações de backup e restauração da VDI (Interface de Dispositivo Virtual) agora são compatíveis com implantações de contêiner do SQL Server desde a CU15 para SQL Server 2019 (15.x) e a CU28 para SQL Server 2017 (14.x). Siga estas etapas para habilitar restaurações ou backup baseado em VDI para contêineres do SQL Server:

1. Ao implantar contêineres do SQL Server, use a opção --shm-size. Para começar, defina o dimensionamento como 1 GB, conforme mostrado no comando a seguir. Substitua <password> por uma senha válida.

   docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" \
   --shm-size 1g \
   -p 1433:1433 \
   --name sql19 \
   --hostname sql19 \
   -d mcr.microsoft.com/mssql/server:2019-latest
   

   A opção --shm-size permite que você configure o tamanho do diretório de memória compartilhada (/dev/shm) dentro do contêiner, que é definido como 64 MB por padrão. Esse tamanho padrão da memória compartilhada não é suficiente para dar suporte a backups de VDI. Recomendamos que você configure para um mínimo de 1 GB ao implantar contêineres do SQL Server e deseja dar suporte a backups de VDI.

2. Você também deve habilitar o novo parâmetro memory.enablecontainersharedmemory em mssql.conf dentro do contêiner. Você pode montar mssql.conf na implantação do contêiner usando a opção -v, conforme descrito na seção Persistir seus dados, ou depois de implantar o contêiner ao atualizar manualmente mssql.conf dentro do contêiner. Veja um arquivo de exemplo mssql.conf com a configuração memory.enablecontainersharedmemory definida como true.

   [memory]
   enablecontainersharedmemory = true
   

Copiar arquivos de um contêiner

Para copiar um arquivo do contêiner, use o seguinte comando:

docker cp <Container ID>:<Container path> <host path>

Obtenha a ID do contêiner executando o comando docker ps -a.

Exemplo:

docker cp d6b75213ef80:/var/opt/mssql/log/errorlog /tmp/errorlog

docker cp d6b75213ef80:/var/opt/mssql/log/errorlog C:\Temp\errorlog

docker cp d6b75213ef80:/var/opt/mssql/log/errorlog C:\Temp\errorlog

Copiar arquivos para um contêiner

Para copiar um arquivo para o contêiner, use o seguinte comando:

docker cp <Host path> <Container ID>:<Container path>

Exemplo:

docker cp /tmp/mydb.mdf d6b75213ef80:/var/opt/mssql/data

docker cp C:\Temp\mydb.mdf d6b75213ef80:/var/opt/mssql/data

docker cp C:\Temp\mydb.mdf d6b75213ef80:/var/opt/mssql/data

Configurar o fuso horário

Para executar o SQL Server em um contêiner do Linux com um fuso horário específico, configure a TZ variável de ambiente (consulte Configurar o fuso horário para o SQL Server 2022 e versões posteriores no Linux para obter mais informações). Para localizar o valor de fuso horário correto, execute o comando tzselect de um prompt de Bash do Linux:

tzselect

Depois de selecionar o fuso horário, o tzselect exibe uma saída semelhante ao seguinte exemplo:

The following information has been given:

    United States
    Pacific

Therefore TZ='America/Los_Angeles' will be used.

Você pode usar essas informações para definir a mesma variável de ambiente em seu contêiner do Linux. O exemplo a seguir mostra como executar o SQL Server em um contêiner no fuso horário Americas/Los_Angeles:

sudo docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 --name sql1 \
-e 'TZ=America/Los_Angeles' \
-d mcr.microsoft.com/mssql/server:2017-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 --name sql1 `
-e "TZ=America/Los_Angeles" `
-d mcr.microsoft.com/mssql/server:2017-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 --name sql1 ^
-e "TZ=America/Los_Angeles" ^
-d mcr.microsoft.com/mssql/server:2017-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 --name sql1 \
-e 'TZ=America/Los_Angeles' \
-d mcr.microsoft.com/mssql/server:2019-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 --name sql1 `
-e "TZ=America/Los_Angeles" `
-d mcr.microsoft.com/mssql/server:2019-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 --name sql1 `
-e "TZ=America/Los_Angeles" `
-d mcr.microsoft.com/mssql/server:2019-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 --name sql1 \
-e 'TZ=America/Los_Angeles' \
-d mcr.microsoft.com/mssql/server:2022-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 --name sql1 `
-e "TZ=America/Los_Angeles" `
-d mcr.microsoft.com/mssql/server:2022-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 --name sql1 ^
-e "TZ=America/Los_Angeles" ^
-d mcr.microsoft.com/mssql/server:2022-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-p 1433:1433 --name sql1 \
-e 'TZ=America/Los_Angeles' \
-d mcr.microsoft.com/mssql/server:2025-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-p 1433:1433 --name sql1 `
-e "TZ=America/Los_Angeles" `
-d mcr.microsoft.com/mssql/server:2025-latest

sudo docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" ^
-p 1433:1433 --name sql1 ^
-e "TZ=America/Los_Angeles" ^
-d mcr.microsoft.com/mssql/server:2025-latest

Alterar o caminho tempdb

É uma boa prática manter seu banco de dados tempdb separado dos bancos de dados de usuário.

1. Conecte-se à instância do SQL Server e execute o script T-SQL (Transact-SQL) a seguir. Se houver mais arquivos associados a tempdb, você também precisará movê-los.

   ALTER DATABASE tempdb
       MODIFY FILE (NAME = tempdev, FILENAME = '/var/opt/mssql/tempdb/tempdb.mdf');
   GO
   
   ALTER DATABASE tempdb
       MODIFY FILE (NAME = templog, FILENAME = '/var/opt/mssql/tempdb/templog.ldf');
   GO
   

2. Usando o seguinte script T-SQL, verifique se o local do arquivo tempdb foi modificado:

   SELECT *
   FROM sys.sysaltfiles
   WHERE dbid = 2;
   

3. Você precisa reiniciar o contêiner do SQL Server para que essas alterações entrem em vigor.

   docker stop sql1
   docker start sql1
   

   docker stop sql1
   docker start sql1
   

   docker stop sql1
   docker start sql1
   

4. Abra uma sessão interativa bash para se conectar ao contêiner.

   docker exec -it sql1 bash
   

   docker exec -it sql1 bash
   

   docker exec -it sql1 bash
   

   Depois de conectado ao shell interativo, execute o seguinte comando para verificar o local de tempdb:

   ls /var/opt/mssql/tempdb/
   

   Se a movimentação tiver sido bem-sucedida, você verá uma saída semelhante à seguinte:

   tempdb.mdf templog.ldf
   

Alterar a localização do arquivo padrão

Adicione a variável MSSQL_DATA_DIR para alterar o diretório de dados em seu comando docker run e monte um volume nessa localização à qual o usuário do contêiner tem acesso.

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-e 'MSSQL_DATA_DIR=/my/file/path' \
-v /my/host/path:/my/file/path \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-e "MSSQL_DATA_DIR=/my/file/path" `
-v /my/host/path:/my/file/path `
-p 1433:1433 `
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-e "MSSQL_DATA_DIR=/my/file/path" ^
-v /my/host/path:/my/file/path ^
-p 1433:1433 ^
-d mcr.microsoft.com/mssql/server:2017-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-e 'MSSQL_DATA_DIR=/my/file/path' \
-v /my/host/path:/my/file/path \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-e "MSSQL_DATA_DIR=/my/file/path" `
-v /my/host/path:/my/file/path `
-p 1433:1433 `
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-e "MSSQL_DATA_DIR=/my/file/path" ^
-v /my/host/path:/my/file/path ^
-p 1433:1433 ^
-d mcr.microsoft.com/mssql/server:2019-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-e 'MSSQL_DATA_DIR=/my/file/path' \
-v /my/host/path:/my/file/path \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-e "MSSQL_DATA_DIR=/my/file/path" `
-v /my/host/path:/my/file/path `
-p 1433:1433 `
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-e "MSSQL_DATA_DIR=/my/file/path" ^
-v /my/host/path:/my/file/path ^
-p 1433:1433 ^
-d mcr.microsoft.com/mssql/server:2022-latest

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=<password>' \
-e 'MSSQL_DATA_DIR=/my/file/path' \
-v /my/host/path:/my/file/path \
-p 1433:1433 \
-d mcr.microsoft.com/mssql/server:2025-latest

docker run -e 'ACCEPT_EULA=Y' -e "MSSQL_SA_PASSWORD=<password>" `
-e "MSSQL_DATA_DIR=/my/file/path" `
-v /my/host/path:/my/file/path `
-p 1433:1433 `
-d mcr.microsoft.com/mssql/server:2025-latest

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<password>" ^
-e "MSSQL_DATA_DIR=/my/file/path" ^
-v /my/host/path:/my/file/path ^
-p 1433:1433 ^
-d mcr.microsoft.com/mssql/server:2025-latest

Usar mssql-config para configurar o SQL Server dentro de um contêiner

Você pode usar a ferramenta mssql-conf para definir parâmetros em contêineres do SQL Server.

Por exemplo, você pode definir um limite de memória para a instância usando as seguintes etapas:

1. Conecte-se diretamente ao contêiner usando docker exec como usuário raiz. Substitua sqlcontainer pelo nome do contêiner.

   docker exec -u root -it sqlcontainer "bash"
   

2. Use mssql-conf para mudar uma configuração. Este exemplo muda a configuração memory.memorylimitmb para 2 GB (2.048 MB).

   /opt/mssql/bin/mssql-conf set memory.memorylimitmb 2048
   

Exemplos de contêineres do Docker personalizados

Para obter exemplos de contêineres personalizados do Docker, confira https://github.com/microsoft/mssql-docker/tree/master/linux/preview/examples. Os exemplos incluem:

• Exemplo de Dockerfile com Pesquisa de Texto Completo
• Exemplo de Dockerfile para RHEL 7 e SQL Server 2019
• Exemplo de Dockerfile para RHEL 8 e SQL Server 2017
• Exemplo de Dockerfile para Ubuntu 20.04 e SQL Server 2019 com Pesquisa de Texto Completo, PolyBase e Tools

Para obter informações sobre como criar e executar contêineres do Docker usando Dockerfiles, confira os exemplos de serviços de ML no GitHub.

Suporte ao grupo de controle (cgroup) v2

SQL Server detecta e respeita as restrições do grupo de controle (cgroup) v2, começando com SQL Server 2025 (17.x) e SQL Server 2022 (16.x) Atualização Cumulativa (CU) 20. Essas restrições fornecem controle refinado no kernel do Linux sobre recursos de CPU e memória e melhoram o isolamento de recursos em ambientes docker, Kubernetes e OpenShift.

Em versões anteriores, implantações em contêineres em clusters do Kubernetes (por exemplo, Azure Kubernetes Service v1.25+) poderiam sofrer erros de falta de memória (OOM) porque o SQL Server não impôs os limites de memória definidos nas especificações do contêiner. O suporte para cgroup v2 resolve esse problema.

Verificar a versão do cgroup

stat -fc %T /sys/fs/cgroup

Os resultados são os seguintes:

Alternar para cgroup v2

O caminho mais fácil é escolher uma distribuição que dê suporte ao cgroup v2 pronto para utilização.

Se você precisar alternar manualmente, adicione o seguinte parâmetro à configuração do GRUB:

systemd.unified_cgroup_hierarchy=1

Em seguida, atualize o GRUB. Por exemplo, no Ubuntu, execute:

sudo update-grub

No RHEL (o Red Hat Enterprise Linux), execute:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Relatórios de limite de CPU com o cgroup v2

Quando você configura os limites de CPU usando o cgroup v2, SQL Server não mostra a contagem de núcleos de CPU configurada no log de erros. Em vez disso, ele continua a relatar o número total de CPUs de host.

Para alinhar o agendador do SQL Server e os planos de consulta, por exemplo, decisões de paralelismo, com a contagem de CPU prevista definida no cgroup v2, aplique a configuração a seguir.

Configurar afinidade de processador

Defina explicitamente a afinidade de processador do SQL Server de acordo com a cota de execução do cgroup. No exemplo a seguir, a cota de cgroup é de quatro CPUs em um host de oito núcleos:

ALTER SERVER CONFIGURATION
SET PROCESS AFFINITY CPU = 0 TO 3;

Essa configuração garante que SQL Server crie agendadores apenas para o número pretendido de CPUs. Para obter mais informações, consulte ALTER SERVER CONFIGURATION e Use PROCESS AFFINITY for Node and/or CPUs.

Habilitar o sinalizador de rastreamento 8002 (recomendado)

Habilite o sinalizador de rastreamento 8002 para usar afinidade flexível na camada SQLPAL:

sudo /opt/mssql/bin/mssql-conf traceflag 8002 on

Por padrão, os agendadores são associados a CPUs específicas definidas na máscara de afinidade. O sinalizador de rastreamento 8002 permite que os agendadores se movam entre CPUs, o que geralmente melhora o desempenho, respeitando ainda as restrições de afinidade e cgroup. Para obter mais informações, veja DBCC TRACEON – sinalizadores de rastreamento.

Reinicie SQL Server depois de habilitar o sinalizador de rastreamento.

Comportamento esperado

Após a reinicialização:

• SQL Server cria apenas o número de agendadores definidos pela configuração de afinidade (por exemplo, quatro agendadores).

• O kernel do Linux continua a impor a cota de execução da CPU do cgroup v2.

• As decisões de otimização e paralelismo de consulta baseiam-se na contagem de CPU pretendida, em vez do total de CPUs de host.

Para obter mais informações, consulte os seguintes recursos:

• Início Rápido: Implantar um contêiner do SQL Server Linux no Kubernetes usando gráficos do Helm
• Grupo de Controle v2 (documentação do Kernel do Linux)

Conteúdo relacionado

• Implantar contêineres do SQL Server no Linux e conectar-se a eles

• Solução de problemas de contêineres do SQL Server no Docker

• Proteger contêineres do SQL Server no Linux

Contribua com a documentação do SQL

Você sabia que pode editar conteúdo do SQL por conta própria? Ao fazer isso, além de melhorar nossa documentação, você também será creditado como um colaborador da página.

Para obter mais informações, consulte Editar a documentação do Microsoft Learn.