1

Conhecendo o Processo do SQL Server

no Windows e Linux
Apesar do seu enorme papel nas grandes corporações do mundo, o SQL Server,

assim como todos os outros SGBDs, não é nada mais nada menos que apenas um

processo do sistema operacional. Assim, conhecer os fundamentos de um processo,

é essencial para ter sucesso na hora de lidar com o SQL Server.

Há uma série de informações que você pode coletar apenas usando ferramentas do

sistema operacional. Sabendo manipular melhor o processo do SQL você consegue

não somente ter um maior controle sobre suas instâncias, mas também ter mais
cartas na manga para resolver um problema incomum, e até montar interessantes
linhas de raciocínio.

Nesta série, iremos mostrar alguns conceitos e ferramentas úteis para o dia-a-dia de

quem Administra instâncias SQL Server, não somente em ambiente Windows, mas
em Linux, e até docker.

Processos e threads
Eu sempre digo em minhas apresentações que entender o que é uma Thread é
essencial pra entender e dominar o SQL Server. Afinal, tudo se resumem a elas.

Em simples palavras, uma Thread é sequência de instruções (isso, Assembly, nada

de SQL ainda) e cada CPU pode executar uma única Thread por vez.
 2

Um processo é uma espécie de “grupo” de Threads, grosseiramente falando. Os

processos definem quais recursos suas threads tem acesso. Tais limites podem ser

impostos por um usuário administrador, através de configuração, ou por

características de hardware e/ou do sistema operacional. Há uma série de

informações que um processo contém.

Processos são isolados de outros processos. Isso significa que threads de um

processo não conseguem acessar recursos, como memória, de outros processos da

mesma maneira, que é simples, como fazem com seus próprios recursos. Você verá
que isso explica muita coisa quando trabalha com múltiplas instâncias!
 3

Para resumir:

 Thread: É a coisa que, de fato, executa instruções em uma CPU. Há várias dessas coisas o

tempo inteiro em um SO.

 Processo: É como se fosse um “grupo” de threads. Um processo não executa código, mas

contém, no mínimo, uma thread. Além disso, o processo contém uma série de outras

informações que limitam os recursos que uma thread pode acessar.

Executável e Argumentos

Todo processo começa a partir de um arquivo binário, contendo as instruções que o

processador deverá executar. No Windows, esse binário geralmente tem a extensão

.exe, e no Linux sem uma extensão específica. Ele é gerado a partir de alguma
linguagem de programação, como C++, que é o caso do SQL Server.

Iniciar um programa significa pedir ao sistema operacional que execute um arquivo

binário como esse. Quando o sistema operacional é acionado para tal ação, ele cria
 4

um novo processo em sua lista de processos, e também cria a primeira thread desse

processo e a aponta para a primeira instrução que se encontra no arquivo binário. A

partir daí, a thread seguirá seu fluxo de execução, realizando as mais variadas

operações que foram codificadas, como abrir arquivos, receber conexões, processar
texto, fazer cálculos e até criar novas threads.

Todo executável pode receber um ou mais parâmetros, que são strings passadas por
quem o iniciou. A sintaxe é:

NomeExecutavel Parametro1 Parametro2 “Parametro 3, com espacos”

O SQL Server contém uma série de parâmetros documentados e não documentados.

Quem determina quais parâmetros um executável irá receber é quem o desenvolveu.

Uma correta documentação irá dizer quais os parâmetros existem, como devem ser
especificados e o que eles causam na execução daquele software.

No caso do SQL server, existem diversos, e os seguintes são bem conhecidos:

Parâmetro Descrição

-e Caminho para o arquivo de error log

-l Caminho para o arquivo de log do banco master

-d Caminho para o arquivo de dados do banco master

-s Nome da instância

Você pode consultar uma lista de parâmetros que o executável do SQL Server

aceita neste endereço.

Você pode observar o executável usado para iniciar um processo, e seus argumentos,
usando ferramentas como Gerenciador de Tarefas ou o Process Explorer:

Executável e argumentos do processo do sql server no Gerenciador de Tarefas

 5

Executável e parâmetros do processo do SQL no Process Explorer

Já com powershell, uma das maneiras, é com os seguintes comandos:

Você verá um resultado como este:

Exercícios para fixar:

 Baixe o process explorer e tente ver os argumentos dos vários processo que existem em

execução

 Use o Gerenciador de Tarefas para observar as mesmas informações:

o Vá na aba “Detalhes”

o Clique com o botão direito no cabeçalho da tabela

o Escolha “Selecionar Colunas”

o Procure na lista e marque a opção “Linha de Comando”

o Aproveite e explore as outras colunas que existem

 Abra novos programas, e observe a linha de comando executada

 Powershell: Explore o cmdlet Get-Process e o comando Get-WmiObject Win32_Process

 6

O Executável do SQL Server

O executável do SQL Server é o sqlservr.exe. No Windows você o encontra em:

<ProgramFiles>\Microsoft SQL Server\<Versao>.<NomeInstancia>\MSSQL\Binn

No Linux, ele fica em:

/opt/mssql/bin/sqlservr (sem extensão).

Talvez você nunca tenha precisado interagir diretamente com o executável do SQL

Server porque você sempre iniciou ele através de um serviço. Em palavras simples,

um serviço está fazendo a mesma coisa que você: pedindo ao sistema operacional

que inicie a execução de um arquivo. Mas, no final das contas, ele é apenas um

processo. Você pode confirmar isso usando ferramentas do seu sistema operacional
que permitem monitorar e gerenciar os processos, como:

 Windows

o taskmgr.exe (Gerenciador de tarefas)

o Process Explorer

o Get-Process (powershell)

o tasklist.exe

 Linux

o Top

o htop

o /proc

Por exemplo, a seguinte imagem demonstra dois processos, cada um referente a uma
instância que iniciei através do Configuration Manager:

No Gerenciador de Tarefas do Windows a partir da versão 2012/8, você encontra

essas informações na aba “Detalhes” (ou “details”), Há uma linha para cada processo
 7

existente no seu sistema operacional. Se há mais de uma instância SQL Server em

execução, cada instância irá ser executada em seu próprio processo. O SQL Server
Agent também é outro processo, e que usa um executável diferente do SQL:

Assim como o SQL Browser, Analysis Services, etc. Cada um tem seu próprio
executável, e aceitam diferentes parâmetros.

O PID
Uma das informações mais importante sobre um processo é seu identificador, ou
“Process ID” (PID). O PID é um número exclusivo que um processo ganha ao ser

criado no sistema operacional. Nunca existirão dois processos com o mesmo ID em

uma mesma sessão do sistema operacional (isto é, depois do boot). Porém, o ID

pode ser reusado quando seu respectivo processo encerrar. Raramente você verá o

serviço do SQL Server usar o mesmo ID de processo entre seus restarts. Se ocorrer,
é uma bela sorte!

A linha de comando
Repare na última coluna dessa imagem:

A coluna “Linha de comando” (você consegue habilitar mais colunas usando o botão

direito do mouse no cabeçalho da tabela e selecionado a opção “Selecionar colunas”)

mostra o caminho do executável que foi usado para iniciar o processo. Se você olhar
na definição do serviço desta instância, poderá ver a mesma informação:

1. Abra o gerenciador de serviços do Windows (digite “services.msc” no executar ou em um shell)

2. Procure o serviço do SQL Server ( o nome é SQL Server (<NOME INSTANCIA>))

3. Clique com o botão direito, e vá em propridades. Você verá uma imagem semelhante a esta:
 8

Se você selecionar o texto sob “Caminho do Executável”, poderá ver o resto das informações.

Quando o Windows é solicitado para rodar esta linha de comando, seja diretamente

pelo usuário, ou através de um serviço, ele cria um novo processo e aponta a primeira

thread para o executável. Além disso, após o nome do executável há os parâmetros

que devem ser passados ao processo. O Windows se encarrega de disponibilizar

esses valores para a primeira thread do processo, e a partir daí ela faz o que quiser
com eles.

No caso do sqlservr.exe, o parâmetro “-s” indica que o valor a seguir é um nome de

instância. No caso do SQL Agent, é o parâmetro “-i” quem dita essa informação.
(No post anterior há uma tabelinha contendo essas informações).
 9

O usuário
Uma outra informação bastante útil vem da coluna “Nome de usuário”. Essa coluna

indica com qual conta de usuário o processo está rodando. Todo processo, e,

consequentemente, suas Threads, necessitam rodar sob alguma conta de usuário

(geralmente, usamos o nome “conta de serviço”, pois estamos falando de uma conta

de usuário que irá rodar um serviço. Mas é tudo a mesma coisa). Essa conta é usada

pelo sistema operacional para validar o acesso a recursos do sistema operacional,

como os arquivos. É comum observar erros de Access Denied a um arquivo ou

diretório porque esta conta não tem as devidas permissões.

Uma outra situação comum, é ter que dar direitos específicos para que o SQL Server

consiga realizar determinadas operações. Por exemplo, no Windows, o famoso

Instant File Initialization é permitido somente se a conta com a qual o serviço está

rodando possui um privilégio chamado SeManageVolumePrivilege. Há diversas

formas de verificar se o processo tem esse privilégio habilitado e uma delas é usando
o Process Explorer:

1. Abra o process explorer como Administrador e procure o processo do SQL da instância

desejada

2. Clique com o botão direito no nome do processo e vá em “Properties”

3. Vá na aba “Security”. No final da janela aberta, você verá a lista de privilégios com as quais o

processo executa (que foi herdado do usuário associado com esse processo)
 10

A lista vem ordenada pelo nome do privilégio. Apesar da conta possuir alguns

privilégios atribuídos, o de nosso interesse não está na lista. Após adicionar o

 11

privilégio, e reiniciar o serviço do SQL Server, conseguimos vê-lo:

Além disso, há uma série de outras informações a respeito do usuário, que podemos
discutir melhor em um outro post.

Não deixe de praticar o que foi aprendido A:

 Utilize as várias ferramentas disponíveis e compare os usuários com os quais o processo

executa

 Experimente retirar ou adicionar permissões da conta de serviço utilizada pelo SQL Server,e

observe os efeitos na execução do serviço.

 Reinicie o serviço do SQL Server e compare os PIDs

 12

 Powershell: Explore cmdlet Get-Service ou a classe WMI win32_service para obter mais

informações sobre um serviço do Windows

O “Gerenciador de Tarefas”
A esta altura, você já percebeu o Gerenciador de Tarefas do Windows é, na verdade,

um “Gerenciador de Processos”. Ele te dá uma lista contendo cada processo que

existe no Windows com diversas informações sobre cada um deles. Há o “process

explorer” e o “Get-Process”, do powershell, também. No Linux, assim como no

Windows, possuímos diversas ferramentas que nos fornecem as mesmas

informações, umas com mais detalhes, outras com menos.

Por exemplo, você pode usar o comando “ps” para encontrar a linha de comando
usada para iniciar o SQL Server:

Note que há dois processos. São duas instâncias? Não. No Linux, o sql server inicia
um processo conhecido como “watchdog”,e este por sua vez é quem inicia um

segundo processo que irá atuar como uma instância SQL como a conhecemos. Como

pode notar, ambos usam o mesmo executável. O primeiro processo fica monitorando

o segundo, e em caso de falhas, irá gerar os dumps para análise. No Windows, é um

recurso nativo do sistema operacional quem faz esse trabalho. Este artigo do Bob
Dorr, detalha.

Você pode usar o seguinte comando para exibir o PID do processo, o usuário e a
linha de comando usada:
 13

Um exemplo:

No exemplo acima, o processo 25526 foi iniciado pelo processo 1 (PPID = parent pid,

ou, pid pai). O processo 1 (init) é semelhante ao processo System e wininit.exe do

Windows, que são os responsáveis por iniciar os serviços. Então, podemos dizer que

o processo 25526 é o “watchdog”, pois ele foi o primeiro processo com o executável

do SQL Sever a ser iniciado. A linha seguinte, demonstra que o respectivo processo,

de PID 25531, é filho de 25526 (o watchdog), então, este é a instância SQL (é este

processo, por exemplo, quem escuta na porta 1433, e processa os comandos SQL
que chegam).

O comando “htop” pode ser uma alternativa interessante ao comando “ps”. Usando a

tecla F5, você consegue trocar a exibição entre uma árvore de processos e uma lista

ordenada:

Aqui, a coluna “PID” é auto explicativa. Ela contém o PID do processo, conceito que

você já aprendeu no post anterior. É a mesma coisa. A coluna “User” informa qual o

usuário sob o qual o processo está executando. A mesma informação está disponível

tanto no Gerenciador de Tarefas e no Process Explorer. No powershell é necessário

um script mais elaborado para obtê-la.
 14

No Windows, você consegue ver essa relação de processo pai e processo filho melhor

com o Process Explorer. Aqui está um exemplo no Windows:

Note que no Windows, não temos um outro processo pai chamado sqlservr.exe. O sqlservr.exe é

filho de “services.exe”, pois eu o iniciei através de um serviço do Windows. Entretanto, ao executar

um xp_cmdshell ‘ping www.microsoft.com’, podemos ver claramente processos filhos do SQL

Server sendo criados. O Process Explorer demonstra que cmd.exe é filho de sqlservr.exe. E

PING.EXE é filho de cmd.exe

Onde estão os argumentos? No caso do SQL Server no Linux, todos os parâmetros

default vem do registro (na verdade, uma implementação parecida, para o Linux):

Assim, como no Windows, ainda é possível usar os parâmetros em linha de comando:

 15

A primeira linha é o comando sudo. Da maneira em que foi executado na imagem, ele

faz com que mudemos o usuário atual. O nome do usuário é “mssql”, criado por

padrão na instalação do SQL. Na próxima linha, eu apenas inicio o executável do SQL

Server, com o parâmetro “-e”, alterando o local do Error Log, semelhante como

fizemos no Windows. A razão pelo qual eu mudei de usuário é apenas para evitar

problemas de permissão quando eu iniciar o serviço normalmente usando o

gerenciador de serviço (systemctl). Eu recomendo que não faça isso, principalmente

em ambiente de produção, pois pode vir a ter seu serviço inoperável. Mas, se o fizer,
e tiver problemas, tente restabelecer as permissões, desta maneira:

Aqui está o processo, usando o comando “ps”, como mostrado anteriormente:

Note que o processo é filho do processo 23892. Utilizando o comando ps, podemos
observar quem é:

bash é um programa que atua como um shell no Linux, semalhante ao que o cmd, ou mesmo o

powershell, é no Windows. Ele é responsável por captar e exibir a saída de comandos fornecidos

no terminal. Quando eu iniciei o SQL Server na linha de comando do Linux, foi o bash da minha

sessão quem o fez. Por isso, ele é o pai.

 16

No Windows você também consegue iniciar o serviço do SQL Server na linha de

comando. Basta mandar executar o arquivo sqlservr.exe e passar os devidos

parâmetros:

Neste exemplo, eu parei o serviço do SQL, usando o Configuration Manager, e

executei esta linha de comando:

Quando eu iniciei o sqlservr.exe, o usuário com o qual eu abrir o prompt é o usuário

quem vai rodar esse processo. Sendo assim, todas os recursos do Sistema

Operacional que minha instância precisar, estarão sujeitos a esse usuário. Note que

não é o mesmo usuário que eu configurei lá “Configuration Manager”. Aquele é o

usuário que será usado quando o sql for iniciado por lá (ou pelo gerenciador de
serviços).

Note que, como no Linux, o processo agora é filho do “cmd.exe” (semelhante ao bash’).

No Linux, é o mesmo caso, porém, eu apenas optei por utilizar o mesmo usuário

configurado nas definições do serviço. No caso do Windows, os efeitos de ser fazer

isso não são tão graves como no Linux, mas ainda sim, não recomendo que faça isso
em um ambiente operacional, pois poderá ter os mesmos problemas.
 17

Como o sqlservr.exe é uma “ConsoleApplication”, ele começou a gerar a saída na

tela, além do errorlog. Isso acontece nas versões para ambos os sistemas
operacionais.

Bom, há muito o que falar sobre processos. Esta foi uma introdução cujo o objetivo é

mostrar como ambos os sistemas operacionais fornecem a mesma visão. Porém,

apesar das informações simples, elas são poderosas armas em situações de

análises. As vezes, os simples fato de olhar o usuário com o qual o processo está
rodando, pode te ajudar a perceber um problema devido a permissões de acesso.

Há ainda uma série de ferramentas poderosíssimas, como o Process Monitor, ou

o strace, que ajudam a compreender tudo o que um processo está fazendo. Conhecer

o que são os processos e seus conceitos mais simples, ajudam a melhor utilizar essas
ferramentas. E em algum momento iremos dedicar atenção a elas aqui no blog!

Aqui estão algumas fontes e referências do assunto de hoje:

 Local dos arquivos de uma instância SQL Server

https://docs.microsoft.com/en-us/sql/tools/sqlservr-application?view=sql-server-2017

 Executável sqlservr

https://docs.microsoft.com/en-us/sql/tools/sqlservr-application?view=sql-server-2017

 Linux Bash

http://tldp.org/LDP/Bash-Beginners-Guide/html/Bash-Beginners-Guide.html#chap_01

 Instalando SQL Server no Linux

https://docs.microsoft.com/en-us/sql/linux/sql-server-linux-setup?view=sql-server-2017

 Processo e Threads no Windows

https://docs.microsoft.com/en-us/windows/desktop/procthread/processes-and-threads

 Linux clone system call (útil para aprender como processos são criados no Linux)

http://man7.org/linux/man-pages/man2/clone.2.html
 18

 Conceitos de Processo e Threads no Linux

https://www.thegeekstuff.com/2013/11/linux-process-and-threads/

 SQL Server PAL (nova arquitetura de processos introduzida no SQL Server)

https://cloudblogs.microsoft.com/sqlserver/2016/12/16/sql-server-on-linux-how-introduction/