Академический Документы
Профессиональный Документы
Культура Документы
Autores: Diego Nogare - Edvaldo Castro - Leonardo Pedroso - Sulamita Dantas - Demtrio Silva -
Thiago Alencar - Nilton Pinheiro - Luciano Moreira - Vitor Fava - Murilo Miranda - Marcelo Fernandes
- Cibelle Castro
Introduo
Estar envolvido em uma comunidade sempre mais importante e proveitoso de que viver de um modo
isolado, seja nos mbitos pessoais, profissionais e quaisquer outros. A comunidade tcnica de
profissionais que trabalham com produtos e ferramentas ligados Plataforma de Dados da Microsoft
bem atuante e unida, isso faz com que muito contedo seja gerado, seja com vdeos, eventos, palestras,
entrevistas e postagens em blogs.
O segundo volume da srie "SQL Server Alm do Conceito" traz agora um conjunto multidisciplinar de
captulos originais, escritos exclusivamente para esta obra. Mais uma vez um grupo de profissionais de
diversas reas do SQL Server se juntaram e escreveram captulos em suas reas de domnio. Baixe agora
sua cpia e mergulhe no mundo a partir da viso destes autores que dedicaram seu tempo para escrever
sobre Administrao, Desenvovimento e Business Intelligence.
Um ponto importante a ser mencionado, este trabalho por ser voluntrio e no ter um cunho com fins
financeiros, teve uma tratativa diferente mas no menos cuidadosa com relao um livro ordinrio. Cada
autor o responsvel direto pelo que escreveu e publicou na coletnea, mas todos esto juntos para
proporcionar e compartilhar o conhecimento que adquiriram ao longo de vrios anos de experincia.
Aproveite bem, e quaisquer necessidades de contato, no hesite em nos enviar uma mensagem
sqlalemdoconceito@outlook.com.
Boa Leitura,
Diego Nogare
http://www.diegonogare.net/
Edvaldo Castro
http://edvaldocastro.com/
Demtrio Silva
https://demetriosilva.wordpress.com/
Prefcio
Desde as suas primeiras verses, o SQL Server continuamente tem se estabelecido como uma
plataforma confivel e robusta com performance, escalabilidade e confiabilidade que atende as todas as
necessidades de negcio desde pequenas empresas at grandes corporaes. AS novidades do SQL Server
consolidam esta posio no mercado como um banco de dados de alta performance, confivel e robusto.
Um dos maiores desafios em escrever o livro SQL Server Alm do Conceito Vol 2 como trazer os
assuntos de maior interesse do pblico, de uma maneira compreensiva e com foco em compartilhar o
conhecimento. Por este motivo, alguns dos maiores profissionais de SQL Server no Brasil se reuniram
novamente para escrever este novo volume tratando dos assuntos mais interessantes sobre SQL Server!
A principal deciso foi escrever este livro com foco nas funcionalidades essenciais sob os aspectos
administrativos e de gerenciamento no dia-a-dia de todo o DBA.
Neste livro, voc ter oportunidade de conhecer mais sobre Segurana, com um captulo
especialmente dedicado ao Gerenciamento de Logon. Como monitorar eficientemente seu ambiente e
como configurar o seu ambiente so dois captulos que valem a pena ler com ateno! No poderamos
deixar de lembrar os captulos especialmente dedicados s ferramentas de Business Intelligence e Azure,
como os captulos dedicados ao Power BI, HDInsight e In-Memory OLTP!
Aproveite esta leitura! Aproveite ao mximo o conhecimento transmitido pelos autores. Tenho a
certeza de que contribuir consideravelmente em seu conhecimento!
Fizemos os melhores esforos para garantir que no haja nenhum erro neste livro, mas se voc
encontrar algum, por favor, nos informe pelo email sqlalemdoconceito@outlook.com.
Roberto Fonseca
https://rffonseca.wordpress.com/
MVTech
O Minha Vida (http://www.minhavida.com.br) uma empresa com um grande propsito: melhorar a
qualidade de vida da populao. Queremos ser capazes de despertar nas pessoas o cuidado com a sua
prpria sade. E quando falamos em sade, nos referimos no s preveno ou ao tratamento de
doenas, mas tambm a pequenas mudanas de hbitos capazes de transformar positivamente o dia a
dia das pessoas.
Pensando nisso, nosso time de tecnologia criou o MVTech, uma iniciativa para disseminar
conhecimento atravs de iniciativas de seus colaboradores, buscando o aprimoramento do mercado
nacional.
Com diversas aes como: artigos tcnicos em blogs; matrias para portais; respostas em foruns de
discusso, palestras em eventos, eventos presenciais e online, etc afinal, somos apaixonados pelo que
fazemos! por que no compartilhar nossa paixo?
Introduo
O conector do Azure dentro do SSIS permite se comunicar com alguns recursos da plataforma de Cloud
Computing da Microsoft para que arquivos sejam movimentados entre o computador de execuo do
pacote e um servidor no Azure, mais especificamente para dentro de um Blob Storage, ou ento para criar
e apagar clusters do HDInsight. Isso permite automatizar a ao de processamento em clusters de Hadoop
atravs da plataforma da Microsoft, garantindo o mximo de economia pela possibilidade de desligar o
cluster aps seu uso, pagando apenas pelo uso real e no por um ambiente ocioso.
Neste captulo voc aprender como instalar este componente no seu SSIS 2014, que j nativo no
SQL 2016. Depois de instalado, acompanhar a criao de um cenrio fictcio no qual ser enviado para o
Azure Blob Storage um arquivo de texto com alguns dados, em paralelo ser disparado o comando para
criar o cluster do HDInsight. Em seguida, uma consulta disparada contra o arquivo enviado e um retorno
baixado para o local que est executando o pacote. Para finalizar, o cluster do HDInsight ser destrudo.
Instalao
Faa o download do Microsoft SQL Server 2014 Integration Services Feature Pack for Azure para ter
acesso s tarefas que permitem a movimentao de dados e gerenciamento de atividades com o Azure.
O link para download est na seo de Recursos, no final do captulo. Aps o trmino do download, faa
a instalao padro clicando em avanar at terminar. Ao final, abra o SQL Server Data Tools e confirme
que os componentes esto disponveis no SSIS Toolbox do Data Flow.
Componentes
Estes so os componentes do Data Flow que foram adicionados Toolbox do SSIS e suas principais
configuraes:
Azure Blob Download Task: Permite que o SSIS faa download de arquivos que esto no Azure Blob
Storage. necessrio informar:
AzureStorageConnection: Especifica ou cria uma conexo para um continer com o Azure Storage
Account;
BlobContainer: O nome do continer que possui os arquivos a serem baixados;
LocalDirectory: Endereo local onde o arquivo ser baixado;
FileName: Especifica o nome do arquivo completo, ou em partes, utilizando o caractere * como
wildcard (como feito no Prompt de Comando)
Azure Blob Upload Task: Permite que o SSIS faa upload de arquivos para uma conta no Azure Blob
Storage. A configurao semelhante do componente Azure Blob Download Task.
Azure HDInsight Create Cluster Task: Possibilita que sejam criados clusters do HDInsight em uma
subscription do Azure. necessrio configurar:
AzureSubscriptionConnection: Especifica ou cria uma conexo para uma subscription do Azure que
receber o cluster do HDInsight;
AzureStorageConnection: Especifica ou cria uma conexo para um continer com o Azure Storage
Account;
Location: o local (regio do Azure) que deseja armazenar o cluster. Deve ser o mesmo lugar
escolhido no Storage;
ClusterName: Informa o nome do cluster do HDInsight que vai criar;
ClusterSize: A quantidade de ns do cluster;
BlobContainer: O nome do continer que possui os arquivos a serem trabalhados;
UserName: Espeficica o usurio que ser o administrador do cluster;
Password: A senha para este usurio;
Azure HDInsight Delete Cluster Task: Esta tarefa permite apaga um cluster de uma subscription.
necessrio informar:
AzureSubscriptionConnection: Especifica ou cria uma conexo para uma subscription do Azure que
receber o cluster do HDInsight;
ClusterName: Informa o nome do cluster do HDInsight que vai apagar;
Azure HDInsight Hive Task: Este componente permite rodar scripts Hive no cluster HDInsight. Existem
duas formas de informar o script, uma especificando diretamente na tarefa e outra com o script
armazenado em um arquivo no Blob Storage. Neste exemplo ser escrito o script na tarefa.
AzureSubscriptionConnection: Especifica ou cria uma conexo para uma subscription do Azure que
j possui um cluster do HDInsight;
ClusterName: Informa o nome do cluster do HDInsight que vai receber e processar o cdigo Hive;
In-Line Script: Colocar o Cdigo Hive que ser processado.
Azure HDInsight Pig Task: Componente que permite executar scripts Pig no cluster HDInsight. A
configurao semelhanto do Hive Task.
Agora que j se sabe o que cada componente novo faz, e o que necessrio configurar para cada um,
preciso comear o desenvolvimento do cenrio comentado na introduo. Ao final do captulo voc ter
criado um pacote utilizando quase todos (com exceo da tarefa de execuo dos scripts Pig) os
componentes do Data Flow do Azure Package instalados no SQL Server Data Tools e seu pacote ter uma
aparncia semelhante ao da imagem a seguir:
Instalando o MakeCert
Para o cenrio de testes estou utilizando meu computador pessoal. Nele est instalado o Windows 10
como sistema operacional e por isso preciso instalar componentes externos ao padro do Windows no
meu ambiente.
Certifique-se que seu ambiente possui o MakeCert. Se encontrar, pode pular esta seo. Porm, pode
ser que seu ambiente no tenha o MakeCert, como no meu caso. Para resolver isso necessrio baixar o
Windows SDK, que voc pode fazer o download a partir do link existente na seo de Recursos.
Na hora da instalao no necessrio instalar todas as opes que o instalador oferece. Garanta ao
menos a marcao da opo de Windows App Certification Kit, como na figura a seguir:
Nesta seo do captulo ser utilizada a ferramenta MakeCert para criar o certificado digital que ser
utilizado posteriormente para se comunicar de forma segura com o Azure. Caso precise, leia a seo
Instalando o MakeCert e em seguida volte para este ponto.
Para criar o certificado abra o prompt de comando. Garanta que est abrindo com permisso de
Administrador. Para isso, clique com o boto direito e aponte o mouse para Executar como
Administrador.
Navegue at a pasta na qual voc instalou o MakeCert, que por padro do SDK do Windows
Insira a linha de comando que cria o certificado. No caso deste captulo criei um certificado com o meu
nome atravs do comando:
MAKECERT -SKY EXCHANGE -R -N "CN=N OGARE CERTIFICATE " -PE -A SHA 1 -LEN 2048 -SS M Y
"NOGARECERTIFICATE .CER"
Se executar o processo com sucesso, v at a pasta no qual instalou o SDK e o MakeCert e voc ter o
arquivo criado. Veja como ficou o arquivo criado neste diretrio:
Criando o pacote e se comunicando com o Azure
Depois de tantos passos de preparao do ambiente para se comunicar com o Azure, nesta seo ser
criado o pacote que utilizar o conhecimento adquirido nas sees anteriores para concluir o captulo.
Os itens apresentados na soluo proposta na introduo ser criado em detalhes, com o objetivo de
guiar no entendimento das tarefas especficas e ter uma viso macro de como esta soluo resolve o
problema geral. Para concluir esta seo, necessrio criar um pacote do SQL Server Integration Services
e acompanhar os passos a seguir.
Depois de criado o pacote, arraste o componente do Azure Blob Upload Task. Clique com o boto
direito no componente, e aponte para Edit.
Voc precisa de um Storage no Azure para prosseguir. V at sua subscription e encontre os dados
necessrios para configurar a conexo do componente no SSIS. Caso no saiba onde esto estes dados,
v at seu Storage e clique em Manage Access Keys. Uma tela semelhante esta imagem abaixo se abre
com as informaes que precisa.
Copie a chave que aparece no Primary Access Key, e preencha no campo de Account Key do SSIS que
ser configurado. Faa a mesma coisa para o Storage Account Name.
Depois de informar os dados solicitados, teste a conexo clicando no boto Test Connection. Se
receber a mensagem de sucesso, voc configurou com sucesso sua conexo.
O prximo item a ser configurado o BlobContainer e o BlobDirectory. Informe os respectivos nomes,
de acordo com seu ambiente. O diretrio opcional, pode deixa-lo em branco, caso queira.
Para finalizar esta configurao, informe o local de origem e o nome do arquivo que ser enviado pelo
SSIS para o Azure Blob Storage.
Ao final da configurao, confirme clicando em OK. E repare que aquele alerta vermelho ao lado do
componente j no existe mais. Isso significa que as configuraes mnimas foram feitas.
Para testar, execute o pacote que possui s este componente e aguarde o envio do arquivo.
Ao final, quando um check verde ficar ao lado do seu componente, abra o Storage e confirme que o
arquivo foi enviado ao servidor.
Se voc encontrar o arquivo dentro do Blob Storage, seu componente e a configurao inicial foram
criados com sucesso.
Depois de enviar o arquivo para o servidor, vamos configurar a tarefa irm do envio, que o download
do arquivo a partir do servidor. Esta tarefa faz o processo inverso ao que foi executado na explicao do
Azure Blob Upload Task, e sua configurao muito semelhante. Acompanhe os passos a seguir.
Arraste o componente do Azure Blob Download Task para uma rea vazia dentro do pacote criado.
Seguindo o mesmo processo do componente anterior, necessrio editar a tarefa para que ela faa o
trabalho proposto. Abra as configuraes para editar. Faa isso clicando com o boto direito na tarefa e
apontando para Edit.
Mais uma vez, repare que o alerta vermelho no est mais apresentado na sua tarefa. Para executar
somente este componente, clique com o boto direito na tarefa de download, e aponte para Execute
Task.
Aps a execuo, um check verde ser mostrado ao lado da tarefa e, se funcionou corretamente, na
pasta que voc informou de destino haver uma cpia do arquivo que foi feito o download.
Com isso, conclumos a movimentao de dados nos dois sentidos, entre o servidor que executa o
pacote do SSIS e o ambiente do Azure.
A criao dos clusters de HDInsight dentro do Azure permite que um cluster de ns de Hadoop seja
disponibilizado atravs da sua subscription, para processar os scripts em Hive que sero enviados para o
ambiente. Para comear esta ao, arraste o controle Azure HDInsight Create Cluster Task para uma rea
vazia do pacote.
Seguindo os mesmos passos das tarefas anteriores, necessrio editar esta tarefa para que ela execute
seu propsito. Clique com o boto direito e v at Edit.
Mais uma vez voc precisar de informaes especficas da sua subscription do Azure. A primeira delas
a Azure Subscription ID. Voc consegue recuperar essa informao nas configuraes da sua
subscription. Procure as configuraes da sua conta em uma tela parecida com esta abaixo:
Perceba que durante a configurao do componente, ele pede um certificado digital. Este certificado
o que foi criado na seo Criando um Certificado Digital alguns pargrafos acima. necessrio que voc
envie este certificado para o Azure. Para isso, ainda na seo de configurao dentro do portal, abra a aba
chamada Management Certificates.
Ao clicar em Upload a Management Certificate, voc deve informar o caminho daquele certificado
criado anteriormente. E em seguida clicar no check para concluir o upload.
Feche a janela de teste de conexo e confirme a conexo com a subscription do Azure clicando em OK.
Voc ser devolvido para a tela inicial da configurao do Azure HDInsight Create Cluster Task.
A seguir preciso informar a regio (lugar onde deseja ter o servio do Azure) que ter o cluster, nome,
tamanho, Blob continer, usurio e senha. Obrigatoriamente o cluster deve ser na mesma regio do
Storage, e no caso deste captulo, East US. Veja na imagem abaixo a configurao realizada para esta
tarefa.
Confirme a configurao clicando em ok, e veja que no tem mais o alerta vermelho ao lado da tarefa.
Para testar, clique com o boto direito na tarefa e aponte para Execute Task.
Depois de alguns instantes, possvel acompanhar o cluster sendo criado dentro do servio do
HDInsight no Azure.
Aps a concluso da tarefa no portal do Azure, e no havendo nenhuma falha, seu componente no
SSIS ser marcado com o check verde.
Seguindo a mesma idia de criar o cluster no HDInsight, a tarefa de excluir o cluster permite que seja
selecionado o momento de destruir o cluster e parar a cobrana do servio.
Para isso, arraste o componente Azure HDInsight Delete Cluster Task para uma rea vazia do pacote
criado.
Mais uma vez, necessrio configurar a tarefa. Para isso, clique com o boto direito e aponte para
Edit.
As configuraes desta tarefa so mais simples do que da tarefa de criao do cluster. Afinal, j existe
uma AzureSubscriptionConnection configurada e funcionado. Reutilize esta conexo no item que
AzureSubscriptionConnection, e informe tambm o nome do cluster que foi criado no campo
ClusterName. No caso deste captulo, HDInsightNoSSIS. Veja como ficou a configurao desta tarefa.
Confirme a configurao clicando em OK, e repare que o alerta vermelho no existe mais.
Para executar somente esta tarefa, clique com o boto direito e aponte para Execute Task.
Ao trmino, seu cluster ser apagado e voc receber a confirmao com o check verde.
Esta tarefa dispara comandos em HiveQL para o cluster existente. Para garantir que ela v executar
com sucesso, garanta que seu cluster est criado e ainda no tenha sido destrudo. Caso voc j tenha
executado a tarefa de apagar o cluster, execute mais uma vez a tarefa que cria o cluster, como j foi feito
mais acima.
Arraste o controle Azure HDInsight Hive Task para uma rea vazia do pacote, em seguida clique com o
boto direito na tarefa e aponte para Edit.
A configurao relativamente simples, uma vez que j foi feita nas tarefas anteriores e voc j deve
estar familiarizado com elas. A configurao inicial e de informar o AzureSubscriptionConnection e o
HDInsightClusterName. O item novo neste componente o Script que fica dentro do In-Line Script.
Clique nas [] para abrir uma caixa de texto no qual ser inserido o script em Hive. No caso deste
exemplo, que num primeiro momento vai s criar a base de dados, mas que at o final do captulo vai ler
o arquivo do blobStorage e jogar dentro de uma tabela de municpios, foi utilizado este cdigo:
O nome HDInsightNoSSIS foi escolhido para dizer o que esta estrutura faz, mas no necessrio manter
o nome HDInsightNoSSIS na criao do banco s porque criou o cluster com este nome. Fique vontade
para informar o que melhor atende sua necessidade. Confirme o script clicando em OK, e finalize a
configurao da tarefa clicando em OK novamente. Veja que o alerta vermelho desapareceu.
Este cdigo acima responsvel por criar o repositrio, porm, para deixar o projeto como no exemplo
que est na seo de introduo, necessrio quadruplicar esta tarefa, para que outros comandos Hive
sejam disparados ao cluster. Copie e cole o controle mais trs vezes, para totalizar quatro tarefas de
execuo de Hive no pacote.
Para fazer o trabalho completo proposto na seo de introduo deste captulo, uma ordem lgica
deve ser seguida. Acompanhe abaixo a ordem de execuo das tarefas para garantir o funcionamento
adequado.
Para facilitar o desenvolvimento, renomeie as tarefas para um nome amigvel. Isso ajuda na
identificao das tarefas na hora de criar o fluxo de atividades, e depois para ler os logs nas bases de
sistemas do SQL Server.
Em paralelo deve-se executar a tarefa de subir o arquivo para o Blob Storage e de criar o cluster de
HDInsight. Aps a concluso de ambas tarefas, preciso criar o banco de dados atravs de uma execuo
de cdigo Hive. Conecte os componentes de modo a criar esta sequncia. Este processo garante que o
banco s ser criado aps o arquivo ser enviado para o Blob Storage e o cluster ser criado.
Em seguida, conecte a tarefa de criao do banco com as outras tarefas de Hive, na sequncia: Criar a
tabela, carregar os dados, selecionar os dados. Aps a criao do banco, possvel criar a tabela, popular
e consultar.
Por fim, conectamos a tarefa de selecionar os dados, que faz o select e salva o arquivo stdout, s tarefas
Baixar o arquivo e Apagar o cluster. Ambas as tarefas podem ser chamadas simultaneamente. O download
do arquivo stdout e a destruio do cluster acontecem em locais distintos do Azure. Um no interfere no
outro e por isso podem ser disparados simultaneamente.
Lembrando que, se voc seguiu exatamente os passos anteriores como descritos, necessrio alterar
o arquivo que ser baixado para o stdout, que gerado a partir do processamento do select no cluster.
Ao executar o pacote completo o arquivo baixado ficou na pasta especificada. Ao ler o contedo do
arquivo possvel encontrar os dados que foram retornados pelo cluster do HDInsight.
Recursos
Microsoft SQL Server 2014 Integration Services Feature Pack for Azure:
https://www.microsoft.com/en-us/download/details.aspx?id=47366
SQL Server Data Tools Business Intelligence for Visual Studio 2013: https://www.microsoft.com/en-
us/download/details.aspx?id=42313
O SQL Server possui algumas opes de autenticao na hora que o usurio vai acessar o sistema, sendo
eles abaixo:
Figura 1.
Usando esse modo, a autenticao feita com o usurio e senha j cadastrado no Windows, ou seja,
geralmente o mesmo login/senha, usado para acessar a estao de trabalho.
Alm dos usurios do Windows poderem se conectar no SQL Server, grupos de usurios desse sistema
operacional tambm podem se conectar, atravs de um mapeamento no SQL Server.
Ao fazer a instalao do SQL Server no Windows, feito um mapeamento de todos os Administradores
locais, permitindo o acesso dos mesmos, para se conectarem ao SQL Server.
A qualquer momento, pode ser cancelado o acesso do usurio do Windows ao software, para isso,
necessrio primeiro excluir a conta do usurio no Windows, e depois cancelar o mapeamento dentro do
SQL Server.
Esse modo o recomendado pela Microsoft, quando todos os usurios que, se conectam ao SQL Server
usa o Windows, e assim toda a segurana, auditoria e gerenciamento de usurios fica por conta do
Windows e suas ferramentas.
Obs.: (A conta no Windows gerenciada pelo Active Directory ou nos cones ''Usurio'' e ''Senha'').
Mixed Mode
Nesse modo, o usurio se conecta ao sistema atravs de logins exclusivos do SQL Server.
Figura 2.
Papel do Servidor
muito importante estar atento quando se trabalha com logins e usurios, pois deve-se dar ateno
com relao a segurana, e principalmente com relao aos dados e a instncia.
bulkadmin
dbcreator
Os usurios dessa funo podem criar, modificar, eliminar e restaurar banco de dados, podendo
tambm, executar os seguintes comandos: ALTER DATABASE, CREATE DATABASE, DROP DATABASE,
EXTEND DATABASE, RESTORE DATABASE E RESTORE LOG.
diskadmin
Processadmin
securityadmin
Gerencia os logins, d permisso de banco de dados e pode ler o log de erros. Adiciona membros do
securityadmin, dando os direitos de conceder e revogar permisses em nvel de servidor e de banco de
dados. Podem executar os comandos: sp_addlinkedsrvlogin, CREATE LOGIN, ALTER LOGIN, DROP LOGIN,
sp_droplinkedsrvlogin, GRANT CONNECT, DENY CONNECT, sp_helplogins e sp_moteoption.
serveradmin
Define opes de configurao em nvel de servidor e encerra o mesmo. Executam os comandos: DBCC
FREEPROCCACHE, RECONFIGURE, SHUTDOWN, SP_CONFIGURE, SP_FULL_TEXT_SERVICE E
SP_TABLEOPTION.
setupadmin
sysadmin
Tem o controle total sobre o SQL Server, ou seja, pode executar qualquer tarefa.
Funes de Banco de Dados
Essas funes so usadas quando se quer atribuir permisses no nvel de banco de dados. Atravs
dessas permisses, so definidos os acessos a logins e Usurios, a objetos e funcionalidades do servidor
de BD (banco de dados), chamados de Roles.
Public
db_accessadmin
db_backupoperator
db_datareader
Apenas faz uma leitura dos dados, e um SELECT nas tabelas do banco de dados.
db_datawriter
Permite adicionar, modificar e apagar os dados na tabela, atravs dos comandos: INSERT, UPDATE e
DELETE.
db_ddladmin
Permite executar as funes relacionadas as DLL (Linguagem de Definio de Dados), com exceo dos
comandos: GRANT, REVOKE ou DENY.
Db_denydatareader
Db_denydatawriter
Impede a modificao do banco de dados pelo login. No utiliza os seguintes comandos: INSERT,
UPDATE e DELETE.
Db_owner
Possui todo o poder do banco de dados, sendo eles: atribuir permisses, modificar configuraes do
banco, realizar manutenes, e realizar qualquer funo de administrao, podendo at eliminar o banco
de dados.
Db_securityadmin
Dbm_monitor
Monitora o estado atual do espelhamento do banco de dados.
Permisses
O SQL Server possui trs comandos relacionados com as permisses:
GRANT
Permite executar qualquer tarefa
DENY
REVOKE
Remove a permisso GRANT, mas no impede que o usurio execute uma funo ou tarefa.
Principal
Securable
Permission
Figura 3.
Aps logado no SSMS, clicar em new query ou use o comando Ctrl + N, conforme Figura 4.
Figura 4.
Digite o comando ''SELECT * FROM sys.syslogins'', e depois aperte F5, ou execute. Ao executar
essa query, ela retorna todos os logins existentes no SQL Server, conforme Figura 5.
Figura 5.
CREATE LOGIN [Nome da sua conta no windows\Escolha um nome para login] FROM WINDOWS
Exemplo: CREATE LOGIN [Sulamita\Sula] FROM WINDOWS
Figura 6.
Ao ser executado o comando acima (Figura 6), acesse a aba logins (localizada dentro de Security), e
verifique o novo login criado, conforme Figura 7.
Figura 7.
DROP LOGIN [Nome da sua conta no Windows\O login criado], conforme Figura 8.
Exemplo: DROP LOGIN [Sulamita\Sula]
Figura 8.
Aps executado o comando acima (Figura 8), pode ser verificado, conforme Figura 9, que o login criado
foi excludo com sucesso.
Figura 9.
Esse login foi criado usando o Transact SQL Server, agora o mesmo ser criado abaixo, usando a
ferramenta do SSMS.
Clique com o mouse direito em cima da aba Security>Logins>New Login, conforme Figura 10.
Figura 10.
Como o login est sendo criado com o domnio do Windows, a opo Windows Authentication, dever
ser marcada, e logo em seguida, clique em search, conforme Figuras: 11 e 12.
Figura 11.
Figura 12.
Ao selecionar a opo ''Avanado'', clique em ''Localizar agora'' e procure pelo login que foi criado no
Windows, conforme Figuras 13, 14 e 15.
Figura 13.
Figura 14.
Figura 15.
Clique em ok. O login criado, pode ser verificado, abrindo as abas SECURITY>Logins, conforme Figura
16.
Figura 16.
Pronto, criado o login pelo modo Authentication Windows, tanto via Transact-SQL, quanto via
Ferramenta SSMS.
Logue pelo Modo Windows Authentication Server, abra uma janela pelo comando Ctrl + N, ou clique
em New Query.
Figura 17.
Comando criado com sucesso.
Depois de criado o login (Figura 17), faa uma nova conexo, e logue com o login criado, conforme
Figura 18.
Figura 18.
Figura 19.
Para excluir o login pelo Transact SQL, logue no modo Authentication Windows e digite o comando:
Abra as abas Security>Logins, escolha o login que deseja ser excludo, clique com o boto direito do
mouse, selecione a opo DELETE, conforme Figura 21.
Figura 21.
Manipulao dos Usurios via Transact SQL
De uma forma simples, ser feita a criao dos Usurios, com e sem comandos, para isso, necessrio
fazer a conexo com algum banco de dados atravs do comando abaixo:
Figura 22.
O comando sp_helpuser, ao ser executado mostra quais usurios esto ligados a determinado banco,
conforme Figura 23.
Figura 23.
CREATE USER [Nome desejado] FOR LOGIN [Nome da conta do Windows\Login desejado]
Exemplo: CREATE USER [Sula] FOR LOGIN [Sulamita\Sula]
Figura 24.
Figura 25.
Figura 26.
Criando um Usurio sem mapear um Login
Figura 27.
Figura 28.
Abra o SSMS, acesse a aba do Banco de Dados que deseja criar o usurio e, em seguida, abra a aba
Security, clicando com o boto direito do mouse em cima de User>New user, conforme Figura 29.
Figura 29.
Aps clicar em New User, aparecer uma janela, no campo User Name, coloque o nome do usurio a
ser criado, conforme Figura 30.
Figura 30.
Prximo passo ser clicar no browser para verificar quais logins existem, e selecionar qual login do
domnio esse usurio ir pertencer, conforme Figura 31.
Figura 31.
Figura 32
Aps selecionado o login desejado, conforme Figura acima (Figura 32), clique em ok.
Aps criado o usurio, e o ter vinculado ao login, abra a aba Database -> Banco de Dados -> Security,
e confirme a criao do usurio, conforme Figura 34.
Figura 34.
Aps criado o usurio, clique com o boto do mouse direito em properties -> Membership, para
atribuir as permisses a nvel de banco de dados (Roles), conforme Figura 35.
Figura 35.
Depois de dado as permisses para o usurio, clique nas abas: Security ->logins, selecione o login
desejado, clique com o mouse direito em cima dele, e selecione properties, conforme Figuras 36 e 37.
Figura 36.
Figura 37.
Selecione Server Roles(Figura 37), e escolha qual privilgio(s), o login poder ter.
Concluso
Esse artigo teve o objetivo de mostrar passo a passo a criao de um login e usurio, e seus acessos a
instncia, e permisses ao banco de dados!
Column Store Index
Veja neste capitulo o que o columnstore ndice e como implement-lo. Voc tambm
ir aprender em que cenrios so ideias o uso dessa poderosa funcionalidade no sql server.
Necessidade de Negcios
Nos dias atuais muito se fala sobre grande quantidade de dados sendo exposta para tomada de
deciso, clculos massivos, transformaes de grandes volumes de dados e etc. Para atender essa
necessidade a indstria de TI tem respondido com velocidade e disponibilizado diversos recursos para
atender o business dos mais diversificados segmentos.
Hoje a maioria dos negcios desejam aproveitar o mximo de infraestrutura contratada, sejam elas
em seu prprio datacenter ou na nuvem, que uma tendncia cada vez mais comum nos dias atuais.
Fazer com que o software que foi adquirido ou desenvolvido faa bom proveito dos recursos que, muitas
vezes so limitados e um desafio dirio para que o negcio seja mais eficiente e a TI no seja apenas
"custo".
Levando em considerao que, ainda h as limitaes em termos de recursos finitos que existem CPU,
memria, disco e rede. Avanos como ColumnStore ajudam atravs do aumento da taxa de transferncia
de dados, capacidade de armazenamento utilizando o mesmo conjunto de recursos finitos. Alm disso, o
ColumnStore foi projetado para funcionar em qualquer implementao de hardware existente,
garantindo que voc no precisa necessariamente colocar todos os dados da tabela em memria (se voc
tiver recurso sobrando, isso seria timo).
Como sabemos, uma das funes de um banco de dados fazer cache de dados que significa: ler dados
do disco e coloc-los na memria para que o acesso seja realizado de forma mais performtica. Quando
uma consulta executada, o SQL Server deve optar pelos mtodos de acesso que sejam mais eficientes
para uma consulta e trazer os dados para memria. O ColumnStore index ajuda o SQL Server a enderear
essa utilizao de memria de maneira eficiente com o hardware existente que voc j possui, isso
significa que: voc pode ter ganhos de desempenho dependendo do seu workload (OLTP ou OLAP) sem
necessidade de fazer novos investimentos de hardware.
ColumnStore ndices funcionam muito bem para workloads que realizam mais leituras em grandes
conjuntos de dados como por exemplo: sumarizao de dados. Workloads que nasceram com
caractersticas OLTP e por algum motivo ou solicitao do usurio necessrio a aplicao tambm
possuir caractersticas analticas. Geralmente consultas que realizam grandes varreduras de dados, no
caso, SCANs.
Aonde utilizar?
ColumnStore ndices no SQL Server podem ser utilizados para acelerar significativamente o tempo de
processamento de consultas que armazenam seus dados, no caso, dados que so armazenados em B-Tree
(rvore balanceada) ou HEAP, utilizados para gerar informao para sistemas de tomada de deciso.
A vantagem do ColumnStore Index permite voc obter desempenho das consultas de sumarizao sem
necessitar, por exemplo, do pr-clculo dos dados da tabela, como citado anteriormente.
Aonde no utilizar/evitar!!
Se voc costuma atualizar os dados em uma tabela, se necessrio atualizar uma grande massa de
registros ou se as caratersticas de suas consultas sempre retornam uma pequena quantidade de registros,
o ColumnStore ndice no se encaixa nas suas necessidades. Pois, se a maioria de suas consultas so
pequenas, talvez buscar em um ndice B-Tree pode ser mais rpido do que ColumnStore Index.
Fique atento, pois, uma funcionalidade no pode resolver todos os problemas de um cenrio. O que
geralmente vejo em campo uma avaliao malfeita de um determinado recurso. Por exemplo, o cliente
tem um problema especfico que deseja resolver, mas, elege uma funcionalidade para atend-lo sem
conhecer as limitaes da mesma. Aps a implementao percebe que o seu problema no foi totalmente
sanado e faz uma avaliao equivocada do recurso. A minha dica aqui : avalie todos os cenrios que voc
precisa atender e teste.
Armazenamento Atual
No SQL Server, os ndices so organizados como B-Tree. O n superior da B-Tree chamado de n raiz
(root). Os nveis inferiores dos ns no ndice so chamados de folha (leaf level). Quaisquer nveis de ndice
entre o n raiz e folha so conhecidos como nveis intermedirios (intermediate level). Em um ndice
clusterizado, os ns folha contm as pginas de dados da tabela propriamente dita. Os ns do nvel
intermedirio e raiz contm pginas de ndice com ponteiros para os dados, isso significa que, pginas
do nvel intermedirio e raiz no possuem dados e sim apontamentos para os mesmos. Cada linha de
ndice contm um valor de chave e um ponteiro para uma pgina de nvel intermedirio na rvore ou
ponteiro para uma linha de dados no nvel folha do ndice. As pginas de cada nvel do ndice so
vinculadas, conhecidas como "doubly-linked list" (lista duplamente encadeada).
Dependendo dos tipos de dados da tabela, cada estrutura de ndice clusterizado ter uma ou mais
unidades de alocao para armazenar e gerenciar os dados de um particionamento especfico. No mnimo,
cada ndice clusterizado ter uma unidade de alocao IN_ROW_DATA por particionamento. O ndice
clusterizado tambm ter uma unidade de alocao LOB_DATA por particionamento se contiver colunas
LOB, e ter uma unidade de alocao ROW_OVERFLOW_DATA por particionamento no caso de haver
colunas de comprimento varivel excedendo o limite de tamanho de linha de 8.060 bytes.
As pginas da cadeia de dados e as linhas so classificadas pelo valor da chave de ndice clusterizado.
Todas as inseres so feitas no ponto em que o valor de chave da linha inserida se ajusta sequncia de
classificao entre as linhas existentes.
https://technet.microsoft.com/pt-br/library/ms177443(v=sql.105).aspx
CSI VS B-Tree
Quando os dados so armazenados de maneira colunar utilizando o columnstore ndice, os dados
muitas vezes podem ser comprimidos de forma mais eficaz do que quando armazenados no formato de
linha. Tipicamente existe mais redundncia dentro de uma coluna do que dentro de uma linha, o que
geralmente significa que os dados podem ser comprimidos em uma taxa muito maior. Quanto mais
compacto o dado, menos IO necessrio para trazer os dados para a memria, isso significa maior
quantidade de informao por segmento. Reduzir IO pode acelerar significativamente o tempo de
resposta das consultas. Fazer com que maior parte dos seus dados permaneam na memria tambm ir
acelerar o tempo de resposta para consultas subsequentes que acessam os mesmos conjuntos de dados.
Imagine o seguinte cenrio: Se uma consulta apenas referncia algumas das colunas da tabela,
necessrio apenas para um subconjunto das colunas a serem buscados do disco ou na memria. Por
exemplo, se uma consulta referente s 10 colunas de uma tabela com 100 colunas (ou seja, 10% das
colunas), IO reduzido em 90% (alm de quaisquer benefcios de compresso).
Por outro lado, o armazenamento de colunas em estruturas independentes significa que os dados
devem ser combinados para retornar os dados como uma linha. Quando uma consulta "toca" apenas um
(ou alguns) registro (s), tendo todos os dados para uma linha armazenada em conjunto pode ser uma
vantagem, caso a linha possa ser rapidamente localizada com um ndice B-tree. Armazenamento em linha
pode oferecer melhor desempenho para consultas muito seletivos, tais como consultas que procuram
uma nica linha ou um pequeno intervalo de linhas (Estamos falando de Seeks, ok?).
Archival Compression
Columnstore ndice e tabelas so sempre armazenados utilizando os algoritmos de compresso do
Columnstore. Voc pode reduzir ainda mais o tamanho dos dados Columnstore, configurando uma
compresso adicional chamado de archival compression. Para realizar essa compresso o SQL Server
utiliza o algoritmo de compresso XPRESS Microsoft (https://msdn.microsoft.com/en-
us/library/hh554002.aspx) sobre os dados.
Use a compactao do archival compression somente quando voc pode se dar ao luxo de usar
recursos de tempo e CPU extra para comprimir e recuperar os dados ou para dados histricos com baixa
utilizao.
Um cenrio poderia ser onde existe uma tabela particionada em que as parties histricas no so
acessadas com frequncia ou no so mais acessadas por caractersticas do negcio e ocupam um espao
considervel de armazenamento. Nesse caso, avaliar a utilizao do archival Compression pode fazer
sentido. Ns iremos abordar mais nesse capitulo, mas, por enquanto essa introduo deve bastar junto
com o link de referncia.
http://msdn.microsoft.com/en-us/library/cc280449(v=sql.120).aspx
No SQL Server 2012 no era possvel criar um ColumnStore ndice clusterizado, apenas um ndice no
clusterizado. A partir do SQL Server 2014 possvel criar ColumnStore ndice clusterizado e no
clusterizado algo que no era possvel at ento. A sintaxe para criar ambos, so muito semelhantes, no
entanto, eles possuem algumas pequenas particularidades e caractersticas.
No caso do ColumnStore ndice no clusterizado ele tem a limitao de quantidade de colunas, que
atualmente no possvel ter mais que 1024 colunas para esse tipo de ndice. Como um ndice no
clusterizado o ColumnStore ndice no possui todas as colunas da tabela, pois, ele armazena apenas uma
cpia dos dados para as colunas que fazem parte do ndice. Embora seja uma boa prtica criar um
ColumnStore ndice com todas as colunas, isso far com que as consultas nessa tabela sejam cobertas.
Uma grande novidade no SQL Server 2016 que esse tipo de ndice poder ser atualizvel, isso significa
que, no mais necessrio destruir/desabilitar o ndice para realizar atualizaes/inseres de novos
registros. No BOL (books online) tem uma lista de todas as limitaes dessa funcionalidade.
O ColumnStore clusterizado teve sua primeira apario no SQL Server 2014, que se trata de um ndice
baseado em coluna que pode sofrer atualizaes, no entanto, o ColumnStore ndice clusterizado toda
a tabela. Isso significa que em uma mesma tabela no possvel ter um ColumnStore ndice clusterizado
e outro ColumnStore ndice no clusterizado, limitao que foi removida na atual verso do SQL Server,
no caso, o SQL Server 2016. Devido ao fator de ser clusterizado, todas as colunas fazem parte do ndice,
ento esse tipo de ndice um ndice totalmente coberto.
A sintaxe para a utilizao da instruo T-SQL CREATE COLUMNSTORE INDEX est especificada na
documentao oficial do produto (https://msdn.microsoft.com/pt-br/library/gg492153.aspx).
Row Groups e Segmentos
Sei que at o momento ns falamos de bastante teoria e apenas conceitos, mas, lembre-se. Conceitos
e teorias so extremamente importante e apenas "saber na prtica", pode no lhe ajudar quando voc
encarar um problema no dia-a-dia.
Para ter uma alta performance e uma alta taxa de compresso, o ColumnStore ndice "corta/divide" a
tabela dentro grupo de linhas, conhecidas como ROWGROUPS. Aps isso, o SQL Server realiza a
compresso em formato de colunas (segmento). O nmero de linhas armazenado no ROWGROUP deve
ser grande o suficiente para ter ganho na taxa de compresso e pequeno o suficiente para se beneficiar
da utilizao de memria para criao dos segmentos. Por enquanto no se preocupe, ns iremos
clarificar esses pontos mais frente.
Vamos tentar explicar isso de maneira muito simples. Imagine que voc possui uma tabela com alguns
milhes de linhas. O SQL Server "coloca" uma linha imaginria para "cortar" em aproximadamente 1
milho de linhas. Que ficar com algo parecido mais ou menos conforme a figura abaixo:
Depois que essa tabela "cortada" o SQL Server separa em colunas, que conhecemos como
segmentos:
Figura 3 - Criao de segmentos.
Depois que as colunas esto segmentadas, o SQL Server aplica a compresso em cada segmento.
Basicamente o ColumnStore ndice composto por ROWGROUP e segmentos. Para clarificar esse
tpico coloquei alguns pontos sobre eles:
Um ROWGROUP geralmente possui o mximo de linhas permitidas em um ROWGROUP, que de
1,048,576.
Segmentos so dados de uma coluna dentro de um determinado ROWGROUP.
Cada ROWGROUP contm uma coluna de um segmento para toda coluna da tabela por partio (se
a tabela for particionada)
Cada segmento uma unidade de transferncia de IO que significa que o SQL Server ir colocar um
segmento por vez na memria e no apenas alguns dados desses segmentos.
Ao contrrio do In-Memory OLTP (a.k.a Hekaton) o ColumnStore ndice utiliza os mecanismos de
armazenamento do SQL Server para que cada segmento seja armazenado em disco.
Os dados que foram utilizados para carregar essa tabela, so os dados da tabela Sales.SalesOrderDetail
do banco de dados AdventureWorks2012.
Agora vamos criar um ndice clusterizado para a nossa tabela, conforme script a seguir:
Agora que o nosso ColumnStore ndice no clusterizado foi criado, ns iremos executar duas consultas
de sumarizao de dados para poder verificar qual o ganho de desempenho de ambas. Conforme script a
seguir:
DBCC DROPCLEANBUFFERS
go
SET STATISTICS TIME, IO ON -- + Ctrl + M
GO
select ProductID AS IdProduto, Sum(OrderQty) as SomaQuantidade, SUM(LineTotal) AS
SomaLinhaTotal,
Avg(UnitPrice) As MediaPrecoUnico,
Avg([UnitPriceDiscount]) as MediaDesconto
from [dbo].CSTable
where [UnitPriceDiscount] <> 0.00
Group by ProductID
OPTION (IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX); -- Apenas para testes
GO
SET STATISTICS TIME, IO OFF
GO
DBCC DROPCLEANBUFFERS
go
SET STATISTICS TIME, IO ON -- + Ctrl + M
GO
select ProductID AS IdProduto, Sum(OrderQty) as SomaQuantidade, SUM(LineTotal) AS
SomaLinhaTotal,
Avg(UnitPrice) As MediaPrecoUnico,
Avg([UnitPriceDiscount]) as MediaDesconto
from [dbo].CSTable
where [UnitPriceDiscount] <> 0.00
Group by ProductID
GO
GO
SET STATISTICS TIME, IO OFF
Mas o que mais impressiona o consumo de recursos que o SQL Server utilizou para essa consulta.
Verifique a sada do comando: SET STATISTICS TIME, IO ON.
IO
Table 'CSTable'. Scan count 1, logical reads 26113, physical reads 1, read-ahead reads
26109, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
CPU
SQL Server Execution Times:
CPU time = 1281 ms, elapsed time = 3055 ms.
Avaliando a segunda consulta podemos perceber que o SQL Server utilizou um operador de
Columnstore Index Scan, conforme a seguir:
E se tratando de recursos ele utilizou muito menos recurso que o Clustered Index Scan da primeira
consulta:
Table 'CSTable'. Scan count 1, logical reads 663, physical reads 19, read-ahead reads
864, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SQL Server Execution Times:
CPU time = 109 ms, elapsed time = 255 ms.
Concluso
Como podemos ver o ColumnStore ndice pode nos trazer ganhos de performance quando utilizado no
cenrio ideal, sendo assim, podemos dizer que o ColumnStore ndice atende as consultas que devem ser
tratadas com caractersticas analticas, mesmo estando em um ambiente OLTP, e para modelos de dados
Star Schema e SnowFlake. O ColumnStore ndice pode ser uma poderosa funcionalidade em cenrios de
big data e data warehousing, onde se necessrio lidar com uma imensa quantidade de dados e possveis
cargas D-1.
Esse captulo trouxe uma breve introduo do ColumnStore ndice, mas, ainda existem diversos
conceitos que podem ser abordados com essa funcionalidade, como por exemplo: data store, delta store,
tuple mover e etc.
Como lio de casa, existem diversas fontes que podem ajud-los no dia-a-dia. Eu particularmente
gosto das trs fontes a seguir: MSDN, Technet e uma outra referncia bem legal deste assunto o blog
do Niko (http://www.nikoport.com/columnstore/), que Data Plataform MVP e desenvolvedor de
software que vive em Portugal.
Referncias
https://technet.microsoft.com/pt-br/library/ms177443(v=sql.105).aspx
http://msdn.microsoft.com/en-us/library/cc280449(v=sql.120).aspx
https://msdn.microsoft.com/pt-br/library/gg492153.aspx
https://msdn.microsoft.com/en-us/library/dn589806(v=sql.120).aspx
http://www.nikoport.com/columnstore/
Lock Escalation no SQL Server
Este artigo oferece uma anlise sobre o funcionamento do mecanismo de lock escalation
no SQL Server, descrevendo alguns cenrios onde o efeito pode trazer impacto negativo ou
benefcio para o ambiente. O captulo composto por scripts para que o leitor possa testar
e analisar o lock escalation em seu laboratrio, permitindo ganhar uma maior densidade
tcnica a certa do tema.
Introduo
O objetivo deste artigo explicar o que o lock escalation, como funciona no SQL Server e citar alguns
cenrios que envolvem o lock escalation, e potencialmente podem trazer problema para seu ambiente.
Este um artigo de nvel intermedirio e parte do pressuposto que o leitor j possui um conhecimento
bsico dos modelos de concorrncia utilizados em bancos de dados relacionais.
Lock escalation, ou escalao de travas (ficarei com o nome em ingls ao longo do artigo), um
mecanismo comum em bancos de dados relacionais, no qual o motor relacional opta por trocar uma srie
de travas de menor granularidade (ex.: travas de registros) por uma trava de maior granularidade (ex.:
trava de tabela), com o intuito de facilitar o gerenciamento das travas, ao custo de uma maior
concorrncia, com menos operaes acessando simultaneamente os dados de um objeto.
Tecnicamente a traduo do termo lock como bloqueio no a ideal, pois quando o banco
de dados protege o registro ou outro objeto qualquer, no necessariamente teremos uma nova
requisio tentando acessar o mesmo elemento, o que resultaria em uma operao sendo bloqueada.
Portanto a traduo mais adequada deve ser trava, e esta ser usada em todo o artigo.
Dito isso, confesso que ainda estou me adaptando a usar o termo, tentando tirar o vcio de anos
falando bloqueio ou simplesmente lock, produzindo frases com uma miscelnea de Portugus e Ingls.
Para exemplificar um pouco da motivao do lock escalation, vamos utilizar o script 01, que cria uma
tabela, insere 10 milhes de registros. Em seguida, com lock escalation desabilitado, feita uma
atualizao de todas as linhas da tabela com a hint rowlock, mantendo travas de registros durante toda a
transao. Vale ressaltar que foi tomado o cuidado de limitar a memria do SQL Server a 4 GB (4096 MB),
que ser til para ilustrarmos outro ponto mais frente neste artigo.
USE master
GO
IF (DB_ID('Mastering') IS NOT NULL)
DROP DATABASE Mastering
GO
CREATE DATABASE Mastering
go
USE Mastering
GO
IF (OBJECT_ID('dbo.LockEscalation') IS NOT NULL)
DROP TABLE dbo.LockEscalation
GO
CREATE TABLE dbo.LockEscalation
(Codigo INT IDENTITY NOT NULL PRIMARY KEY,
Nome VARCHAR(100) NOT NULL,
DataHora DATETIME2 NOT NULL DEFAULT SYSDATETIME())
GO
INSERT INTO dbo.LockEscalation (Nome)
VALUES ('Sr. Nimbus'), ('SQL Server'), ('Expert')
GO
INSERT INTO dbo.LockEscalation (Nome)
SELECT TOP 1000000
XMP.name + XOC.name
FROM sys.dm_xe_map_values AS XMP
CROSS APPLY sys.dm_xe_object_columns AS XOC
GO 10
SELECT TOP 100 * FROM dbo.LockEscalation;
SELECT COUNT(*) FROM dbo.LockEscalation;
GO
ALTER TABLE dbo.LockEscalation
SET (LOCK_ESCALATION = DISABLE);
GO
EXEC SP_CONFIGURE 'MAX SERVER MEMORY', 4096
RECONFIGURE
GO
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
GO
BEGIN TRANSACTION
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome
SELECT @@TRANCOUNT
-- Verificar a conexo de monitoramento antes do commit
COMMIT TRANSACTION
/*
Conexo de monitoramento
*/
SELECT * FROM SYS.dm_os_memory_clerks ORDER BY pages_kb DESC
SELECT COUNT(*) FROM sys.dm_tran_locks
Go
Para os mais curiosos, um pouco do detalhe de funcionamento do SQL Server: Nas verses de 64 bits
do produto so necessrios 64 bytes para identificar o lock owner (dono da trava), que a identificao
da sesso/transao que requisitou a trava, e 128 bytes para o lock resource (recurso da trava),
responsvel por representar qual a estrutura est sendo protegida e sua identificao (ex.: objectid da
tabela, RID do registro, entre outros). Ressalto que existem outras informaes nessas estruturas de
dados, mas por simplicidade a explicao acima suficiente para este artigo.
Uma dvida comum dos profissionais se o SQL Server primeiro escala as travas para o nvel
de pgina, posteriormente chegando ao nvel de tabela. E a resposta NO, o SQL Server NUNCA escala
as travas para o nvel de pgina, somente para a tabela ou para a partio, caso esteja adequadamente
configurado para isto.
No entanto, caso o lock manager opte por pegar travas de pginas ao invs de proteger o
registro, o lock escalation ainda pode acontecer, promovendo a trava para a tabela ou partio. Neste
artigo voc no ver isto acontecendo porque est sendo forado a trava de registro com a hint
ROWLOCK, contudo este comportamento facilmente confirmado colocando-se a hint PAGLOCK ou
quando o lock manager opta por proteger as pginas de dados.
Utilizando o script 02, inserimos mais 10 milhes de registros no banco de dados e fazemos novamente
a operao de atualizao de todos os registros. Dessa vez, ao invs da transao completar com sucesso,
recebemos esta exceo: Msg 1204, Level 19, State 2, Line 105 The instance of the SQL Server Database
Engine cannot obtain a LOCK resource at this time. Rerun your statement when there are fewer active
users. Ask the database administrator to check the lock and memory configuration for this instance, or to
check for long-running transactions.
Um resultado nada bom para nossa transao, onde atingimos o limite de espao em memria que o
lock manager pode alcanar (com base no 4GB definido para max server memory), causando o rollback
da transao. Isto acontece pelo fato da operao estar impossibilitada de conseguir mais uma trava, s
restando ao SQL Server desfazer todas as X milhes de atualizaes executadas at aquele momento,
dentro do mesmo contexto transacional. O total de memria alocado para o lock manager foi de
aproximadamente 2,5 GB (o que equivale a algo em torno de 60% de 4GB), atingindo o limite permitido
pelo SQL Server para esta rea de memria, conforme figura 02.
USE Mastering
GO
INSERT INTO dbo.LockEscalation (Nome)
SELECT TOP 1000000
XMP.name + XOC.name
FROM sys.dm_xe_map_values AS XMP
CROSS APPLY sys.dm_xe_object_columns AS XOC
GO 10
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
GO
BEGIN TRANSACTION
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome
SELECT @@TRANCOUNT
-- Erro na transao...
COMMIT TRANSACTION
/*
Conexo de monitoramento
*/
SELECT * FROM SYS.dm_os_memory_clerks ORDER BY pages_kb DESC
SELECT COUNT(*) FROM sys.dm_tran_locks
GO
Vamos agora executar a mesma operao (script 03) permitindo que o lock manager faa o lock
escalation, quando a engine achar necessrio. Isso feito configurando a propriedade
LOCK_ESCALATION do objeto para AUTO, que a configurao padro que havia sido alterada no
script 01.
USE Mastering
GO
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
GO
ALTER TABLE dbo.LockEscalation
SET (LOCK_ESCALATION = AUTO);
GO
BEGIN TRANSACTION
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome
SELECT @@TRANCOUNT
-- Verificar a conexo de monitoramento antes do commit
COMMIT TRANSACTION
/*
Conexo de monitoramento
*/
SELECT * FROM SYS.dm_os_memory_clerks ORDER BY pages_kb DESC
SELECT COUNT(*) FROM sys.dm_tran_locks
SELECT * FROM sys.dm_tran_locks
GO
Neste caso, ao fim da execuo no recebemos mais a exceo. E de acordo com a figura 03, podemos
notar dois aspectos:
1. O consumo de memria do lock manager est muito baixo, com aproximadamente 2 MB;
2. Existem somente 7 travas para todo o SQL Server, sendo que a nica relevante a trava em modo
exclusivo (request mode X) no recurso 82099333, que o object_id da tabela LockEscalation.
Figura 03 Consumo do lock manager aps lock escalation
Durante a execuo da transao o SQL Server decidiu que seria interessante fazer o lock escalation,
isto , ao invs de manter em memria as estruturas de dados necessrias para representar milhares de
travas de registros, o lock manager opta por utilizar uma trava na tabela inteira (escalar a trava),
minimizando o custo do gerenciamento dos lock resources, sacrificando a concorrncia no acesso ao
objeto.
este trade-off do lock escalation que importante ressaltarmos, gerenciar menos estruturas de
dados diminuindo o acesso concorrente, ou ficar com um custo alto de gerenciamento das travas e
permitir acessos concorrentes em diferentes pontos da tabela (desde que no exista acessos simultneos
aos mesmos registros).
Voc, caro leitor, talvez esteja se perguntando: Este parece ser um mecanismo desnecessrio, afinal
as mquinas com o SQL Server em produo tm muito mais memria que 4GB e nunca um desenvolvedor
ou administrador de banco de dados faria uma transao envolvendo milhes de registros....
HAHAHAHAHAHAHAHAHAHAHAHAHAHA.... Desculpe-me ...HAHAHAHAHAHAHAHAHAHAHA.... Agora
que recuperei o flego, devo dizer que j presenciei esse cenrio diversas vezes, ento dado a quantidades
de ambientes existentes que eu no administro, diariamente existe algum DBA presenciando cenrio
semelhante.
Quando o nmero de travas em um objeto, que uma nica instruo conseguiu, ultrapassar o valor
de 5000.
Quando a memria utilizada para armazenar os lock resources ultrapassar 24% da memria utilizada
pela engine do SQL Server.
Note que estes so valores internos de referncia para a o SQL Server e que podem ser alterados em
verses ou Service Packs futuros.
Sabendo dos limites acima, para verificar quando efetivamente acontece o lock escalation, vamos fazer
uso dos Extended Events (xEvents ou XE), monitorando dois eventos: lock_acquired e lock_escalation,
tomando o cuidado de filtrar pelo identificador do banco de dados onde estamos conduzindo os testes,
que durante a montagem deste artigo foi o database_id de nmero 7 (ajuste o seu script de acordo com
seu ambiente).
USE Mastering
GO
-- SQL Server 2014
SELECT @@VERSION
SELECT DB_ID()
go
CREATE EVENT SESSION xMonitorLocks
ON SERVER
ADD EVENT sqlserver.lock_acquired (WHERE sqlserver.database_id = 7)
, ADD EVENT sqlserver.lock_escalation (WHERE sqlserver.database_id = 7)
ADD TARGET package0.ring_buffer
GO
ALTER EVENT SESSION xMonitorLocks
ON SERVER
STATE = START
GO
BEGIN TRANSACTION
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo < 10000
SELECT @@TRANCOUNT
COMMIT TRANSACTION
SELECT name, target_name, CAST(xet.target_data AS xml)
FROM sys.dm_xe_session_targets AS xet
JOIN sys.dm_xe_sessions AS xe
ON (xe.address = xet.event_session_address)
WHERE name = 'xMonitorLocks'
GO
ALTER EVENT SESSION xMonitorLocks
ON SERVER
STATE = STOP
GO
DROP EVENT SESSION xMonitorLocks ON SERVER
Go
Aqui o detalhamento fica um pouco mais complicado, pois no XML de sada do monitor foram
registrados 6252 eventos, sendo que a penltima entrada o evento de lock escalation. Isto , 6250
travas foram adquiridas antes do lock escalation acontecer, e provavelmente voc esperava que o lock
escalation acontecesse depois de 5000 eventos registrados no ring buffer do xEvent.
Figura 04 Sada do monitoramento xEvent
Se voc estiver com coragem e quiser validar quando o SQL Server verifica se pode fazer um lock
escalation, sugiro uma pequena brincadeira. Utilize o Windbg e coloque um breakpoint em
sqlmin!IsEscalationPossible, disparando diferentes transaes e monitorando as travas que pertencem
a sua transao (filtro por request_owner_lockspace_id), conforme o script 05. Assim voc vai notar que
somente em alguns momentos o SQL Server verifica se possvel fazer o lock escalation (exatamente a
cada 1250 chamadas do mtodo GetLock, a partir de 2500 travas do mesmo dono), encontrando uma
stack trace semelhante ao da figura 05. Isso evita que a engine gaste tempo precioso validando a todo
momento se vale a pena fazer lock escalation.
Cenrio 01
O primeiro cenrio, e provavelmente mais comum, seria uma transao que segue um esquema
parecido com a estrutura definida no pseudocdigo abaixo:
BEGIN TRANSACTION
UPDATE de 10.000 registros da tabela de vendas (principal objeto do banco)
SELECT de 1 registro na tabela B
COMMIT TRANSACTION
Caso o lock escalation acontea no primeiro UPDATE e a transao fique bloqueada por trinta segundos
ao tentar ler um registro da tabela B, toda e qualquer operao de registro de venda ficar bloqueada at
que esta transao se conclua, o que no seria nada bom para uma empresa de e-commerce, por exemplo.
Voc poderia minimizar o potencial problema desta transao diminuindo o nmero de registros
atualizados, ou tentando colocar o SELECT fora da transao ou antes do UPDATE (caso o negcio
permita).
Cenrio 02
Neste cenrio temos transaes concorrentes que impedem o lock escalation, de acordo com o cdigo
abaixo. Como as transaes esto em execuo antes de atingir o limite para o lock escalation, o SQL
Server vai verificar que no possvel escalar as travas, pois existe outra transao bloqueando registros
e impedindo o lock escalation acontecer. Caso as operaes sejam grandes e o lock manager fique sem
memria disponvel, o resultado ser novamente o erro Msg 1204, Level 19, State 4, Line 4 - The instance
of the SQL Server Database Engine cannot obtain a LOCK resource at this time., para ambas as transaes.
Script 06 Cenrio 02
BEGIN TRANSACTION
SELECT @@TRANCOUNT
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo <= 1
-- Outra transao executa seu primeiro update
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo <= 10000000
COMMIT
BEGIN TRANSACTION
SELECT @@TRANCOUNT
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo = 10001000
-- Outra transao executa seu primeiro update
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo >= 10001001
COMMIT
Cenrio 03
Caso tenhamos diversas operaes dentro da mesma transao, em que cada operao manipule um
conjunto de registros que no chegue ao limite de travas adquiridas para causar o lock escalation, mesmo
que a transao acabe com cem mil travas o lock escalation no acontecer, conforme script 07. Note que
o lock escalation ainda est sujeito a acontecer devido ao consumo de memria, portanto dependendo
do seu ambiente e da quantidade de travas gerenciadas pelo lock manager, o lock escalation ainda pode
acontecer seguindo fielmente este exemplo.
Script 07 Cenrio 03
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
GO
SELECT @@TRANCOUNT
BEGIN TRANSACTION
DECLARE @I INT = 0
WHILE (@I <= 100000)
BEGIN
UPDATE dbo.LockEscalation WITH (ROWLOCK)
SET Nome = Nome
WHERE Codigo > @I AND Codigo <= (@I + 5000)
SET @I = @I + 5000;
end
-- Verificar a conexo de monitoramento antes do commit
SELECT @@TRANCOUNT
SELECT COUNT(*) FROM sys.dm_tran_locks
COMMIT TRANSACTION
razovel que em alguns casos o comportamento desejado pelo desenvolvedor seja exatamente este,
o de no atingir o limite do lock escalation, porm para muitos o exemplo acima parecer estranho, por
imaginar que o lock escalation aconteceria.
Cenrio 04
Este cenrio no traz um problema com o lock escalation, pelo contrrio, mostra que em casos onde o
volume de registros manipulados muito grande, o custo para a engine do SQL Server gerenciar os
recursos alto, e quando simplificado pode trazer ganhos significativos de desempenho.
Utilizando o script 07 possvel comparar o desempenho de 10 milhes de updates e a diferena de
desempenho entre uma execuo com lock escalation e outra sem. No meu ambiente de teste, a
comparao de performance a seguinte: 28 segundos sem lock escalation contra 7 segundos quando o
lock escalation acontece.
Script 08 Cenrio 04
CHECKPOINT
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
GO
ALTER TABLE dbo.LockEscalation
SET (LOCK_ESCALATION = DISABLE);
GO
BEGIN TRANSACTION
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo <= 10000000
SELECT @@TRANCOUNT
-- Mdia de 28 segundos
COMMIT TRANSACTION
CHECKPOINT
DBCC FREESYSTEMCACHE('ALL')
DBCC DROPCLEANBUFFERS
GO
ALTER TABLE dbo.LockEscalation
SET (LOCK_ESCALATION = AUTO);
GO
BEGIN TRANSACTION
UPDATE dbo.LockEscalation WITH (ROWLOCK) SET Nome = Nome WHERE Codigo <= 10000000
SELECT @@TRANCOUNT
-- Mdia de 7 segundos
COMMIT TRANSACTION
Concluso
Quando estiver desenvolvendo seu cdigo T-SQL, sempre que for manipular milhares de registros,
procure analisar em que momentos o lock escalation pode acontecer e qual ser efeito para a aplicao
e outras transaes concorrentes, pois um lock escalation no momento errado pode causar srios
problemas de concorrncia no seu banco de dados.
Para este tipo de cenrio, o SQL Server possibilita a coleta de mtricas de desempenho de todas as
instncias e bancos de dados existentes, atravs da ferramenta Data Collector (DC).
Para aumentar a eficincia das mtricas coletadas, deve-se ajustar o DC de acordo com cada ambiente
existente em sua infraestrutura (desenvolvimento, homologao, produo). O DC armazena todas as
informaes coletadas em um datawarehouse de gerenciamento (MDW) e permite que sejam
configurados diferentes perodos de reteno para cada mtrica que ser coletada.
Como o DC possui uma interface de programao (API), podemos customizar coletas para qualquer
outro tipo de mtrica desejada. Porm, neste captulo nos concentraremos apenas nas trs coletas de
sistema do DC: Disk Usage, Query Activity e Server Activity.
Target: Uma instncia de banco de dados SQL Server que suporte o processo de coleta de mtricas
atravs da utilizao do DC;
Target Type: Define o tipo de target do qual sero coletadas as mtricas. Por exemplo, uma instncia
de banco de dados SQL Server possui mtricas diferentes do que as mtricas coletadas de uma
base de dados SQL Server;
Data provider: Uma origem de dados que prover mtricas para o collector type;
Collector Type: Um delimitador lgico para os pacotes do SQL Server Integration Services (SSIS) e
que fornece o mecanismo para a coleta e armazenamento das mtricas no MDW;
Collection Item: um item de coleta no qual so definidas quais as mtricas sero coletadas, com
que frequncia esta coleta ser realizada e qual o tempo de reteno da mtrica armazenada;
Collector Set: Um conjunto de Collection Items;
Collection Mode: A forma que as mtricas sero coletadas e armazenadas no MDW. As mtricas
podem ser coletadas de forma contnua (Cached Mode) ou de forma espordica atravs de um
agendamento (Non-Cached Mode);
Management Data Warehouse (MDW): O banco de dados relacional utilizado para o armazenado
de todas as mtricas coletadas.
Um collector type est associado um determinado target, e que este relacionamento tambm define
como as mtricas sero coletadas e qual o esquema de armazenamento destas mtricas, pois o collector
type tambm fornece a localizao do MDW, que pode ser no servidor que est executando a coleta ou
em um servidor centralizado.
J um collection item possui uma frequncia de coleta pr-definida e s pode ser criado dentro de um
collector set. O collector set, por sua vez, criado na instncia de banco de dados SQL Server que ser
monitorada atravs do DC e composto por um ou mais collection items. A coleta do conjunto de mtricas
definidas no collector set realizada atravs de Jobs executados pelo servio SQL Server Agent, e as
mtricas coletadas so armazenadas no MDW periodicamente por meio de agendamentos pr-definidos.
A Figura 2 mostra um collector set de sistema chamado Disk Usage, no qual visualizamos que a
configurao foi realizada com o collection mode definido como Non-Cached, utilizando dois collection
items do tipo Generic T-SQL Query Collector Type, e que as mtricas sero coletadas a cada 60 segundos,
com reteno destas mtricas no MDW por 730 dias.
Para isso, podemos utilizar um banco de dados relacional j existente e configur-lo como um MDW,
porm recomendvel que seja definido um novo banco de dados, pois durante o processo de
configurao do MDW diversos esquemas e tabelas referentes ao DC sero criadas. Os esquemas gerados
automaticamente aps a configurao do DC so o core e o snapshot. Um terceiro esquema, de nome
custom_snapshots, ser criado quando um collectior set customizado for definido pelo administrador do
banco.
O principal esquema do MDW o core, pois possui as tabelas, stored procedures e views que ficam
disponveis para todos os collector types e que tambm sero utilizadas para organizar e identificar as
mtricas coletadas. Para garantir a integridade e segurana do MDW, todos os objetos de banco de dados
pertencentes ao esquema core s podero ser alterados pelos membros dos perfis de banco de dados
db_owner e mdw_admin.
A Tabela 1 lista todas as tabelas existentes no esquema core e suas respectivas descries.
O esquema snapshot, por sua vez, possui os objetos necessrios para o armazenamento das mtricas
coletadas atravs dos collection sets de sistema. As tabelas deste esquema s podem ser alteradas pelos
membros pertencentes ao perfil de banco de dados mdw_admin.
A Tabela 2 ilustra quais tabelas so utilizadas pelos collection sets de sistema Server Activity e Query
Statistics, criados aps a configurao do DC.
J o esquema custom_snapshot possui as tabelas e views que foram criadas quando um collection set
customizado foi configurado. Qualquer collection set customizado que necessitar de uma nova tabela para
armazenar mtricas coletadas poder criar tabelas neste esquema. As tabelas podem ser adicionadas por
qualquer membro do perfil de banco de dados mdw_writer.
Configurando o Data Collector
Para exemplificar a coleta de mtricas utilizando o DC, teremos a instncia VITADB\SQLCMS,
responsvel por hospedar o banco de dados MDW, e as instncias VITADB\SQLINSTANCE1 e
VITADB\SQLINSTANCE2, que tero suas mtricas coletadas atravs dos collector sets de sistema.
Dito isso, a primeira etapa para configurao do DC a criao do MDW na instncia VITADB\SQLCMS,
conforme os passos a seguir:
Finalizada a configurao da coleta, temos a criao de trs collector sets de sistema: Disk Usage, Query
Statistics e Server Activity. O collector set Disk Usage coleta mtricas sobre o crescimento dos arquivos de
dados (.mdf e .ndf) e dos arquivos de log (.ldf) dos bancos de dados de usurio e de sistemas existentes
na instncia monitorada pelo DC. Com estas informaes possvel saber qual a tendncia de crescimento
dirio, em MB, dos arquivos analisados. A Tabela 2 mostra as propriedades do collector set de sistema
Disk Usage.
Por fim, o collector set de sistema Query Statistics coleta mtricas referentes s consultas executadas
no banco de dados monitorado pelo DC, como estatsticas, planos de execuo, consultas mais custosas
em relao utilizao de disco, CPU, memria e as consultas que mais tempo demoraram para serem
finalizadas. A Tabela 4 mostra as propriedades do collector set de sistema Query Statistics.
No topo do relatrio visualizamos de qual instncia SQL Server so as mtricas exibidas e em que data
e hora foram solicitadas. Abaixo desta informao possvel selecionar qual o perodo de tempo, no qual
as mtricas foram coletadas, deve ser carregado no relatrio. Em cada um dos grficos apresentados,
existem informaes sobre o sistema operacional (linhas de cor verde) e sobre o SQL Server (linhas de cor
azul).
A Figura 7 mostra a parte inferior do relatrio Server Activity History, extrado da instncia
VITADB\SQLINSTANCE2.
Figura 7. Parte inferior do relatrio Server Activity History
Este relatrio lista o tamanho dos bancos de dados monitorados pelo DC e qual a mdia de crescimento
dos mesmos durante um perodo de tempo. As mtricas exibidas pelo relatrio esto separadas por
arquivos de dados e pelos arquivos de log dos bancos de dados monitorados. Como mostra a Figura 8,
cada um dos arquivos de dados e arquivos de log possui a informao do tamanho inicial, do tamanho
atual e a mdia de crescimento por dia em MB.
Figura 8. Relatrio Disk Usage Summary.
O motivo mais comum para os problemas de desempenho encontrados no SQL Server a escrita de
comandos T-SQL de forma ineficiente. Portanto, a coleta de mtricas de desempenho destas consultas
uma parte essencial para o processo de tuning. Por padro, so exibidas as 10 consultas que mais
consumiram CPU, mas possvel alterar este filtro e visualizar as consultas que realizaram mais operaes
de IO, mais tempo ficaram em execuo, realizaram mais leituras fsicas ou realizaram mais escritas
lgicas.
Utilize um servidor centralizado para o MDW, pois isto permite que exista apenas um nico local
para a execuo e visualizao dos relatrios;
Todos os servidores de banco de dados SQL Server que sero monitorados pelo DC devem fazer
parte do mesmo domnio;
Quando criar um collector set customizado utilizando o collector type Generic SQL Trace, defina um
conjunto de filtros para que somente as mtricas realmente necessrias sejam coletadas, pois
desta forma o MDW no armazenar informaes desnecessrias;
Antes de criar um collector set customizado utilizando contadores de desempenho, tenha certeza
de que o collector set de sistema Server Activity j no esteja coletando esta mtrica;
Caso existam coletas de mtricas atravs de vrias consultas T-SQL e estas sejam executadas com a
mesma frequncia, combine-as em um mesmo collector set. Fazendo isso diminuiremos a
quantidade de memria utilizada pelo executvel do DC (DCCEXEC.exe) durante a coleta de
mtricas. De maneira similar, combine vrios collection items do tipo Performance Counters em
um nico collection item sempre que possvel;
Combine vrios collection items em um nico collector set sempre que possvel. O nico motivo
para criarmos collector sets separados se houverem perodos de reteno diferentes ou
agendamento de coletas diferentes;
Um collector set que utilize o collection mode configurado como Cached sempre manter um
processo de coleta em execuo. Se as mtricas forem coletadas frequentemente, isto mais
eficiente do que iniciar e parar o processo de coleta sempre que novas mtricas devam ser
coletadas. Em contraste, o collection mode configurado como Non-Cached no ter um processo
de coleta em execuo durante a maior parte do tempo, ou seja, um novo processo de coleta ser
iniciado de acordo com o agendamento pr-definido e ento ser parado novamente, evitando a
utilizao excessiva dos recursos de hardware do servidor. Assim, caso a coleta de mtricas ocorra
raramente, o collection mode definido como Non-Cached mais eficiente do que deixar o
processo de coleta em espera a maior parte do tempo. Como regra geral, se a mtrica necessita
ser coletada a cada cinco minutos ou mais frequentemente que isso, considere configurar um
collector set que utilize o collection mode: Cached. Caso a coleta de mtricas possa ser realizada
com uma frequncia maior do que cinco minutos, recomendado configurar collector set que
utilize o collection mode: Non-Cached;
Quanto maior a frequncia de coleta, maior ser a sobrecarga no servidor de banco de dados. Deste
modo, opte sempre por configurar a menor frequncia possvel que atenda a necessidade de
coleta.
Concluso
Conforme descrito no captulo, podemos utilizar o Data Collector para facilitar o gerenciamento de um
ambiente de banco de dados SQL Server composto por mltiplas instncias.
Com o DC temos uma funcionalidade que coleta mtricas de todas as instncias SQL Server e as
armazena em um banco de dados centralizado, chamado Management Data Warehouse. Atravs da
configurao do DC e do Management Data Warehouse, so criados trs collector sets de sistema que
coletam mtricas referentes utilizao dos recursos de hardware do servidor (CPU, memria, disco e
rede), crescimento dos arquivos de dados e log dos bancos de dados monitorados alm das consultas T-
SQL mais custosas executadas no servidor de banco de dados e esta coleta realizada por meio de Jobs
definidos no SQL Server Agent.
Vale destacar que o DC fornece tambm uma grande diversidade de relatrios, para que as mtricas
coletadas pelos collector sets possam ser avaliadas durante os processos de troubleshooting e tuning.
Por fim, podemos constatar que o DC uma ferramenta de monitorao completa, mas que precisa
ser configurada da melhor maneira possvel para evitar uma alta sobrecarga nos servidores de banco de
dados.
Pensando fora da caixa SQL Server FCI usando o File Share (SMB3.0)
como opo de Storage
Neste captulo ser apresentado o protocolo SMB 3.0 e como podemos tirar vantagens,
aumentar a disponibilidade e performance do ambiente investindo menos em
infraestrutura.
uma nova alternativa de Storage para cluster SQL Server onde podemos usar n ossa
infraestrutura com mais eficincia e reduzir pontos de falhas no cluster
Existem diversos tipos de Storage que podem ser utilizadas com o SQL Server:
Como podemos notar o SQL nos permite usar diversos tipos de armazenamento para a instalao do
nosso SQL Server e armazenamento das bases de dados.
Existem tambm algumas tecnologias que nos permitem o uso de Failover Clustering SEM a
necessidade de uma shared Storage:
Neste captulo focaremos no SMB que como vimos podemos usar em um SQL Server stand-
alone ou em cluster (FCI)
Storage HDD vs SSD
muito importante em cenrios com gargalos de I/O entendermos que disco temos em nosso
ambiente e qual a performance oferecida por estes discos, ento vamos comparar a performance entre
os discos SSD e os discos mecnicos (HDD):
Como podemos notar o HDD no tem bom desempenho em I/O randmico o SSD tem excelente
desempenho para o I/O randmico, as placas PCI-E so as melhores.
Obviamente que o disco mais lento mais barato e o disco com melhor desempenho mais caro, logo,
para alguns cenrios de gargalo de I/O a simples troca do disco por um SSD ou placas PCI-E no so to
viveis devido ao custo.
Comparativo de Desempenho de I/O
Para comparar os desempenhos dos discos citados anteriormente, executei um simples teste de I/O
em um storage compartilhado em um data center o que um cenrio muito comum nos ambientes atuais,
nem toda empresa tem um capital para dedicar um storage para um determinado servio, executei
tambm o mesmo teste em um disco SSD local e em um disco de uma Storage High-End dedicada para o
SQL.
Como podemos perceber, temos 3 tipos de soluo onde a mais barata a storage compartilhada com
discos SAS e a mais cara (e pe cara nisto ) a storage high-end que custa alguns milhes de reais.
Comparativos de Storages
Read IO Write IO Total IO
32768
8192
2048
512
128
32
8
2
0,5
I/O I/O I/O
MB/s per s AvgLat MB/s per s AvgLat MB/s per s AvgLat
Storage Comp. SSD High-end
Read IO 66,25 8479,36 6,978 146,66 18772 2,698 181,5 23232,6 2,469
Write IO 22,1 2828,59 1,7 49 6271,93 2,113 60,61 7758,36 0,853
Total IO 88,34 11308 5,658 195,66 25043,9 2,552 242,12 30991 2,064
Lendo a tabela acima observamos que a melhor soluo o storage high-end que custa muito caro,
mas olhando com ateno o disco SSD perde pouco para o storage high-end e o disco SSD me custou 150
dlares o que no to distante em preo da soluo de storage compartilha oferecida pela maioria dos
datacenters.
No passado muitos se assustariam com esta ideia, pois historicamente as estatsticas do SMB (Server
Message Block) no so muito boas, podemos destacar alguns pontos negativos que muitos
administradores de infraestruturas citavam sobre o SMB:
No novo SMB 3 estes pontos negativos foram tratados ou eliminados, abaixo alguns pontos chaves
sobre o SMB 3 que detalharemos no decorrer deste captulo:
Somente a verso SQL Server 2012 ou superior suportam o SMB como soluo de storage para o SQL
que pode ser um SQL Server Standanlone ou FCI.
Figura 1.1: Exemplo de ambiente utilizando File Server como opo de Storage
Na figura 1.1 temos uma imagem que ilustra um ambiente com SQL Server em cluster utilizando um
File Server (SMB) como soluo de storage para o SQL.
Na imagem podemos notar que estamos utilizando o SOFs (Scale-Out File Server) que uma nova
soluo de armazenamento de arquivo e um cluster SQL Server com 3 nodes
Esta uma soluo de armazenamento de nvel empresarial pois escalvel, confivel e sempre
disponvel.
Utiliza as mais recentes tecnologias de rede (Ethernet convergente, RDMA) o que nos proporciona
maior flexibilidade,
uma soluo que reduz as despesas de capital e operacionais, pois temos um storage corporativo
que pode ser utilizado por outros servios.
Uma soluo com SMB nos oferece algumas features que no temos em solues convencionais:
SMB Transparent Failover - Disponibilidade contnua se um n falhar
SMB Scale-out - clusters de servidor de arquivos Ativo / Ativo, automaticamente balanceados
SMB Direct (SMB sobre RDMA) - Baixa latncia, alto rendimento, baixo uso de CPU
SMB Multichannel - Aumento do throughput da rede e tolerncia a falhas
SMB Encryption - Transmisso de dados segura, sem a custosa infraestrutura PKI
VSS para SMB File Shares - Backup e Restore usando a estrutura VSS existente
SMB PowerShell, VMM Support - Capacidade de gerenciamento e suporte atravs do System Center
e PowerShell
SMB Transparent Failover
Um dos pontos que no tem muita proteo em um cluster tradicional o disco, se ocorrer alguma
falha no storage ou no meio de comunicao entre o storage e o servidor (Fibra, HBA, etc.) o servio do
SQL Server que esta clusterizado ir falhar! Pensando nisto, o SMB inclui um recurso que sem dvidas,
esta uma das features mais legais do SMB 3 que nos permite efetuar o Failover da aplicao que utiliza
o SMB (no caso de nosso exemplo o SOFs) com zero downtime para o SQL Server, existem um pequeno e
rpido delay de I/O durante o Failover
O Transparente Failover ocorre para Failover planejado ou no planejados, isto significa que
aumentaremos o nvel de disponibilidade de nossa aplicao. Isto no significa que se por um acaso
ocorrer um Failover do SQL Server este processo ser transparente para a aplicao, o SQL Server tem
downtime, o que no tem downtime o File Server que estamos usando como alternativa de storage, ou
seja, eliminamos o problema de proteo existente entre o meio de comunicao do Storage e o Servidor.
Na figura 1.2 temos uma ilustrao do processo do Transparent Failover, temos um cluster SQL Server
que foi instalado alocando seus bancos de dados em diretrio do File Server (\\fileserver\SQLteste) e
neste cenrio notamos que o servio estava ativo no primeiro n e foi transferido (Failover) para o outro
n e nesta ao o servio do SQL Server no afetado e continua online. Este tipo de proteo atualmente
s possvel com o SMB 3!
SMB Direct (SMB sobre RDMA)
Antes de iniciarmos com o SMB sobre o RDMA (Remote Direct Memory Access) vamos primeiro
entender o que o RDMA.
O RDMA como o nome diz, um protocolo que permite o acesso a memria de um computador
remoto. Ou seja, se voc tiver uma placa de rede com o suporte RDMA o cliente SMB tem acesso direto
memria do servidor SMB transformando a transferncia de arquivo extremamente rpida e com
baixssimo consumo de CPU.
Baixa latncia
Alto rendimento
Capacidade de cpia zero
SO / by-pass
InfiniBand
iWARP: RDMA sobre TCP / IP
RoCE: RDMA sobre Ethernet convergente
File Server ativo-ativo Todos os ns de cluster podem aceitar e atender a solicitaes do cliente
SMB com Failover transparentes entre os ns.
Largura de banda aumentada A largura de banda mxima de um compartilhamento corresponde
soma da largura da banda da placa de rede de todos os ns do cluster File Server. Nas verses
anteriores do Windows Server, a largura de banda total era limitada largura de banda de um
nico n de cluster. Voc pode aumentar a largura de banda total adicionando novos ns.
CHKDSK com zero downtime Houve uma melhora significativa do CHKDSK no Windows Server 2012
que reduz de forma drstica o tempo que um sistema fica off-line para reparos, os CSVs (Clustered
Shared Volumes) eliminam a fase do off-line.
Cache de Clustered Shared Volumes Os CSVs no Windows Server 2012 introduzem o suporte a um
cache de leitura melhorando significativamente a performance.
Gerenciamento mais simples Com o SOFs, voc pode adicionar novos CSVs e criar diversos
compartilhamentos. No mais preciso criar vrios cluster de File Servers cada um com discos de
cluster separados.
Rebalanceamento automtico de clientes do SOFs No Windows Server 2012 R2, o
rebalanceamento automtico melhora a escalabilidade e capacidade de gerenciamento do SOFs.
As conexes dos clientes SMB so controlados por compartilhamento ao invs de servidor, deste
modo, os clientes so redirecionados para o n com melhor acesso ao volume daquele
compartilhamento, deste modo temos uma melhora significativa na performance e reduz o
trafego entre os servidores.
SMB Multichannel
O SMB Multichannel outra grande feature do SMB 3, pois com nos proporciona aumento do
throughput da rede e tolerncia a falhas.
Vamos imaginar dois cenrios onde temos um ambiente com 4 cores e uma placa de rede de 10 GB
sem a tecnologia Multichannel e outro ambiente com a tecnologia Multichannel.
No primeiro cenrio, vamos imaginar que temos uma sesso com vrios I/Os veramos um alto uso de
apenas um core enquanto temos 3 sem uso, isto ocorre porque na verso antiga do SMB no tnhamos
suporte ao Multichannel e o SMB cria apenas 1 conexo TCP.
Se eu executar o mesmo teste no segundo cenrio com o SMB 3 suportando o Multichannel veremos
a distribuio do uso dos Cores, isto ocorre, pois o SMB 3 detecta que a placa de rede tem a feature
Receive Side Scaling (RSS) e cria mltiplas conexes TCP distribuindo a carga entre os CPUs.
Figura 1.4: Comparativo de comportamento de ambiente com e sem Multichannel (imagem gentilmente cedidas pelo Jos Barreto
[http://blogs.technet.com/b/josebda/])
Vamos imaginar outros 2 cenrios, 1 sem o SMB 3 com dois File Servers o primeiro com duas placas de
rede com suporte RSS e outra com duas placas de rede sem o RSS. O outro cenrio exatamente igual o
primeiro, mas com o suporte ao SMB 3 Multichannel, a imagem 1.5 ilustra este cenrio.
No cenrio sem o suporte ao SMB 3 Multichannel, apesar de ter duas placas de redes nos dois clusters
de File Server, no temos o Failover automtico que est presente somente no SMB 3, vamos imaginar
que temos uma sesso com vrios I/Os, neste caso usaremos apenas 1 placa de rede (tanto no cluster
com o suporte ao RSS e no outro sem o suporte ao RSS) e teramos o cenrio de alto consumo de um nico
core devido a criao de apenas 1 conexo TCP.
No cenrio com o suporte ao SMB 3 Multichannel, temos o Failover automtico e podemos usar toda
a banda disponvel no servidor pois o Multichannel utilizar as duas placas de redes aumentando a largura
da banda. No cluster com as placas de redes sem o suporte ao RSS, mas com o SBM 3, o Multichannel
utilizar as 2 placas de redes abrindo apenas uma conexo em cada uma delas.
A figura 1.5 ilustra este comportamento do SMB Multichannel com mltiplas placas de rede.
Figura 1.5: Comparativo de comportamento de ambiente com e sem Multichannel usando mltiplas NICs (imagem gentilmente cedidas pelo Jos Barreto
[http://blogs.technet.com/b/josebda/])
Full Throughput
Failover automtico
Configurao automtica
O Jose Barreto que Principal Program Manager na Microsoft e ajudou no desenvolvimento do SMB
3 fez um timo teste de performance com o SMB3 com as seguintes configuraes:
O resultado obtido com os testes foi espetacular, note a performance com o Multichannel
2500
2000
1500
1000
500
0
I/O Size
1 x 10GbE 2 x 10GbE 3 x 10GbE 4 x 10GbE
Figura 1.6: Performance do SMB Multichannel (imagem gentilmente cedidas pelo Jos Barreto [http://blogs.technet.com/b/josebda/])
Notamos que para I/Os pequenos no conseguimos muita vantagem aumentando a quantidade de
placa de rede, para I/O maiores o ganha significativo conforme aumentamos o nmero de placa de
redes, alcanando cerca de 4500 Mb/s com 4 placas de rede para I/O size maior que 16384
Lembra da tabela de testes comparando alguns tipos de storage que comentamos no incio do
captulo?
Obviamente que o teste que fiz com o Diskspd foi diferente do teste que o Jos Barreto fez, mas nos
serve de parmetro para quebrar alguns paradigmas, observe a coluna MB/s do storage vs o SMB 3, voc
ter uma grata surpresa.
No estou lhe dizendo para sair da SAN e ir para o SMB 3 amanh pois isto teria um certo impacto
financeiro e burocrtico, mas j vale um teste em seu ambiente, correto? E que tal considerar o SMB3
para os novos projetos?
O SMB 3 mais uma alternativa que temos de storage com o diferencial da performance,
disponibilidade e escalabilidade. Sendo assim pense fora da caixa!
Conforme apresentado, temos uma maior proteo dos discos com o Failover transparente e
utilizamos toda a largura de banda disponvel nos servidores.
SQL Server FCI usando o File Share (SMB3.0) como opo de Storage
A partir do SQL Server 2012 ou superior, foi adicionado o suporte a utilizao de file share SMB3.0
(Windows Server 2012) ou 3.02 (Windows Server 2012 R2) como opo de storage para bancos de dados
de sistemas ou usurios, suportado para instncias stand-alone ou em cluster e tem o desempenho
otimizado para workloads OLTP.
Suporte tambm para failover transparente do SOFs provendo downtime 0 e otimizado para
random read/write I/O.
Antes de iniciar o setup do SQL Server utilizando o SMB, segue abaixo uma viso geral do ambiente de
laboratrio para o SQL em SMB 3
Na figura 1.7 temos os detalhes de cada servidor / cluster que utilizaremos no laboratrio, para este
laboratrio estou usando um servidor como AD e tambm como iSCSI Server, temos um cluster Windows
2012 R2 para o SOFs e o nosso Cluster Windows 2012 para o SQL Server 2016 que ser instalado usando
o SMB com storage.
Nota: Neste laboratrio focarei no setup do SQL sobre o SMB, sendo assim no detalharei o setup do
AD e iSCSI Server, mas voc pode ter maiores informaes nos links abaixo:
http://social.technet.microsoft.com/wiki/contents/articles/5119.instalacao-do-active-directory-no-
windows-server-2012-pt-br.aspx
http://blogs.technet.com/b/meamcs/archive/2012/03/30/installing-and-configuring-target-iscsi-
server-on-windows-server-8-beta.aspx
Configurando o Scale-Out File Server (SOFs)
Siga as etapas abaixo para configurar o SOFs, como dito acima, neste capitulo no demonstrei como
criar e configurar o iSCSI Server e o AD, mas voc pode utilizar os links informados para criar o seu
ambiente e apresentar os discos para o cluster de File Server que criaremos a seguir:
1. Crie um cluster para o File Server, instale o Windows Server 2012 R2 com no mnimo dois ns e
apresente 3 discos para o cluster:
2. Conecte-se em um dos ns do cluster de File Server e converta os discos para Shared Volumes,
voc poder ter maiores informaes sobre o CSV no livro SQL Server 2014: Alta
Disponibilidade na Prtica com AlwaysOn Failover Cluster Instances, de minha coautoria
juntamente com Nilton Pinheiro.
3. Em Storage clique sobre os discos com o boto direito e escolha a opo Add to Cluster Shared
Volumes (execute o processo para os 3 discos)
4. Clique sobre Roles como boto direito e escolha a opo Configure Role...
Figura 1.9: Criando uma nova Role
7. Na tela File Server Type selecione Scale-Out File Server for application data e clique em
Next
8. Na tela Client Access Point informe o nome virtual para o compartilhamento e clique em
Next, este ser o nome do host que os clientes acessaro, ex. \\SQLSMB\data
Figura 1.12: Informando o Client Access Point
Se voc acessar o Failover Cluster e clicar sobre Roles, ver que foi criado uma nova Role chamada
SQLSMB e selecionando esta role veremos que temos dois recursos um Nome e o SOFs.
Figura 1.13: Recursos do SOFs
11. Aps criao do SOFs, devemos criar os nossos compartilhamentos para a instalao do SQL,
criaremos os seguintes compartilhamentos:
\\SQLSMB\SQLBIN
\\SQLSMB\SQLDATA
\\SQLSMB\SQLLOG
Para isto, clique com o boto direto sobre a role SQLSMB e escolha a opo Add File Share
Figura 1.14: Adicionando um novo Share ao SOFs
12. Na tela Select the profile for this share selecione a opo SMB Share - Applications e clique
sobre o boto Next
Como o share que estamos criando ser o \\SQLSMB\SQLBIN selecionaremos o discos que
criamos para o BIN, no caso o Volume1 que possui 40 Gbs. E clique sobre o boto Next
14. Na tela Specify share name informe o nome SQLBIN para o Share Name e clique sobre o
boto Next
Figura 1.17: Informando o nome do share.
15. Na tela Configure share settings podemos escolher algumas opes de segurana como
criptografia, vamos deixar a opo default, clique sobre o boto Next
Figura 1.18: Configuracao do share.
16. Na tela Specify permissions to control access voc pode customizar as permisses, como boa
prtica, configure as permisses conforme o direcionamento da rea de segurana de seu
ambiente, neste laboratrio deixe leitura para alguns usurios e adicionei a conta de servio
do SQL Server contoso\SQLService que criei previamente, com full control do share, clique
sobre o boto Next.
Figura 1.19: Configurando as permissoes do share.
18. Na tela View results verifique se as tarefas foram concludas com sucesso e clique sobre o
boto Close
Figura 1.20: Tela de concluso da criao do share.
19. Repita as etapas 11 a 18 para criar os prximos shares selecionando os discos especficos:
20. Aps criao dois outros dois compartilhamentos voc dever ter um resultado final
semelhante figura 1.21 abaixo:
Figura 1.21: Lista de compartilhamentos SMB com os repectivos discos.
Aps a criao e configurao do SOFs no tpico acima, agora nos resta criar um novo cluster SQL
Server selecionando o SOFs como storage. Para este laboratrio vou utilizar o SQL Server 2016, como foi
mencionado anteriormente o SQL Server j oferece o suporte ao SMB desde a verso 2012.
No detalharei passo a passo como criar um cluster, mas caso voc no saiba ou tem dvidas como
criar um cluster, recomendo a leitura do livro SQL Server 2014: Alta Disponibilidade na Prtica com
AlwaysOn Failover Cluster Instances, de minha coautoria juntamente com Nilton Pinheiro.
Siga as etapas abaixo para instalar o SQL Server em cluster sobre SMB,
1- Crie um cluster para o SQL Server, instale o Windows Server 2012 R2 com no mnimo dois ns,
no apresente discos para este cluster, iremos utilizar o SOFs!
2- Inicie o Setup do SQL Server e selecione a opo Installation e New SQL Server Failover cluster
installation para iniciar o setup do SQL Server em cluster.
Figura 1.22: Iniciando a instalao do SQL Server em cluster
8- Na tela Feature Selection selecione os itens que deseja instalar e clique em Next.
Figura 1.24: Tela para selecao de features do SQL Server.
9- Na tela Instance Configuration informe o SQLINSTP1 para SQL Server Network Name e P1
para Named Instance e clique em Next
Figura 1.25: Tela de configurao da instancia.
10- Na tela Cluster Resource Group informe o nome da role a ser criada no cluster, informe
SQLINSTP1 e clique em Next
Figura 1.26: Informando o nome da role que ser criada no Failover Cluster.
11- Na tela Cluster Disk Selection observe que o setup no lista os discos pois no foi apresentado
discos no Failover Cluster, clique no boto Next.
Figura 1.27: O setup no lista os discos, pois no foi apresentado discos no cluster.
12- Na tela Cluster Network Configuration informe o IP para o nome virtual do SQL Server.
Figura 1.28: Informando o IP para o nome virtual do SQL.
13- Na tela Server Configuration informe a conta de servio do SQL Server e caso deseje alterar
o Collation, clique sobre a aba Collation altere conforme sua necessidade e clique em Next
Figura 1.29: Informando a conta de servio do SQL Server
15- Na aba Data Directories comea a configurao do SQL Server sobre SMB, informe os nomes
dos compartilhamentos criados no SOFs conforme a figura 1.31 abaixo:
Figura 1.31: Configurao setup do SQL Server nos compartilhamentos do SMB
Ser exibido uma mensagem alertando sobre as permisses do compartilhamento clique sobre o
boto Yes
16- Na janela Ready to Install revise os itens e clique em Install note que o diretrio da
instalao so os caminhos criados no SOFs
Figura 1.33: Tela de verificacao da configurao da intalacao do SQL
Concludo a instalao do SQL Server sobre SMB no primeiro n, basta executar o setup no segundo
n para adicionar o segundo n.
1- Acesse o segundo n do Cluster do SQL Server e execute o setup do SQL Server selecionando a
opo Add node to a SQL Server Failover cluster
10- Na tela Ready to Add Node revise o setup e clique em Install, observe que neste tipo de
setup no existe a informao do SMB, isto porqu estamos adicionando um n em cluster
existente e esta informao j esta implcita.
Figura 1.36: Tela de informaes sobre o setup
11- Na tela Complete clique em close concluindo a instalao do Add Node do SQL Server.
Figura 1.37: Tela concluso do add node do SQL Server
Podemos notar na figura 1.38 que o diretrio \\SQLSM\SQLBIN temos uma pasta MSSQL13.P1 que
intencionalmente foi mantida desta forma pois aqui temos um outro benefcio do SQL sobre SMB, posso
instalar mais de uma instncia em cluster no mesmo disco!! Alis posso instalar vrias instncias neste
compartilhamento. No cluster com disco dedicado eu preciso ter um grupo de disco para cada instncia.
Este reaproveitamento excelente para um uso otimizado de espao no storage, mas devemos ter o
cuidado de criar as nomenclaturas corretas para evitar futuros problemas e tambm para uma boa
documentao, como podemos notar nas figuras 1.39 foi criado uma pasta MSSQL13.P1\MSSQL\Data
para armazenamento dos dados isto evita confuses caso eu instale mais de uma instancia no mesmo
compartilhamento.
Verificando o SMB
Conectado em um dos ns do cluster de SQL Server inicie a janela do PowerShell e execute o cmdlet
abaixo:
Get-SmbConnection
O retorno deve ser parecido como o resultado abaixo:
ServerName ShareName UserName Credential Dialect
---------- --------- -------- ---------- -------
sqlsmb sqlbin CONTOSO\sqlservice CONTOSO.COM\sqls... 3.02
sqlsmb sqldata CONTOSO\sqlservice CONTOSO.COM\sqls... 3.02
sqlsmb sqllog CONTOSO\sqlservice CONTOSO.COM\sqls... 3.02
Como podemos notar no resultado acima, temos 3 conexes SMB 3.02 para a credencial do
SQLService.
Abaixo, na figura 1.40, se olharmos o Failover Cluster do SQL Server notaremos que no temos recurso
de discos, apenas o Nome, IP e os servios do SQL Server.
Efetue um teste de Failover no SQL Server e ao final mantenha o servio rodando no n SMBSQLN1,
note que este tipo de Failover causa indisponibilidade no SQL!
Aps os testes de Failover, execute o T-SQL abaixo para verificar o status atual do cluster.
O Resultado deve ser parecido com a figura 1.41, note que o n ativo o SQLSMBN1 e o Servio foi
iniciado as 21:28.
Figura 1.41: verificando qual o n ativo e quando foi iniciado
Aps os testes de Failover, execute o T-SQL abaixo para criar um loop para criar um pouco de I/O nos
servidores do File Serves(SOFs) e com o loop em execuo vamos fazer um Failover do SOFs e ver o que
acontece com o SQL Server.
Observe que teremos um I/O nos compartilhamentos SMB e durante este I/O vou fazer um Failover.
use DBTeste
go
--cria tabela de teste
create table TBteste (id int identity(1,1), data datetime default getdate(), campo1
int)
go
--loop para gerar i/o
declare @x int =0
While @x < 999999
begin
insert into TBteste (campo1) values (@x)
set @x = @x + 1
checkpoint
end
Deixe o comando acima rodando no SQL Server e conecte-se em um dos ns do cluster de File Server,
inicie a janela do PowerShell e execute o cmdlet abaixo para executar o Failover
Move-ClusterGroup SQLSMB
Execute o cmdlet algumas vezes (no mnimo umas 5 vezes) voc ver que o Failover do SMB
extremamente rpido.
Como podemos observar na figura 1.42, o SQL Server no sofreu impactos com os diversos failovers
do SOFs, aqui ocorre o Transparent Failover do SMB!
Se voc reiniciar o n ativo do cluster de File Server, mesmo assim o SQL Server continuar disponvel
e no ser impactado por stop e start no servio do File Server que estamos utilizando no SQL Server para
armazenar os dados do Binrio e dados do database de teste.
Voc pode parar o script e executar novamente o T-SQL para verificar o status do cluster de SQL Server
O Resultado deve ser parecido com a figura 1.43, note que o n ativo ainda o SQLSMBN1 e o Servio
foi iniciado as 21:28, ou seja, no houve falha no cluster de SQL Server. Esta a maravilha do Transparent
Failover do SMB.
Bom, espero que em seu prximo projeto voc possa considerar o SMB como alternativa para os discos
em seu ambiente, ele tm diversos benefcios que os sotrages convencionais no tm alm poder
aumentar significativamente a performance de I/O com o RSS e o Multichannel.
AlwayOn Availability Groups - Conceitos e Cenrios
Neste captulo ser apresentado uma breve descrio dos componentes e conce itos
acerca do AlwaysOn Availability Groups, bem como uma viso sobre cenrios de utilizao,
prs e contras desta features que foi lanada partir do SQL Server 2012.
Fonte: https://msdn.microsoft.com/en-us/library/ff877884.aspx
Introduo
Desde as primeiras verses lanadas o SQL Server sempre teve diversas opes para o provimento de
Alta Disponibilidade (HA High Availability) e Recuperao de Desastres (DR Disaster Recovery).
As principais opes at antes do surgimento do AlwaysOn Availability Groups (AG) eram, dentre
outras:
SQL Server Failover Cluster Instances (FCI)
Fonte: https://technet.microsoft.com/en-us/library/hh270278%28v=sql.110%29.aspx
Fonte: https://msdn.microsoft.com/en-us/library/ms189852.aspx
Uma soluo de Replicao de dados baseada em uma feature interna do SQL Server que independe
de recursos externos (como o caso do SQL Server FCI que depende do Windows Server Failover
Cluster).
A principal caracterstica do Database Mirroring o espelhamento de um nico banco de dados por
vez, sendo possvel tambm incluir uma instncia como testemunha para monitorar o servio de
espelhamento entre as instncias, o que possibilita o failover automtico em caso de falhas.
Log Shipping
Fonte: http://blogs.technet.com/b/sql_server_isv/archive/2010/11/03/sql-server-2008-r2-high-availability-options-for-temenos-t24-part-3-of-4-log-
shipping.aspx
O princpio bsico de uma soluo de log shipping, a criao automtica de backups de log em
uma instncia primria, cpia tambm automtica destes para uma segunda instncia e restore
na instncia secundria.
As instncias que recebem o shipping destes logs podem ficar disponveis para leitura, porm
quando executado o restore dos logs no momento do agendamento, todas as conexes
existentes na base so perdidas.
Replicao
Fonte: https://technet.microsoft.com/en-us/library/ms152567%28v=sql.110%29.aspx
Considerada por muitos uma soluo de alta disponibilidade, e no considerada por outros tantos,
a replicao baseia-se na criao de artigos contendo tabelas que so replicadas de diversas
formas (transacional, snapshot, merge, etc).
Os que no a consideram como uma soluo de alta disponibilidade, justificam isso basicamente
pela complexidade na administrao e principalmente pela necessidade de interveno humana
no caso de uma falha da instncia primria.
AlwaysOn
O AlwaysOn Availability Groups foi lanado na verso 2012, edio Enterprise do SQL Server com a
premissa de prover Alta Disponibilidade (HA) e Recuperao de Desastre (DR) em uma nica soluo.
Assim como o SQL Server FCI, o SQL Server AG tambm depende diretamente do WSFC, porm, esta
uma das pouqussimas semelhanas entre essas duas solues, que infelizmente tem o mesmo nome com
sobrenomes diferentes, fazendo com que muitos profissionais confundam e desconheam a diferena
entre elas.
O AlwaysOn AG prov soluo de HADR pelo agrupamento de bancos de dados, que tem seus dados
replicados de forma sincrona ou assincrona para replicas secundarias que podem ou no serem utilizadas
para aliviar o workload da rplica primria, tendo as conexes de leitura redirecionadas para estas.
A alta disponiblidade d-se pela criao de uma Role no WSFC para cada AG criado, nesta Role, existem
apenas um recurso referente ao Availability Group criado na instncia (lembrando que podem ser criados
diversos grupos de bancos de dados em cada instncia), um IP referente ao Nome Virtual (caso seja
configurado um Listener) que pode ser criado por grupo de disponibilidade, e o prprio nome virtual do
AG.
Em uma eventual falha na instncia (assim como no FCI), sero direcionados s rplicas secundrias
somente os grupos de disponiblidade com seus respectivos bancos de dados (dependendo das
configuraes de replicao). Os bancos de dados que que no fizeram parte do grupo de disponibilidade
somente podero ser acessados pelo nome da instncia que pertencem ou quando o Listener de algum
dos A.G. estiver disponvel nesta instncia, pois no participam de nenhum AG e consequentemente no
tem rplicas em nenhum outro servidor.
Pelo fato de no carregar consigo diversos recursos (como o caso do FCI) na Role do WSFC, um
failover de uma role com um AG tende a ser muito mais rpido do que um failover de uma role que contm
um servio do SQL Server como FCI, pois este precisa ser movido (em caso de falha, ou move group
manual) juntamente com discos, nome e ip virtuais, MSDTC, etc.
O principal requisito para que haja um failover automtico em uma soluo com AG, que a replicao
esteja em modo sncrono e configurada para failover automtico.
Apesar de ser verdica a informao supracitada, quando se fala em DR, o principal foco para as
situaes onde no necessariamente existe a disponibilidade de uma replicao sncrona (replicao para
um site remoto distante, por exemplo). Nestes casos, geralmente necessrio interveno manual para
que o sistema possa ser reestabelecido.
O AlwaysOn AG, protege contra falhas, os bancos de dados que esto inseridos em um AG, atravs de
replicao de todos seus dados. Se esta replicao se d de forma assncrona, a rplica secundria de uma
soluo de HADR utilizando o AlwaysOn AG, no deixar o banco disponvel automaticamente, para isso
necessrio que haja ao manual para sncronizar os dados desta base, o que devido ao fato de poder
no estar em sincronismo com a rplica primria, pode haver perda de dados. A possibilidade de perda
de dados, depender muito das caractersticas da aplicao, pois mesmo estando com uma configurao
assncrona, quando uma transao submetida rplica primria, ela imediatamente replicada para as
secundrias quando possvel, o que difere uma replicao sncrona de uma replicao assncrona, que a
segunda no no exige que uma transao seja consistida na replica secundria antes de considerar a
transao completada e retornar para a aplicao . Normalmente as rplicas pertencentes a uma soluo
com AlwaysOn AG que so destinadas recuperao de desastres, ficam configuradas com replicao de
modo assncrono e em sites remotos, com relao ao site (datacenter) principal, onde se encontra a
rplica primria com o AG.
Principais Conceitos
Aps uma sucinta introduo ao funcionamento do SQL Server AlwaysOn Availability Groups e seus
antecessores, a seguir falarei um pouco sobre cada um dos principais componentes de um AlwaysOn AG,
bem como algumas particularidades de cada um destes componentes.
Availability Groups (AG)
Um dos grandes pronto fracos do SQL Server AlwaysOn AG, a no possibilidade de utilizao do
MSDTC (Microsoft Distributed Transaction Coordinator), o que impossibilita a utilizao em cenrios onde
h necessidade de existncia de transaes distribudas. Esta restrio existiu nas verses 2012 e 2014 do
SQL Server, porm nos primeiros CTPs (Community Technical Previews) do SQL Server 2016 j havia sido
anunciado (na data em que este texto foi escrito) a compatibilidade do AlwaysOn AG com o MSDTC.
Por ser o AlwaysOn AG uma soluo para disponbilidade de grupos de bancos de dados, itens
pertencentes instncia do SQL Server (Logins / Senhas / Jobs) no so replicados, devendo estes serem
feitos manualmente.
Availability Replicas
Um Availability Rplica so as instncias do SQL Server que fazem parte da soluo de HADR de um
determinado AG. Um AG obrigatriamente tem 1 (uma) rplica primria e at 4 (quatro) rplicas
secundrias na verso 2012 do SQL Server Enterprise Edition, e at 8 (oito) rplicas secundrias na verso
2014 do SQL Server Enterprise Edition.
Comumente as rplicas em uma soluo de HADR com o AlwaysOn AG so instaladas como Stand
Alone, porm tambm possvel em um cenrio um pouco mais complexo, insegir uma instncia FCI como
uma rplica de um AG, neste cenrio as rplicas FCI no podem ser configuradas para Failover automtico.
Um excelente uso das rplicas secundrias, que alm de fornecer duplicidade de dados, podendo ser
crucial em momentos de desastres, estas tambm podem ser utilizadas para leitura, e consequentemente
alvio na carga da rplica primria, podendo esta ter seu trabalho focado para a utilizao de sistemas
transaes (insert, update e delete).
Availability Database
Cada um dos bancos de dados que fazem parte de um AG recebe o nome de Availability Database.
Geralmente os bancos so agrupados no mesmo AG por tipo de negcio e uma falha a nvel de banco de
dados no causa failover de um AG, tendo para isto o mesmo comportamento de uma soluo de SQL
Server FCI. Nas verses CTP (Community Technical Preview) do SQL Server 2016, j estava previsto a
possibilidade de configurao, para que o Failover pudesse acontecer em caso de falha a nvel de banco
de dados.
Listener
O Listener funciona para o AG assim como o Virtual Server Name para uma soluo de FCI. criado um
nome virtual para cada AG, e este nome faz o redirecionamento das conexes comuns para a rplica
primria, e o redirecionamento das conexes somente leitura (com o parmetro Aplication Intent = Read-
only na string de conexo) para as rplicas secundrias configuradas para receber tais tipos de workloads)
Por padro, via SSMS (SQL Server Management Studio) possvel criar apenas um Listener por AG,
porm atravs da ferramenta de Administrao do Cluster do Windows, possvel criar Listeners
adicionais para o mesmo AG. Uma das grandes vantagens na criao de mltiplos Listeners para um nico
AG atender s necessidades de conexo de aplicaes legadas, com cdigo fechado que no podem ser
alteradas. Esta uma soluo de contorno para casos especficos, toda a administrao do Alwayson AG
deve ser realizada estritamente via SSMS.
Cenrios
Conforme o titulo deste capitulo, bem como j falado no decorrer do mesmo por diversas vezes, o
AlwaysOn AG uma das opes (sim, provavelmente a melhor e mais completa) para suprir necessidades
de contingenciamento (geogrfico ou no) dos bancos de dados e tambm necessidades de Alta
Disponibilidade desses mesmos dados.
No existe uma soluo, produto, servio ou qualquer coisa que v ser sempre a melhor opo em
todos os cenrios. No caso do AlwaysOn AG no diferente, o AlwaysOn AG uma soluo muito boa,
que atende a diversos cenrios onde h requisitos de solues de Alta disponibilidade e Recuperao de
Desastres, mas existem casos onde no se aplicam tais solues.
Uma grande falha de um profissional que est desenhando um projeto o desconhecimento de opes
alternativas para adequao demanda que lhe proposta, isto faz com que o profissional tenha sempre
em mente a utilizao de um determinado conceito ou soluo (neste caso o AG) para toda e qualquer
situao, e nem sempre a nica nem mesmo melhor opo a ser utilizada.
preciso levar-se em conta diversos fatores como: Recursos Financeiros do projeto, demanda por Alta
Disponibilidade e Recuperao de Desastres, skill tcnica dos profissionais acerca das possveis solues
a serem implementadas, dentre diversos outros. Tais fatores determinam se para determinadas
demandas, haver melhor aplicabilidade de umas soluo de AG, FCI, Log Shipping e etc.
Portanto o AlwaysOn Availability group pode nem sempre ser a soluo mais barata, mais apropriada
e nem a que mais se adequa aos requisitos propostos, preciso ter bastante cuidado na fase de projeto
para implementao de uma soluo de Alta Disponibilidade, Recuperao de Desastres ou at mesmo
de replicao de dados.
Benefcios de utilizao do AG
A seguir uma descrio sucinta sobre as principais vantagens em se utilizar o AlwaysOn Availability
Groups como soluo de Alta Disponibilidade e Recuperao de Desastre.
Pontos negativos do AG
Talvez pontos negativos no seja a expresso mais adequada, mas aqui so listados os esforos
necessrios para que uma soluo com o AlwaysOn AG seja implantada em um ambiente.
Storage: Cada nova rplica secundria adicionada ao AlwaysOn AG, existe que o armazenamento
seja duplicado em relao aos bancos que fazem parte de um AG na rplica primria.
MSDTC: Conforme j mencionado previamente, o AlwaysOn AG no trabalha com transaes
distribudas (at a verso 2014).
Logins, senhas, jobs e outros itens pertencentes somente instncia no so replicados, neste caso
necessrio criar uma soluo alternativa para sanar esta necessidade.
O AlwaysOn Availability Group uma excelente ferramenta que j est disponvel a quem possuir
licena do SQL Server 2012 ou 2014 (nicos disponveis at a redao deste texto) na verso Enterprise
Edition. Com todos os cuidados necessrios e um bom planejamento possvel construir solues
confivels, resilientes e robustas utilizando-se do AlwaysOn AG.
Referncias deste captulo:
Windows Server Failover Clustering (WSFC) with SQL Server
https://technet.microsoft.com/en-us/library/hh270278%28v=sql.110%29.aspx
AlwaysOn Professional
http://blogs.msdn.com/b/alwaysonpro
http://edvaldocastro.com
Boas prticas em configurao de servidores de banco de dados
Nesse artigo vamos abordar alguns itens referente boas prticas em servidores de
banco de dados. O intuito de melhor aproveitar os recursos de hardware do servidor e
evitar pontos de contenes decorrentes de configuraes default que na maioria das
vezes no atendem os ambientes corporativos que rodam o SQL Server.
Introduo
Antes e aps realizar a instalao do SQL Server em seu ambiente importante verificar alguns pontos
para que nenhuma surpresa desagradvel venha a acontecer. O SQL Server por padro j vem instalado
com opes de fbrica e alguns itens de configurao no condizem com a realidade da maioria dos
ambientes. Nesse artigo irei explanar itens como configurao de memria, paralelismo, tempdb e
autogrowth de banco de dados, dentre outros.
Desabilitar o usurio SA
Por razes de segurana, considere desabilitar o usurio SA e criar um grupo no Active Directory como
sysadmin e incluir somente os DBA's responsveis pela instncia nesse grupo. Outra opo habilitar
somente o Windows Authentication Mode no momento da instalao, e s depois habilitar o Mixed
Mode, assim no ser preciso digitar a senha do SA e o mesmo ser criado com o status desabilitado.
[Na imagem acima temos a opo de manter habilitado apenas o Windows Autentication Mode evitando que o usurio SA seja criado no momento da
instalao.]
Como boas prticas para evitar ou corrigir conteno no banco de dados tempdb, sugerimos que:
Os arquivos de dados e log do tempdb sejam acomodados em um disco separado fisicamente dos
arquivos de dados e log de bancos de usurio:
Criar mltiplos arquivos de dados para o banco tempdb. Essa configurao importante e ajuda a
diminuir contenes que venham a ocorrer no tempdb. Para chegar ao nmero correto de
arquivos de banco de dados seguimos a seguinte regra:
No exemplo abaixo o tempdb foi divido em 5 arquivos para melhorar o throughput das operaes nele
realizadas. Note que o tamanho inicial e o Autogrowth devem estar do mesmo tamanho para garantir o
crescimento uniforme dos bancos.
Essa configurao pode ser realizada com o SQL Server em funcionamento que o mesmo j se
beneficiar dos novos arquivos instantaneamente. Na verso 2016 essa configurao poder ser realizada
no momento da instalao do SQL Server, podendo configurar os seguintes itens:
Quantidade de arquivos
Tamanho inicial (em MB)
Autogrowth (em MB)
Localizao dos arquivos
Fonte: https://support.microsoft.com/en-us/kb/328551
https://support.microsoft.com/en-us/kb/2154845
Paralelismo
As opes Cost Threshold for Paralelism e Max Degree of Paralelism controlam a maneira como o SQL
Server paraleliza suas requisies. A primeira opo representa o custo da query como um limite entre
paralelizar ou no e aceita valores de 0 a 32.767, o valor default 5. A segunda opo representa a
quantidade de cores utilizados para o paralelismo, recomenda-se que a configurao do MAXDOP (Max
Degree of Paralelism) seja ajustada de acordo com nmero de cores presentes em um NUMA NODE.
For servers that have NUMA configured, the maximum degree of parallelism should not exceed the
number of CPUs that are assigned to each NUMA node. This is because the query is more likely to use
local memory from 1 NUMA node, which can improve memory access time.
Importante: Ao mudar a configurao do Max Server Memory os caches SQL Plans, Object Plans e Boud
Trees so zerados, portanto tenha cincia disso quando for realizar tal operao.
Compresso de backup
Essa opo faz com que a instncia trabalhe de forma nativa com a compresso de backup. Entre as
vantagens esto a reduo do tamanho e tempo necessrio para realizao do backup de banco de dados,
porm utiliza-se de mais CPU para realizar tal operao. Por default essa opo vem desabilitada e pode
ser alterada via interface grfica ou command line, confome exemplos abaixo:
Para efeitos de comparao, faremos um script de backup rodando com a opo desabilitada, e logo
aps o mesmo script porm coma opo habilitada:
No nosso exemplo, o tamanho do backup com compresso chegou a ser 4 vezes menor que o backup
sem compresso:
Tempo gasto em milissegundos para realizar o backup:
Sem compresso:
Alm do espao em disco reduzido devido compresso do backup, o tempo necessrio para realizar
tal operao diminui consideravelmente pelo simples fato do backup compactado ser menor que o
tradicional e utilizar menos operao de escrita em disco, conforme citao abaixo retirada do MSDN:
-Como um backup compactado menor do que um backup no compactado dos mesmos dados, a
compactao de um backup normalmente requer menos operaes de E/S do dispositivo e, portanto,
normalmente aumenta significativamente a velocidade do backup.
Fonte: https://msdn.microsoft.com/pt-br/library/bb964719(v=sql.120).aspx
Na opo Erros and Warnings, clique em Blocked Process Report e depois em Run:
Aps realizar essa parametrizao, um evento como esse ser gerado no profiler sempre que houver
algum bloqueio acima do valor configurado no parmetro Blocked Process Threshold.
Em geral o banco de dados MSBD possui muito mais dados do que o banco Master, isso ocorre porque
no banco MSDB que ficam salvos os histricos de Jobs e informaes referente a backups (full,
diferencial e logs), dentre outras informaes. Por esse motivo o tamanho do banco MSDB tende a ser
maior que o Master e em consequncia disso, o autogrowth realizado com mais frequncia, justificando
ter seu autogrowth configurado com um valor maior.
Em relao ao banco model, devemos tomar cuidado ao realizar tais alteraes, pois todos os bancos
que venham a ser criados na instncia usam essa base como modelo para sua configurao. Portanto se
o banco model estiver com os arquivos configurados com o tamanho de 10GB, o mesmo ser replicado
para os demais bancos que forem criados aps a configurao do banco model.
Caminho: Server -> Management -> SQL Server Logs, boto direito em SQL Server Logs e clique em
configure:
Nesse exemplo colocamos o SQL Server para guardar at 20 arquivos de log ao invs de apenas 6!
Acessa a opo: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies ->
User Rights Assignment e clique duas vezes em Perform Volume Maitenance Taks:
Clique em Add User or Group e procure pelo usurio que esteja rodando o servido do SQL Server!
Clique em Ok, Aplicar e Ok novamente.
Feito isso a opo j estar configurada para usufruir desse recurso, porm preciso reiniciar o servio
do SQL para que as alteraes sejam efetivadas.
Fonte: https://msdn.microsoft.com/en-us/library/ms175935.aspx
Desabilitar o XP_CMDSHELL
Essa opo permite que o usurio utilize recursos interativos com o Sistema Operacional diretamente
do SQL Server. Isso pode ser til em alguns casos mas geralmente traz mais riscos instancia do que
benefcios, pois atravs de um simples ataque de SQL Injection o usurio poderia acessar recursos do
Sistema Operacional atravs dessa opo, caso a mesma esteja habilitada.
Para verificar se a opo est desabilitada, basta executar o comando abaixo, o esperado que os
campos config_value e run_value estejam = 0.
Caso a opo estiver ativa, basta executar o comando abaixo para desabilit-la:
sp_configure 'xp_cmdshell', 0
reconfigure
Se atente ao fato de alguma aplicao ou pacote do SSIS (SQL Server Integration Services) estar usando
esse recurso, o ideal adaptar a soluo para que a mesma no utilize o XP_CMDSHELL e logo depois
desabilitar. Caso voc desabilite essa opo e algum recurso a utilize, um erro ser retornado para a
aplicao e vai e impactar no processo.
Concluso
Sempre que concluir uma instalao do SQL Server no deixe de realizar os ajustes finos em
configuraes a nvel de banco e instncia. Por mais que seu servidor possua muitos recursos como CPU,
Memria e Disco, a m configurao far com que o SQL no utilize os recursos da melhor maneira. No
artigo foram citados itens que considero mandatrios aps a instalao de qualquer instncia, existem
outras configuraes e abordagens a serem exploradas e que podem ser encontradas nos demais posts e
na edio anterior do livro.
Criando dashboards com o Power BI
Neste artigo ser apresentado(a) a ferramenta/servio na nuvem chamada Power BI. A o
longo do captulo iremos mostrar um passo a passo de como configurar e usar o Power BI
para criar dashboards na sua empresa.
Por Demtrio Silva
https://demetriosilva.wordpress.com/
Reviso tcnica por Felipe Ferreira
http://www.templar.com.br/blogs/felipe/
Introduo
O Power BI um conjunto de ferramentas de anlise de negcios para analisar dados e compartilhar
ideias. Monitore seu negcio e obtenha respostas rapidamente com painis avanados disponveis em
cada dispositivo. https://powerbi.microsoft.com/pt-br/
O escopo deste captulo mostrar como criar uma conta e configurar o Power BI para criao de
Dashboards.
Alm da criao dos Dashboards este artigo mostrar como configurar o Power BI para realizar o
refresh dos dados usados, sendo que, estes dados estaro armazenados no ambiente on-premises e o
Power BI uma ferramenta que funciona na Nuvem.
Configurao do Ambiente
Para a demonstrao dos exemplos ns usaremos uma base de dados chamada Northwind_PT-BR que
pode ser baixada neste link http://1drv.ms/1XMvUwB .
O database usado nos exemplos um backup do SQL Server da base Northwind_PT-BR. Caso ainda
no o SQL Server instalado voc pode baixar um trial, que funciona por 180 dias,
https://www.microsoft.com/pt-br/evalcenter/evaluate-sql-server-2014.
Basicamente ser necessrio o SQL Server Engine e o SSMS. Caso tenha dvida em como instalar o SQL
Server siga este link https://msdn.microsoft.com/en-us/library/ms143219.aspx .
Para o nosso exemplo temos uma instncia padro do SQL Server 2014 instalada em um computador
chamado CLIENT81.
Aps baixar o backup da base Northwind_PT-BR ns iremos realizar os passos abaixo para disponibiliz-
la em nosso ambiente.
Criao do database
Abra o SSMS - SQL Server Management Studio e, conectado na instncia, clique com o boto direito
em databases e depois em restore conforme a Figura 1:
V at a pasta onde voc salvou o backup indicado no tpico 2 - Configurao do Ambiente conforme
Figura 4.
Figura 4 Local do backup
Clique na opo Files no canto superior esquerdo e logo em seguida em Relocate all files to folder.
Isso transfere os arquivos de dados e log do backup para o local padro de arquivos de dados e log que
voc configurou na instncia. Veja o exemplo na Figura 7.
Volte tela inicial, guia General, e clique em OK. Ao final do processo de restore ser exibida uma
tela igual a Figura 8.
Nesta etapa ser realizada a criao da conta no servio Power BI na nuvem, para isso, acesse o site
www.powerbi.com.
A Figura 11 exibe duas opes de uso do Power BI, sendo uma delas um download e outra um cadastro.
A opo de download chamada Power BI Desktop. Basicamente esta verso permite realizar anlises
usando vrias funcionalidades do Power BI, porm tudo fica na mquina de algum usurio, ou em algum
servidor de arquivos. Poderamos fazer uma comparao bem simplria ao Excel. Tanto o Power BI
Desktop quanto o Excel permitem a criao de relatrios porm ambos so aplicaes desktop, logo, o
compartilhamento, verso e segurana destes relatrios de difcil administrao em um ambiente
corporativo.
J o Power BI, que o BI da Microsoft na nuvem oferece o mesmo conjunto de visualizaes do Power
BI desktop porm funciona na nuvem da Microsoft e pode ser acessado atravs de Apps no Android, IOS
e Windows Phone.
Vale citar que o Power BI Desktop pode ser usado para criar relatrios e publicar no Power BI na
nuvem, conforme veremos adiante.
Obs.: o Power BI no aceita e-mails de domnios @hotmail, @globo, etc., apenas e-mails corporativos.
Abra seu e-mail corporativo e veja que voc recebeu um e-mail da Microsoft com o texto conforme a
Figura 14.
Ao clicar no link enviado atravs do e-mail voc ser direcionado ao site de cadastro do Office 365.
Agora aguarde a criao da sua conta no Office 365 e o deploy do Power BI conforme Figura 16
Figura 16 Deploy
Ao finalizar o deploy voc ver a tela abaixo, indicando que seu espao no Power BI j foi criado e
encontra-se pronto para uso.
Configurao do Gateway
Um Gateway do Power BI funciona como uma camada intermediria entre os dados locais de sua
organizao e o servio do Power BI na nuvem. Basicamente o gateway permite que os dados no Power
BI sejam atualizados conforme os dados de seu banco de dados local seja alterado. Por exemplo, voc cria
relatrios no Power BI usando dados que esto no SQL Server de sua organizao. Nestes relatrios voc
usa a tabela de vendas do seu database DB_VENDAS. Sabemos que vendas so realizadas de forma diria
e que os dados usados no Power BI logo ficaro defasados e ai onde entra o Gateway do Power BI, com
ele possvel, por exemplo configurar o Power BI para atualizar, de forma segura, diariamente os dados
da tabela de vendas.
Utilizando o gateway enterprise possvel usar o direct query pra que as consultas sejam executadas
sempre no ambiente on-premise, logo, os dados no necessariamente precisam estar na nuvem. Com o
Direct Query e o Gateway o Power BI cria uma conexo online entre a nuvem da Microsoft e o seu SGBD
que contm os dados on-premise.
possvel, por exemplo, manter os dados em um banco de dados SQL Server on-premise e configurar
o Power BI para executar as consultas diretamente no SGBD SQL Server de forma online.
No. Apenas quando seu Power BI usar fontes de dados locais diretamente ( DirectQuery )e que sejam
compatveis com atualizao atravs do Gateway. Veja mais em https://powerbi.microsoft.com/pt-
br/documentation/powerbi-personal-gateway/#preciso-de-um-gateway.
Existem dois tipos de Gateways, o pessoal e o corporativo. Basicamente a diferena que o corporativo
permite uma administrao centralizada dos acessos.
Para o nosso exemplo iremos usar o pessoal. Clique em download conforme Figura 19.
Figura 19 Tipos de gateways
Aps finalizar o download d um clique duplo no arquivo e clique em Run conforme Figura 20.
Informe o local que deseja instalar o gateway e clique em Next conforme Figura 24.
Figura 24 Local da instalao
Neste ponto teremos o gateway instalado. Clique em Launch para abrir a tela de configurao do
gateway.
Figura 25 Gateway instalado
Na tela inicial de configurao do gateway informado que ser necessrio efetuar login no Power BI
antes de configur-lo.
Figura 26 Configurao do gateway
Neste passo voc deve informar seu login e senha do Power BI e clicar em Sign in.
Figura 27 Login no Power BI
Power BI Desktop
Neste passo iremos realizar a instalao do Power BI Desktop. Conforme j foi citado anteriormente,
usaremos o Power BI Desktop para criar os relatrios e publicar no Power BI na Nuvem.
Para realizar o download do aplicativo v na pgina inicial do Power BI clique em Power BI Desktop
conforme a Figura 29.
Clique em Run
Clique em Seguinte.
Figura 32 Assistente do Power BI Desktop
Marque a opo Criar atalho do ambiente de trabalho e clique em Instalar conforme Figura 35.
Figura 35 Instalar Power BI Desktop
O Power BI Desktop foi instalado com xito. Deixa a opo Iniciar Microsoft Power BI Desktop
marcada e clique em Concluir.
Figura 36 Iniciar Power BI Desktop
A tela de boas vindas abaixo pode ser fechada clicando no X no canto superior direito.
Aps fechar a tela de boas vindas ns teremos a tela inicial do Power BI Desktop aberta. Neste passo
ns iremos importar os dados da base de dados Northwind_PT-BR, que foi apresentada no item
Configurao do ambiente.
Na tela inicial clique em Obter Dados e em seguida em SQL Server conforme Figura 38.
Uma curiosidade!
O Power BI Desktop, assim como o PowerPivot e a instncia tabular do Analysis Services Tabular
armazenam os dados em um Data Model. Basicamente as 3 ferramentas acima so um container para o
Data Model. Para ver o tamanho do arquivo Data Model voc pode renomear o arquivo, disponvel neste
link, do Power BI Desktop Dados BI Livro.pbix para Dados BI Livro.zip.
Deixando um pouco mais claro, o Power BI Desktop uma ferramenta que presta os servios de ETL
(Power Query), Dados ( Data Model ) e Relatrios. Para os exemplos do livro ns usaremos o Power BI
Desktop apenas para servir como repositrio dos dados.
Desta forma possvel saber o tamanho do Data Model, seja no PowerPivot ou no Power BI Desktop.
Figura 40 Data Model
A prxima imagem, Figura 41, exibe um preview dos dados que sero importados. possvel editar os
dados atravs do boto Editar, usando assim o Power Query, que a ferramenta de ETL do Power BI.
Para manter o foco do nosso captulo iremos apenas clicar em Carregar. Desta forma, os dados sero
importados para dentro do Power BI Desktop.
Importar: Importa os dados para o arquivo do Power BI Desktop. Para manter os dados importados
atualizados possvel configurar o refresh automtico utilizando o gateway que configuramos
anteriormente.
DirectQuery: Ao invs de importar, conecta o Power BI diretamente fonte de dados em tempo real.
Iremos usar o modelo de importao, sendo assim, clique em Importar conforme Figura 42.
Figura 42 Tipo de conexo.
Os dados foram importados. Nosso prximo passo ser alterar o nome da tabela importada. Selecione
o nome da tabela e clique em Mudar o nome conforme Figura 43.
Existem diversas formas de conectar o Power BI aos dados que sero analisados, por exemplo,
Planinhas do Excel/PowerPivot, On-premise data sources ( SQL Server, SSAS, etc. ), Hadoop, Cloud Services
( ZenDesk, SalesForce, etc. ).
Para o exemplo do livro ns iremos conectar o Power BI ao arquivo do Power BI Desktop criado no
tpico anterior. Para isso, faremos o upload do arquivo Dados BI Livro.pbix para o OneDrive e, dentro
do Power BI iremos apontar para este arquivo que estar no OneDrive. Lembram do Data Model? ele
que contm os dados de vendas que importamos anteriormente.
Abra o seu OneDrive, pode ser o OneDrive ou OneDrive For Business. No caso deste livro usaremos o
OneDrive pessoal, vide Figura 46. Caso ainda no tenha OneDrive ento crie gratuitamente uma conta no
Outlook.com.
Figura 46 OneDrive
Crie uma nova pasta no seu OneDrive chamada BI conforme Figuras 47 e 48.
Figura 47 Nova pasta
Figura 48 Pasta BI
Localize o arquivo que foi salvo na Figura 45 e clique em Open conforme Figura 51.
Figura 51 Upload do arquivo
Pronto. Agora seu arquivo do Power BI Desktop est salvo no OneDrive e pronto para ser usado no
Power BI na nuvem.
Criao dos relatrios e dashboards
Neste ponto ns j temos todo o ambiente configurado para usar o Power BI. Iniciaremos agora na
Home Page do nosso Power BI e em seguida iremos clicar na opo Obter logo abaixo do item
Arquivos. A idia neste ponto conectar o Power BI ao nosso arquivo Dados BI Livro.pbix que foi salvo
no OneDrive anteriormente.
Ao clicar em arquivos o Power BI oferece vrios formas de conectar, Arquivo Local ( Txt, Excel, etc. ),
Arquivos no OneDrive / OneDrive For Business e Arquivos em blibliotecas do SharePoint.
No nosso exemplo iremos conectar ao arquivo do Power BI Desktop que est no nosso OneDrive
Pessoal. Clique em OneDrive Pessoal conforme Figura 53.
Figura 53 Tipo de conexo
O OneDrive solicitar que voc informe login e senha para conectar e aps conectado a a tela abaixo
exibida, mostrando as pastas e arquivos disponveis no seu OneDrive. Clique em BI conforme Figura
54.
Em seguida selecione o arquivo chamado Dados BI Livro.pbix clique em Conectar. Aps este passo
o seu Power BI far uma importao do Data Model que est dentro do arquivo Dados BI Livro.pbix.
Figura 55 Dados importados.
O Power BI cria um dataset com os dados importados do nosso arquivo. Como os dados foram
importados eles so estticos e, por padro, no so atualizados. Eventualmente ser necessrio realizar
um refresh dos mesmos, visto que, os dados de vendas de uma empresa aumentam a cada dia. Iremos
ento programar a atualizao dos dados de forma automtica.
De acordo com o agendamento configurado, o Power BI solicita ao OneDrive que abra o modelo de
dados, conecte na base usando a string de conexo configurada atravs do Power BI Gateway e execute
a consulta novamente, atualizando os dados do modelo.
Clique em Dados BI Livro, logo abaixo de Conjunto de dados e em seguida clique em Programar
Atualizao.
Pronto. A avaliao de 60 dias da verso Pro foi iniciada. Agora voc j pode usar o gateway do Power
BI para realizar o refresh dos dados.
Novamente, clique em Dados BI Livro, logo abaixo de Conjunto de dados e em seguida clique em
Programar Atualizao.
Figura 60 Visualizar refresh
Desta vez a opo de configurao do refresh dos dados exibida. Note que o Power BI informa o
status do nosso gateway configurado anteriormente.
O passo a seguir configurar as credenciaris que sero usadas no Data Source. Na guia Credenciais
da fonte de dados clique em Editar credenciais.
Figura 62 Editar credenciais
Na guia Agendar atualizao clique em deixe as opes configuradas conforme Figura 64 e clique em
Aplicar. Neste caso, estamos agendando a atualizao para executar diariamente s 04h da manh, no
fuso horrio de Braslia e enviar e-mail em caso de falhas na atualizao.
Figura 64 Agendamento
A atualizao que definimos anteriormente referente aos dados que esto na nossa base de dados
Northwind_PT-BR, porm, no caso do OneDrive, existe uma outra atualizao que pode ser configurada:
atualizao de arquivo. Este tipo de atualizao verifica, por exemplo, se o Data Model que est no
OneDrive ainda o mesmo e, caso alguma alterao seja realizada no arquivo Dados BI Livro.pbix, do
OneDrive, esta atualizao ser refletida no Power BI. A Figura 65 mostra como configurar esta
atualizao.
Tambm possvel usar o Cortana junto ao Power BI. Clique em Aplicar conforme Figura 65.
Figura 65 Atualizao do OneDrive e Cortana
Novamente clique em Dados BI Livro, logo abaixo de Conjunto de dados e em seguida clique em
Atualizar Agora, isso fora uma atualizao no agendada.
Para visualizar o histrico de atualizaes clique em Dados BI Livro, logo abaixo de Conjunto de
dados e em seguida clique em Programar Atualizao.
Figura 67 Visualizar histrico de atualizaes
Expanda a guia Agendar Atualizao e em seguida clique em Histrico de Atualizao conforme
Figura 68.
A tela abaixo ser exibida, mostrando todas as atualizaes realizadas, quando, tipo e status.
Figura 69 Status das atualizaes
Nesta etapa final ns realizaremos a criao dos relatrios no Power BI usando os dados importados
anteriormente.
Na tela inicial do Power BI, logo abaixo de Conjunto de Dados, clique em Dados BI Livro. Isso
mostrar a tabela de pedidos no lado direto da tela, bem como, os seus campos.
No canto direito da tela, selecione os campos Categoria e Quantidade e em seguida clique no smbolo
do pincel e na guia geral aumente o tamanho da fonte para 27pt conforme Figura 71:
Figura 71 Relatrio inicial
Agora iremos testar se a atualizao est funcionando corretamente. Para isso abra o SQL Server
Management Studio e conecte na instncia CLIENT81 ( ou o nome da sua instncia configurada no tpico
2, no incio deste captulo ) na sua rede e execute o script 1 - Alterar Pedidos.txt, que pode ser baixado
neste link.
Agora faa uma atualizao manual. Clique em Dados BI Livro, logo abaixo de Conjunto de dados
e em seguida clique em Atualizar Agora, isso fora uma atualizao no agendada.
Figura 75 Teste gateway
E visualize o relatrio novamente. Note que na Figura 72 o total era 51317 e aps o update e refresh
o valor 61304 conforme Figura 75. Isso comprova que o Power BI atualizou os dados corretamente.
Iremos agora fixar estes itens no nosso dashboard. Para isso, ainda no relatrio, clique em Fixar
painel conforme Figura 78.
Selecione o dashboard que deseja exibir esta tabela. No nosso caso criaremos um novo dashboard.
Figura 79 Novo dashboard
Pronto. Agora j temos nossa tabela disponvel no dashboard chamado Painel Livro. Iremos agora
adicionar o grfico de pizza ao mesmo dashboard. Para isso, clique em Fixar painel conforme Figura 80.
Selecione Painel existente e em seguida informe o nome Painel Livro conforme Figura 81.
Figura 81 Adicionar pizza ao dashboard
Agora volte tela inicial do Power BI e na opo Painis clique em Painel Livro. A tela com o
dashboard ser exibida conforme Figura 82
Por exemplo, caso o usurio queira saber quantos pedidos foram vendidos por categoria ele poderia
realizar a pergunta Pedidos by categoria e, caso queira que o resultado seja exibido em formato de
barras pode perguntar Pedidos by categoria as barchart conforme a Figura 83. Neste caso, o Power BI
procura as colunas no nosso dataset e gera os grficos.
Esta integrao do Q&A tambm funciona com o Cortana, que ainda no estava disponvel no Brasil
no momento que este captulo foi escrito.
Abaixo uma outra pergunta, pedidos by categoria as barchart where categoria = bebidas. Neste caso
estamos perguntando ao Power BI quantos pedidos foram vendidos, agrupados por categoria, em
formato e barra filtando apenas a categoria bebidas.
Figura 84 Q&A, pedidos da categoria bebidas
Podemos tambm gerar grficos do tipo pizza. Para isso basta adicionar o predicado as pie.
Vale lembrar que os predicados ( where, as pie, as baarchart, etc. ), no momento, esto dispinveis
apenas em ingls.
Insights
Uma das funcionalidades do Power BI na nuvem o Insights Rpidos, onde o Power BI ir
automaticamente analisar o modelo de dados e gerar um dashboard com algumas informaes
interessantes sobre os dados que ele detectou.
Logo abaixo de Conjunto de dados clique em Dados BI Livro e em seguida Insights Rpidos
Aps finalizar, logo abaixo de Conjunto de dados clique em Dados BI Livro e em seguida Exibir
Insights
Figura 88 Insight 1
Figura 89 Insight 2
Figura 90 Insight 3
Concluso
Power BI A ferramenta de BI da Microsoft, recebendo atualizaes semanalmente, provando o
quanto a Microsoft est empenhada na sua evoluo.
Conforme descrito no artigo, possvel criar relatrios e dashboards de forma simples e intuitiva
usando o Power BI Desktop ou diretamente no navegador.
Muito bem, para entender porque o qurum importante para o cluster, vamos considerar um cenrio
como o apresentado pela figura 1.1.
Na figura 1.1 temos a configurao de um Failover Cluster composto por quatro servidores (ou ns),
distribudos geograficamente entre dois sites: So Paulo e Rio de Janeiro. Vamos imaginar que devido a
um problema de comunicao de rede entre os dois sites os ns do site Rio de Janeiro no conseguem
mais se comunicar com os ns do site So Paulo. Neste cenrio os ns de um site pensaro que os ns do
outro site no esto mais disponveis ou online e o servio de cluster tentar subir os recursos em cada
site para que possam atender as requisies dos ambientes.
Esta situao conhecida como split-brain e na prtica faz com que o cluster seja dividido em dois
clusters independentes e que no estaro visveis um ao outro. J d para imaginar o problema que isso
causar? Neste caso, voc teria o SQL Server online nos dois sites, cada um operando de forma
independente, tratando as requisies dos clientes dos respectivos sites e, o pior, cada um escrevendo
nos discos de suas respectivas storages. Certamente isso causaria um grande transtorno, incluindo a perda
de dados/informaes e no uma situao desejada em cenrios de alta disponibilidade.
Ento, para evitar essas situaes de split-brain foi desenvolvido o mecanismo de votao em um
cluster. Ao aplicar o mecanismo de votao ter acesso aos recursos do cluster o site que constituir um
qurum, ou seja, o site que tiver a maioria dos elementos votantes online e em comunicao. Dessa
forma, somente um dos sites poder prover os servios s aplicaes.
Quando configuramos um Failover Cluster cada n do cluster assume o direito de voto. Dependendo
do modelo de qurum utilizado, alm dos ns que compem o cluster votos tambm podem ser
atribudos a um disco (conhecido como disk witness) ou um compartilhamento de rede (conhecido
como File Share Witness ou FSW). Ento, baseado na quantidade de ns existentes no cluster e no
modelo de qurum escolhido, o cluster sabe quantos votos ele precisa para constituir um qurum. Um
qurum constitudo quando a frmula (nmero de ns/2)+1 resulta em mais da metade dos elementos
votantes Online e em comunicao, ou seja, dizemos que o cluster tem qurum quando mais da metade
dos elementos votantes esto online e em comunicao uns com os outros e que no tem qurum se
mais da metade dos elementos votantes ficarem indisponveis ou perderem a comunicao entre eles.
Neste caso, dizemos que o cluster perdeu o qurum e consequentemente causar a indisponibilidade dos
servios ou aplicaes em execuo no cluster. Ento, podemos dizer que na prtica o qurum determina
o nmero mnimo de ns que devem se manter online e em comunicao para que o cluster funcione!
Voltando ao exemplo da figura 1.1, temos que o cluster composto por quatro ns! Considerando que
cada n conta 1 voto, o cluster possui ento 4 votos no total. No entanto, ao perder a comunicao entre
os sites, cada site fica com apenas 2 ns online. Nenhum dos sites manter a maioria (que seria: 4/2+1=3),
ou se preferir 50% dos ns +1, e neste caso o cluster no ter qurum e ocorre a indisponibilidade total
do cluster. Isso evita ento o problema do split-brain!
Os modelos de Qurum
Quando configuramos o qurum de um cluster no Windows Server 2012/R2 podemos optar por quatro
modelos de qurum a seguir:
Node Majority: Nesta configurao cada n do cluster conta 1 voto. O cluster possui qurum e
permanece online enquanto tiver a maioria dos votos, ou seja, enquanto mais da metade dos elementos
votantes que formam o cluster estiverem online e em comunicao. Este o modelo recomendado para
cluster que possui um nmero mpar de ns, por exemplo, 3, 5 ou 7 ns,
Node and Disk Majority: Nesta configurao cada n do cluster e um disco ("disk witness") contam 1
voto. a configurao recomendada para cluster que possui um nmero par de ns, por exemplo 2 ou 4
ns.
Node and File Share Majority: Nesta configurao cada n do cluster e um file share ("file share
witness" ou FSW) contam 1 voto. Este modelo semelhante ao Node and Disk Majority com a diferena
que ao invs de utilizar um disco, utiliza-se um file share. a configurao recomendada para cluster que
possui um nmero par de ns, por exemplo 2 ou 4 ns e no tm um disco de storage para a configurao
do disk witness, ou ainda se est configurando um cluster onde os ns esto geograficamente
distribudos.
No Majority: Disk Only: Nesta configurao o cluster funcionar enquanto pelo menos 1 n estiver
online e em comunicao com o disco ("disk witness"). Neste caso, dizemos que o disco um ponto nico
de falha pois mesmo que todos os ns estejam online e em comunicao, se o disco ficar off-line todo o
cluster cair. Devido a este ponto crtico de falha esta no mais uma configurao recomendada.
Jogando estas informaes em uma tabela chegamos seguinte definio apresentada na tabela 1.1:
Observando a figura 1.2 podemos notar que o cluster possui 4 servidores e duas instncias virtuais de
SQL Server: VSQLINST1 e VSQLINT2. Considerando que o cluster possui um nmero par de ns, este est
configurado com o modelo de qurum recomendado para a sua quantidade de ns, o Node and Disk
Majority, portanto, o cluster possui 5 elementos votantes, sendo 1 voto para cada servidor (n) + 1 voto
para o disco, o disk witness, formando ento um nmero mpar de elementos votantes.
Voc pode estar se perguntando, ao invs de utilizar o disco eu poderia ter utilizado um file share,
adotando o modelo Node and File Share Majority? Sim, poderia! Neste caso voc precisa apenas de um
compartilhamento de rede em qualquer servidor da sua rede, servidor este que no pode fazer parte do
cluster sendo configurado.
Bom, considerando ento que para um cluster permanecer online e operacional com este modelo de
qurum preciso que mais da metade dos elementos votantes estejam online e em comunicao,
chegamos concluso que para o cluster da figura 1.2 permanecer operacional preciso manter no
mnimo trs votos online (nmero de ns/2+1=3).
Neste cenrio, supondo que o n SQLNODE3 fique indisponvel, a instncia de SQL Server em execuo
neste n ser automaticamente transferida para um dos ns restantes e o cluster passar a ficar com 4
votos. Consequentemente o cluster mantm qurum e continua online!
Felizmente a partir do Windows Server 2012 surgiram significativas melhorias com relao s opes
de configurao do qurum e a configurao do modelo de qurum ficou bastante flexvel. Ento, quando
configurando o qurum em um Cluster com Windows Server 2012 ou 2012R2 atravs da ferramenta
Configure Cluster Quorum Wizard voc ter trs opes de configurao possveis (figura 1.3):
Use default quorum configuration: Nesta opo o cluster automaticamente atribuir um voto para
cada n e gerenciar dinamicamente os ns votantes. Dependendo da quantidade de ns no cluster e
sendo identificada a presena de um disco de storage, o cluster selecionar automaticamente um disk
witness. Em muitos casos esta a opo mais recomendada pois permitir que o prprio cluster
configure o melhor modelo de qurum e se necessrio um disk witness, garantindo para seu cluster a
maior disponibilidade possvel.
Select the quorum witness: Selecione esta opo sempre que desejar alterar a configurao do modelo
de qurum em vigor, seja adicionando, alterando ou removendo um witness. Podendo este witness ser
um disk witness ou um file share witness (FSW). Nesta opo o cluster tambm atribuir um voto para
cada n e gerenciar automaticamente os elementos votantes.
Advanced quorum configuration: Selecione esta opo sempre que voc desejar executar alguma
configurao especfica nas configuraes do qurum. Atravs dessa opo voc pode alterar o tipo de
witness, determinar quais ns devem ou no contar votos no cluster (muito til para configuraes em
ambientes geograficamente distribudos) e tambm determinar se o cluster dever ou no gerenciar
automaticamente os elementos votantes no cluster.
Agora que voc j sabe da importncia do qurum para um cluster, dos seus modelos e opes de
configurao, vamos ao qurum dinmico.
Qurum e Witness Dinmico
Como visto no tpico anterior, por padro, cada n do cluster recebe um voto e para que um cluster
mantenha-se online ele precisa satisfazer a regrinha (nmero de ns/2+1). Dessa forma, em um cluster
com 5 elementos votantes possvel perder at 2 servidores ou elementos votantes que o qurum
continuar sendo mantido e o cluster continuar operacional. Ou seja, baseado no nmero de elementos
votantes o cluster sabe o nmero mnimo de votos que ele precisa ter para se manter operacional.
Usando como exemplo a figura 1.4 onde temos um cluster com 5 elementos votantes, o qurum
mantido enquanto trs ou mais elementos votantes estiverem online. No exemplo dois servidores foram
perdidos, no entanto, o cluster continua operacional porque ainda possui a maioria dos elementos
votantes online e em comunicao. No entanto, se outro servidor ficar indisponvel o cluster perder o
qurum e os recursos do cluster ficaro indisponveis.
Vimos que com o Windows Server 2012/R2 possvel utilizar o Configure Cluster Quorum Wizard e
redefinir quais servidores devem ou no contar votos no cluster, ento, ao perder dois servidores
possvel reconfigurar o qurum do cluster e assim garantir uma maior disponibilidade do ambiente. No
entanto, voc precisar reconfigurar isso manualmente.
Na figura 1.5 tem-se um exemplo de como ficaria a votao do qurum aps a reconfigurao dos
elementos votantes. Ao reconfigurar, apenas 3 elementos passam a contar voto e a necessidade mnima
de votos para manter o qurum ser recalculada considerando os novos elementos votantes. Assim
garantimos que o cluster continuar operacional enquanto pelo menos dois elementos votantes
estiverem online.
Neste tpico abordaremos duas excelentes funcionalidades implementadas no Windows Server 2012
e Windows Server 2012R2 que alm de simplificar significativamente a configurao do qurum, aumenta
muito as chances do cluster sobreviver a falhas. Estamos falando do Dynamic Quorum e Dynamic
Witness.
Quorum Dinmico
Implementado a partir do Windows Server 2012 o qurum dinmico ou Dynamic Quorum prov ao
Failover Cluster a funcionalidade de poder gerenciar automaticamente a atribuio de votos no qurum
baseado no status de cada n. Ou seja, voc no precisa mais ficar reconfigurando o qurum
manualmente e tudo ser feito de forma automtica considerando se o n est online ou off-line.
Na prtica o que acontece que quando o n fica indisponvel ele deixa de contar voto e a necessidade
mnima de votos para manter o qurum recalculada automaticamente. Quando o n volta a ficar
disponvel ele volta a contar voto e o clculo refeito considerando ento o novo elemento votante.
Voltando ao exemplo da figura 1.4 onde a reconfigurao dos elementos votantes precisou ser feita
manualmente, com o Dynamic Quorum a reconfigurao passa a ser dinmica. E mais, a idia com o
Dynamic Quorum que ao permitir que a atribuio de votos e o recalculo do nmero mnimo de votos
necessrios para se manter o qurum seja feito dinamicamente, o cluster possa sobreviver a falhas
sequenciais dos ns mesmo que ao final reste apenas um nico n online no cluster, o que referenciado
como last man standing.
O Dynamic Quorum ativado por padro durante a criao do cluster e dois pontos que se deve ter
em mente so:
1. O Dynamic Quorum somente atua sobre ns que esto definidos como elementos votantes no
cluster. Isso significa que se durante a configurao ou reconfigurao do quorum voc selecionar
um n como no votante, o Dynamic Quorum no atuar sobre ele e no o redefinir
dinamicamente como um elemento votante.
2. O Dynamic Quorum somente atua enquanto a indisponibilidade ou falha dos servidores se derem
de forma sequencial, ou seja, se o cluster perder simultaneamente dois ou mais ns o Dynamic
Quorum no conseguir ajustar dinamicamente a atribuio dos votos e consequentemente no
conseguir recalcular o nmero mnimo de votos necessrios para manter o cluster operacional.
Neste resultado, o valor da coluna DynamicWeight igual a 1 indica que o n possui voto dinmico. J
a coluna NodeWeight igual a 1 indica que o n deve ser considerado para contar voto no cluster. Ento,
por padro quando todos os ns do cluster estiverem online, ambas as colunas devero possuir o valor 1
e o valor de NodeWeight no se alterar a menos que reconfigurando o qurum manualmente voc
selecione que o n no dever ser considerado para votao no cluster.
Imaginando ento que os servidores SQLNODE2 e SQLNODE3 sofrem uma falha e so desligados, o
Dynamic Quorum entra em ao e o resultado da votao ser a seguinte:
Note que para os servidores SQLNODE2 e SQLNODE3 a coluna DynamicWeight ficou como 0 (indicando
para o cluster que esses servidores no possuem mais voto). Com isso, ao recalcular o nmero mnimo de
votos necessrios para manter o qurum, o cluster passa a utilizar a coluna DynamicWeight e no a coluna
NodeWeight (como seria se o Dynamic Quorum no estivesse ativo). Com isso, temos que para o cluster
continuar operacional a partir desse ponto preciso que pelo menos dois servidores permaneam online.
Considerando agora que o servidor SQLNODE1 tambm falhe, teremos a reconfigurao dos votos
como segue:
Observe que ficando agora com apenas dois ns, foi removida tambm a configurao de voto do
servidor SQLNODE4, mesmo com ele estando online. Isso acontece porque quando restam apenas dois
ns online, o Dynamic Quorum tem como regra remover tambm o voto de um dos dois ns restantes.
Isso acontece de forma randmica e garante que na falha do n que ficou sem voto (o SQLNODE4), o
outro n ainda possa continuar online e atendendo s demandas do ambiente, provendo ao cluster uma
chance de 50% de sobreviver a uma nova falha.
A partir desse ponto, o cluster pode perder a comunicao entre os dois ns restantes ou ter uma falha
do n que no conta voto, que ainda assim continuar operacional. Em ambos os casos, entra em ao o
last man standing, ficando o cluster online e operacional apenas com o n que possui o voto (o
SQLNODE5).
Neste momento voc pode estar se fazendo a seguinte pergunta: O que acontece se restando apenas
dois ns ocorrer uma falha no servidor que possuir o voto? Neste caso, as seguintes situaes podem
ocorrer:
a) Se o n que mantm o voto sofrer uma falha inesperada ou for desligado de forma abrupta todo o
cluster ficar indisponvel uma vez que o n restante no possui voto e no poder sustentar o
cluster,
b) Se o n que mantm o voto sofrer uma reinicializao ou for desligado de forma planejada, o
cluster atribuir voto ao n que se manter online, ficando o cluster ainda operacional apenas com
um n restante.
Como podemos imaginar, em um ambiente real existe uma grande possibilidade de que o item a)
acontea, ento, a partir deste momento a recomendao reconfigurar o qurum adicionando witness
(disco ou file share). Desta forma voc estar adicionando mais um elemento votante ao cluster
mantendo-o com um nmero mpar de votos e provendo uma maior proteo ao cluster.
Witness Dinmico
Entendido o funcionamento do Dynamic Quorum, a boa notcia que a partir do Windows Server
2012 R2 existe tambm o Dynamic Witness. Isso mesmo, o Dynamic Witness tem exatamente o
mesmo comportamento do Dynamic Quorum, porm, ele atua somente sobre a votao do witness,
seja ele um disk witness ou um file share witness.
No Windows Server 2012 R2 se o cluster estiver configurado para utilizar Dynamic Quorum (o
default), o voto do witness tambm ser atribudo ou removido dinamicamente. Dessa forma, quando o
nmero de ns votantes no cluster for mpar, o witness no contar voto. Por outro lado, se o nmero de
ns votantes no cluster for par, o witness contar voto e assim garantir um balanceamento do cluster
deixando-o sempre com um nmero mpar de votos.
Ento voc pode estar se perguntando...Mas o que acontece se o witness ficar off-line? Neste caso,
da mesma forma que com o Dynamic Quorum os votos so ajustados baseado no status de cada n,
com o Dynamic witness o voto do witness tambm ajustado baseado o status do witness, ou seja, se
o recurso de witness falhar ou por qualquer motivo ficar off-line, o cluster remover o voto do witness.
Quando o recurso de witness voltar a ficar online, seu voto ser reatribudo caso o nmero de ns votantes
no cluster seja par.
Lembre-se que com um nmero par de elementos votantes sempre recomendado adicionar um
witness para balancear o cluster e deix-lo com um nmero mpar de votos. isso que o Dynamic
witness faz, procura sempre manter o balanceamento do cluster.
Voc pode identificar se o witness est contado voto ou no no cluster executando o comando
PowerShell Get-Cluster e verificando o parmetro WitnessDynamicWeight. Assim como verificando o
parmetro DynamicQuorum voc identifica se o Dynamic Quorum est ativo ou no.
PS C:\Users\Administrator.SQLNET> (Get-Cluster).DynamicQuorum=0
E lembre-se que o Dynamic Witness somente atuar se o Dynamic Quorum estiver ativo e mesmo
assim o cluster somente atribuir voto ao witness se necessrio. Ento, no se espante se mesmo com o
Dynamic Quorum ativo voc identificar o WitnessDynamicWeight como 0.
Como voc pode observar, o Dynamic Quorum e Dynamic Witness so duas excelentes
funcionalidades que reduzem significativamente as chances de um cluster ficar indisponvel por causa de
uma falha nos ns ou mesmo do recurso de witness. Eles tambm adicionam uma grande simplicidade e
flexibilidade na configurao do qurum, removendo definitivamente a necessidade de uma interveno
manual na configurao ou reconfigurao pois agora o prprio cluster far isso de forma dinmica.
Considerando que estes recursos estaro ativos por padro no Windows Server 2012/R2, procure sempre
tirar vantagem destes recursos mantendo-os ativos independente do nmero de ns em seu cluster.
Neste momento voc pode estar se perguntando: Mas e quando Eu tiver um cluster com apenas dois
ns e estiver utilizando a configurao de Node Majority, mesmo assim devo considerar o uso do
Dynamic Quorum? Bom, primeiramente, considerando um cluster com apenas dois ns, como j vimos
aqui o recomendado que voc configure um terceiro voto, seja colocando um disco ou um file share
como witness. No entanto, caso por qualquer motivo voc insista em manter a configurao do qurum
como Node Majority, a resposta SIM!
Como j vimos no decorrer deste tpico, para um cluster se manter online e operacional ele precisa
satisfazer a frmula (nmero de ns/2+1). Ento, com apenas dois ns teremos 2/2+1=2, ou seja, seu
cluster se manter Online somente enquanto os dois servidores estiverem Up. Ento, sua possibilidade
de falhas de ns para este cluster 0. Um restart em um dos servidores j ser o suficiente para derrubar
seu cluster e causar a indisponibilidade do SQL Server. Voc pode comprovar isso facilmente executando
o comando abaixo para desativar o Dynamic Quorum no Windows Server 2012/R2 e posteriormente
executar um restart em um dos ns.
PS C:\Users\Administrator.SQLNET> (Get-Cluster).DynamicQuorum=0
Por outro lado, se voc mantiver o Dynamic Quorum ativo, notar nas configuraes do cluster que
apenas um dos ns (no exemplo da figura 1.6 o n SQLNODE2) mantm a coluna Current Vote igual a 1
(isso feito aleatoriamente). Na ferramenta Failover Cluster Manager a coluna Current Vote
corresponde ao DynamicWeight do comando PowerShell Get-ClusterNode.. Ento, isso significa que
apenas um dos ns est mantendo voto no cluster.
Como neste caso a atribuio dos votos dinmica, se por acaso o n que no est contando voto
(SQLNODE1) cair ou for desligado, mesmo assim o n SQLNODE2 continuar ativo e o cluster se manter
online e operacional. Neste caso teremos a atuao do last man standing, lembra?
Por outro lado, se por acaso o n que mantm o voto (SQLNODE2) for desligado ou reiniciado, o
DynamicQuorum entrar em ao e passar o voto para o n que se manter online e o cluster
continuar operacional. Temos novamente a atuao do last man standing.
Isso pode ser visto na figura 1.7 aps ser desligado o servidor SQLNODE2.
Neste momento voc pode estar se perguntando: Bom, ento quando eu poderei perder o meu cluster
se os votos so reatribudos dinamicamente e o cluster sempre se mantm online?
Vou responder esta pergunta apresentando a voc 4 possveis possibilidades do que pode acontecer
quando temos um cluster com apenas dois ns e usando Node Majority como configurao do qurum.
Para isso vamos usar o exemplo da figura 1.6 onde o n SQLNODE2 o n que mantm o voto do cluster.
As possibilidades so:
Ento, voc perder o seu cluster apenas se o servidor que mantiver o voto cair de forma inesperada
e abrupta, pois neste caso o cluster no ter tempo para remover o voto do servidor que caiu e atribuir o
voto para o servidor que permaneceu online. Neste caso todo o cluster cair, causando a indisponibilidade
de todos os servios.
Para se prevenir desta possibilidade de falha inesperada e queda do cluster, entra ento a
recomendao de configurao de mais um elemento votante no cluster, como por exemplo, a
configurao de um disco ou file share witness.
Mo na Massa: Configurando o Qurum do Cluster
Agora que voc sabe todo o conceito sobre o qurum, veja nos passos seguintes todo o passo a passo
para a configurao do qurum em um cluster.
No Failover Cluster Manager, clique com o boto direito do mouse sobre o nome do cluster e selecione
as opes More Actions | Configure Cluster Quorum Settings... como apresentado na figura 1.8
Na janela Configure Cluster Quorum Wizard, na pgina Before You Begin simplesmente clique em
Next para prosseguir. Em seguida, na pgina Select Quorum Configuration Options, voc deve selecionar
uma das trs opes apresentadas. Estas opes j foram abordadas no tpico sobre os modelos de
qurum. Vale ressaltar que na opo Advanced quorum configuration voc poder selecionar quais os
ns que devero ser considerados como elementos votantes no cluster e o tipo de witness. Voc tambm
poder optar para que nenhum n seja elemento votante, mas neste caso voc ser obrigado a utilizar
um disk witness. O disco ser ento o seu ponto nico de falha no cluster, ou seja, se por qualquer
motivo o disco falhar ou os servidores no conseguirem acesso a ele, todo o cluster falhar.
Para nosso exemplo, vamos manter todos os ns como elementos votantes e apenas adicionar um
witness. Ento, selecione a opo conforme apresentado na figura 1.9.
Figura 1.9: Opes para configurao do quorum
Na pgina Select Quorum Witness, figura 1.10, voc tem a opo de selecionar qual o tipo de witness
deseja configurar para o cluster. Podendo optar por um disk witness (requer um disco), file share
witness (requer um compartilhamento de rede) ou simplesmente no configurar um witness.
Para configurar um disco, mantenha selecionada a opo Configure a disk witness e clique em Next.
Vale destacar que ao relacionar as opes apresentadas na figura 1.10 com os modelos de qurum
abordados no tpico sobre os modelos de qurum, chegamos ao apresentado na tabela abaixo:
Tabela 1.2: Opes de configurao do quorum e modelo de quorum
Aps selecionar o tipo de witness e clicar em Next na janela da figura 1.10, voc dever selecionar na
pgina Configure Storage Witness qual o disco que a ser utilizado para o qurum, o disk witness.
Lembre-se que ao selecionar um disco, ele contar como mais um elemento votante no cluster e tambm
armazenar uma cpia do banco de dados do cluster, banco de dados este que sincronizado com todos
os ns do cluster.
Aps selecionar o disco de qurum, clique em Next na pgina Confirmation e aguarde a configurao
do qurum. Aps alguns segundos ser apresentada a janela de sumrio com o status da configurao
executada. Clique ento sobre o boto Finish para concluir.
Figura 1.12: Confirmando as informaes para configurao do qurum
Concluda a configurao voc poder visualizar as informaes sobre o modelo de qurum em uso na
janela principal do Failover Cluster Manager com apresentado na figura 1.13.
Figura 1.13: Cluster utilizando o modelo de quorum Node and Disk Majority
Concluso
Como voc viu, a configurao do qurum em um cluster bastante simples e fcil de ser executada.
Vimos tambm que o Dynamic Quorum e Dynamic Witness so timas funcionalidades a serem
usadas como default em todos os seus cluster uma vez que elas permitem prover uma tolerncia a falhas
bem maior para os cluster, reduzindo significativamente as chances do cluster ficar indisponvel por falhas
nos ns ou mesmo do recurso de witness. Eles tambm adicionam uma grande simplicidade e flexibilidade
na configurao do qurum, removendo definitivamente a necessidade de uma interveno manual na
reconfigurao pois agora o prprio cluster far isso de forma dinmica.
Caso voc queira saber mais sobre o assunto, duas timas referncias so: Configure and Manage the
Quorum in a Windows Server 2012 Failover Cluster (http://technet.microsoft.com/en-
us/library/jj612870.aspx) e o livro SQL Server 2014: Alta Disponibilidade na Prtica com AlwaysOn
Failover Cluster Instances, este ltimo de minha coautoria juntamente com Marcelo Fernandes
In-Memory OLTP 2016: O relanamento de uma potncia
No demorou muito para o In -Memory OLTP chamar ateno, assim que foi lanado no
SQL Server 2014. Porm, a euforia deu lugar a alguma decepo, devido a sua extensa lista
de limitaes. Com o anncio do SQL Server 2016, muitas novidades viro, e o In -Memory
OLTP acumula uma grande parte delas. Neste artigo sero abordados no s as melhorias
desta funcionalidade no SQL Server 2016, assim como as motivaes que levaram ao
desenvolvimento do In-Memory OLTP.
O lanamento do SQL Server 2014 trouxe algumas novidades, sendo o In-Memory OLTP uma das
estrelas da companhia, carregando a fama de ser uma tecnologia revolucionaria que pela primeira vez
iria permitir que tabelas, ndices e dados fossem inteiramente alocados em memria durante todo o seu
ciclo de vida. De fato a tecnologia trazida pelo In-Memory OLTP era revolucionaria, assim como a outra
tecnologia da mesma famlia, lanada com o SQL Server 2012, mas focada em sistemas OLAP: o
Columnstore.
Mesmo sendo uma tecnologia que prometia muito, sua implementao tem sido escassa, muito por
conta de suas imensas e inconvenientes limitaes. Apesar de ser provado que na prtica o ganho de
performance realmente ocorre, difcil encontrar um caso de uso que mude por inteiro o panorama de
uma base de dados.
Desde o incio, ficou claro que a Microsoft lanou a funcionalidade inacabada e com o objetivo ir
desenvolvendo melhorias em paralelo. Uma deciso inteligente por um ponto, j que desta forma a
aceitao do In-Memory OLTP poderia ser testada, da mesma forma que sistemas compatveis com as
limitaes poderiam tirar proveito da funcionalidade de imediato. Mas existe o outro lado da moeda. Vi
muitos clientes desistindo do In-Memory OLTP por conta de suas limitaes, o que pode ter abalado a
imagem de uma funcionalidade revolucionria.
Felizmente o SQL Server 2016 est a, trazendo muitas coisas interessantes. Na minha opinio, uma
das melhores verses do SQL Server lanadas at hoje. Muitas novidades, melhorias e mais integrao
com o Azure E claro, o In-Memory OLTP ganhou (muitas) melhorias, gerando a expectativa de um
verdadeiro relanamento desta poderosa funcionalidade.
In-Memory OLTP: o conceito e as motivaes
Mas afinal, o que o In-Memory OLTP? Se to bom, porque a Microsoft no desenvolveu esta
funcionalidade antes?
Observando a evoluo do hardware, possvel perceber que houveram dois fatos interessantes:
O preo por gigabyte da memria RAM vem caindo desde o inicio dos anos 2000.
A evoluo dos processadores (CPU) mudou de rumo, tendo estagnado na mesma taxa de clock
desde o inicio deste sculo.
Hoje em dia podemos comprar memoria RAM, com uma grande capacidade, um tempo de resposta
muito bom e um preo indiscutivelmente mais baixo do que a 10 anos atrs. O seguinte grfico mostra
que o preo por gigabyte no ano 2000, comparado com o preo atual, era aproximadamente 20 vezes
mais caro.
Alm de ser financeiramente vivel configurar um servidor com memoria ao nvel de Terabytes hoje
em dia, outra situao motivou a criao do In-Memory OLTP: a performance de bases de dados
tradicionais deixou de ser aceitvel em muitos casos. Isso acontece por vrios motivos, porm possvel
apontar dois dos fatores principais: os mecanismos de lock e o tempo desperdiado nas operaes em
disco.
No possvel executar todos ao mesmo tempo. O que fazer para resolver este conflito? necessrio
uma estratgia que no permita que mais do que uma operao seja executada em simultneo nesta
linha. Por este motivo o SQL Server usa locks.
Desta forma, o primeiro processo a conseguir o lock requisitado prosseguir com a sua operao,
trancando a linha durante a operao e liberando a aps a concluso de seu trabalho. Os outros dois
processos ficaram em espera durante este tempo, e assim que o lock foi liberado, um deles ir conseguir
o lock, e assim sucessivamente.
O lock um artificio usado para evitar que hajam conflitos de operaes diferentes numa mesma
estrutura partilhada. Porm, como visto no exemplo anterior, em um ambiente altamente concorrente,
sempre existiro processos parados a espera de um certo recurso, que estaria trancado por um outro
processo. Esta situao pode parecer simples, mas em grande escala, pode trazer muita dor de cabea
O outro grande culpado por problemas de performance, muitas vezes o disco. Basicamente
operaes de escrita e leitura de dados custosa, mesmo com os melhores SSDs (Solid State Drive) do
mercado.
Os dois problemas referidos resultaram em toda uma estrutura baseada em extents, pages, locks e
latches, o que penaliza sistemas altamente concorrentes, em nome da integridade dos dados.
Com o objetivo de fugir da complexidade de estruturas em disco, assim como de tirar proveito da
excelente performance da memria RAM, a Microsoft iniciou o desenvolvimento do Projeto Hekaton, o
que resultou no In-Memory OLTP.
Muito se fala que o SQL Server j usa a memoria RAM para guardar os dados, e de fato isso verdade.
Se um servidor tiver um montante de memria RAM suficiente para alocar uma base de dados inteira, a
performance ir certamente melhorar. Por isso a estratgia de muitas empresas adicionar mais memria
ao invs de investir em tuning resolve-se o problema, no a causa.
De uma forma geral, quando uma query executada, o SQL Server ir primeiro verificar se as pginas
contendo os dados requeridos j esto em memria, se sim, o disco nem ser acessado. Este um dos
motivos porque o tempo de execuo de uma query maior na sua primeira execuo ou depois que a
instancia reiniciada, j que as respectivas estruturas em memria, incluindo o Buffer Pool, sero
recriadas.
Outra possibilidade muito comentada o comando DBCC PINTABLE, este comando permitia a
fixao de pginas de uma tabela em memria, de forma a minimizar acessos ao disco. Esta possibilidade
foi removida no SQL Server 2005, o que motivou formas criativas de manter-se uma tabela inteiramente
em memria. Um exemplo: Criar um job para executar um simples SELECT * FROM tabela
periodicamente ao longo do dia.
Tudo isso pode ser feito, porm nada comparvel ao que foi feito para o In-Memory OLTP, sendo
que no final das contas a estrutura que estar na memria a mesma que est no disco, o que no
otimizado para estar em memria.
De forma a tirar todo proveito da memria RAM, o In-memory OLTP foi construdo de raiz, sendo uma
engine completamente nova. Existem rumores de que a Microsoft cogitou o lanamento do Hekaton
como um produto paralelo ou complementar ao SQL Server, mas felizmente isso no aconteceu, o que
resultou num atrativo muito grande que diferencia o SQL Server de outros DBMS (Database Management
Systems): Tabelas em memoria e tabelas em disco podem compartilhar a mesma base de dados e at
conversarem entre si.
Em resumo, dentre outros, seguem quatro motivos para o In-Memory OLTP ser to rpido:
Os dados estaro inteiramente em memria, o que exclui a penalizao de escrita e leitura em disco.
Novas estruturas de dados foram criadas, permitindo que a excelente performance da memria
RAM seja explorada ao mximo.
Modelo Otimista: No existem locks nem latches.
Os objetos so compilados, o que evita o passo extra de interpretao que o T-SQL tradicional
requer.
O que tanto mudou do SQL Server 2014 para o 2016?
Como era previsto, a Microsoft manteve o investimento no In-Memory OLTP no SQL Server 2016,
trazendo melhorias essenciais. Tais melhorias trouxeram o que faltava no In-Memory OLTP no SQL Server
2014, acabando com as principais limitaes quase por completo.
Sem mais delongas, vamos ao que interessa: o que mudou no In-memory OLTP no SQL Server 2016.
No SQL Server 2014, existe uma limitao no tamanho total das memory-optimized tables de 256 Gb.
Este valor no relativo a uma tabela apenas, os 256 Gb compreendem todas as tabelas in-memory em
uma nica base de dados. Desta forma podemos ter, por exemplo, uma tabela ocupando o espao de 256
Gb da mesma forma que poderamos ter quatro tabelas de 64 Gb. Como referido, este um limite por
base de dados, o que permitiria termos duas bases de dados com uma soma de 512 Gb de dados in-
memory.
Mesmo sendo um limite relativamente alto para uma tabela de um ambiente OLTP, a Microsoft
trabalhou na melhoria deste cenrio no SQL Server 2016, aumentando o limite de tabelas in-memory para
2 Tb por base de dados. O que permitiria a migrao de uma de uma VLDB na integra para memria.
O In-memory OLTP no 100% memria. Afinal algum disse que o disco no usado? Infelizmente
. De forma a garantir a durabilidade dos dados, a servio de tabelas in-memory durveis, checkpoint files
so mantidos no disco. Os checkpoint files so compostos por dois arquivos: Data e Delta. Todas as
adies, alteraes e remoes de dados iro ser registradas no transaction-log e persisidas nos
checkpoint files.
Estes arquivos so mantidos em containers e alimentados por uma um processo chamado Log Reader
thread, que basicamente aplica os registros de log que vo sendo gerados pelas transaes, presentes no
tail do transaction-log. Este processo passou a ser identificada como um possvel gargalo, j que no
escalvel no SQL Server 2014.
J que os checkpoint files foram introduzidos no ponto anterior, podemos revelar mais um problema
que foi detectado a sua volta no SQL Server 2014.
Conforme dito, os checkpoint files esto armazenados em containers. A gesto destes containers
feita com base numa soluo j existente no SQL Server: O Filestream.
Porm, o processo de Garbage Collector (coletor do lixo) gerado pelos checkpoint files no eficiente,
sendo que o Garbage Collector do FIlestream no liberta o espao em disco imediatamente, o que pode
causar problemas de falta de espao para a manuteno de checkpoint files ativos, ou criao de novos
arquivos.
Este lixo gerado pela operao de Merge que executada periodicamente de forma a remover do
disco dados que j no so mais referenciados por tabelas in-memory durveis, o que pode ser gerado
por comandos de DELETE , UPDATE, DROP TABLE e ALTER TABLE.
De forma a resolver este problema, a Microsoft desacoplou a gesto de storage do FileStream, no SQL
Server 2016, permitindo que os checkpoint files no utilizados sejam apagados imediatamente aps no
terem mais apontadores os referenciando no transaction log.
Para alguns ramos da indstria, o TDE essencial de forma a se obter certificaes importantes que
permitem o negocio atingir altos nveis de competitividade e aceitao por parte dos clientes. Por este
motivo, mesmo que a melhoria de performance seja a prioridade nmero um, a falta de suporte ao TDE
ou de uma tecnologia semelhante impede que muitas bases de dados passem a usufruir das capacidades
do In-Memory OLTP. Seria o mesmo que dirigir um carro de Formula-1 sem capacete e cinto de segurana.
Paralelismo
No SQL Server 2014, planos de execuo envolvendo tabelas otimizadas para memria nunca iro usar
paralelismo. J no SQL Server 2016 esta situao foi melhorada, sendo que algumas operaes usando
ndices in-memory o tipo HASH podero ser executadas em paralelo, desde que no seja executada por
uma Stored Procedure compilada nativamente.
AlwaysOn Availability Groups
Ao utilizar o Availability Groups em bases de dados contendo tableas in-memory, no SQL Server 2014,
era possvel verificar um atraso no sincronismo face a tabelas tradicionais. Esta problema foi solucionado,
sendo que no SQL Server 2016 todas as tabelas, independentemente do tipo, sero sincronizadas em
simultneo.
Imagine uma tabela que foi mal planejada, com tipos de dados no convenientes, ou mesmo um novo
requisito trouxe a necessidade de se adicionar uma nova coluna. simples alterar uma tabela certo?
Agora pense num relatrio que funcionaria melhor se um simples ndice fosse adicionado. Uma boa
soluo que pode trazer timos resultados, certo?
E se existisse um SGBD no qual no fosse possvel a alterao de tabela, ou criao de ndices. Voc
iria escolher esta plataforma para o seu projeto?
Pois exatamente isso que acontece no In-Memory OLTP para SQL Server 2014. No podemos alterar
tabelas, no podemos renomear tabelas nem ao menos alterar ou adicionar novos ndices. Estas
limitaes fazem tarefas simples como responder a mudanas nos padres de dados ou modificaes
aplicacionais serem um pesadelo.
Esta grande limitao est no Top-5 dos motivos de rejeio do in-memory OLTP, em conjunto com
comandos bsicos de T-SQL que no so suportados. Coisas simples, que j estamos acostumados, mas
que no podemos viver sem. Seria como tentar respirar em lugar sem oxignio.
Felizmente muitos dos problemas descritos foram resolvidos no SQL Server 2016, trazendo um novo
flego ao In-Memory OLTP. Finalmente, o comando ALTER ser suportado!
No In-Memory OLTP voc poder apreciar no apenas o poder de um comando ALTER TABLE, assim
como um ALTER PROCEDURE. O famoso sp_recompile tambm ser suportado.
Em conjunto com o ALTER TABLE, os comandos ADD/DROP/ALTER INDEX podero ser usados, o que
permitira seguir o dinamismo dos requisitos tcnicos e resolver problemas de performance. Ainda sobre
ndices, outra preocupao era uma opo para alterar o bucket_count dos ndices In-Memory do tipo
HASH, o que afeta diretamente a performance. Isso ser possvel atravs de um rebuild deste ndice.
de grande importncia referir que ao se executar o comando ALTER TABLE, a alterao ser feita
offline e requer espao livre em memria igual ao ocupado pela tabela. Uma limitao a esta operao,
mas que provavelmente ser trabalhada no futuro. Infelizmente a execuo de sp_rename ainda no ser
suportado.
Em relao a comandos T-SQL, a seguinte lista mostra o que no era suportado no SQL Server 2014 e
passou a ser no SQL Server 2016:
CREATE PROCEDURE
DROP PROCEDURE
ALTER PROCEDURE
SELECT e INSERT SELECT
SCHEMABINDING e BEGIN ATOMIC (stored procedures com compilao native requeridas)
NATIVE_COMPILATION
Parametros e variveis podero ser declaradas como NOT NULL
Parmetros table-valued.
GRANT e DENY suportados em tabelas e procedures
Aninhamento de Stored Procedures nativas
RIGHT OUTER JOIN, LEFT OUTER JOIN, INNER JOIN, e CROSS JOIN em clusulas SELECT
Operadores NOT, OR, e IN nas clusulas SELECT, UPDATE e DELETE
UNION ALL e UNION
SELECT DISTINCT
Clusula GROUP BY, sem funes de agragao, suportadas na clusula SELECT.
COLUMNSTORE
COLLATE
AFTER DML triggers compilados nativamente
Outra importante nota que no SQL Server 2016 todas as collations sero suportadas, ao contrrio do
SQL Server 2014 que obrigava o uso da collation BIN2.
Ferramentas
Para fechar o assunto, algumas melhorias a nvel de ferramentas foram introduzidas, incluindo:
Outra concluso de que a evoluo no SQL Server 2016 notvel, e aborda praticamente todos os
pontos nos quais o In-Memory OLTP foi mais criticado no SQL Server 2014, trazendo uma resposta, quase
que subliminar, a quem no acredita no poder desta funcionalidade assim como no forte investimento
nesta rea que vem sido feito por parte da Microsoft.
A documentao oficial e completa do In-Memory OLTP, para SQL Server 2016, poder ser encontrada
no seguinte link: https://goo.gl/o3Nhcv.
Deadlock no SQL Server
Veja neste artigo quais os tipos de locks encontrados no SQL Server 2008/2008 R2/2012,
o que deadlock e como acontece um deadlock. Por fim, veja como receber um alerta no
seu e-mail quando este evento ocorrer no ambiente de produo.
Introduo
O artigo tem como objetivo demostrar como receber notificaes por e-mail quando a sua instncia
de SQL Server sofrer um deadlock. A princpio irei conceituar um pouco sobre locks, os tipos de locks, para
finalmente entrarmos propriamente dito no tema deadlock. O mesmo tambm ser conceituado e depois
comeo a demonstrar a soluo adotada para recebermos por e-mail os dados que participaram
diretamente do deadlock.
Definio Lock
O gerenciamento de locks uma funo crucial para qualquer sistema de banco de dados. Os locks so
utilizados em ambos os modelos otimista e pessimista, embora os processos sejam diferentes.
No modelo otimista o nico bloqueio que ocorre que os escritores bloqueiam outros escritores. O
modelo otimista usa um mtodo de controle de concorrncia chamado de multiversion concurrency
control (MVCC) usado para o versionamento de linha para permitir que os leitores possam ver o dado no
estado anterior a modificao ocorrer. Um processo que modifica os dados no afetado por um processo
de leitura, porque o leitor est acessando a verso anterior das linhas de dados. O SQL Server usa o
tempdb para armazenar as verses de todas as linhas alteradas e mantm essas cpias enquanto
existirem quaisquer transaes que precisam ser acessadas. O espao utilizado no tempdb para as verses
anteriores chamado de version store. Antes de utilizar o row versioning deve-se considerar
cuidadosamente as vantagens e desvantagens da utilizao deste modelo de concorrncia. Uma vez que
ser necessrio monitorar mais de perto o aumento do uso do tempdb para armazenamento das verses.
Outra coisa que deve ter em mente que o controle de verso diminui o desempenho de operaes de
alterao de dados, por causa do trabalho extra envolvido na manuteno das verses antigas. Quando
voc usa o row versioning, leitores no bloqueiam escritores e escritores no bloqueiam leitores, embora
escritores continuem a ter bloqueios e bloquear outros escritores.
Lock Modes
O SQL Server pode bloquear os dados utilizando diferentes modos de bloqueios, so mais conhecidos
como lock modes. O lock mode mostra o quo restritiva um lock , e que outras aes so possiveis
enquanto o lock mantido.
Uma comparao interessante foi a do livro Professional SQL Server 2012 Internals and
Troubleshooting [5], ele fala que os dados em um banco de dados no igual a de um livro que s pode
estar na posse de uma pessoa ao mesmo tempo. Se voc est lendo um livro, ele est nas suas mos e
outras pessoas que desejam l-lo no podem simplesmente tirar das suas mos e comear a ler. Precisam
esperar voc acabar a sua leitura e disponibilizar o livro para a prxima pessoa interessada.
Traduzindo para o SQL Server seria por exemplo voc querendo fazer uma operao de leitura (read
operation) em uma tabela qualquer, neste momento adquire o chamado shared lock, se fosse uma
operao de escrita (write operations) iria adquirir um exclusive lock e por fim se fosse uma operao de
atualizao (update lock) seria adquirido durante a parte inicial da operao de update, enquanto SQL
Server est em busca dos dados para realizar o update.
SQL Server adquire e libera esses tipos de locks automaticamente. Assim como gerencia a
compatibiliade entre os modos de bloqueio, resolve deadlocks e escala locks caso seja necessrio. Ele
controla bloqueio em tabelas, nas pginas das tabelas, nas chaves de indices (index keys) e em linhas
individuais de dados. [1]
Por padro o SQL Server adquire um Shared Lock (S) quando faz a leitura de dados. Um Shared Lock
pode ser mantido em uma tabela, uma pgina, um index key ou uma linha individual [2]. Quando o pedido
para a leitura de uma linha feito, o SQL Server ir solicitar um lock no modo shared. Esse modo
compatvel com a maioria dos outros locks, uma vez que s permitido a leitura da linha na pgina de
dados. Muitos processos podem segurar um shared lock nos mesmos dados, mas nenhum processo pode
adquirir um exclusive lock no dado que tem um shared lock sobre ele (a menos que o processo que est
solicitando um exclusive lock seja o mesmo processo que est segurando o shared lock [3]).
No nvel de isolamento padro, os bloqueios compartilhados so liberados assim que os dados forem
lidos, mas esse comportamento pode ser alterado usando hints ou um nvel de isolamento diferente.
Os bloqueios exclusivos (exclusive locks) so usados para modificao de dados atravs dos comandos
de INSERT, UPDATE e DELETE. No caso do exclusive lock, ele no compativel com qualquer outro tipo de
lock, incluindo outros exclusive locks. Todos os locks devem experar at que o exclusive lock seja liberado
antes que possam continuar. Bloqueios exclusivos so mantidos at o final da transao seja ela um
commit ou rollback. Porm, voc pode ler dados com um exclusive lock basta usar o hint NOLOCK ou usar
o nvel de isolamento uncommited. Isso acontece porque os comandos DML precisam primeiro ler os
dados de sero modificados, ou seja, voc sempre achar um exclusive lock acompanhado de um shared
lock nos mesmos dados. Por exemplo, ao utilizar o comando update para modificar as linhas de uma tabela
usando um join para outra tabela, o update neste caso, solicita um shared lock nas linhas lidas na tabela
do join e depois solicita um exclusive lock nas linhas que sero atualizadas [8].
Update Lock
Os bloqueios de atualizao (update locks) so uma forma hibrida do shared locks e exclusive locks.
Eles so adquiridos quando uma operao de modificao de dados solicitada. A primeira coisa que o
SQL Server deve fazer procurar a tabela que precisa ser modificada. O processo simples, o SQL Server
usa o update lock para localizar os dados e em seguida impede que outros processos atualizem esses
dados. Como o update lock obstruiu todos os outros bloqueios de modificao, tudo o que precisa fazer
esperar at ele poder ser convertido para um exclusive lock, quando o ltimo shared lock (se houver)
for liberado.
Update locks oferecem compatibilidade com outros leitores, permitindo que o processo de
modificao dos dados tenha garantido que os dados no foram alterados desde a ltima leitura. Um
update lock no suficiente para permitir que voc altere os dados. Todas as modificaes exigem que o
recurso que est sendo modificado tenha um exclusive lock. [4]
Apesar do nome ser update locks, ele no se refere apenas a operaes de UPDATE. O SQL Server
usa update locks para qualquer operao de modificao de dados que exige uma pesquisa de dados antes
da modificao real. Tais operaes incluem updates e deletes condicionais, bem como inserts into em
uma tabela sem ndice cluster (clustered index). Neste ltimo caso, o SQL Server deve primeiro procurar
os dados (usando o ndice cluster) para encontrar a posio correta para inserir a nova linha. Mesmo que
o SQL Server s esteja pesquisando, ele usa update locks para proteger os dados. S depois de achar o
local correto e comear a inserir que ele faz a converso do update lock para um exclusive lock [1].
Intent Lock
Esse tipo de bloqueio no um modo diferente, o termo Intent um qualificador para os modos que
foram descritos anteriormente. O SQL Server pode conceder lock em vrios nveis ou graus de
granularidade e esses nveis so usados para formar uma hierarquia dentro do SQL. Por exemplo, uma
linha est na parte inferior dessa hierarquia e ela pertence a uma pgina, a pgina pertence a uma tabela
e assim por diante.
O propsito do Intent Lock indicar aos nveis mais altos da hierarquia de bloqueios que uma parte do
recurso tem um lock mantido contra ele. Seria mais ou menos assim: Se um exclusive lock adquirido em
um registro, a pgina e a tabela tero um intent exclusive lock (IX) mantido contra eles. Caso outro
processo queira adquirir um table lock, ele pode ver que existe um intent exclusive lock no nvel da tabela
e consequentemente sabe que a operao est bloqueada, sem ter que fazer um scan na tabela inteira
procurando por locks conflitantes. Esse tipo de lock no a mesma coisa que um shared lock ou exclusive
lock, eles servem de indicadores para o SQL Server, mostrando que um lock foi obtido em um nvel mais
baixo da hierarquia para um recurso. [5]
Schema Lock
Esse tipo de bloqueio um pouco diferente dos outros bloqueios mencionados acima, uma vez que
so adquiridos no nvel do objeto e metadados. Por exemplo, imagine que voc tem uma tabela e quer
excluir uma coluna porque houve uma mudana no negcio e o dado contido nela no mais necessrio,
mas ao mesmo tempo tem uma outra pessoa tentando criar um ndice que inclui a coluna que voc
pretende excluir. Neste caso ns temos duas pessoas tentando alterar o mesmo objeto simultaneamente.
O schema lock (Sch-M) similar ao lock exclusive uma vez que eles so mantidos at o final da
transao. Essa informao importante para quando formos executar instrues DDL dentro de
transaes explicitas (aquelas que voc define o incio e o trmino da transao formalmente), pois em
caso de erro possvel desfazer as alteraes de schema e tambm impede qualquer acesso aos objetos
afetados at que a transao seja confirmada [13].
Existem dois modos de schema locks: schema modification (Sch-M) e schema stability (Sch-S). Quando
uma consulta compilada os locks de schema stability impedem que outros processos adquiram locks de
schema modification que so usados quando a estrutura de uma tabela est sendo modificada. Eles so
disparados por diferentes processos, mas basicamente se resumem a mesma coisa.
Deadlock
O deadlock ocorre quando uma transao bloqueia um recurso e em seguida tenta adquirir um lock
em outro recurso, mas bloqueado por outra transao e no ser capaz de concluir a sua operao at
que a segunda transao seja concluda e liberar seus bloqueios. Porm, se a segunda transao faz algo
que precisa esperar a primeira transao, eles vo ficar esperando para sempre. Felizmente, essa situao
detectada pelo Database Engine e um dos processos terminado. O SQL Server permite que uma
transao seja completada e elimina a outra transao com uma mensagem de erro, notificando ao
usurio que ele foi escolhido como vtima do deadlock (deadlock victim).
Imagine a seguinte situao: Voc v em um site qualquer uma promoo imperdvel de uma viagem
que quer fazer faz muito tempo, mas a mesma s possui duas passagens. Imediatamente voc manda
mensagem para seu namorado falando que vai comprar as passagens e j faz todo o cadastro para poder
garantir a compra. Ao tentar selecionar os acentos voc s consegue visualizar uma poltrona. Porm, do
outro lado da cidade est seu namorado (que por coincidncia do destino tambm viu a mesma
promoo) est tentando fazer uma surpresa para o aniversrio de namoro que est prximo. S que ao
tentar selecionar as duas poltronas restantes s existe uma poltrona a outra est reservada!
1. Voc tentando reservar as poltronas A1 e B1. Ou seja, voc (Transao 1) est bloqueando as
poltronas, ao mesmo tempo o seu namorado (Transao 2) tambm est tentando reservar as
poltronas.
2. Voc (Transao 1) conseguiu selecionar a poltrona A1, mas ao tentar reservar a poltrona B1 no
consegue, pois a mesma est bloqueada pelo seu namorado (Transao 2). Ou seja, voc
(Transao 1) entra em estado de espera.
3. Seu namorado (Transao 2) tenta acessar a poltrona B1 para fazer a reserva, mas ela j est
bloqueada por voc (Transao 1). Seu namorado (Transao 2), neste caso tambm entra em
estado de espera. Caso nada acontea a Transao 1 e o Transao 2 vo ficar esperando
indefinidamente.
Existe uma thread separada no SQL Server conhecida como LOCK_MONITOR, ela responsvel por
verificar se ocorreu um deadlock a cada cinco segundos. Esse intervalo pode ser reduzido at menos que
100 milissegundos dependendo da frequncia que ocorrem os deadlocks [1].
Quando o deadlock detectado o Database Engine termina uma das threads para resolver o deadlock.
Existem 21 nveis diferentes de prioridade, de -10 at 10. O valor baixo (low) equivale a 5, nomal (normal)
0 e alto (high) 5 [7]. Se as sesses possuem diferentes prioridades de deadlock, a sesso com menor
prioridade ser escolhida como vtima. Caso, ambas as sesses possuam a mesma prioridade de deadlock,
o SQL escolhe a sesso que menos cara para fazer o rollback. Porque se o SQL Server deve matar uma
transao, qualquer trabalho feito at o momento deve ser revertido para colocar o banco de dados em
um estado consistente. Neste caso, o SQL Server faz o rollback da sesso que usa menos espao no log de
transao, olhando o valor de LOG USED (Figura 2). A sesso que foi finalizada recebe um erro 1205 e a
seguinte mensagem exibida:
Error 1205: Transaction (Process ID) was deadlocked on resources with another process and has been
chosen as the deadlock victim. Rerun the transaction.
Depois que o processo morto, a transao abortada e seus locks liberados, o outro processo
envolvido no deadlock pode terminar o trabalho e liberar os seus locks.
Lembrando que o nvel de prioridade pode ser controlado atravs da instruo: SET
DEADLOCK_PRIORITY. Essa configurao definida em tempo de execuo e no quando acontece o
parse [12]. Ou seja, voc define a importncia da sesso caso ocorra um deadlock com outra sesso.
Monitorando Deadlock
Agora que sabemos o que deadlock, podemos pensar em qual a melhor maneira de identificarmos
se nosso ambiente est sofrendo desse tipo de problema. Na realidade existem vrias maneiras tais
como: system health, extend events, profiler ou habiltando alguns trace flags.
Irei descrever a soluo que adotei para poder receber notificaes por e-mail da minha instncia
quando ocorresse algum deadlock. O objetivo era descobrir qual a frequncia desse evento e depois traar
um plano para descobrir o motivo desse deadlock e, consequentemente, buscar uma soluo para evitar
ou pelo menos diminuir a incidncia desse problema em nosso ambiente.
A primeira coisa que precisamos saber seria quando o deadlock ocorre, uma vez com essa informao
precisamos pegar as consultas envolvidas no deadlock, para, por fim, enviar um e-mail com essa
informao. Na Figura 3 descreve como nossa soluo ser montada.
Criao Alerta
A primeira coisa que devemos fazer ser criar um alerta na nossa instncia para o evento de deadlock.
Alertas no servem apenas para erros ou eventos, voc pode criar um alerta para ser acionado em
resposta a uma condio especifica. Neste caso, voc diz que mtrica o alerta deve monitorar, define um
threshold (valor limite) para o alerta e o comportamento para do contador que ir disparar o alerta.
Existem duas maneiras de configurar o SQL Server Agent Alert, uma usando a interface grfica e a
outra utilizando a stored procedure sp_add_alert. No nosso acaso um alerta deve ser enviado cada vez
que ocorrer um deadlock e um job ser executado. Lembrando que essa feature est disponvel somente
nas edies Enterprise e Standard do SQL Server.
3. Na guia General , preencha o campo name com o nome que voc quer dar para o alerta.
4. No campo type selecione a opo SQL Server performance condition alert.
5. Na guia Performance condition alert definition, especifique a mtrica de desempenho que voc
deseja ser alertado e o threshold, conforme figura 5.
6. Na guia Response se marcarmos o check no combo Execute Job ir mostrar todos os jobs criados
(na prxima seo criaremos o job).
Figura 6. Habilitar Job
Criao JOB
O prximo ser criar o job que o alerta ir disparar. No JOB iremos fazer a chamada de uma stored
procedure que ser a responsvel por enviar o e-mail contendo o contedo do trace flag 1204. Existem
dois trace flags que capturam as informaes de deadlock e jogam no error log do SQL Server. So eles:
1204 Fornece as informaes sobre os ns envolvidos no deadlock. Cada n tem uma seo
dedicada e uma seo final que descreve o deadlock victim.
1222 Retorna as informaes do deadlock no formato xml.
Use o comando abaixo para habilitar o trace flag 1204. Quando ocorrer uma nova situao de
deadlock, voc receber uma mensagem de erro no error log.
Uma vez habilitado quando ocorrer um deadlock o seu error log estar mais ou menos assim:
Figura 7. Error Log com trace flag habilitado
Lembre-se que se houver um restart do seu SQL Server este trace flag no estar mais habilitado. Se
voc precisa que este trace flag esteja ativo aps um reboot, failover ou restart por n motivos. Existe a
opo de startup parameters nas propriedades do servio do SQL Server. Uma vez nesta guia voc
poder dizer quais trace flags quer estejam habilitados aps o banco de dados estiver ativo.
Na procedure do alerta iremos fazer um insert na tabela TB_DEADLOCK. Essa tabela ser responsvel
por armazenar todos os eventos de deadlock ocorridos na instncia. Criei essa tabela com o objetivo de
depois desenvolver um relatrio com a mdia por semana, ms ou ano, relatando a frequncia com que
ocorrem deadlocks (a criao do relatrio no ser contemplada neste artigo).
Uma vez concludo o insert na tabela a procedure ira pegar as informaes do deadlock inseridas no
error log do SQL Server e ir enviar por e-mail em uma tabela para os usurios definidos na varivel
@EMAILUSUARIO. Abaixo o cdigo para a criao da procedure:
/* ===========================================================================
RESPONSAVEL: CIBELLE CASTRO
DATA DE CRIAO: 24/02/2015
DATA ALTERAO: 24/02/2016
CONTATO: CIBASCASTRO@GMAIL.COM
OBJETIVO: PROCEDURE INSERE NA TABELA TB_DEALOCK O CNTR_VALUE E A DATA. DEPOIS
DISPARA O EMAIL COM O TEXTO INSERIDO NO ERRORLOG
============================================================================== */
/*
1 - VERIFICAR SE O TRACE ESTA HABILITADO
DBCC TRACESTATUS (1204);
GO
DBCC TRACEON (1204,-1)
GO
*/
BEGIN
INSERT INTO dbo.TB_DEADLOCK (DT_DEADLOCK, CNTR_VALUE)
SELECT GETDATE(), CNTR_VALUE
FROM SYS.DM_OS_PERFORMANCE_COUNTERS
WHERE COUNTER_NAME = 'NUMBER OF DEADLOCKS/SEC'
AND INSTANCE_NAME = '_Total'
PRINT 'DEADLOCK OCORREU!! INSERE CNTR_VALUE NA TB_DEADLOCK'
DECLARE @TMP_ERRORLOG AS TABLE (
ID_TMP_DEADLOCK BIGINT IDENTITY (1,1),
LOGDATE DATETIME,
PROCESSINFO VARCHAR(100),
ERRORTEXT VARCHAR(MAX)
)
INSERT INTO @TMP_ERRORLOG
EXEC MASTER.DBO.SP_READERRORLOG 0, 1
DECLARE @TMP_DEADLOCK AS TABLE (
ID_TMP_DEADLOCK BIGINT IDENTITY (1,1),
LOGDATE DATETIME,
PROCESSINFO VARCHAR(100),
ERRORTEXT VARCHAR(MAX)
)
INSERT INTO @TMP_DEADLOCK
SELECT LOGDATE, PROCESSINFO, ERRORTEXT
FROM @TMP_ERRORLOG
WHERE ID_TMP_DEADLOCK >=
(
SELECT MAX(ID_TMP_DEADLOCK)
FROM @TMP_ERRORLOG
WHERE ERRORTEXT LIKE '%DEADLOCK ENCOUNTERED%'
)
AND PROCESSINFO NOT IN ('LOGON', 'BACKUP')
AND ERRORTEXT NOT LIKE '%LOGIN%'
--SELECT * FROM @TMP_DEADLOCK
DECLARE @SERVER AS VARCHAR(100)
SET @SERVER = (SELECT 'SERVER\INSTANCIA: '+@@SERVERNAME )
DECLARE @EMAILUSUARIO AS VARCHAR(256)
SET @EMAILUSUARIO = 'cibascastro@gmail.com'
DECLARE @BACKGROUND AS VARCHAR(50)
SET @BACKGROUND = '#FFFFF0'
DECLARE @MSG AS VARCHAR(MAX)
DECLARE @QTROWS AS NUMERIC
DECLARE @ROWATUAL AS NUMERIC
SELECT @QTROWS = COUNT(*) FROM @TMP_DEADLOCK
PRINT '@QTROWS: ' + CAST(@QTROWS AS VARCHAR(10))
SET @ROWATUAL = 1
1. Abra o Management Studio e v no cone do SQL Server Agent -> Job. Clique com o boto direito e
selecione a opo New Job.
2. Na Guia General preencha o campo Name, com o nome que deseja d para o job. No nosso caso
colocarei o nome: JOB_MONITORAMENTO_DEADLOCK.
3. Na guia Steps clique no boto New e inclua a procedure que criamos anteriormente.
Figura 11. Criao Step
4. Na guia Scheduler no ser necessrio fazer nada, pois o alerta que ir disparar a execuo do
job quando ocorrer um evento de deadlock.
5. Na aba de Notifications selecione o operado que voc deseja que receba um e-mail caso o job
venha falhar por algum motivo. Para maiores informaes de como criar um operador basta l
esse artigo no site do MSDN [10].
Interpretando o resultado
Agora vamos simular um deadlock para visualizarmos se o e-mail ir chegar no momento que ocorrer
o evento de deadlock. Para montar o ambiente da nossa simulao devemos baixar o banco de exemplos
AdventureWorks2012, o mesmo pode ser adquirido acessando o site do codeplex atravs do link:
http://sql2012kitdb.codeplex.com/releases/view/86805
USE AdventureWorks2012
GO
BEGIN TRAN
UPDATE [Person].[Address]
SET AddressLine2 = '5672 Hale Dr.'
WHERE AddressID = 26156
WAITFOR DELAY '00:00:10'
SELECT * FROM [Person].[Address]
WHERE AddressLine2 IS NOT NULL
AND City = 'Bellevue'
USE AdventureWorks2012
GO
BEGIN TRAN
UPDATE [Person].[Address]
SET AddressLine1 = '6387 Scenic Avenue'
WHERE AddressID = 24852
UPDATE [Person].[Address]
SET AddressLine1 = '1254 Scenic Avenue'
WHERE AddressID = 26156
WAITFOR DELAY '00:00:10'
Logo aps alguns segundos, a mensagem de erro 1205 mostrada na sesso que foi escolhida como
vtima do SQL Server.
Figura 14. Mensagem de erro 1205
Lembram que anteriormente havia falado que o SQL Server faz o rollback da sesso que usa menos
espao no log? A ttulo de curiosidade executei a query da listagem 1, que traz o valor da coluna
database_transaction_log_bytes_used onde contem o nmero de bytes utilizados no log para a
transao. Nesse exemplo a sesso que sofreu o rollback foi a de nmero 55, conforme figura 15. Veja
que o SPID 51 possui 716 bytes,e o SPID 55 tm 700 bytes portanto ela a transao mais rpida para
fazer o rollback.
USE AdventureWorks2012
GO
SELECT
ST.SESSION_ID,
DT.DATABASE_TRANSACTION_LOG_RECORD_COUNT,
DT.[DATABASE_TRANSACTION_LOG_BYTES_USED],
SQLTEXT.TEXT,
QP.QUERY_PLAN
FROM SYS.DM_TRAN_DATABASE_TRANSACTIONS DT
INNER JOIN SYS.DM_TRAN_SESSION_TRANSACTIONS ST ON DT.TRANSACTION_ID =
ST.TRANSACTION_ID
INNER JOIN SYS.DM_EXEC_SESSIONS ES ON ES.SESSION_ID = ST.SESSION_ID
LEFT OUTER JOIN SYS.DM_EXEC_REQUESTS ER ON ER.SESSION_ID = ST.SESSION_ID
INNER JOIN SYS.DM_EXEC_CONNECTIONS EC ON EC.SESSION_ID = ST.SESSION_ID
CROSS APPLY SYS.DM_EXEC_SQL_TEXT (EC.MOST_RECENT_SQL_HANDLE) SQLTEXT
OUTER APPLY SYS.DM_EXEC_QUERY_PLAN (ER.PLAN_HANDLE) QP
WHERE DT.DATABASE_ID = DB_ID()
ORDER BY DT.DATABASE_TRANSACTION_BEGIN_TIME
Listagem 1. Consulta log used
Depois que o deadlock ocorreu voc ir receber no seu email uma tabelinha igual a imagem abaixo:
Figura 16. Email com relatrio de deadlock
Legal!! Estamos recebendo o e-mail com a saida do error log. Porm precisamos interpret-los para
que tomarmos uma deciso do que dever ser feito para diminuir a incidncia desse evento ou sanar o
problema de vez. Na listagem 1 mostra os dados gerados aps o evento de deadlock:
BEGIN TRAN
UPDATE [Person].[Address]
SET AddressLine1 = '6387 Scenic Avenue'
WHERE AddressID = 24852
UPDATE [Person].[Address]
SET AddressLine1 = '1254 Scenic Avenue'
WHERE AddressID = 26156
WAITFOR DELAY '00:00:10'
-- ROLLBACK TRAN
Grant List 3:
Requested by:
ResType:LockOwner Stype:'OR'X des:0x0000000276C66890 Mode: S SPID:51 BatchID:0 ECID:0
TaskProxy:(0x00000002698EC638) Value:0x65bc0340 Cost:(0/1044)
NULL
Node:2
KEY: 8:72057594043826176 (a42839bc1d8b) CleanCnt:2 Mode:X Flags: 0x1
Grant List 3:
Owner:0x0000000265BBF0C0 Mode: X Flg:0x40 Ref:0 Life:02000000 SPID:51 ECID:0
XactLockInfo: 0x0000000276C668C8
SPID: 51 ECID: 0 Statement Type: SELECT Line #: 11 Input Buf: Language Event:
BEGIN TRAN
UPDATE [Person].[Address]
SET AddressLine2 = '5672 Hale Dr.'
WHERE AddressID = 26156
WAITFOR DELAY '00:00:10'
SELECT * FROM [Person].[Address]
WHERE AddressLine2 IS NOT NULL
AND City = 'Bellevue'
Requested by:
ResType: LockOwner Stype:'OR'X des:0x0000000276C5C700 Mode: U SPID:55 BatchID:0 ECID:0
TaskProxy:(0x0000000265DBA638) Value:0x741b5680 Cost:(0/1048)
NULL
Victim Resource Owner:
ResType: LockOwner Stype:'OR'X des:0x0000000276C66890 Mode: S SPID:51 BatchID:0 ECID:0
TaskProxy:(0x00000002698EC638) Value:0x65bc0340 Cost:(0/1044)
Listagem 2 . Sada Error Log
Toda essa informao pode ajud-lo a identificar exatamente como ocorreu o deadlock. Essa
informao um pouco mais difcil de ler do que quando vemos um deadlock graph ( a sada grfica das
informaes sobre as sesses e os recursos que foram envolvidos no deadlock), mas o conjunto de
informaes muito similar, apenas mais detalhada. Perceba que existem dois ns na sada do error log,
o node 1 e node 2, cada n representa um recurso bloqueado. Podemos observar que os detalhes da
situao do deadlock so descritos tais como:
Assim, podemos ver que no node 2 tem um intent exclusive (IX) lock que est sendo mantido pelo SPID
55 em um objeto com o ID 72057594043826176. Ou seja, ns podemos extrair as informaes binrias
da sada do deadlock. Por exemplo, para sabermos de qual objetos estamos nos referindo, basta consultar
as DMVs sys.objects e sys.partitions. Na opo KEY do segundo n, voc consegue ver o dado com o
seguinte formato: DatabaseID:ObjectID em alguns casos ela pode aparecer assim:
DatabaseID:ObjectID:IndexID. Para saber qual de que objeto trata-se essa identificao, vamos executar
a listagem 2.
SELECT
O.OBJECT_ID, O.NAME AS TABELA, P.HOBT_ID,
P.OBJECT_ID AS OBJECT_ID, P.INDEX_ID AS INDEX_ID
FROM SYS.PARTITIONS P
INNER JOIN SYS.OBJECTS O ON O.OBJECT_ID = P.OBJECT_ID
WHERE P.HOBT_ID = 72057594043826176;
GO
Listagem 3. Consulta sys.objects e sys.partitions
Como resultado podemos visualizar na Figura 17. Nela podemos perceber que o formato apresentado
anteriormente de DatabaseID:ObjectID. Esse formato nos traz todas as informaes necessrias para
sabermos quais objetos esto envolvidos nos bloqueios.
Figura 17. Consulta na chave KEY:8:72057594043826176
Ao final do node 1, podemos ver a opo Requested by, que detalha os pedidos dos recursos que no
podem ser concedidos, devido ao bloqueio. Veja que o SPID 51 est esperando por um shared read lock
na tabela Address, porm ela est bloqueada por um update lock mantido pelo SPID 55. No node 2,
podemos ver que o SPID 55 est esperando adquirir um update lock na pgina de dados, mas a mesma
est bloqueada pelo shared read lock realizado pelo SPID 51.
Como podemos ver na figura 17, a primeira sesso segura um exclusive lock (X) em uma linha. A
segunda sesso est tentando adquirir um update lock na mesma linha e est sendo bloqueado devido a
incompatibilidade de bloqueios. Neste artigo no abordei nada sobre lock compatibility, sugiro que deem
uma leitura na documentao do SQL Server ou nos livros de Internals do SQL Server [17].
No ode 1 ao invs de mostrar a opo KEY que observamos anteriormente, est mostrando a opo
PAG, referente a pgina de dados. O formato para PAG : DatabaseID:FileID:PageID.
A sada do DBCC PAGE dividida em quatro sees principais: Buffer, Page Header, Data e Offset Table.
A seo que nos interessa neste momento a Page Header, para ser mais especifica a opo Metadata:
ObjectId e Metadata: IndexId. Nestas opes ns conseguiremos obter o nome do objeto e do ndice
que obtiveram um lock IX.
Os resultados das consultas podem ser visualizados na Figura 19, onde podemos finalmente concluir
que o objeto que estvamos procurando a tabela Address e o ndice no-cluster IX_Address_01.
No final da listagem 1 podemos ver a opo Victim Resource Owner. Essa opo mostra qual SPID foi
escolhido como vtima do deadlock. No nosso exemplo foi o SPID 51. Compreender as consultas que esto
sendo executadas e os objetos envolvidos no deadlock fundamental para solucionar o problema.
Uma vez que voc analisar a causa dos bloqueios, o prximo passo determinar as possveis solues.
Tente otimizar as consultas executadas pelo bloqueio e os processos bloqueados. Fazendo isso voc ir
reduzir o tempo que os bloqueios so mantidos pelos processos. Tenha em mente que a reduo no quer
dizer que no haver mais bloqueios, porm, a execuo das consultas estar em um limite aceitvel e
uma pequena quantidade de bloqueios poder ser ignorada.
Uma outra abordagem que pode ser adotada para resolver problemas de bloqueios pode ser a
utilizao de um nvel de isolamento inferior. Por exemplo, suponhamos que voc quer fazer uma leitura
de dados na maior tabela da sua base de dados, uma vez que executar o comando select na transao
voc obter um shared lock (S) na linha de dados que deseja fazer a pesquisa, se o nvel de isolamento
fosse reduzido para o read uncommitted o bloqueio requisitado anteriormente no seria mais necessrio
na instruo select. Porm, como nada vem de graa essa soluo possui alguns problemas. Voc pode
fazer o que chamamos de dirty reads. Dirty reads uma leitura suja, ou seja, quando lemos dados que
ainda no foram confirmados (uncommitted). Isso pode significar que os dados retornados na instruo
select est sendo alterado e a sua leitura est sendo comprometida, pois os dados no so consistentes.
O read uncommitted uma forma muito utilizada para reduzir a conteno, mas vem com altos custos
em termos de preciso de dados. Precisamos estar cientes dos custos dessa prtica antes de habilitarmos
nos nossos bancos de dados.
Algumas bases de dados possuem um grande volume de dados que precisam ser acessados a todo
momento, uma forma de minimizar os bloqueios a utilizao de particionamento. O particionamento
tem como objetivo facilitar o gerenciamento de grandes tabelas ou ndices permitindo o acesso e o
gerenciamento de subconjuntos de dados de forma rpida e eficaz [16]. Os dados particionados so
divididos horizontalmente, isto , o particionamento feito em cima de certos valores, por exemplo, a
tabela de alunos de uma escola pode ser particionada pela data da matricula e os dados divididos nos
meses do ano. Isso permite que as transaes sejam executadas simultaneamente nas parties
individuais, sem bloquear um ao outro. Essas parties so tratadas como uma unidade nica para
consultar, atualizar e inserir. Lembre-se que o particionamento s est disponvel nas verses developer
e enterprise do SQL Server.
Concluso
O objetivo desse artigo era demonstrar uma forma rpida e fcil de monitorar seu ambiente quando
ocorressem deadlocks. Uma vez identificado a frequncia que esse evento ocorre voc deve definir quais
estratgias devero ser tomadas para solucionar ou minimizar esse tipo de problema no seu servidor de
banco de dados. Ressalto que necessrio estudar um pouco mais sobre locks, os modos, a
compatibilidade, os nveis de isolamento e etc., para conseguirmos resolver outros tipos de deadlocks no
nosso ambiente. Acredito que o artigo deva d um ponta p inicial para entendermos um pouco mais
sobre o comportamento do SQL Server no nosso ambiente.
Referncias
Randal, P.; et al. Microsoft SQL Server 2012 Internals pag. 774
Bolton C.; et al. Professional SQL Server 2008 Internals and Troubleshooting. Professional. pag 598
Delaney, K.; et al. Microsoft SQL Server 2012 Internals. Professional. pag 776.
Bolton C.; et al. Professional SQL Server 2012 Internals and Troubleshooting pag 168