Próximo Meetup da Data Tuning

Fala galera! Na próxima quinta-feira, 27/06 às 20:00 ocorrerá o próximo Meetup da Data Tuning. Desta vez iremos expor problemas tensos que passamos em algum momento de nossa carreira como DBA SQL Server, como identificamos estes problemas, como analisamos e como resolvemos cada um. Você não pode perder! Clique no link abaixo e se inscreva!

https://www.meetup.com/pt-BR/Data-Tuning-Group/events/262365536/

Dica: removendo arquivos do tempdb

Recentemente ao realizar o acerto dos arquivos do tempdb em instâncias do SQL Server 2012 e superiores, me deparei com uma situação que ainda não tinha visto nas versões anteriores ao SQL Server 2012.

Vamos a simulação do problema!

Ao executar o comando abaixo:

ALTER DATABASE tempdb REMOVE FILE temp03

O erro abaixo é apresentado:

Msg 5042, Level 16, State 1, Line 2
The file ‘temp03’ cannot be removed because it is not empty.

Com a mensagem acima, executei o comando abaixo:

USE tempdb
GO
DBCC SHRINKFILE(temp03,EMPTYFILE)

DBCC SHRINKFILE: Page 3:32 could not be moved because it is a work table page.

Msg 2555, Level 16, State 1, Line 4
Cannot move all contents of file “temp03” to other places to complete the emptyfile operation.

E agora? O SQL Server informa que não é possível remover o arquivo do tempdb porque o mesmo não está vazio e ao tentar realizar o shrink o SQL informa que não consegue mover todo o conteúdo para outro arquivo.
Confesso que a primeira vez que vi o erro fiquei confuso!

Abaixo, eu mostro como está a distribuição dos arquivos do tempdb da instância.

Trace Flag 3608

Para a simulação desse problema, estou utilizando o SQL Server 2017.
Uma das formas que eu encontrei para contornar esse comportamento é utilizando a Trace Flag 3608.
A TF 3608 faz com que não ocorra o start e recovery de nenhuma base de dados, exceto a master. Nessa situação as bases de dados só passarão pelo start e recovery ao serem acessadas e com isso é possível executar o comando de exclusão dos arquivos do tempb sem receber o erro “The file xxx cannot be removed because it is not empty”.

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql?view=sql-server-2017

Habilitando a Trace Flag 3608

A primeira coisa a fazer é acessar o SQL Server Configuration Manager, ir nas propriedades do serviço do SQL Server e selecionar a aba Startup Parameter.

SQLServerConfigurationManagerStartupParameter

No campo Specify a startup parameter adicione o parâmetro -T3608 e clique no botão Add.

3608

Feito isso, basta realizar stop/start do serviço do SQL Server e com o SQL Server reiniciado, podemos observar no ERRORLOG que a engine fez o recovery apenas na base de dados master.

Com isso podemos observar que ao listar os arquivos do tempdb novamente, apenas os arquivos padrão de quando o SQL Server foi instalado será listado.

tempdb3608

Porém se listarmos os arquivos do tempdb pela sys.master_files iremos observar que os demais arquivos estão configurados, porém como o tempdb não foi realizado o recovery eles não estão em uso.

sysmasterfile3608

Feito isso agora iremos conseguir realizar a exclusão dos arquivos do tempdb com sucesso.

tempdb_removefile

Agora iremos remover a TF 3608 e dar stop/start no serviço do SQL Server para verificarmos se a remoção do arquivo temp03 de fato ocorreu e analisar que sem a TF 3608 todas as bases são startadas e o recovery é executado após o restart do serviço.

tempdb files

tempdb2

ERRORLOG

ERRORLOG após remoção da TF 3608.

Bom pessoal, espero que isso possa ajudá-los no dia a dia. Remover arquivos do tempdb não é uma tarefa que se realiza com frequência nos ambientes, mas é importante sempre checar essas configurações para que o tempdb não esteja configurado de forma errada.
Até a próxima.

SQL Server + Docker – Provisionando uma Instância de Banco de Dados Rapidamente

Fala meu povo! Espero que todos estejam bem. 

Sabe quanto você quer testar um sistema, um código que desenvolveu ou até mesmo uma nova feature de um banco de dados, mas não quer instalar todo o SGBD? Quem já instalou alguns SGBDs (Sistemas Gerenciadores de Banco de Dados) sabe que alguns deles possuem setups extensos como Microsoft SQL Server e Oracle, por exemplo. 

Neste post trago uma alternativa extremamente rápida que você pode utilizar para provisionar uma instância SQL Server em poucos minutos. 

Para isso, antes de tudo, precisamos instalar o Docker, sistema gerenciador de container mais popular existente. Esse tutorial está sendo feito em cima de Linux, mais especificamente o Ubuntu 18.04: 

Instalação do Docker CE no Ubuntu

Agora vamos instalar o Docker Community Edition ou apenas Docker CE.  

1. Atualize o seu repositório apt

$ sudo apt-get update

2. Instale alguns pacotes para que o apt possa utilizar repositórios HTTPS

$ sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common

3. Adicione a chave GPG oficial do Docker:

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

4. Verifique se a chave corresponde com o fingerprint 9DC8 5822 9FC7 DD38 854A E2D8 8D81 803C 0EBF CD88

5. Com o próximo comando adicionaremos o repositório da versão estável (stable) do Docker CE, para instalar versões que ainda estão em teste utilize o tutorial que deixaremos nos links finais do post. 

Como meu computador possui um sistema operacional 64 bits, utilizarei a versão x86_64, caso seu sistema operacional seja 32 bits, arm entre outros, utilize os repositórios existentes no link que irei deixar no final do post. 

$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"

Após feito os passos acima, vamos então instalar o Docker CE.  

6. Atualize o índice de pacotes do apt

$ sudo apt-get update

7. Agora sim! Vamos instalar a última versão do Docker CE e do containerd: 

$ sudo apt-get install docker-ce docker-ce-cli containerd.io

8. Verifique se a instalação funcionou executando o comando a seguir. Esse comando baixa uma imagem de container chamada Hello World e depois executa esta imagem: 

$ sudo docker run hello-world

A saída do comando acima deverá ser essa: 

Bom, agora que estamos com o Docker devidamente instalado, podemos partir para o provisionamento da instância SQL Server. O objetivo deste post é ser o mais simples possível, voltado para uma utilização controlada da instância de banco de dados, ou seja, um ambiente para testes e talvez, para alguns casos, desenvolvimento de aplicações. Futuramente farei outros posts voltados mais especificamente para ambientes que vão do desenvolvimento até ambientes produtivos altamente escaláveis.

Provisionamento da Instância SQL Server em container

Bora subir um SQL Server 2019 CTP 2.5 então.

1. Baixar a imagem do SQL Server do repositório da Microsoft: 

$ sudo docker pull mcr.microsoft.com/mssql/server:2019-CTP2.5-ubuntu

2. Baixou a imagem? Então agora é só executar um novo container que a magia vai acontecer: 

$ sudo docker run -e 'ACCEPT_EULA=Y' -e 'SA_PASSWORD=SENHAdoS@2019' \
   -p 1433:1433 --name sqldt \
   -d mcr.microsoft.com/mssql/server:2019-CTP2.5-ubuntu

O que temos no comando acima:

  • run: comando do docker para executar um novo container; 
  • -e 'ACCEPT_EULA=Y': aqui você está aceitando aquele contrato de termos de uso que aparece na instalação do SQL; 
  • -e 'SA_PASSWORD=SENHAdoS@2019': senha do usuário SA, precisa ser uma senha forte; 
  • -p 1433:1433: no comando -p você declara a porta em que o SQL Server ficará disponível, o primeiro número antes do : é a porta que ficará disponível para o host, ou seja, para sua máquina. O número depois do : é a porta que será aberta dentro do container. Calma que mais pra frente ficara mais claro; 
  • --name sqldt: aqui você coloca um nome para o container, é uma boa prática fazer isso pois além de ficar mais fácil de identificar o seu container, também facilita com que outros containers comuniquem com este container. Se você não declara um nome, o próprio Docker seta um nome para o seu container; 
  • -d: esse comando faz com que o container seja executado em backgroud, ou seja, você executa o comando, um hash é printado na saída do comando, esse hash é a identificação de execução do seu container; 
  • mcr.microsoft.com/mssql/server:2019-CTP2.5-ubuntu: aqui temos a imagem que baixamos anteriormente e que é utilizada para executar o container. 

Depois de executar o comando acima apenas apareceu um hash gigante, não é? Então, essa é a identificação de execução do container. Para verificar se o container está rodando, execute o comando abaixo: 

$ docker ps

A saída do comando é essa: 

Como podemos ver, o container está em execução. Sendo assim, vamos conectar na instância. 

Estou utilizando um Linux, logo, vou utilizar o Azure Data Studio para conectar no SQL Server: 

Se estiver tudo certo, o client irá conectar: 

Clique em New Query para que possamos executar algumas consultas interessantes, como:

SELECT @@VERSION

Com este comando podemos ver qual é a versão do SQL que estamos utilizando: 

Como podemos na imagem, o comando trouxe a versão do SQL que escolhemos (2019 – CTP2.5), a edição (Developer – Padrão, podemos especificar qual edição queremos antes de iniciar o container, é só utilizar a opção -e 'MSSQL_PID=Enterprise') e a versão do Linux, que no caso é o Ubuntu 16.04. 

Mas calma, eu havia dito no começo do post que a versão que estou executando no meu computador é a 18.04, então como o container está executando uma versão abaixo da minha? Essa é a magia dos containers. Os containers se beneficiam do LXC (Linux Containers), sistema que abstrai algumas camadas de acesso ao kernel (cgroups e namespace são algumas delas), tornando-o “compartilhado”, desta forma, possibilitando que outras distribuições de Linux usufruam do mesmo kernel do sistema operacional em execução no host. O Docker foi construído para facilitar a execução de containers no Linux e vem revolucionando a forma como fazemos aplicações atualmente. 

Não irei me estender muito sobre Docker neste post, mas deixarei links onde vocês poderão conhecer mais sobre Docker e sobre containers. 

Vamos agora criar um banco de dados e ver se tudo se comporta bem:

CREATE DATABASE test;

Aparentemente o banco de dados foi criado, mas será mesmo que foi? Vamos verificar: 

SELECT 
    name
    ,state_desc
    ,compatibility_level
FROM sys.databases 
WHERE name = 'test';

O banco de dados está lá conforme podemos ver. 

Bom pessoal, esse foi nosso post sobre SQL Server em containers Docker. Deixo alguns links uteis os quais me baseei para fazer este post e outros que utilizei para aprender mais sobre Docker. 

Links Úteis 

https://docs.docker.com/install/linux/docker-ce/ubuntu/

1º Meetup da Data Tuning

Fala galera! No dia 30/05 às 20Hrs estaremos apresentando nosso primeiro Meetup online! Falaremos um pouco sobre as novas Features de Performance que estão vindo no Microsoft SQL Server 2019. Todos estão convidados para participar deste evento que é totalmente gratuito e online! Para se inscrever e ver mais detalhes é só clicar no link abaixo:

https://www.meetup.com/pt-BR/Data-Tuning-Group/events/261596790