SQL Server: Além do Conceito

Transcrição

Blog Post Collection
MVTech |1
MVTech |2
Diego Nogare – Edvaldo Castro – Demetrio Silva – Marcel Inowe – Marcos
Freccia – Ivan Lima – Fabiano Amorim – Sulamita Dantas – Marcelo
Fernandes – Cibelle Castro – Leandro Ribeiro – Luciano Moreira – Nilton
Pinheiro – Tiago Balabuch – Felipe Ferreira
MVTech |3
MVTech |4
Uma coletânea de posts escolhidos
pelos próprios autores para te
ajudar nas atividades do dia-a-dia.
MVTech |5
Editor: Diego Nogare
Introdução: Edvaldo Castro
Prefácio: Roberto Fonseca
Capa: Felipe Borges
Autores: Diego Nogare – Edvaldo Castro – Demetrio Silva – Marcel
Inowe – Marcos Freccia – Ivan Lima – Fabiano Amorim – Sulamita
Dantas – Marcelo Fernandes – Cibelle Castro – Leandro Ribeiro –
Luciano Moreira – Nilton Pinheiro – Tiago Balabuch – Felipe Ferreira
MVTech |6
Introdução
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 técnica de profissionais que trabalham com
produtos e ferramentas ligados à Plataforma de Dados da Microsoft é bem
atuante e unida, isso faz com que muito conteúdo seja gerado, seja com
vídeos, eventos, palestras, entrevistas e postagens em blogs.
Com esta grande quantidade de material correlacionado, um grupo de
amigos que aqui denominados "SQL Friends" teve a ideia de reunir seus
trabalhos em blogs pessoais para criar uma coletânea destes posts e
entregar em uma única publicação alguns textos de seus blogs.
Os assuntos estão direcionados ao que os autores escrevem geralmente em
seus blogs pessoais, podendo ou não estarem correlacionados entre si. O
mais interessante, é que em uma mesma publicação, encontra-se um rico e
variado conteúdo: Administração de Banco de Dados, BI, Performance
dentre outros.
“SQL Server: Além do Conceito - Blog Post Collection" foi idealizado para
proporcionar uma experiência variada e com conteúdo idem, por isso
aprecie o conteúdo e se tiver alguma dúvida ou sugestão, fique à vontade
para entrar em contato direto com o autor, através do blog do mesmo que
está informado no interior desta publicação.
Um ponto importante a ser mencionado, este trabalho por ser voluntário e
não ter um cunho com fins financeiros, teve uma tratativa diferente mas não
menos cuidadosa com relação à um livro ordinário. Cada autor é o
responsável direto pelo que escreveu e publicou na coletânea, mas todos
estão juntos para proporcionar e compartilhar o conhecimento que
adquiriram ao longo de vários anos de experiência.
MVTech |7
Apesar de NÃO ser um LIVRO formalmente falando, é possível absorver
conhecimento técnico de alta qualidade escrito pelos autores, exatamente
como pode ser encontrado em seus respectivos blogs.
Aproveite bem, e quaisquer necessidades de contato, não hesite em nos
enviar uma mensagem.
Boa Leitura,
Edvaldo Castro
MVTech |8
Prefácio
A presente obra foi cuidadosamente produzida como fruto de diversos anos
de trabalho e conhecimento dos autores e corresponde a uma compilação
aprimorada de posts publicados por eles no decorrer dos últimos meses e
extensivamente testado como parte dos seus esforços em adquirir um
conhecimento avançado e aprofundado.
O Microsoft SQL Server 2014 é a próxima geração da Plataforma de
Informação da Microsoft, com novas funcionalidades que entregam um
melhor desempenho, expandem seus dados para a nuvem e provêem
estruturas de BI poderosas. O SQL Server 2014 possui dezenas de novas
funcionalidades e melhorias para DBAs, Desenvolvedores e especialistas em
Business Intelligence.
O material aqui apresentado tem como finalidade principal servir como base
de pesquisa para aqueles que têm interesse em entender sobre novas
funcionalidades e evoluir os seus conhecimentos. Neste livro, você verá
como o SQL Server 2014 utiliza funcionalidades como o Read Committed
Snapshot Isolation, Particionamento de Tabelas, Tuning no Sharepoint e SQL
Server, Importação de Dados com o Integration Services, Auditoria no SQL
Server, Erros de Instalação, Fragmentação do Transaction Log, uso de
Snapshots, Deadlocks, conversões e uso de tipos de dados de Datas,
Contadores de Performance e problemas de rede para entregar uma das
melhores ferramentas para a tomada de decisão e gerenciamento de bancos
de dados disponíveis no mercado.
Temos a certeza que esta obra irá contribuir consideravelmente para a
desmistificação de muitos tópicos considerados complexos, mostrando não
apenas o significado destes tópicos, mas também mostrando o caminho a
seguir para a utilização no dia-a-dia.
MVTech |9
Desejamos a todos que tirem o melhor proveito deste excelente trabalho e
pedimos que nos informem quaisquer imprecisões ou incorreções que
possam ser encontradas nesta obra através do email
[email protected], para que possamos sempre manter
disponível um texto útil e eficaz para o seu aprendizado.
Roberto Fonseca
M V T e c h | 10
MVTech
O Minha Vida (http://www.minhavida.com.br) é uma empresa com um
grande propósito: melhorar a qualidade de vida da população. Queremos ser
capazes de despertar nas pessoas o cuidado com a sua própria saúde. E quando
falamos em saúde, nos referimos não só à prevenção ou ao tratamento de
doenças, mas também a pequenas mudanças de hábitos capazes de transformar
positivamente o dia a dia das pessoas.
Queremos fazer diferença na vida das pessoas!
Pensando nisso, nosso time de tecnologia criou o MVTech, uma
iniciativa para disseminar conhecimento através de iniciativas de seus
colaboradores, buscando o aprimoramento do mercado nacional.
Com diversas ações como: artigos técnicos em blogs; matérias para
portais; respostas em foruns de discussão, palestras em eventos, eventos
presenciais e online, etc… afinal, somos apaixonados pelo que fazemos! por que
não compartilhar nossa paixão?
A criação do MVTech dá um passo adiante nesta linha de
compartilhamento de conhecimento, passando a existir um canal oficial onde
poderão ser encontrados grandes conteúdos.
Seja bem vindo ao MVTech
Alexandre Tarifa – Diretor de Tecnologia – Minha Vida
M V T e c h | 11
M V T e c h | 12
Sumário
EDVALDO CASTRO ............................................................................... 21
DBA por acidente X Command Line ...................................................................... 21
“DBA por acidente” ........................................................................................... 21
READ COMMITTED SNAPSHOT ISOLATION – Aprecie com moderação ................ 24
“RCSI – Aprecie com moderação” ...................................................................... 24
MUITO BOM...................................................................................................... 24
CENÁRIO 1 ........................................................................................................... 25
RCSI NO CASO DO SR. JOAQUIM ............................................................................... 25
MAS…................................................................................................................ 26
CENÁRIO 2 ........................................................................................................... 27
O PROBLEMA........................................................................................................ 27
RCSI NESTE CASO .................................................................................................. 27
RESUMINDO:..................................................................................................... 32
PRÓS E CONTRAS DO RCSI: ...................................................................................... 32
REFERÊNCIAS .................................................................................................... 33
Artigos técnicos: O guia definitivo (ou não) .......................................................... 34
MOTIVAÇÃO ......................................................................................................... 34
RISCOS E OPORTUNIDADES....................................................................................... 34
QUANDO COMEÇAR? ............................................................................................. 35
PESQUISE ............................................................................................................. 35
LEIA E ESTUDE MUITO ............................................................................................. 35
FAÇA CITAÇÕES E REFERÊNCIAS .................................................................................. 36
REVISÃO PERIÓDICA (NÃO OBRIGATÓRIA) .................................................................... 36
O ARTIGO TÉCNICO ........................................................................................... 37
TIPOS DE ARTIGOS TÉCNICOS ............................................................................ 37
DOCUMENTAÇÃO................................................................................................... 37
HOW TO(S) .......................................................................................................... 37
BENCHMARKS E EXPERIÊNCIAS .................................................................................. 37
O ARTIGO TÉCNICO EM SI.................................................................................. 38
ESTRUTURA .......................................................................................................... 38
LINGUAGEM ......................................................................................................... 38
PÚBLICO ALVO ...................................................................................................... 38
GRAMÁTICA ...................................................................................................... 39
M V T e c h | 13
EVITE OS ERROS MAIS COMUNS (DIGITAÇÃO, GÍRIAS, CONCORDÂNCIA, ETC) ......................... 39
SOLICITE REVISÕES (AMIGOS, COMUNIDADE, PARENTES, SR. JOAQUIM) ............................ 39
PRINCIPAIS PREOCUPAÇÕES .............................................................................. 40
SEMPRE ............................................................................................................... 40
NUNCA................................................................................................................ 40
PUBLICIDADE ........................................................................................................ 40
FAÇA BARULHO ................................................................................................. 41
CONCLUSÃO ...................................................................................................... 41
DIEGO NOGARE................................................................................... 42
Partition Table ...................................................................................................... 42
Particionamento de Tabelas .............................................................................. 42
CENÁRIOS/BENEFÍCIOS ............................................................................................ 44
DEFINIÇÕES/TERMINOLOGIAS ................................................................................... 45
CRIANDO FILEGROUP .............................................................................................. 48
CRIANDO PARTITION FUNCTION ................................................................................ 54
CRIANDO O PARTITION SCHEME ................................................................................ 56
CRIANDO A TABELA................................................................................................. 57
COMPARATIVO DE INSERÇÃO DE DADOS EM UMA TABELA COM COLUMNSTORE INDEX NO SQL
SERVER 2012 ....................................................................................................... 58
DEMETRIO SILVA ................................................................................. 73
Tuning no SharePoint e SQL Server com o Developer Dashboard ........................ 73
Tunin no SharePoint com Developer Dashboard ............................................... 73
INTRODUÇÃO .................................................................................................... 73
CONFIGURAÇÃO .................................................................................................... 74
Veja a execução do script na figura 3: ............................................................... 76
Visualizando o Developer Dashboard ................................................................ 76
CONCLUSÃO ...................................................................................................... 80
Acessando dados do SharePoint com PowerPivot ................................................ 82
INTRODUÇÃO .................................................................................................... 82
REQUISITOS .......................................................................................................... 82
COMO FUNCIONA .................................................................................................. 82
IMPORTAR PARA O POWERPIVOT NO EXCEL ................................................................. 85
CONCLUSÃO ...................................................................................................... 91
Configurar envio de e-mail no SharePoint / SQL Server com o GMAIL ................. 92
M V T e c h | 14
PASSO 1: CONFIGURAR O SMTP SERVER NO WINDOWS 2008 ........................................ 92
MARCEL INOWE ................................................................................ 101
Dicas sobre o banco de dados do Protheus(Totvs) ............................................. 101
VAMOS AS DICAS: ................................................................................................ 101
MARCOS FRECCIA ............................................................................. 105
Importando arquivos excel usando o SSIS .......................................................... 105
T-SQL no SQL Server 2012 – Parte 1 .................................................................... 113
1) EXECUTE WITH RESULT SETS ....................................................................... 113
VAMOS VER COMO FUNCIONA? ............................................................................... 113
2) SEQUENCE .................................................................................................. 115
COMO UTILIZAR? ................................................................................................. 116
PASSO 1: CRIAÇÃO DA SEQUENCE. ........................................................................... 116
COMO UTILIZAMOS A SEQUENCE? ............................................................................ 116
RESULTADO. ....................................................................................................... 118
T-SQL no SQL Server 2012 – Parte 2 – Paginação de dados ................................ 120
CONSULTA 1 ....................................................................................................... 121
CONSULTA 2 ....................................................................................................... 122
IVAN LIMA ......................................................................................... 124
Inside The Machine – Introdução ....................................................................... 124
VELOCIDADE DO PROCESSADOR É TUDO? ................................................................... 124
REFERÊNCIAS: ................................................................................................. 128
Inside the Machine – Processadores................................................................... 129
INTRODUÇÃO .................................................................................................. 129
PROCESSADORES ................................................................................................. 129
OVERVIEW DA MICROARQUITETURA......................................................................... 129
CORE E UNCORE .................................................................................................. 130
PLANTA ............................................................................................................. 130
XEON E7 ........................................................................................................... 131
CORE I5 460M ................................................................................................... 132
MOORE’S LAW .................................................................................................... 133
M V T e c h | 15
COMPLEXIDADE ................................................................................................... 135
GPGPU ............................................................................................................ 135
CACHE............................................................................................................... 135
REFERÊNCIAS .................................................................................................. 135
Inside The Machine - Hyper-Threading (SMT) e SQL Server ................................ 137
TEORIA E PRÁTICA ................................................................................................ 138
MITO ................................................................................................................ 138
PROCESSADORES ................................................................................................. 138
REFERÊNCIAS: ................................................................................................. 139
FABIANO NEVES AMORIM................................................................. 140
Join reordering e Bushy Plans ............................................................................. 140
INTRODUÇÃO .................................................................................................. 140
JOIN REORDERING E BUSHYPLANS ............................................................................ 140
BUSHY PLANS NO SQL SERVER ............................................................................... 141
STATISTICS IO: ................................................................................................. 144
PLANO ESTIMADO: ............................................................................................... 145
STATISTICS IO: ................................................................................................. 149
STATISTICS IO: ................................................................................................. 150
STATISTICS IO: ................................................................................................. 152
STATISTICS IO: ................................................................................................. 153
CONCLUSÃO .................................................................................................... 154
NOTA IMPORTANTE: ............................................................................................. 154
REFERÊNCIAS .................................................................................................. 154
SULAMITA DANTAS ........................................................................... 155
Policy Based Management ................................................................................. 155
MARCELO FERNANDES ...................................................................... 162
Solucionando Problemas: Error Failed to open loopback connection ao executar
SP_READERRORLOG ........................................................................................... 162
INTRODUÇÃO .................................................................................................. 162
SINTOMA ........................................................................................................... 162
CAUSA .............................................................................................................. 162
SOLUÇÃO ........................................................................................................... 163
M V T e c h | 16
LEITURAS ADICIONAIS ............................................................................................ 164
Error to install SQL Server 2008 on Windows 2012............................................. 165
Token Bloat - Cannot generate SSPI context....................................................... 171
PROBLEMA ......................................................................................................... 171
COMO RESOLVER ................................................................................................. 176
EM CADA ESTAÇÃO ............................................................................................... 176
LEITURAS ADICIONAIS ..................................................................................... 177
CIBELLE CASTRO ................................................................................ 178
Auditoria ............................................................................................................. 178
Descobrindo Auditoria no SQL Server 2008 ..................................................... 178
POR QUE UTILIZAR AUDITORIA? ............................................................................... 178
PODE SER FEITO ATRAVÉS DE SCRIPTS........................................................................ 179
NOTA 01: .......................................................................................................... 179
COMO O SQL SERVER AUDIT TRABALHA? .................................................................. 179
NOTA 02: .......................................................................................................... 181
NOTA 03: .......................................................................................................... 184
DATABASE AUDIT SPECIFICATIONS .................................................................. 184
NOTA 03: .......................................................................................................... 186
PASSA A PASSO DE COMO CRIAR UMA AUDITORIA........................................................ 187
FAREMOS ESSAS CONFIGURAÇÕES DO SERVER AUDIT ATRAVÉS DE TSQL E O MANAGEMENT
STUDIO.............................................................................................................. 193
CRIANDO UM SERVER OU SERVER AUDIT SPECIFICATION. .............................................. 200
CRIANDO UM SERVER OU DATABASE AUDIT SPECIFICATION. .......................................... 206
CONCLUSÃO .................................................................................................... 213
REFERÊNCIAS .................................................................................................. 213
Performance e Desempenho .............................................................................. 215
System Monitor & SQL Profiler ........................................................................ 215
O QUE É O SYSTEM MONITOR? ............................................................................... 215
NOTA 1: ............................................................................................................ 215
NOTA 2 ............................................................................................................. 217
COMO CRIAR UM DATA COLLETOR SETS? .................................................................. 218
PARA CRIAR UM DATA COLLETOR SETS PERSONALIZADO, SIGA OS PASSOS ABAIXO: .............. 218
SQL SERVER PROFILER ..................................................................................... 225
O QUE É O TRACE? ............................................................................................... 225
NOTA 4: ............................................................................................................ 228
M V T e c h | 17
COMO APLICAR FILTROS NO SQL PROFILER? .............................................................. 230
PERFORMANCE X MONITORAMENTO ....................................................................... 231
DICA: ................................................................................................................ 231
CRIANDO TRACES ................................................................................................. 231
DICA *: ............................................................................................................. 239
CONCLUSÃO .................................................................................................... 239
REFERÊNCIAS .................................................................................................. 239
Restore Database com SSIS ................................................................................ 241
FTP COM WINSCP .............................................................................................. 242
EXECUTE PROCESS TASK ........................................................................................ 244
CRIAÇÃO VARIÁVEIS NO SSIS .................................................................................. 247
FOREACH LOOP CONTAINER ................................................................................... 248
EXECUTE SQL TASK (DELETE DATABASE) .............................................................. 250
EXECUTE SQL TASK (RESTORE DATABASE / USER PERMISSION) ............................ 253
EXECUTE PROCESS TASK (MODIFY NAME FTP FILE) ................................................ 255
LEANDRO RIBEIRO ............................................................................. 256
Fragmentação do Transaction Log - Parte I......................................................... 256
INTRODUÇÃO .................................................................................................. 256
TRANSACTION LOG ............................................................................................... 257
Fragmentação do Transaction Log - Parte II........................................................ 260
DICA: ................................................................................................................ 264
VAMOS TESTAR! .................................................................................................. 267
INFORMAÇÃO ADICIONAL ....................................................................................... 271
MELHORES PRÁTICAS: ........................................................................................... 271
LUCIANO MOREIRA ........................................................................... 273
O caso dos snapshots e data cache thrashing ..................................................... 273
DATA CACHE E O DATABASE SNAPSHOT. ......................................................... 273
SCRIPT 1 – CRIAÇÃO DOS BANCOS DE DADOS .............................................................. 273
SCRIPT 3 – RESULTADO DE IO PARA AS CONSULTAS ...................................................... 275
SCRIPT 4 – CONSULTANDO O DATA CACHE ................................................................. 275
DATA CACHE THRASHING ................................................................................ 276
SCRIPT 5 – CRIANDO DIVERSOS SNAPSHOTS E MAX SERVER MEMORY ................................ 276
SCRIPT 6 – UTILIZANDO O ESPAÇO DO DATA CACHE ...................................................... 277
SCRIPT 7 – DATA CACHE THRASHING ........................................................................ 278
M V T e c h | 18
Trigger causando deadlocks................................................................................ 279
PERGUNTA: INDEXAÇÃO PODE ELIMINAR PROBLEMAS DE DEADLOCKS? .............................. 279
ENTÃO PERGUNTO: AONDE ESTÁ O DEADLOCK? ........................................................... 280
ENCONTRANDO O DEADLOCK .................................................................................. 280
MINIMIZANDO OS DEADLOCKS ................................................................................ 282
RESOLVENDO O PROBLEMA (DE VERDADE) ................................................................. 284
CONCLUSÃO .................................................................................................... 285
VARCHAR(MAX) vs. TEXT (Sintaxe?) ................................................................... 287
SCRIPT 01 – DUAS TABELAS IDÊNTICAS, VARCHAR(MAX) E TEXT ................................ 287
SCRIPT 02 – ANALISANDO AS UNIDADES DE ALOCAÇÃO ................................................. 289
SCRIPT 03 – SP_TABLEOPTION PARA LARGE VALUES ..................................................... 289
NILTON PINHEIRO ............................................................................. 293
Trabalhando com datas e conversões no SQL Server ......................................... 293
OS TIPOS DE DADOS DATETIME E SMALLDATETIME ..................................................... 293
ENTENDENDO O ARMAZENAMENTO DOS VALORES DATA E HORA...................................... 294
TRABALHANDO COM A PARTE DATA .......................................................................... 296
LISTAGEM 1. SCRIPT PARA CRIAÇÃO E POPULAÇÃO DA TABELA DE PEDIDOS ........................ 297
FUNÇÕES E CONVERSÕES ....................................................................................... 299
TRABALHANDO COM A PARTE HORA ......................................................................... 302
CONCLUSÃO .................................................................................................... 305
Monitorando alterações de Dados com a Cláusula OUTPUT .............................. 306
DICAS PARA A UTILIZAÇÃO DO OUTPUT ................................................................... 311
TIAGO BALABUCH ............................................................................. 313
PERFORMANCE COUNTER - SUBSISTEMA DE DISCOS ......................................... 313
UTILIZAÇÃO DE DISCO ........................................................................................... 313
OS CONTADORES UTILIZADOS PARA MEDIR AS INFORMAÇÕES SÃO: ................................... 313
TEMPO DE RESPOSTA ............................................................................................ 314
REFERÊNCIAS: ................................................................................................. 315
PROBLEMAS DE REDE – ASYNC_NETWORK_IO ................................................... 316
OBJETIVO ........................................................................................................... 316
ANÁLISE INICIAL – BANCO DE DADOS: ...................................................................... 316
ANÁLISE INICIAL – WEB: ....................................................................................... 317
ANÁLISE DETALHADA ............................................................................................ 318
M V T e c h | 19
OS CONTADORES UTILIZADOS FORAM:....................................................................... 318
AMBIENTE DE BANCO DE DADOS .................................................................... 319
AMBIENTE WEB............................................................................................... 322
RESOLUÇÃO ........................................................................................................ 323
CONCLUSÃO .................................................................................................... 323
REFERÊNCIAS: ................................................................................................. 324
Suspect database - MSDTC in-doubt transaction ................................................ 325
PROBLEMA ...................................................................................................... 325
RESOLUÇÃO .................................................................................................... 326
CONCLUSÃO .................................................................................................... 327
REFERÊNCIAS: ..................................................................................................... 328
FELIPE FERREIRA ............................................................................... 329
A carreira de DBA está morrendo? ..................................................................... 329
NO MERCADO DE HOJE NÓS TEMOS DOIS PROBLEMAS MUITO COMUNS: ............................ 329
Criando um datawarehouse para testes ............................................................. 331
PASSO 1: ........................................................................................................... 331
PASSO 2: ........................................................................................................... 332
PASSO 3: ........................................................................................................... 333
PASSO 4: ........................................................................................................... 334
M V T e c h | 20
Edvaldo Castro
www.edvaldocastro.com
DBA por acidente X Command Line
“DBA por acidente”
Começo o texto de hoje falando um pouco deste que é um termo muito
comum em rodas de conversas de DBAs e profissionais que se dedicam a
fazer bem feito e com excelência aquilo que se propõe a fazer, neste caso
mais especificamente falando, ser um DBA cada vez melhor… Abro aqui um
parêntese para indicação de leitura – “How to become an exceptional DBA”.
O “DBA por acidente”, as vezes nem mesmo sabe que é um DBA, a ele são
atribuídas atividades de um DBA em paralelo às suas obrigações e quando
menos se dá conta, já está atuando única e exclusivamente com a
Administração do SGBD (Aqui, leia-se SQL Server).
Pelo fato de o SQL Server, diferente da maioria dos demais SGBDs, ter uma
interface amigável e bastante intuitiva, muitos dos DBAs do tipo supracitado,
ao executarem tarefas cotidianas e relativamente simples do dia-a-dia (tais
como: backup, restore, criação de base nova, etc), simplesmente se
acomodam e deixam de buscar conhecimento e entendimento a fundo do
funcionamento da ferramenta, de possíveis problemas e soluções para
poder atuar de forma mais rápida e efetiva.
Em outros SGBDs, como por exemplo: Oracle e DB2, a administração da
ferramenta geralmente é de certa forma mais complexa e requer maior
conhecimentos das particularidades destas, e talvez por este motivo, seja
muito mais comum a existência de “DBAs por acidente” no mundo SQL
Server.
Ainda que o Microsoft SQL Server ofereça uma interface super amigável e
fácil de trabalhar, uma boa forma de se livrar das armadilhas do vício na
interface gráfica que “facilita” muito a vida do DBA, é começar a olhar como
as coisas funcionam em background. Por exemplo, ao executar um backup
simples de uma base de dados via SSMS (SQL Server Management Studio),
M V T e c h | 21
porque não gerar um script da execução deste backup e das próximas vezes
que se for executar um backup simples, fazê-lo via T-SQL apenas alterando o
script previamente gerado? Com o tempo, naturalmente este comando de
backup será memorizado e não haverá mais a necessidade da dependência
da interface para execução desta atividade…
Um dos pontos, é o conhecimento dos códigos gerados por tras de cada
instrução submetida via interface gráfica, mas o estudo e conhecimento
daquilo que se faz (neste caso, Administrar Banco de Dados (SQL Server)), vai
muito além disto. Neste post, estou dando ênfase à utilização de códigos nas
atividades do dia-a-dia de um DBA, pois acredito ser este um grande passo
para se deixar o rótulo de “DBA por acidente” para se tornar um profissional
cada vez melhor e saber exatamente aquilo que se está fazendo…
Posso citar inúmeras vantagens, na utilização de códigos de comando ao
invés de interfaces gráficas, mas em minha opinião, destacam-se os
seguintes fatores:
Produtividade: Particularmente depois que se adquire prática, é muito mais
rápido criar um usuário, executar um backup ou restore via T-SQL do que
efetuar diversos cliques na tela, para realizar estas tarefas.
Escalabilidade: Para fazer uma operação de backup/restore, pode ser
pequena a diferença de tempo gasto usando tanto interface quanto T-SQL,
porém tente fazer uma operação destas com dezenas ou até mesmo
centenas de bases (e acredite, existem muitos cenários para isto).
Flexibilidade: Se você é um DBA que usa única e exclusivamente a interface
gráfica do SSMS e mal sabe como as coisas acontecem nos códigos
executados por suas “telinhas”, é bem possível que suas mãos ficarão
literalmente atadas caso você se depare com um servidor onde o SQL Server
esteja devidamente instalado, mas não haja o SSMS. Caso você não seja
totalmente dependente da ferramenta gráfica, você poderá (em casos
extremos) trabalhar normalmente conectando-se via SQLCMD.
Além dos três fatores supracitados, existem outros diversos, porém não é a
intenção ficar enumerando o que considero melhor ou pior em cada um dos
meios de administração do SQL Server.
M V T e c h | 22
Na minha visão a relação existente entre um DBA por acidente e Linhas de
código, é que normalmente DBAs por acidente não se preocupam em
entender como a coisa funciona, e por isto, geralmente continuam a sempre
fazer a mesma tarefa, da mesma maneira, enquanto aqueles que se propõe
a ser excelentes profissionais, sempre estão correndo atras de entendimento
e fugindo das limitações impostas (neste caso, falando sobre utilizar única e
exclusivamente, Interface Gráfica).
Sinceramente, não tenho nada contra quem utiliza interface gráfica, desde
que o faça por preferência, e não por limitação de não saber fazer de outra
maneira. É fato que ninguém nasce sabendo, ou com Master degree em
nada, mas nunca é tarde para começar a correr atras do prejuízo…
A intenção do texto realmente não foi em ser técnico, apenas externar algo
que penso com relação ao assunto que se faz presente nos meios
profissionais…
Grande abraço,
Edvaldo Castro
http://edvaldocastro.com
M V T e c h | 23
READ COMMITTED SNAPSHOT ISOLATION – Aprecie
com moderação
“RCSI – Aprecie com moderação”
“Não existe almoço grátis”
“Muito cuidado com as armadilhas do RCSI”
O início proposital deste post é para demonstrar alguns dos benefícios e
também os pontos de atenção com a possibilidade da alteração do
comportamento padrão de uma base de dados no SQL Server, quando se
trata de concorrência e isolamento das transações.
Por padrão, o SQL Server tem um comportamento “Pessimista”, onde o nível
de isolamento padrão é o “Read Committed”, o que basicamente faz com
que o SQL Server tenha um número maior de locks, reduzindo a concorrência
entre as transações.
Acesse (https://msdn.microsoft.com/enus/library/ms189122(v=sql.105).aspx) para um overview nos Níveis de
Isolamento no SQL Server.
MUITO BOM
Resumidamente, o Read Committed Snapshot Isolation (RCSI), trabalha com
o versionamento de registros, utilizando-se da tempdb para tal, fazendo com
que o comportamento “Pessimista” do nível de isolamento “Read
Committed” onde Leitores (Select) bloqueiam Escritores (Insert, Update e
Delete), e vice-versa, seja substituído por padrão na base em que foi ativado
o RCSI para o comportamento “Otimista”, onde Leitores (Select) e Escritores
(Insert, Update, Delete) não se bloqueiam.
M V T e c h | 24
Quando há concorrência entre um Updates e Selects submetidos a um
mesmo registro, é gerado uma versão comitada do registro, que então esta
é lida da pela transação que entrou em segundo lugar.
Esta alteração do corportamento Pessimista para Otimista, pela habilitação
do RCSI não acaba com bloqueios entre escritores (update x update) e
também não evita bloqueios onde há verificação de constraints (foreign
Keys, por exemplo).
Quando leva-se em consideração o Read Committed Snapshot Isolation Level
apenas até os pontos aqui exibidos, não há mais o que se pensar, pode se ter
a falsa ideia de solução para todos os problemas de concorrência e bloqueios
e a ideia de ativá-lo imediatamente em todas as bases SQL Server da
instância é demasiadamente tentadora.
Para Exemplificar melhor, segue uma citação de quando o problema é
solucionado habilitando-se o RCSI.
C ENÁRIO 1
Na padaria do Sr. Joaquim, são produzidos 1.000.000 de pães por dia, e o
sistema de panificação automaticamente faz um update na tabela de pães
produzidos naquele dia. Esporadicamente o Sr. Joaquim gosta de tirar
relatórios para saber a quantidade produzida até então, porém, seus
relatórios ficam bloqueados por muito tempo, visto que os updates são
constantes e demorados.
RCSI NO CASO DO S R . J OAQUIM
Neste caso específico, a habilitação do RCSI pode minimizar drasticamente
os problemas do Sr. Joaquim com a lentidão de seus relatórios, uma vez que
seus “selects” não mais esperarão pelos “updates” automáticos realizados
pelo moderno sistema de fabricação de pães.
Os updates continuam sendo realizados com a mesma frequência, e apenas
bloqueando-se entre si quando necessários (lembrando que o RCSI não evita
bloqueios entre updates), e quando o Sr. Joaquim submeter um select
M V T e c h | 25
envolvendo os registros bloqueados, ele receberá o resultados dos últimos
comitados e não serão considerados aqueles com transações em aberto.
MAS…
Porém, como mencionado no início deste post…
“Não existe almoço grátis”…
“Muito cuidado com as armadilhas do RCSI”…
Adiciono mais uma…
“Coisas estranhas podem acontecer”
Não são raras as vezes em que os bloqueios e esperas são benéficos e
necessários, para se evitar erros de negócios ou até mesmo inconsistências
no valor dos dados de sua base.
O Read Committed Snapshot Isolation, é uma excelente opção, fantástica e
que é passível sim, de ser habilitada na maioria das bases de dados da
maioria dos ambientes com SQL Server, porém é necessário um
levantamento cauteloso dos pontos onde podem incorrer problemas pela
habilitação deste “comportamento” de uma base de dados do SQL Server.
Um dos maiores pontos de atenção é que o RCSI é habilitado para a base
inteira, fazendo com que o nível de isolamento das transações para esta
base, seja por padrão alterado. Para que se tenha níveis de isolamento
diferentes, é necessário que estes sejam informados dentro das transações
submetidas.
M V T e c h | 26
Vale ressaltar que apesar dos cuidados, custos e advertências supracitados,
normalmente a relação CUSTO X BENEFÍCIO vale a pena e os problemas em
potencial são poucos, em relação aos benefícios com o uso do RCSI.
Para facilitar um pouco o entendimento, segue uma descrição de um caso
onde o RCSI pode causar um grande problema.
C ENÁRIO 2
Uma empresa tem um programa conjunto entre as áreas Financeira e RH, de
empréstimo de dinheiro da própria empresa a seus empregados, com
desconto em folha de pagamento. As regras para que o colaborador possa
pegar dinheiro, são bem simplistas e a principal delas, é que o e mesmo
esteja empregado.
O P ROBLEMA
João Castro, trabalhou por 10 anos na empresa referida, e um belo dia foi
chamado pelo RH que lhe agradeceu pelos serviços e o demitiu. Sabendo
João que a empresa tinha o programa de empréstimos e que o Depto
Financeiro era logo na sala ao lado, passou diretamente no financeiro e
pegou 20 mil reais que foi prontamente liberado. João acabava de ser
demitido e receber 20 mil reais em empréstimo, que não pagaria nunca, visto
que não teria mais vínculo com a empresa.
RCSI NESTE CASO
Supondo que existam 2 Tabelas envolvidas no processo:
TB_PESSOA
TB_EMPRESTIMO
O processo de empréstimo verifica se a pessoa está empregada ou não
(TB_PESSOA) para liberar o dinheiro (TB_EMPRESTO).
Hipoteticamente falando, João por demitido por alguém do RH que abriu o
sistema para atualizar o status para “DEMITIDO”, mas antes de executar
M V T e c h | 27
o commit da transação, resolveu ir tomar um café e a deixou aberta. João foi
ao Depto Financeiro, alguém deste departamento abriu uma transação para
liberar empréstimo, foi consultar na tabela TB_PESSOA se João estava
empregado e recebeu como resultado “EMPREGADO”, visto que uma
transação de update já estava aberta, porém não havia sido comitada.
Quando o alguém do RH voltou, salvou via sistema a demissão de João,
alterando seu status para “DEMITIDO”, porém o campo
SITUACAO_EMPRESTIMO na tabela TB_EMPRESTIMO estava como
“LIBERADO”.
Neste caso específico, o bloqueio deveria acontecer e a transação de
liberação do empréstimo obrigatoriamente deveria ser bloqueada pela
alteração na tabela que informa se a pessoa está empregada ou não.
Ainda assim, este não seria um empecilho para a habilitação do RCSI na base,
visto que é possível forçar com um HINT que a espera aconteça.
Foram criados Scripts para demonstração do caso citado que podem ser
baixados pelo endereço: http://edvaldocastro.com/rcsi-2/
Ou visualizados no trecho de código abaixo.
–CRIAÇÃO DO AMBIENTE PARA OS TESTES
–CRIAÇÃO DA BASE
USE master
GO
IF db_id(‘DEMO_RCSI’) IS NOT NULL
DROP DATABASE DEMO_RCSI
GO
CREATE DATABASE DEMO_RCSI
ON PRIMARY
(NAME = ‘DEMO_RCSI_Data’,FILENAME = ‘C:TEMPDE
MO_RCSI.mdf’,SIZE = 128 MB)
LOG ON
(NAME = ‘DEMO_RCSI_Log’, FILENAME = ‘C:TEMPDE
MO_RCSI.ldf’,SIZE = 128 MB)
GO
USE DEMO_RCSI
GO
–CRIA A TABELA PESSOA
IF object_id(‘TB_PESSOA’) IS NOT NULL
M V T e c h | 28
DROP TABLE TB_PESSOA
GO
CREATE TABLE TB_PESSOA
(
ID_PESSOA INT IDENTITY CONSTRAINT PK_TB_PESSO
A_ID_PESSOA PRIMARY KEY
,DATA_CONTRATACAO DATE DEFAULT GETDATE()
,NOME_PESSOA VARCHAR(60)
,BOL_EMPREGADO CHAR(1)
)
GO
–CRIA A TABELA EMPRESTIMO
IF object_id(‘TB_EMPRESTIMO’) IS NOT NULL
DROP TABLE TB_EMPRESTIMO
GO
CREATE TABLE TB_EMPRESTIMO
(
ID_EMPRESTIMO INT IDENTITY CONSTRAINT PK_TB_E
MPRESTIMO_ID_EMPRESTIMO PRIMARY KEY
,ID_PESSOA INT –CONSTRAINT
FK_TB_PESSOA_TB_EMPRESTIMO FOREIGN KEY
REFERENCES TB_PESSOA (ID_PESSOA)
,VALOR_EMPRESTIMO DECIMAL(10,2)
,LIBERACAO_EMPRESTIMO CHAR(1)
)
–EXISTE O NÍVEL DE ISOLAMENTO
–EXIBE INFORMAÇÃO SOBRE O NIVEL DE ISOLAMENTO
ATUAL
SELECT
NAME
,CASE is_read_committed_snapshot_on
WHEN 1 THEN ‘ENABLED’
WHEN 0 THEN ‘DISABLED’
END
AS ‘Read_Committed_Snapshot’
FROM SYS.DATABASES
WHERE NAME = ‘DEMO_RCSI’
–CARREGA DADOS NA TABELA PESSOA
INSERT INTO TB_PESSOA (NOME_PESSOA, BOL_EMPRE
GADO)
VALUES (‘JOAO CASTRO’,‘S’)
,(‘MANOEL MAIA’,‘S’)
,(‘BENEDITO LIMA’,‘N’)
,(‘MARIA CASTRO’,‘N’)
,(‘CLEONTINA OLIVEIRA’,‘S’)
M V T e c h | 29
,(‘CANDIDO DUARTE’,‘S’)
–ALTERA O NÍVEL DE ISOLAMENTO PARA RCSI
USE master
ALTER DATABASE DEMO_RCSI SET READ_COMMITTED_S
NAPSHOT ON
–EXIBE DADOS DA TABELA PESSOA
SELECT * FROM TB_PESSOA
–
ID_PESSOA
DATA_CONTRATACAO
NOME_PESSOA
BOL_EMPREGADO
–1
2013-07-27
JOAO
CASTRO
S
–2
2013-07-27
MANOEL
MAIA
S
–3
2013-07-27
BENEDITO
LIMA
N
–4
2013-07-27
MARIA
CASTRO
N
–5
2013-07-27
CLEONTINA
OLIVEIRA
S
–6
2013-07-27
CANDIDO
DUARTE
S
–ALTERA NÍVEL DE ISOLAMENTO
–ALTER DATABASE DEMO_RCSI SET
READ_COMMITTED_SNAPSHOT ON
READ_COMMITTED_SNAPSHOT OFF
/*——————————————————————————*/
TRANSAÇÃO T1
–TRANSAÇÃO DE DEMISSÃO (T1)
–EXIBE INFORMAÇÃO SOBRE O NIVEL DE ISOLAMENTO
ATUAL
SELECT
NAME
,CASE is_read_committed_snapshot_on
WHEN 1 THEN ‘ENABLED’
WHEN 0 THEN ‘DISABLED’
END AS ‘Read_Committed_Snapshot’
FROM
SYS.DATABASES
WHERE NAME = ‘DEMO_RCSI’
– PARA ALTERAR PARA O RCSI
–USE MASTER
M V T e c h | 30
READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK
IMMEDIATE
–INICIO DA TRANSAÇÃO DE UPDATE
BEGIN TRAN T1
WHERE NOME_PESSOA = ‘JOAO CASTRO’
USE DEMO_RCSI
GO
UPDATE P
SET P.BOL_EMPREGADO = ‘N’
FROM TB_PESSOA P
GO
–ROLLBACK TRAN T1
–COMMIT TRAN T1
–ABRA A SEGUNDA TRANSAÇÃO EM UMA NOVA JANELA
(NEW QUERY)E FAÇA A OPERAÇÃO DE EMPRESTIMO
(T2)
/*——————————————————————————*/
TRANSAÇÃO T2
–TRANSAÇÃO DE EMPRÉSTIMO (T2)
—- GARANTIR QUE ESTEJA COM RCSI HABILITADO
–USE MASTER
READ_COMMITTED_SNAPSHOT ON WITH ROLLBACK
IMMEDIATE
–GO
——————————————————————————————
–INICIO DA TRANSAÇÃO DE UPDATE
BEGIN TRAN T2
USE DEMO_RCSI
GO
INSERT INTO TB_EMPRESTIMO
SELECT ID_PESSOA, ‘20000’,‘S’
FROM TB_PESSOA P
COMMIT TRAN T2
——————————————————————————————
SELECT * FROM TB_EMPRESTIMO
——————————————————————————————
M V T e c h | 31
–VEJA O RESULTADO ANTES DO COMMIT DA T1
(TRANSAÇÃO DE DEMISSÃO)
SELECT P.ID_PESSOA, P.NOME_PESSOA, E.VALOR_EM
PRESTIMO, P.BOL_EMPREGADO,E.LIBERACAO_EMPREST
IMO
FROM TB_EMPRESTIMO E
JOIN TB_PESSOA P
ON E.ID_PESSOA = P.ID_PESSOA
——————————————————————————————
–EXECUTE O COMMIT DA TRANSAÇÃO T1 E RODE
NOVAMENTE O RESULTADO. OBSERVER QUE HÁ ERRO
DE NEGÓCIO
–POIS FOI LIBERADO EMPRÉSTIMOI PARA UMA
PESSOA QUE NÃO ESTÁ EMPREGADA.
SELECT P.ID_PESSOA, P.NOME_PESSOA, E.VALOR_EM
PRESTIMO, P.BOL_EMPREGADO,E.LIBERACAO_EMPREST
IMO
FROM TB_EMPRESTIMO E
JOIN TB_PESSOA P
ON E.ID_PESSOA = P.ID_PESSOA
RESUMINDO:
P RÓS E C ONTRAS DO RCSI:
Reduz consideravelmente problemas provenientes de bloqueios.
Habilitação fácil e rápida.
Contras do Read Committed Snapshot Isolation:
M V T e c h | 32
Não é útil em bloqueios entre transações de update.
Bloqueios com verificação de constraints também não são beneficiados.
Pode resultar com algum erro negocial não esperado, caso não seja bem
mapeado.
CONCLUSÃO:
O RCSI é passível de utilização em qualquer ambiente, desde que os “poréns”
sejam bem mapeados e os erros provenientes sejam mitigados, com o uso
de HINTS (Ex: (SELECT * FROM TABELA WITH (READCOMMITTED)), Alterando
o nível de isolamento nas transações que necessitam que os bloqueios
aconteçam entre outros meios que podem ser utilizados.
READ COMMITTED SNAPSHOT ISOLATION – APRECIE COM MODERAÇÃO
REFERÊNCIAS
http://msdn.microsoft.com/pt-br/library/ms173763.aspx
http://msdn.microsoft.com/en-us/library/tcbchxcb(v=VS.80).aspx
Grande abraço,
Edvaldo Castro
M V T e c h | 33
Artigos técnicos: O guia definitivo (ou não)
Estar presente e participar ativamente de uma comunidade, sempre ajuda
no crescimento das pessoas, seja ele profissional, pessoal, religioso ou
quaisquer outros âmbitos. Para quem trabalha na área de TI
particularmente, esta participação pode culminar em uma curva de
aprendizado e crescimento profissional muito mais acentuada do que se o
profissional se isolar e caminhar sozinho na carreira.
Basicamente é possível participar de comunidades consumindo informações
compartilhadas e compartilhando informações e conhecimentos. Algumas
das principais formas de compartilhar conhecimento e informações são:
Palestras (presenciais e online), Redes Socais em geral, vídeos, Wiki e Blogs
com postagens técnicas.
Para aqueles que se aventuraram, ou desejam se aventurar com a redação e
compartilhamento de textos técnicos, a seguir existe uma serie de pontos
importantes que devem ser observados na intenção de que erros sejam
evitados e uma melhor qualidade seja alcançada.
M OTIVAÇÃO
Existem diversos motivos que podem e levam profissionais à iniciarem uma
efetiva participação em comunidades técnicas e criarem seus próprios blogs
pessoais, ou mesmo escreverem para canais já bem conhecidos. Com
motivações diferentes, geralmente os objetivos são comuns: exposição
profissional, compartilhamento de conhecimento, networking e
reconhecimento. Abaixo, alguns pontos que são relevantes e que podem
influenciar direta ou indiretamente os resultados desta decisão de tornar-se
público através principalmente de artigos técnicos.
R ISCOS E O PORTUNIDADES
A “Exposição Profissional” proveniente da decisão de escrever artigos
técnicos é ambígua, ou seja, pode ser uma excelente oportunidade de se
M V T e c h | 34
criar um ótimo círculo de contatos profissionais, networking de alto nível e
gerar grandes benefícios nos âmbitos profissional e pessoal, porém esta
mesma “Exposição Profissional” pode ser extremamente perigosa e
prejudicial à carreira do profissional, caso este não tome alguns cuidados
básicos na hora de expor-se através de seus textos, por exemplo: Textos não
fidedignos, com erros de português, dentre outros graves erros que estão
melhor detalhados adiante, neste artigo.
Q UANDO C OMEÇAR ?
Tendo-se conhecimentos dos riscos e oportunidades, e considerando-se
apto a dar início ao trabalho de compartilhamento de informações via textos
técnicos (ou não), existem alguns importantes pré-requisitos a serem
seguidos, para aumentar a probabilidade de que o texto a ser publicado seja
bem recebido e faça “sucesso”.
P ESQUISE
Há um grande equívoco por parte de muitos autores de blogs, que é o
conhecimento relacionado a um determinado assunto. Muitas pessoas,
quando propõe-se a escrever um artigo técnico, enganam-se e pensam já
saber o suficiente para não ser necessário fazer nenhuma pesquisa adicional.
Mero engano, todo e qualquer conteúdo técnico, fica muito melhor
apresentado, se expor pontos de vistas diferentes, ou mesmo conteúdo de
fontes variadas, para defender um ponto de vista, ou mesmo descrever algo.
L EIA E ESTUDE MUITO
Leitura e estudo, nunca é demais. E quanto mais conhecimento sobre o
assunto a ser dissertado, melhor e mais rico ficará o artigo técnico. É sempre
muito importante estudar, ler e fazer tantos testes quantos possíveis antes
de publicar o artigo, visto que uma vez publicado, seu texto estará exposto
para o mundo inteiro a qualquer momento para visualização de qualquer
pessoa que quiser visualizá-lo, e conforme já citado anteriormente, pode ser
muito bom ou muito ruim esta exposição.
M V T e c h | 35
F AÇA CITAÇÕES E REFER ÊNCIAS
Um ponto não menos importante que os anteriores é a existência de citações
e referências no artigo técnico dos textos que foram escritos por outros
autores. É frustrante para um autor, ver que todo trabalho de pesquisa e
estudo que ele teve para escrever determinado trecho de artigo, ou mesmo
um artigo completo, e repentinamente ver este “roubado” e publicado sem
referência em outro local, que até então era desconhecido. É até mesmo
uma questão de respeito e demonstração de maturidade e bom senso, que
ficarão explícitos aos leitores do artigo em questão.
R EVISÃO P ERIÓDICA (N ÃO OBRIGATÓRIA )
Esta não é uma necessidade extremamente importante, mas
esporadicamente é interessante ler alguns de seus posts / artigos técnicos
para que se por algum acaso houver algum erro (digitação, português ou
conceitual), este possa ser corrigido.
Revise sua estratégia / metodologia
Um Blog baseado no dia a dia, ou na carreira de um profissional, deve
acompanhar as mudanças que naturalmente ocorrem na carreira. Um bom
exemplo é a tendência de migração de vários serviços de tecnologia para a
nuvem. Se você fala sobre infraestrutura de servidores (Windows ou Linux),
por exemplo, considere começar a estudar sobre computação na nuvem, e à
medida que sentir-se confortável, os artigos naturalmente devem
acompanhar esta mudança, isto fará com que os leitores, acompanhem as
mudanças e talvez até se consiga mais leitores assíduos dos artigos técnicos
publicados.
M V T e c h | 36
O ARTIGO TÉCNICO
Abaixo, listo algumas características e especificidades referentes aos tipos
mais comuns de artigos técnicos, detalhes do mesmo e alguns pontos de
observação no que se refere à gramática na redação destes.
TIPOS DE ARTIGOS TÉCNICOS
D OCUMENTAÇÃO
Este tipo de artigo técnico visa dissertar sobre algum produto, feature ou
atividade, demonstrando sua finalidade sem se preocupar na apresentação
dos métodos ou passo a passo para implementação. Este tipo de artigo
técnico, geralmente é escrito quando são lançadas versões novas ou um
produto totalmente novo, com a finalidade principal de demonstrar tal
produto ou feature.
H OW T O ( S )
Artigos técnicos deste tipo, são como tutoriais onde normalmente é descrito
um passo a passo com detalhes de implementação, ativação ou quaisquer
alterações que objetivem o autor do artigo a criá-lo.
B ENCHMARKS E E XPERIÊNCIAS
Este é um outro tipo de artigo bastante interessante, onde o autor do artigo,
por necessidade ou ocasionalidade, passou por algum problema ou fez
alguns testes que posteriormente demonstra em seu artigo técnico.
Geralmente estes artigos são bem interessantes e demonstram situações do
dia a dia e podem agregar bastante conhecimento à quem atua ou possui
ambiente similar ao descrito no artigo.
M V T e c h | 37
O ARTIGO TÉCNICO EM SI
E STRUTURA
Um artigo técnico (ou não) bem estruturado é muito importante, pois facilita
e contribui para que a leitura fique mais agradável e entendível. Se a ideia é
escrever muito, este tópico é especialmente importante, pois quanto maior
o texto, mais cansativa e desestimulante fica a leitura, caso a mesma não
esteja bem estruturada, sendo o inverso igualmente verdadeiro, quando
mais bem estruturado, melhor e mais agradável se torna a leitura do mesmo.
Por um texto bem estruturado, entende-se a divisão do mesmo (introdução,
desenvolvimento e conclusão), estruturação utilizando-se marcadores,
definições de fontes tradicionais de tamanhos proporcionais e
principalmente a divisão em tópicos e subtítulos, determinando exatamente
o assunto que determinado ponto do artigo trata.
L INGUAGEM
Não se pode dizer que é correto ou incorreto escrever de uma forma
completamente informal ou de forma muito formal. O ideal é definir o
público alvo que se deseja atingir, e escrever da forma correta para este
público alvo. Por exemplo, talvez escrever de forma extremamente formal,
um artigo onde os principais leitores serão jovens universitários em início de
carreira, pode tornar a leitura um tanto quanto chata e cansativa. Da mesma
forma, não é aconselhado um texto muito informal, quando o público alvo
são diretores e presidentes de empresas de Tecnologia, ou outras. Sendo seu
artigo formal ou não, o importante é o correto direcionamento do artigo ao
seu respectivo público alvo.
P ÚBLICO A LVO
Conforme mencionado anteriormente, além de escrever da maneira correta
para o público alvo correto, é preciso conhecer e saber para quem se está
M V T e c h | 38
escrevendo, com isto é possível adequar a linguagem, estrutura e conteúdo
do seu artigo.
GRAMÁTICA
E VITE OS ERROS MAIS COMUNS ( DIGITAÇÃO , GÍRIAS , CONCORDÂNCIA , ETC )
Um dos pontos mais importantes em um artigo técnico é a clareza e
assertividade com que se escreve um texto, relacionado à gramática do
idioma no qual este texto é escrito. Se o texto está em português por
exemplo, é imprescindível tomar todos os cuidados com erros de
concordância, gírias, neologismos e até mesmo com erros de digitação, que
naturalmente podem aparecer durante a redação do mesmo. Um texto bem
escrito e gramaticalmente correto corrobora muito para que ao final da
leitura, o leitor tenha prestado atenção ao conteúdo e tenha tido bom
entendimento do que pretendia-se ter passado, do que ficar em mente os
“assassinatos” ao idioma encontrados durante a leitura.
S OLICITE R EVISÕES (A MIGOS , C OMUNIDADE , P ARENTES , S R . J OAQUIM )
Uma ferramenta gratuita e muito útil é a revisão antes da publicação. É bem
provável que uma pessoa que possui um local onde publicar seus artigos
(técnicos ou não), conheça outras pessoas do meio, que podem ler e avaliar
o texto antes de o mesmo ser publicado. Ainda assim, caso não seja possível
encontrar alguém que possa revisar o texto, é possível solicitar que uma ou
mais pessoas o façam (mesmo não sendo do meio relacionado ao conteúdo
do artigo).
Se possível, é aconselhável que sejam feitas revisões técnicas e gramaticais,
assim mitiga-se o risco de incorreções tanto na parte técnica proposta no
artigo, como também a parte gramatical que é tão importante quanto.
Abaixo, listo alguns pontos importantes com relação à algumas principais
preocupações e com a publicidade quando se está desenvolvendo um artigo
técnico.
M V T e c h | 39
PRINCIPAIS PREOCUPAÇÕES
S EMPRE
Solicite que alguém revise seus textos antes de publicá-los
Cite as fontes das informações
Pesquise em fontes fidedignas
Não assassine o idioma
Deixe claro que o texto é sua opinião, não uma verdade absoluta
N UNCA
Escreva com pressa de publicar
Publique um artigo sem pelo menos uma revisão
Copie ou reblogue algo, sem autorização do autor do texto original
Diga que sua forma é a única maneira existente
P UBLICIDADE
Canais disponíveis
Blog Pessoal
Technet Wiki
Facebook (Pages and Profile)
Twitter
M V T e c h | 40
FAÇA BARULHO
Divulgue sempre seus artigos técnicos.
Cuidado para não se tornar um spammer ou um chato bloqueado
CONCLUSÃO
Em resumo, um blog ou canal de textos técnicos quando bem escrito pode
alavancar uma carreira, tornar seu autor conhecido por seus ótimos artigos
e consequentemente rendendo bons resultados (convites, empregos,
propostas, networking, etc). Em contrapartida, se o texto não é bem escrito
e não toma-se diversos cuidados (alguns mencionados no texto supracitado)
esta exposição pode ter o efeito contrário e fazer as oportunidades, a “fama”
e propostas sumirem, visto que você pode estar mostrando a todos em seu
texto seus pontos fracos (gramática, conhecimento técnico, etc).
Eu gostaria ainda de esclarecer que tudo o que foi escrito foi baseado em
minhas preocupações e minha opinião. De forma alguma é a representação
absoluta da verdade. Se você concorda, discorda ou tem algo a acrescer, será
muito bem vindo nos comentários….
Obrigado por chegar até aqui,
Grande abraço,
Edvaldo Castro
M V T e c h | 41
Diego Nogare
www.diegonogare.net
Partition Table
Particionamento de Tabelas
Fala galera, esses dias atrás estava fazendo uma apresentação sobre SQL
Server 2012 e surgiu uma dúvida de um dos participantes
sobre particionamento horizontal de tabelas. Decidi procurar alguns
materiais em português e não achei muitos, então resolvi dar minha
contribuição sobre esse assunto.
Bom, os benefícios de se utilizar Partition Table no SQL Server são muitos,
mas antes de falar dos benefícios, vamos criar um banco de dados de
exemplo para simular uma tabela do mundo real e depois entender o que é
o Partition Table.
Esse script cria um banco que irá simular uma tabela de visitas de um museu,
imaginando que o museu foi inaugurado no dia 1º de Janeiro de 2012 e hoje
é dia 31 de Dezembro, totalizando neste 1 ano de atividades 1 milhão de
visitas. Com os próximos sub-capítulos vamos criar as partições, separar
esses dados e deixar cada agrupamento (visitas do mesmo mês) em uma
tabela específica. Depois podemos comparar os prós e contras desta técnica.
CREATE DATABASE dbMuseu
GO
USE dbMuseu
GO
CREATE TABLE tbVisitas
(id INT IDENTITY(1,1) PRIMARY KEY
,nome VARCHAR(50)
,data DATE)
GO
M V T e c h | 42
INSERT INTO tbVisitas (nome, data)
VALUES (newid(), /*Dados aleatórios para o
nome*/
convert(date, convert(varchar(15),'2012-' +
convert(varchar(5),(convert(int,rand()*12))+1
) + '-' + /* Gerar mês aleatório */
convert(varchar(5),(convert(int,rand()*27))+1
) /* Gerar dia aleatório */ )))
GO 1000000
Ótimo, agora que já temos nossa base para simular… Vamos entender o que
é o particionamento!
O particionamento horizontal de tabelas é uma técnica que utilizamos na
arquitetura
da
estrutura
de
dados,
para
melhorar
a
performance/desempenho/gerenciamento do sistema gerenciador de
banco de dados. Esta técnica consiste em dividir os dados, baseado em um
parametro, em tabelas e File Groups diferentes.
Para exemplificar, veja na imagem abaixo os dados que estavam na tabela
Visitas foram divididos em 12 tabelas, cada uma armazenando os dados de
um mês específico. A tabela azul armazena visitas de Janeiro, a
tabela verde armazena de Fevereiro e a tabela laranja armazena visitas de
Dezembro. Porém, a tabela preta representa a consulta de todas as visitas
do ano inteiro…
M V T e c h | 43
No decorrer dos próximos sub-capítulos, vamos trabalhar em atividades
específicas necessárias para particionar com sucesso essa tabela de visitas
do museu.
C ENÁRIOS /B ENEFÍCIOS
Fala galera, uma duvida frequente quando falamos em particionar uma
tabela, é: Porque Particionar?! Pensamos em particionamento de tabelas
quando ela possui muitos registros e precisamos melhorar escalabilidade,
performance e gerenciamento. Normalmente desenhamos as tabelas para
armazenar informações de uma entidade específica, como Funcionarios,
Vendas ou Produtos. Não é porque desenhamos e entendemos este modelo
de dados que otimizamos a tabela para receber grande volume… Já
encontrei por ai, e não foi só uma vez, tabelas com quantidade de dados
significativa e que não tinha nenhum tipo de índice. Acreditem, é triste mas
é verdade! Quando falamos de bancos de dados realmente grandes, nos
referimos à VLDB (Very Large Database). Não é regra que um VLDB possua
tabelas que precisam ser particionadas. Para particionar uma tabela um dos
pontos mais importante a se levar em consideração é o tempo gasto para
dar manutenção nesta tabela, e não somente a quantidade de registros.
Imaginem o caso de uma tabela de Produtos de um e-Commerce que fica
2h/dia lenta porque está reorganizando/reconstruindo o índice, ou fica
travada quando estão rodando algum relatório… Esse tipo de tabela pode
ser particionada para melhorar o tempo de resposta das consultas e garantir
que o e-Commerce continue fazendo suas vendas online. Pensando em
relatórios, isso pode causar uma lentidão grande no seu RDBMS (Relational
Database Management System) quando tem um ROLAP (Relational On Line
Analytical Processing) realizando agregações. Se uma tabela com 1 milhão
de registros precisa agregar as vendas por mês, o processamento irá
trabalhar com todas as linhas da tabela e fará o somatório. Imaginando este
mesmo cenário em um ambiente particionado, cada partição faz suas
agregações e no final do processamento, você terá uma resposta mais rápida
e seu ambiente continuou respondendo com rapidez. Um outro tipo de
particionamento de tabelas pode ser feito para separar dados “quentes” e
M V T e c h | 44
histórico. Os dados quentes são os dados que você trabalha atualmente, por
exemplo, os dados do trimestre atual e os dados de histórico são os dados
dos trimestres passados. Se você separar os dados da sua tabela a cada 3
meses, você pode deixar os dados atuais em discos mais nobres do seu
storage (SSD) e os dados de histórico em outros discos menos nobres (SAS
ou SATA). Imagine a necessidade de consultar as vendas do ultimo ano, com
a tabela particionada, você faria isso sem ter nenhuma concorrencia com as
transações que estão acontecendo atualmente na tabela.
D EFINIÇÕES /T ERMINOLOGIAS
Fala galera, para implementar o particionamento horizontal de tabelas, é
importante conhecer as definições e terminologias utilizadas. Para
alinharmos, vou falar do que é fundamental para você entender e aplicar
essa tecnologia nos seus projetos.
Para começar, vamos entender a estrutura de armazenamento do Partition
Table. Esta forma de trabalhar se aplica desde SQL Server 2005 até o 2012,
antes disso, com o SQL Server 7 ou 2000, até onde me lembro, tinha que
fazer manualmente a quebra dos dados nas tabelas particionadas e a
consulta era feita através de uma VIEW com UNION ALL de todas as tabelas
particionadas… um verdadeiro parto!
Desde o SQL Server 2005, quando criamos uma tabela e/ou índice no nosso
banco e não definimos onde ele será armazenado, ele fica no
filegroup default. Porém, podemos criar a tabela e/ou índice em um partition
scheme. O partition scheme faz um mapeamento de um ou mais filegroups,
mas para armazenar os dados nos arquivos físicos corretos (nos filegroups)
ele usa o partition function, que por sua vez, contém o algoritmo que
realmente identifica onde determinada linha será armazenada. A ordem
cronológica é mais ou menos assim:
M V T e c h | 45
Ok, agora que entendemos de forma macro a estrutura de armazenamento,
vamos entender conceitualmente como o SQL Server quebra os dados
baseado em uma coluna da tabela.
Para isso, é necessário definir o Range que o algoritmo de particionamento
irá usar para separar os dados de forma correta e informar o partition
function (que irá armazenar no local indicado). Esse Range atua juntamente
ao Partition Key, que é uma coluna única existente na tabela e é utilizada
como separador lógico dos dados. Depois dos dados separados em tabelas
específicas, é possível trabalhar com os dados das tabelas não só fazendo
consultas, mas também juntando (Merge) e/ou particionando ainda mais as
tabelas (Split). Também usa-se o Switch para “converter” uma tabela que
estava sendo usada como atual, com dados quentes, para ser entendida
como histórico.
M V T e c h | 46
Pegando como base o database criado no sub-capitulo de Particionamento
de Tabelas, se for separar os dados com base em cada mês, o Partition
Key seria a coluna Data e o Range seria cada período que quero utilizar,
baseado em um início e fim da coleção de dados. Seria algo assim:
Intervalo
1
2
…
12
Inicio
01/01/2012
01/02/2012
…
01/12/2012
Fim
31/01/2012
28/02/2012
…
31/12/2012
Fiquem atentos à essas nomenclaturas, a medida que precisarmos usar cada
uma delas vou explicar em detalhes suas caracteristicas e funcionamento.
M V T e c h | 47
C RIANDO F ILEGROUP
Fala galera, mesmo o Filegroups sendo o “final” do processo de criar a
Partition Table pois é onde os dados serão armazenados de fato, vamos criálos primeiro. Depois de criar os filegroups podemos voltar e criar o Partition
Function e o Partition Scheme.
Antes de criar o filegroup, vamos relembrar um pouco de conceito do SQL
Server. Todos os dados de uma tabela são armazenados em um agrupador
chamado Página que possui 8Kb de tamanho. Independente de uma página
estar com apenas 1 registro, ou totalmente preenchida com dados, ela ocupa
8Kb de tamanho. Outra caracteristica é que dentro de uma página são
armazenados somente dados de uma mesma tabela. Se neste exemplo
abaixo existisse somente 1 funcionário e 1 produto, existiriam 2 páginas
criadas. O conjunto de 8 páginas é chamado de Extent, que por sinal,
tem 64Kb de tamanho (8Kb de cada uma das 8 páginas).
Mais pra frente vamos entender o porque é importante saber o tamanho de
uma Página e de um Extent.
Os Databases são criados no filegroup Default, se não for especificado em
qual filegroup deve ser criado. Por padrão, no SQL Server 2012, os filegroups
M V T e c h | 48
são armazenados dentro da pasta \Program Files\Microsoft SQL
Server\MSSQL11.SQL2012\MSSQL\DATA com o nome do Database que você
criou. Se você quiser especificar o filegroup na hora de criar seu Database,
deve adicionar o código T-SQL junto à criação do seu Database. Veja abaixo
a criação do dbMuseu_2 informando o filegroup via código T-SQL.
CREATE DATABASE dbMuseu_2
ON
( NAME = dbMuseu_2,
FILENAME = 'C:\Program Files\Microsoft SQL
Server\MSSQL11.SQL2012\MSSQL\DATA\dbMuseu_2.m
df',
SIZE = 10,
MAXSIZE = 50,
FILEGROWTH = 5 )
LOG ON
( NAME = dbMuseu_log,
FILENAME = 'C:\Program Files\Microsoft SQL
Server\MSSQL11.SQL2012\MSSQL\DATA\dbMuseu_2_l
og.ldf',
SIZE = 5MB,
MAXSIZE = 25MB,
FILEGROWTH = 5MB ) ;
GO
Esta criação do dbMuseu_2 é só para exemplificar como especificar o
filegroup na hora da criação do Database, fique a vontade para excluir o
dbMuseu_2, caso tenha criado.
Quando se cria mais de um filegroup por Database, os novos arquivos de
filegroup possuem a extensão .NDF ao invés de .MDF. Também temos o
arquivo .LDF que são os arquivos de LOG das transações que o Database
processa.
Os Databases já criados, tanto o dbMuseu (criado no primeiro sub-capitulo)
quanto o dbMuseu_2 criado agora, possuem apenas 1 Filegroup. Veja na
imagem abaixo estes arquivos físicos.
M V T e c h | 49
Vamos criar agora outros filegroups para o dbMuseu (criado no primeiro subcapitulo) para poder separar os dados da tabela tbVisitas e utilizar o
propósito destes capítulo, o Partition Table!
Primeiro vamos adicionar o nome lógico dos Filegroups ao nosso Database.
Como já temos o dbMuseu criado, vamos alterar o banco de dados ao invés
de criar um novo. Veja o código T-SQL abaixo:
USE MASTER
GO
ALTER DATABASE
[FG2012_JAN]
ALTER DATABASE
[FG2012_FEV]
ALTER DATABASE
[FG2012_MAR]
ALTER DATABASE
[FG2012_ABR]
ALTER DATABASE
[FG2012_MAI]
ALTER DATABASE
[FG2012_JUN]
ALTER DATABASE
[FG2012_JUL]
ALTER DATABASE
[FG2012_AGO]
ALTER DATABASE
[FG2012_SET]
ALTER DATABASE
[FG2012_OUT]
dbMuseu ADD FILEGROUP
M V T e c h | 50
ALTER DATABASE dbMuseu ADD FILEGROUP
[FG2012_NOV]
ALTER DATABASE dbMuseu ADD FILEGROUP
[FG2012_DEZ]
GO
Para confirmar os nomes lógicos adicionados ao seu Database, você pode ir
até as propriedades do banco, clicando com o botão direito em dbMuseu >>
Properties, e então nas opções da esquerda, vá até Filegroups como na
imagem abaixo, ou então através do código T-SQL:
USE dbMuseu
GO
sp_helpfilegroup
GO
M V T e c h | 51
Pronto, os nomes lógicos estão criados, agora é o momento de criar
os arquivos físicos e associá-los à esses nomes lógicos dos filegroups. Para
isso, é necessário realizar outro código DDL de Alter Database, veja esse
código abaixo:
USE MASTER
GO
ALTER DATABASE dbMuseu
ADD FILE
(NAME = 'FG2012_01_JAN'
,FILENAME = 'C:\Program Files\Microsoft SQL
Server\MSSQL11.SQL2012\MSSQL\DATA\FG2012_01_J
AN.ndf')
TO FILEGROUP [FG2012_01_JAN]
GO
M V T e c h | 52
Neste
código
acima,
criamos
fisicamente
o
filegroup FG2012_01_JAN.NDF baseado no nome lógico criado
anteriormente, e que receberá somente os dados de Janeiro/2012 quando
particionarmos os dados.
Voltando
para
a
pasta
\Program
Files\Microsoft
SQL
Server\MSSQL11.SQL2012\MSSQL\DATA, podemos ver o arquivo físico já
criado:
Devemos replicar esse ultimo código de Alter Table para todos os outros
Filegroups que precisamos criar, isso é: Fevereiro, Março, Abril …
até Dezembro.
Sempre lembrando de alterar a localização do arquivo, o nome e o nome do
filegroup.
Para verificar que todos arquivos foram criados, outra alternativa é executar
o código T-SQL abaixo:
USE dbMuseu
GO
sp_helpfile
GO
M V T e c h | 53
Nos próximos sub-capítulos, vamos criar o Partition Function e o Partition
Scheme.
C RIANDO P ARTITION F UNCTION
Fala galera, logo depois de criar os filegroups e distribuir entre os discos
existentes, é hora de criar o Partition Function que sustentará os algoritmos
que farão a quebra dos dados.
Quando se cria o partition function, é necessário definir os limites
condicionais dos períodos. O primeiro ponto que precisa ter atenção é
exatamente essa criação dos limites (boundary) informando se o período
(range) terá como base de criação os dados do esquerdo (left) ou do lado
direito (right), IMPORTANTE ressaltar que o boundary utilizado força que o
valor informado será utilizado naquele range do contexto. Para exemplificar,
vamos criar uma partição que teria os dados anteriores a 30/junho/2012 em
uma partição e a partir de 01/julho2012 em outra.
Para usar o boundary left, a quebra deve usar os dados à esquerda da
condição, incluindo-a. Uma outra forma de dizer, é que os dados ficariam
em <= 2012-06-30
Veja o código abaixo como ficaria essa partition function com left.
CREATE PARTITION FUNCTION
QuebraPelaEsquerda(date)
AS
RANGE LEFT FOR VALUES ('20120630')
M V T e c h | 54
Para usar o boundary right a quebra será a direita da condição, com a
condição informada entrando na quebra, outra leitura para isso seria >=
2012-07-01
Veja o código abaixo como ficaria essa partition function com right.
QuebraPelaDireita(date)
AS
RANGE RIGHT FOR VALUES ('20120701')
Voltando ao cenário do museu, que estamos utilizando durante todo este
capítulo, vamos criar os partition functions baseados nos 12 meses de 2012.
Vou escrever o código para boundary right, mas fique a vontade para
escrever com o left, para estudar. Lembrando que para usar o left, ao invés
de informar o primeiro dia de cada mês, você deve informar o ultimo dia do
mês anterior.
USE dbMuseu
GO
CREATE PARTITION FUNCTION MuseuPorMes(date)
AS
RANGE RIGHT FOR VALUES ('20120101',
'20120201', '20120301',
'20120401', '20120501', '20120601',
'20120701', '20120801', '20120901',
'20121001', '20121101', '20121201')
Criamos 12 partition functions informando qual é a data inicial de cada uma
delas dentro do dbMuseu, isso significa que os dados anteriores a
01/Janeiro/2012 estão armazenados em 1 partição unica, contendo os dados
desde quando começaram a ser inseridos até o dia 31/12/2011. Outro ponto
importante a ser lembrado é que os dados acima de 01/12/2012 estão todos
M V T e c h | 55
em uma mesma partição, visto que não existe uma próxima partição que
encerra o range deste grupo iniciado em 1º de Dezembro.
No próximo sub-capítulo, finalmente será criado o partition scheme…
C RIANDO O P ARTITION S CHEME
Fala galera, seguindo a sequência lógica do particionamento, uma vez
os Partition Function criados, você deve associá-los aos Partition Scheme. O
Partition Scheme é responsável por encaminhar os dados para
os Filegroups corretos, por isso é muito importante nomear corretamente os
Filegroups e os Partition Schemes.
Quando fizemos a quebra dos dados no Partition Function MuseuPorMes,
definimos 12 partições (uma para cada mês). Agora serão criados os “13
Partition Scheme” para os meses. Você deve estar se perguntando porque
13 e não 12. A ultima Partition Scheme irá receber os dados acima de
01/12/2012, e irá encaminhar para o Primary Filegroup. Veja o código:
CREATE PARTITION SCHEME MuseuPorMesScheme
AS
PARTITION MuseuPorMes TO
(
[FG2012_01_JAN],[FG2012_02_FEV],[FG2012_03_MA
R]
,[FG2012_04_ABR],[FG2012_05_MAI],[FG2012_06_J
UN]
,[FG2012_07_JUL],[FG2012_08_AGO],[FG2012_09_S
ET]
,[FG2012_10_OUT],[FG2012_11_NOV],[FG2012_12_D
EZ]
,[PRIMARY] )
GO
Lembrando que o MuseuPorMes é o nome do Partition Function criado
anteriormente.
M V T e c h | 56
Caso todas as partições estivessem apontando para o mesmo Filegroup, você
poderia escrever uma sintaxe mais simples, apontando todas as partições
para o Primary Filegroup. Veja como seria esse código:
CREATE PARTITION SCHEME MuseuPorMesScheme
AS
PARTITION MuseuPorMes ALL TO ([PRIMARY])
GO
Por final, você precisa criar a tabela informando qual será o Partition
Scheme que irá controlar o armazenamento dos dados. No próximo subcapítulo vamos ver essa criação!
C RIANDO A TABELA
Fala galera, este é o ultimo sub-capítulo sobre a parte estrutural do Partition
Table, e é onde se cria a tabela utilizando os conceitos vistos nos subcapítulos anteriores.
Para conseguirmos comparar o desempenho de uma tabela com os dados
em um unico Filegroup (tbVisitas) e a tabela com todo o Partition Table,
criaremos uma segunda tabela (tbVisitas_2) exatamente com a mesma
estrutura da tabela anterior e vamos popular com os mesmos dados
inseridos anteriormente na tabela inicial.
Veja a criação da tabela, informando o Partition Scheme (veja a linha 5) em
frente ao ON, que pode ser colocado ou não na criação da tabela. Caso não
informe, o SQL Server cria a tabela com o filegroup padrão, que geralmente
é o primary. Quando informamos um Partition Scheme na criação da tabela,
os dados passam a utilizar o Partition Scheme para escrever no filegroup
correto, que na sequência consulta o Partition Function para saber qual é o
algoritmo de quebra dos dados…
M V T e c h | 57
CREATE TABLE tbVisitas_V2
(id INT IDENTITY(1,1)
,nome VARCHAR(50)
,data DATE)
ON MuseuPorMesScheme(data)
GO
E aqui é a inserção dos dados exatamente igual à tabela original:
INSERT INTO TBVISITAS_V2(NOME,DATA)
SELECT NOME,DATA FROM TBVISITAS
GO
Pra fixar a idéia, lembre-se da imagem postada no sub-capítulo de
definições/terminologias:
Com isso, conseguimos separar em diversos Filegroups, que por sua vez
estão em discos separados, garantindo alta-performance nas consultas
realizadas nesta tabela.
Façam testes com esta técnica aprendida nestes sub-capítulos em seus
projetos e comprovem o desempenho!
C OMPARATIVO DE INSERÇÃO DE DADOS EM UMA T ABELA COM C OLUMN S TORE
I NDEX NO SQL S ERVER 2012
Fala galera, o ColumnStore Index é um novo formato de índice que foi
lançado junto ao SQL Server 2012, este índice usa um padrão de compressão
M V T e c h | 58
de dados proprietário da Microsoft e altera o formato de armazenamento
dos dados nas páginas do índice. A primeira vez que um registro é inserido
no índice, ele registra o dado bruto, qualquer outra aparição deste mesmo
dado dentro do índice, o SQL faz um apontamento de memória para o
primeiro registro, diminuindo significativamente o tamanho da página com
os índices. Este novo formato de índice não chegou para substituir os já
convencionais e úteis Clustered e Non-Clustered index, ele vem para atender
um outro cenário. O armazenamento do ColumnStore Index altera a escrita
dos dados do índice que estamos acostumados a ver em um padrão linear
(como a figura abaixo).
Para um formato colunar – por isso o nome ColumnStore – armazenando
todos os registros da coluna em uma mesma página. Uma representação
visual seria como da imagem abaixo:
M V T e c h | 59
Os ganhos de performance com o uso correto do ColumnStore Index varia
entre 10 e 100X. Podendo, em alguns casos reais que já presenciei, chegar a
retornos 400X mais rápidos. Porém o ColumnStore Index não é só
maravilhas. A utilização deste índice em uma tabela a transforma em Read
Only, impedindo manutenção nos dados já existentes. Este cenário de dados
como somente leitura nos remete à ambientes de Data Warehouse, onde a
informação armazenada sofre manutenção incremental em determinados
momentos do ciclo e normalmente não é atualizada ou excluída. Em alguns
casos sendo incrementado somente uma vez por noite, em outros cenários
somente uma atualização semanal, em um terceiro podendo ser uma vez por
mês. Isso varia de acordo com a necessidade da área de negócios. Agora, se
a tabela está em um formato Read Only, como podemos inserir dados
incrementais nela???
Pensando sobre como implementar estes incrementos, vem à mente 3
possibilidades. Podemos: 1) desabilitar, inserir e reabilitar o índice; 2)
remover, inserir e recriar o índice; ou 3) então trabalhar com
Particionamento de Tabelas, onde temos as partições com o índice e uma
tabela onde serão inseridos os dados atuais. Para colocar em comparação
estes três cenários, montei um ambiente de teste com aproximadamente
35Milhões de linhas e fiz comparativo entre eles. Veja o comparativo abaixo
entre Logical Read dos três cenários, e também o tempo necessário para
realizar cada atividade.
M V T e c h | 60
O teste consistiu em criar uma tabela com 33milhões de registros e aplicar o
ColumnStore Index nesta tabela. Em seguida, adicionar mais 1.6Milhões de
linhas… Realizamos o teste no mesmo ambiente 2 vezes, e tiramos a média
M V T e c h | 61
tanto de Logical Reads quanto de Elapsed Time do processo. Os resultados
provam que a melhor solução, disparada, é a utilização de Partition Table.
Caso alguém queira simular o processo que utilizei, segue abaixo a criação
do ambiente e a população das tabelas com menos dados. É claro que para
você simular a mesma coisa que fiz aqui, você precisa adaptar este código
abaixo para seu cenário.
/*******************************************/
/*********** CRIAÇÃO DO AMBIENTE ***********/
/*******************************************/
CREATE DATABASE ngrSolutionsDW
GO
USE ngrSolutionsDW
GO
/*******************************************/
/*********** LIMPEZA DO AMBIENTE ***********/
/*******************************************/
USE ngrSolutionsDW
GO
DROP SEQUENCE seq_Codigo
GO
DROP TABLE tabelaProducao
GO
DROP TABLE tabelaProducao_v2
GO
DROP PARTITION SCHEME ps_DataAtualizacao
GO
DROP PARTITION FUNCTION pf_DataAtualizacao
GO
/*******************************************/
/********** POPULAÇÃO DO AMBIENTE **********/
/*******************************************/
CREATE TABLE tabelaProducao(
id INT NOT NULL
, idOrigem INT NOT NULL
, nome VARCHAR(20) NOT NULL
M V T e c h | 62
, endereco VARCHAR(30) NOT NULL
, dataCadastro date NOT NULL
, dataAtualizacao date NOT NULL
ON [PRIMARY]
GO
)
ALTER TABLE tabelaProducao WITH CHECK ADD
CONSTRAINT [validarCodigo_V1_Check]
CHECK
(dataAtualizacao >= '2010-01-01' and
dataAtualizacao < '2013-03-01')
GO
ALTER TABLE tabelaProducao CHECK CONSTRAINT
[validarCodigo_V1_Check]
GO
CREATE SEQUENCE seq_Codigo AS INT
INCREMENT BY 1
minvalue 1
maxvalue 10000
GO
/* 1K registros de SETEMBRO 2012 */
insert into tabelaProducao(id, idOrigem,
nome,
endereco, dataCadastro,
dataAtualizacao)
values (next value for seq_Codigo,
convert(int,rand()*100)+1,
substring(convert(varchar(40),newid()),1,20),
dateadd(month,-5, convert(datetime,
getdate())),
getdate())))
go 1000
/* 1K registros de OUTUBRO 2012 */
nome,
dataAtualizacao)
M V T e c h | 63
getdate())),
getdate())))
go 1000
/* 1K registros de NOVEMBRO 2012 */
nome,
dataAtualizacao)
getdate())),
getdate())))
go 1000
/* 1K registros de DEZEMBRO 2012 */
nome,
dataAtualizacao)
getdate())),
getdate())))
go 1000
M V T e c h | 64
/* 1K registros de JANEIRO 2013 */
nome,
dataAtualizacao)
getdate())),
getdate())))
go 1000
/* 500 registros de FEVEREIRO 2013 */
nome,
dataAtualizacao)
getdate(), getdate())
go 500
SET STATISTICS IO ON; SET STATISTICS TIME ON
GO
/*******************************************/
/*********** DISABLE / REBUILD *************/
/*******************************************/
/************ CRIAÇÃO DO INDEX *************/
/*******************************************/
CREATE NONCLUSTERED COLUMNSTORE INDEX
[idx_csi_tabelaProducao]
ON tabelaProducao ( id, nome, endereco,
dataCadastro, dataAtualizacao )
GO
M V T e c h | 65
/*******************************************/
/******** INSERIR NA TABELA DE PROD ********/
/*******************************************/
/* +1 em FEVEREIRO 2013 */
-- Forçar o erro por causa que a tabela está
com ColumnStore Index
nome,
dataAtualizacao)
/*******************************************/
/************ DISABLE / REBUILD ************/
/*******************************************/
ALTER INDEX idx_csi_tabelaProducao ON
tabelaProducao DISABLE
GO
tabelaProducao REBUILD
GO
/*******************************************/
/************ POPULAR A TABELA *************/
/*******************************************/
tabelaProducao DISABLE
GO
nome,
dataAtualizacao)
M V T e c h | 66
getdate())), getdate())
go 1000
tabelaProducao REBUILD
GO
/*******************************************/
/************** DROP / CREATE **************/
/*******************************************/
/************ CRIAÇÃO DO INDEX *************/
/*******************************************/
GO
/*******************************************/
/*******************************************/
nome,
dataAtualizacao)
/*******************************************/
/************** DROP / CREATE **************/
/*******************************************/
DROP INDEX [idx_csi_tabelaProducao] ON
tabelaProducao
GO
M V T e c h | 67
GO
/*******************************************/
/************ POPULAR A TABELA *************/
/*******************************************/
DROP INDEX [idx_csi_tabelaProducao] ON
tabelaProducao
GO
nome,
dataAtualizacao)
getdate())), getdate())
go 1000
GO
/*******************************************/
/************* PARTITION TABLE *************/
/*******************************************/
/********** CRIAÇÃO DAS PARTIÇÕES **********/
/*******************************************/
[pf_DataAtualizacao](date) AS RANGE RIGHT
FOR VALUES ('2012-09-01','2012-10-01','201211-01',
'2012-12-01','2013-01-01','201302-01','2013-03-01')
M V T e c h | 68
GO
CREATE PARTITION SCHEME [ps_DataAtualizacao]
AS PARTITION [pf_DataAtualizacao] ALL TO
([PRIMARY])
GO
/*******************************************/
/************ CRIAÇÃO DOS INDEX ************/
/*******************************************/
CREATE CLUSTERED INDEX [idx_DataCodigo] ON
tabelaProducao(DataAtualizacao)
ON ps_DataAtualizacao(dataAtualizacao)
GO
GO
/*******************************************/
/*******************************************/
nome,
dataAtualizacao)
/*******************************************/
/******** CRIAÇÃO DA SEGUNDA TABELA ********/
/*******************************************/
CREATE TABLE tabelaProducao_V2 (id INT NOT
NULL, idOrigem int NOT NULL,
M V T e c h | 69
nome VARCHAR(20) NOT NULL, endereco
VARCHAR(30) NOT NULL,
dataCadastro date NOT NULL,
dataAtualizacao date NOT NULL)
GO
ALTER TABLE tabelaProducao_V2 WITH CHECK ADD
CONSTRAINT[validarCodigo_V2_Check] CHECK
(dataAtualizacao >= '2013-02-01' and
dataAtualizacao < '2013-03-01')
GO
/*******************************************/
/************ CRIAÇÃO DOS INDEX ************/
/*******************************************/
CREATE CLUSTERED INDEX [idx_DataCodigo]
ON tabelaProducao_v2(DataAtualizacao) ON
[PRIMARY]
GO
/*******************************************/
/********* MOVIMENTAÇÃO DOS DADOS **********/
/*******************************************/
-- Conta os registros
SELECT COUNT(0) [TOTAL], min(dataAtualizacao)
[MENOR],
max(dataAtualizacao) [MAIOR] FROM
tabelaProducao
GO
[MENOR],
tabelaProducao_v2
GO
-- Movimenta os dados
ALTER TABLE tabelaProducao SWITCH PARTITION 7
TO tabelaProducao_v2
GO
[MENOR],
M V T e c h | 70
tabelaProducao
GO
[MENOR],
tabelaProducao_v2
GO
/* Fevereiro na TABELA 2 */
insert into tabelaProducao_V2(id, idOrigem,
nome,
dataAtualizacao)
go 10
[MENOR],
tabelaProducao
GO
[MENOR],
tabelaProducao_v2
GO
ON tabelaProducao_v2 ( id, nome, endereco,
GO
ALTER TABLE tabelaProducao_V2 switch to
tabelaProducao partition 7
M V T e c h | 71
GO
[MENOR],
tabelaProducao
GO
[MENOR],
tabelaProducao_v2
GO
Bom divertimento em seus testes!
M V T e c h | 72
Demetrio Silva
demetriosilva.wordpress.com
Tuning no SharePoint e SQL Server com o Developer
Dashboard
Tunin no SharePoint com Developer Dashboard
INTRODUÇÃO
Apesar do nome sugerir, esta ferramenta não é específica para
desenvolvedores. Developer Dashboard é um recurso do SharePoint que
ajuda os desenvolvedores a rastrear problemas de performance em
componentes customizados ou não, dentro uma página.
Seu uso é muito comum por desenvolvedores, pois possibilita que os
mesmos repassem as informações das consultas SQL aos DBAs, para análise
e
possível
tuning.
A página do dashboard é carregada no endereço do site, acrescentando
/_layouts/15/devdash.aspx
ao
final.
Tempo que a página levou para carregar, quais componentes foram
carregados, as consultas SQL executadas ( duração, plano de execução, etc),
correlation id, logs ULS são exemplos de informações exibidas no dashboard.
Por padrão, este recurso é desabilitado e este artigo vai mostrar como
configurar e habilitar esta feature. Vale lembrar que o Developer Dashboard
não pode ser usado na Central Admin.
M V T e c h | 73
C ONFIGURAÇÃO
O Developer Dashboard requer que o Service Application “Usage & Health
Data Collection” esteja configurado. Os passos abaixo mostram como
verificar se o recurso está ou não configurado:
1 – No menu iniciar, abra a console “SharePoint 2013 Management Shell”
conforme figura 1
M V T e c h | 74
Figura 1 – Abrir console PowerShell
2 – Com a console aberta, execute o script abaixo conforme figura 2
Figura 2 – Script
O script acima tenta criar o Service Application. Caso o mesmo já exista,
mesmo com outro nome, ele gera um erro.
O próximo passo é habilitar o Developer Dashboard. Copie e cole o script
abaixo na mesma console do passo 2 e tecle enter:
$service =
[Microsoft.SharePoint.Administration.SPWebService]::ContentService
$dd = $service.DeveloperDashboardSettings
$dd.DisplayLevel = "On"
$dd.Update()
Obs.: para desativar o Developer Dashboard basta executar novamente o
script acima, trocando $dd.DisplayLevel = "On" por $dd.DisplayLevel =
"Off".
Por questões de performance, após realizar o throubleshooting, desabilite
o Developer Dashboard.
M V T e c h | 75
Veja a execução do script na figura 3:
Figura 3 – Habilitando o Developer Dashboard
Visualizando o Developer Dashboard
Neste momento, já temos o Developer Dashboard configurado. Os passos
abaixo mostram como visualizar os dados na página, bem como, ilustra
algumas
de
suas
funcionalidades.
1 – Abra qualquer site da Farm. Neste exemplo, usamos o site
http://palestras2013. No canto superior direito, clique no ícone “Iniciar
painel
de
desenvolvimento”
conforme
figura
4
Figura
4
-
Iniciar
painel
M V T e c h | 76
de
desenvolvimento
2 – Após o passo anterior, será aberto um pop-up igual ao da figura 5
Figura
5
–
pop-up
do
painel
Na guia “Solicitações”, podemos ver cada requisição às páginas no
SharePoint. Basta clicar na solicitação desejada para que o painel mostre as
informações sobre a mesma. No exemplo abaixo, clicamos na chamada à
página “http://palestras2013/SitePages/Como Usar esta
Biblioteca.aspx?AjaxDelta=1&isStartPlt1=1405695726064”, conforme figura
6
M V T e c h | 77
Figura 6 – Página requisitada
Na Figura 6, dentro da aba “Informações do Servidor” temos dois grids:
a) “Estatísticas da Solicitação” – Com um resumo da solicitação. Exibe
informações como Hora de Início, Duração Total para carregar a página,
Servidor, Usuário, etc.
b) “Estatísticas Agregadas” - Nela podemos ver o resumo das consultas SQL
executadas, exibindo o número de consultas, duração total das consultas,
etc.
Seguindo para a aba “ULS”, podemos ver todas as entradas no log
referentes à página que estamos analisando. Isso é fantástico, uma vez que
o painel já faz o filtro no log e nos mostra tudo que está ocorrendo na
página e foi registrado no log.
Na figura 7, podemos ver o log ULS
M V T e c h | 78
Figura 7 – ULS
Outra guia interessante é a SQL. Nela podemos ver o tempo de execução
de cada consulta, o plano de execução, comando T-SQL, estatísticas de IO e
algumas outras informações úteis.
A figura 8 mostra a guia SQL:
Figura 8 – SQL
M V T e c h | 79
Para visualizar mais informações sobre a consulta, basta clicar no nome da
mesma. A figura 9 mostra as informações exibidas ao clicar na consulta
“SELECT t1.[Tim”:
Figura 9 – Informações da consulta
Ao clicar em plano de execução, também podemos ver e/ou salvar o plano
gerado
para
a
consulta.
Existem diversas outras abas no painel que mostram informações úteis. Para
mais informações acesse o link: http://technet.microsoft.com/ptbr/library/jj219701(v=office.15).aspx.
CONCLUSÃO
Este artigo mostrou como configurar o Developer Dashboard, uma
ferramenta essencial para os desenvolvedores em SharePoint. Também
mostramos
algumas
de
suas
funcionalidades.
M V T e c h | 80
Esta é apenas uma das diversas maneiras que o SharePoint nos fornece para
analisar o ambiente e ajustar a performance da Farm.
M V T e c h | 81
Acessando dados do SharePoint com PowerPivot
INTRODUÇÃO
É um cenário muito comum as empresas adotarem o SharePoint como
ferramenta de colaboração e uma das verticais do SharePoint são os sites.
Dentro dos sites, temos várias listas e bibliotecas, que armazenam reuniões,
cadastros
de
clientes,
tarefas
dentre
outros
dados.
Com os dados já armazenados, uma necessidade muito comum é gerar
relatórios dos dados das listas. Existem várias formas de gerar relatórios de
listas e uma delas é através do PowerPivot, que será o foco deste artigo.
Este artigo usará uma funcionalidade do SharePoint que expõe os dados da
lista em forma de Atom feed e como importar os dados Atom Feed para
dentro do data model PowerPivot.
R EQUISITOS
É necessário instalar o runtime ADO.NET nos servidores WFE – Web FrontEnd da Farm. Mais informações aqui ou nos links abaixo:
http://go.microsoft.com/fwlink/?LinkId=221066: Windows Server 2008 R2
http://go.microsoft.com/fwlink/?LinkId=195068: Windows Server 2008
C OMO FUNCIONA
Usaremos os dados do banco de dados adventureworks2012, onde
neste outro artigo, os dados da tabela person foram exportados para Excel e
importados no SharePoint, criando assim uma lista no SharePoint com os
dados
da
planilha
do
Excel.
O acesso aos dados será realizado pela REST Interface, que permite acesso
M V T e c h | 82
às listas e bibliotecas do SharePoint no formato de relational data service.
Neste caso, as operações de leitura, atualização, criação e exclusão de itens
são feitas através da SharePoint Foundation REST, que provê várias
operações para os Web Services RESTFull. Todas mapeadas diretamente
para
GET,
POST,
PUT
e
DELETE
HTTP
Verbs.
A
URL
para
acesso
à
REST
tem
o
seguinte
padrão http://NomeDoSiteSharePoint/_vti_bin/ListData.svc, onde, nos
exemplos
o
site
usado
(NomeDoSiteSharePoint)
se
chama http://palestras2013/, logo, a URL dos exemplos terá o
formato http://palestras2013/_vti_bin/ListData.svc.
Ao acessar a REST Interface do site de exemplo a tela abaixo é exibida:
(Figura
1
–
REST
Interface
do
site
http://palestras2013/)
Para acessar os dados de uma lista específica, basta adicionar o nome da lista
no
final
da
URL,
deixando-a
assim
http://palestras2013/_vti_bin/ListData.svc/Categorias/Categorias.
Onde
Categorias é o nome da lista que foi importada da base
M V T e c h | 83
AdventureWorks2012
para
o
SharePoint.
O conteúdo da lista pode ser visto na Figura 2 e o resultado do REST para
esta
lista
pode
ser
visto
na
Figura
3.
(Figura
2
–
Lista
M V T e c h | 84
de
Categorias)
(Figura
3
–
Lista
de
Categorias
Atom
Feed)
I MPORTAR PARA O P OWER P IVOT NO E XCEL
Para realizar a importação da lista no PowerPivot do Excel, basta abrir a
janela do PowerPivot e na guia "From Data Service" clicar em From OData
Data
Feed
conforme
Figura
4.
(Figura
4
–
Selecionar
fonte
de
dados)
Na tela seguinte, em Data Feed Url, informe a Url da lista que deseja acessar
via REST. Neste caso, http://palestras2013/_vti_bin/ListData.svc/Categorias.
A
figura
5
ilustra
o
exemplo:
M V T e c h | 85
(Figura
5
–
Conexão
do
PowerPivot
ao
Feed)
Clique em next, finish e a tela de importação será exibida conforme abaixo.
(Figura
6
–
Finalizando
a
importação)
Por fim, a figura 7 mostra os dados da lista do SharePoint já importados para
M V T e c h | 86
dentro
(Figura
do
7
–
PowerPivot.
Dados
importados)
A partir deste ponto é possível usar os dados da lista dentro do PowerPivot
e usufruir de todas as funcionalidades do mesmo.
Exportar do SharePoint para o PowerPivot
Caso a Farm e o Site Collection que você esteja usando já tenha o PowerPivot
configurado, a importação da lista para o PowerPivot é ainda mais simples.
Basta selecionar a opção "Exportar como Feed de Dados" na lista desejada
conforme
figura
8.
M V T e c h | 87
(Figura 8 – Exportando lista do SharePoint para o PowerPivot)
Após clicar na opção Exportar como Feed de Dados selecione a opção "abrir"
que fica no fim da tela. Caso o tipo de extensão não esteja associado ao Excel,
selecione
abrir
com
->
Excel.
(Figura
Habilite
9
a
–
conexão
Abrir
de
Feed
dados
M V T e c h | 88
com
conforme
Excel)
Figura
10.
(Figura
10
–
Habilitar
conexão
de
dados)
Na tela a seguir, marque a opção "Only Create Connection", caso queira
apenas importar os dados neste momento. Por padrão, o Excel importa os
dados para o PowerPivot e cria uma Table. Note que a opção "Add this data
to the Data Model" está marcada. Isso indica que os dados serão importados
para
o
PowerPivot.
M V T e c h | 89
(Figura
11
–
Selecionar
o
tipo
de
importação)
Por fim, acesse a guia PowerPivot e veja que o Data Model foi exportado para
o
Excel.
M V T e c h | 90
(Figura 12 – Dados exportados)
CONCLUSÃO
Este artigo mostra uma das muitas formas possíveis de gerar relatórios
usando os dados das listas do SharePoint. Após importar os dados, fica bem
fácil criar relatórios complexos e dinâmicos usando PowerPivot, Excel,
PowerView e PowerMap.
M V T e c h | 91
Configurar envio de e-mail no SharePoint / SQL
Server com o GMAIL
Neste artigo irei mostrar como configurar o envio de e-mail através do
SharePoint/SQL Server utilizando contas do gmail.
A ideia do post é mostrar como configurar o relay para envio de e-mail em
aplicações que não suportam autenticação smtp. Alguns exemplos de
ferramentas são Reporting Services, ArcServe Backup, SharePoint, etc.. Para
estas aplicações a configuração de e-mail não é possível através de contas
que requerem autenticação para enviar mensagens.
Bem, vamos lá. Para realizar esta configuração nós precisamos configurar o
relay de e-mails no Windows Server através do IIS, usando SMTP Server:
P ASSO 1: C ONFIGURAR O SMTP S ERVER NO W INDOWS 2008.
No Server Manager, vá em Add Features:
M V T e c h | 92
Na guia seguinte, escolha SMTP Server e deixe todas as configurações
padrão:
Confirme para adicionar os serviços necessários:
M V T e c h | 93
Deixe as demais opções com o valor padrão e clique em next até a aba final
onde tem a opção de instalar.
Após instalado, feche o Server Manager e abra o IIS 6.0: Menu iniciar / IIS /
Enter.
Com o IIS aberto, expanda o nó Local Computer e clique em propriedades do
SMTP Virtual Server:
Vá na guia access e clique em Relay:
M V T e c h | 94
Configure os PCs liberados para enviar e-mails através deste Relay. No meu
caso, liberei para todos da rede:
M V T e c h | 95
Salve, volte para a guia propriedades e acesse a guia Delivery:
M V T e c h | 96
Clique em Outbound Security e selecione a opção Basic Authentication.
Informe seu e-mail do Gmail, senha e marque a opção TLS:
M V T e c h | 97
Novamente no menu Delivery, acesse a opção Outbound Connections e
mude a porta para 587 conforme abaixo e clique em OK:
M V T e c h | 98
Mais uma ves no menu Delivery, selecione a opção advanced e em Smart
Host informe o SMTP do Gmail e clique em OK:
Feche a tela clicando em OK e reinicie o IIS:
M V T e c h | 99
Para testar no SharePoint, abra a Central Admin do Sharepoint e Acesse o
menu System Settings e na guia Outgoing E-mail Settings configure conforme
abaixo:
Pronto. Após isso seu SharePoint está pronto para enviar e-mails de
notificações para listas, etc.
M V T e c h | 100
Marcel Inowe
4sqlserver.wordpress.com
Dicas sobre o banco de dados do Protheus(Totvs)
Olá pessoal,
Esses dias meu amigo Leandro Ribeiro (http://www.sqlleroy.com
|@sqlleroy) solicitou no Twitter dicas sobre o banco de dados do Protheus e
como eu dou manutenção no banco de dados desse produto, percebi que eu
sabia vários detalhes que poderiam ser úteis para quem está começando a
trabalhar com o Protheus agora.
Para quem não conhece o Protheus é um dos maiores ERPs do mundo, ele é
desenvolvido pela empresa brasileira Totvs onde há alguns anos é líder de
mercado nacional. A grande vantagem do Protheus é que além dele ser bem
completo ele customizável, ou seja, você compra a licença do sistema e pode
contratar um desenvolvedor para customizá-lo a seu gosto, já imaginou isso?
Já pensou se você pudesse fazer isso com qualquer software que comprasse
ou utilizasse? Pois é, por aí dá para sentir o poder do produto e dá para
começar a perceber o porque ele é tão usado no mercado nacional, mas é
claro que nem tudo são flores e é obvio que esse produto tem seus pontos
fracos, algumas particularidades e é exatamente para discutir isso que
escrevi esse post.
V AMOS AS DICAS :
Quase sempre o banco de dados se chama DADOSADV ou pelo menos
começa com DADOS. Não me pergunte o motivo, pois eu não sei;
A aplicação não acessa o banco de dados diretamente ela usa uma camada
intermediária chamada Top Connect. O Top Connect quase sempre é
instalado no mesmo servidor que o banco de dados, porém há casos em que
ele é instalado em uma máquina exclusiva e então a aplicação se conecta ao
Top e o Top se conecta ao SQL Server;
M V T e c h | 101
O Protheus é multiempresa, porém ao contrário do que estamos
acostumado a ver nas modelagens onde a empresa é identificada com um
campo dentro de cada tabela, o banco do Protheus cria uma tabela para cada
empresa até a versão 10 do ERP, então se o teu cliente tiver mais de uma
empresa aberta trabalhando no mesmo banco de dados, para cada empresa
terá uma tabela de cliente, produto, nota fiscal e assim suscetivamente.
Agora imaginem uma construtora do ramo imobiliário que para cada
incorporação construída tem que ser aberto um CNPJ. Já pensou se ela tiver
mais de 100 empreendimentos construídos ou em construção? O banco
passará de 100 mil tabelas facilmente!
A partir da versão 11 do Protheus já é possível criar as empresas dentro da
mesma tabela o que diminui significativamente o número de tabelas dentro
do banco de dados. Essa dica da versão 11 do Protheus foram dadas pelos
amigos Bruno e Luiz Carlos nos comentários do post.
O nome das tabelas não ultrapassam 6 caracteres e são representados da
seguinte maneira: 3 primeiros caracteres é a família que aquela tabela
pertence, os 2 próximos caracteres representa a empresa que aquela tabela
pertence e o último caractere é reservado ao sistema, por exemplo a tabela
de cliente da empresa 01 é a SA1010, da empresa 02 é a SA1020 onde SA1 é
a família da tabela, 01 e 02 representa a empresa e o 0 no final é reservado.
Como assim família ? Exemplo, cliente é SA1, fornecedor é SA2 e assim por
diante. A Totvs considera que Cliente e Fornecedor pertencem à mesma
família;
O campo chave primária das tabelas é sempre o mesmo, ou seja, todas as
tabelas tem um campo chamado R_E_C_N_O_ que é auto-incrementado
pelo Top Connect e é a PK das tabelas;
Os registros das tabelas nunca são deletados fisicamente. Todas as tabelas
contém um campo chamado D_E_L_E_T_ e quando alguém excluí um
registro no sistema, no banco de dados esse campo é preenchido com um *,
então sempre que for fazer qualquer select lembrem-se de desprezar os
registros deletados colocando na condição where D_E_L_E_T_ = ”, ou
D_E_L_E_T_ <> ‘*’. Esse conceito de exclusão lógica foi herdado do DBF;
M V T e c h | 102
Não existe campo DateTime nas tabelas. Todos os campo data são
VARCHAR(8), nunca são nulos e são sempre preenchidos com 8 caracteres
em branco para informar que estão vazios;
Não existe campo NULL. Se o campo for numérico ele é preenchido com zero
e se for String/Char é preenchido com espaços em branco. Em ambos os
casos o preenchimento é feito via Constraint Default. Agora imaginem a
quantidade de Constraint que cada tabela tem!;
Muito cuidado ao criar índices nas tabelas, pois se você criar em uma terá
que criar em todas, por exemplo: Se criar um índice na tabela de cliente
SA1XX0 lembre-se de replicar esse índice para as demais tabelas de cliente
caso tenha;
O Protheus trabalha com um dicionário de dados próprio onde são definidas
as tabelas, campos e índices então em uma atualização de versão é feita uma
checagem do dicionário de dados com a estrutura do banco de dados e tudo
que não estiver definido no dicionário será apagado, seja campo, índice ou
tabela, portanto ao criar um índice utilizado em um trabalho de Tuning eu
aconselho a criar uma rotina que diariamente verifica a existência desse
índice e então caso não exista mais crie-o novamente. Eu costumo colocar
tudo dentro do step de um job que diariamente consulta a sys.indexes pelo
nome;
Nunca crie um campo em uma tabela sem antes passar para o dicionário de
dados do Protheus, pois ao abrir uma tela que use a tabela onde o campo foi
criado, essa tela irá travar por não ter o campo no dicionário;
O desempenho das consultas não são grande coisa, pois a maioria dos
desenvolvedores Protheus não tem grandes habilidades e conhecimento
sobre indexação, então é sempre bom dar uma checada nas consultas mais
lentas e dar um help para a galera de desenvolvimento;
Uma forma de ganhar espaço em disco com o banco do Protheus é usar a
compressão de dados a nível de página caso o SQL Server seja Enterprise. Em
testes realizados na tabela SB1(Produtos) com 28000 produtos,
comprimindo apenas a tabela passou de 72 MB para 6 MB, ou seja, uma taxa
de compressão de 91.66%;
M V T e c h | 103
Os bancos geralmente são enormes então é válido pensar em uma estratégia
de particionamento das tabelas;
Índices não usados e duplicados não é excessão e sim regra, então é válido
analisar isso e repassar para os desenvolvedores. Nunca apague um índice
sem antes apagar no dicionário, pois as telas fazem essa verificação também
em sua abertura e caso não encontre no banco elas travarão;
O Top Connect não funciona em cluster devido ao hardlock que é quem
licencia o Protheus e como em alguns casos ele é instalado no mesmo
servidor do banco de dados, não será possível colocar ele no Service and
Application do Cluster e quando ocorrer um Failover será necessário reiniciar
o servidor de licença que fica geralmente em outro servidor, senão ele não
voltará ao ar e a aplicação não abrirá;
Não é possível fazer uma replicação merge das tabelas, devido fato da
replicação merge adicionar um campo de controle de unicidade chamado
rowguid e caso tenha um campo na tabela do banco e não tenha no
dicionário do Protheus isso causa sérios impactos. Mesmo que não houvesse
o impeditivo do campo rowguid, muitas tabelas ultrapassam 246 colunas e
seria impossível replicar com merge devido o limite de 246 colunas por
artigo;
Devido o padrão das tabelas do Protheus não terem campos NULL e todos
serem preenchidos com uma Constraint Default isso impede que as tabelas
sejam colocadas In-Memory a.k.a Hekaton que é o novo recurso do SQL
Server 2014. É possível desde que todas as Constraints Defaults sejam
excluídas e os campos que são Not Null passem a ser Null, porém isso
implicaria em uma grande mudança na modelagem do banco e os efeitos
colaterais nesse tipo de mudança são incontáveis;
Normalmente os bancos são muito grandes, então a rotina de manutenção
de índices se torna uma tarefa difícil e quase impossível para a rotina do
Maintenance Plan do SQL Server, portanto é válido usar rotina própria ou de
terceiros como a rotina do Ola Hallengren.
Bom galera espero que essas dicas sejam úteis para todos. Conforme eu for
me lembrando de mais coisas eu vou atualizando o post.
*Leandro Ribeiro | blog: sqlleroy.com | twitter: @sqlleroy
M V T e c h | 104
Marcos Freccia
marcosfreccia.wordpress.com
Importando arquivos excel usando o SSIS
Olá pessoal,
Hoje recebi uma dúvida do amigo Raphael Wanderley (@raphaelwsantos)
sobre como importar um arquivo do Excel para o SQL Server. Na
oportunidade eu mencionei a ele para utilizar o SQL Server Integration
Services (SSIS), pois é muito mais simples de ser feito.
Então, abaixo vou demonstrar como realizar a importação de arquivos
utilizando o SSIS.
Crie um novo projeto do tipo “Integration Services Project” conforme a
imagem abaixo.
M V T e c h | 105
Você deverá agora arrastar o componente “Data Flow Task”, pois é dentro
desse passo que vamos adicionar as fontes e destinos para realizar a cópia.
De um duplo clique no componente e uma nova aba irá aparecer. Expanda a
area Other Source e arraste o componente “Excel Source”. Expanda a area
Other Destinations e arraste o componente “OLE DB Destination”. Por fim,
conecte através da linha azul os dois componentes conforme a imagem
abaixo.
M V T e c h | 106
De um duplo clique no componente “Excel Source” e depois crie uma nova
conexão.
Escolha o caminho do arquivo Excel que deseja importar, qual a versão do
seu arquivo Excel e também se a primeira linha do documento contém as
colunas e não dados.
Para trabalhar com a arquitetura 64bit, você deve realizar o download
do Microsoft Access Database Engine 2010 Redistributable. Baixe a versão
64bit
M V T e c h | 107
O próximo passo é escolher qual aba (Sheet) você deseja importar.
Agora, de um duplo clique em “OLE DB Connection Manager” e clique em
New para criar a conexão com o banco de dados.
Crie a conexão com o banco de dados e confirme a operação.
M V T e c h | 108
Enquanto configura o destino dos seus dados, você tem a opção de escolher
uma tabela já existe, ou criar uma nova tabela para receber os dados a serem
importados. Neste exemplo vamos criar uma nova tabela.
M V T e c h | 109
Feito a criação da tabela, você já estará pronto para realizar a importação do
arquivo.
Agora, você poderá iniciar a execução do pacote pressionando a tecla F5 ou
pressionando o botão conforme a imagem abaixo.
O pacote sendo executado com sucesso, você deverá ver isso no fluxo criado.
M V T e c h | 110
Verificando o SQL Server, os arquivos foram importados corretamente.
Pronto, você já fez a sua primeira solução em SSIS. Agora basta você seguir
um tutorial de como agendar pacotes do SSIS no SQL Server Agent.
M V T e c h | 111
Espero que tenham gostado e estarei montando mais tutoriais desse tipo
explicando pequenas funcionalidades.
M V T e c h | 112
T-SQL no SQL Server 2012 – Parte 1
Olá pessoal,
O intuito dessa série de posts que vou iniciar agora é mostrar tudo de novo
que temos na parte de T-SQL no SQL Server 2012. Antes de iniciarmos é bom
deixar frisado que o intuito aqui não é mostrar nada mirabolante, mas sim o
SIMPLES! Então esqueçam de ver algo avançado, o que vocês irão ver aqui é
o básico.
Para não criar posts extensos que nos cansam de ler, vou fazê-lo por partes.
Hoje vamos falar de:
Execute WITH RESULT SETS
Sequence
1) EXECUTE WITH RESULT SETS.
Esse novo recurso surgiu no SQL Server 2012 como uma necessidade de
formatação de nossos conjuntos de dados, provenientes de uma stored
procedure. Então sua explicação e demonstração é bastante simples.
Pegamos um result set que está vindo como saída de uma procedure e
mostramos para o usuário da maneira que necessitamos através desse result
set personalizado.
V AMOS VER COMO FUNCIO NA ?
Tenho aqui uma simples procedure.
USE AdventureWorksDW2012
GO
CREATE PROCEDURE spGetSalesAmout
AS
SELECT FirstName ,
SalesAmount
FROM
FactInternetSales AS fact
JOIN
DimCustomer
AS
cust
fact.CustomerKey = cust.CustomerKey
M V T e c h | 113
ON
Temos aqui duas possibilidades de deixar nosso
result set mais amigável.
1) Mudar diretamente no código T-SQL
2) Utilizar o recurso WITH RESULT SETS.
Vamos ver como funciona?
execute spGetSalesAmout
WITH RESULT SETS
(
([Primeiro Nome] varchar(20),
[Total de Vendas] money)
);
Como vemos aqui, podemos até trocar o tipo de dados que será retornado.
Vamos agora ver o resultado.
M V T e c h | 114
Em questões de usabilidade esse recurso seria interessante onde não
podemos mudar o código da consulta T-SQL, por muitas vezes estar
capturando dados de outros sistemas.
Como podemos ver um recurso muito simples e que pode nos ajudar
bastante.
2) SEQUENCE
Recurso esse muito conhecido no Oracle é a sequence, um objeto
responsável por gerar números sequencias. Ai você me pergunta: Mas já
M V T e c h | 115
temos o identity. Correto, porem o objeto Sequence vem para abrir mais
possibilidades de utilização e como a mesma é um objeto permite outros
tipos de gerenciamento que não temos no campo identity.
C OMO UTILIZAR ?
P ASSO 1: C RIAÇÃO DA S EQUENCE .
A criação da sequence é muito simples e com apenas alguns comandos já
conseguimos criar.
CREATE SEQUENCE DemoSequence
START WITH 1
INCREMENT BY 1;
Até ai também podemos utilizar o identity no campo, já que conseguimos ter
o início e realizar incrementos personalizados.
C OMO UTILIZAMOS A SEQUENC E ?
CREATE TABLE Demo1
(
id INT PRIMARY KEY ,
nome VARCHAR(100)
)
GO
INSERT INTO Demo1
VALUES ( NEXT VALUE FOR dbo.DemoSequence,
'Marcos Freccia' )
O comando NEXT VALUE FOR dbo.DemoSequence é o que faz o número ser
gerado e automaticamente incrementado.
M V T e c h | 116
Se realizarmos mais uma inserção teremos.
Como eu disse anteriormente, a Sequence é um objeto então a possibilidade
de gerenciamento e de usabilidade é maior por exemplo.
INSERT INTO Demo1
VALUES ( NEXT VALUE FOR dbo.DemoSequence +
2, 'Marcos Freccia' )
M V T e c h | 117
R ESULTADO .
Podemos criar também sequences que possuem um limite máximo de
números a serem gerados.
CREATE SEQUENCE DemoSequence2
START WITH 1
INCREMENT BY 1
MAXVALUE 5;
Vamos realizar apenas uma demonstração.
CREATE TABLE Demo2 ( id INT, nome
VARCHAR(100) )
GO
INSERT INTO Demo2
VALUES ( NEXT VALUE FOR dbo.DemoSequence2,
'Marcos Freccia' )
GO 5
SELECT
FROM
*
Demo2
M V T e c h | 118
Vamos realizar apenas mais uma inserção.
Como puderam ver, a nossa sequence não deixou que realizássemos mais
inserções de dados no campo.
Bom pessoal por hoje era isso, espero que tenham gostado e no decorrer do
tempo estarei mostrando mais funcionalidades em T-SQL no SQL Server
2012.
M V T e c h | 119
T-SQL no SQL Server 2012 – Parte 2 – Paginação de
dados
Olá pessoal,
Atualmente aplicações web fazem o uso de uma funcionalidade até então
presente apenas a nível de desenvolvimento que é o recurso de realizar a
paginação dos dados, ou seja, mostrar dados em tela pouco a pouco e não
simplesmente retornar tudo, assim evitando problemas de performance.
Foi pensando nisso que no SQL Server 2012 foi implementado um novo
recurso juntamente a clausula Order By utilizando dois recursos de nome
OFFSET e FETCH.
Para iniciarmos o entendimento sobre essa funcionalidade, precisamos ter
em mente dois termos que serão utilizados na clausula Order By.
OFFSET: Especifica o número de linhas a ignorar antes de iniciar o retorno
dos dados propostos pela consulta. Esse valor sempre deverá ser maior ou
igual a 0(zero)
FETCH: Especifica o número de linhas a retornar depois que a clausula
OFFSET foi processada. Esse valor sempre deverá ser um inteiro constante
ou uma expressão que é maior ou igual a 1.
Bom, vamos parar com a parte teórica e vamos demonstrar a parte pratica
dessa nova função.
Apenas alguns scripts de criação de base de dados e inserção de dados.
USE master
GO
CREATE DATABASE DB_OrderByClause
GO
USE DB_OrderByClause
GO
CREATE TABLE tblPaginacao
(
id INT IDENTITY ,
M V T e c h | 120
nome VARCHAR(100)
)
GO
INSERT
VALUES
INTO tblPaginacao
( 'Registro 1' ),( 'Registro 2' ),
( 'Registro 19' ),( 'Registro 20' )
C ONSULTA 1
SELECT *
FROM
tblPaginacao
ORDER BY id
OFFSET 5 ROWS
M V T e c h | 121
Na primeira consulta apenas a clausula OFFSET foi especificada, ou seja,
como foi falado anteriormente o OFFSET ignora o número de linhas
desejadas. No exemplo estamos realizando o OFFSET de 5 registros, então é
normal que a consulta seja retornada a partir do registro de número 6.
C ONSULTA 2
SELECT *
FROM
tblPaginacao
ORDER BY id
OFFSET 5 ROWS
FETCH NEXT 10 ROWS ONLY
M V T e c h | 122
Nessa segunda consulta foi especificado a clausula OFFSET e FETCH, ou seja,
de acordo com a consulta será ignorada os cinco primeiros registros e apenas
irá retornar os próximos dez registros, por isso a clausula FETCH NEXT 10
ROWS ONLY.
Bom pessoal como vocês puderam ver apenas duas demonstrações básicas
de como utilizar esse novo recurso no SQL Server 2012.
Espero que tenham gostado e até a próxima.
M V T e c h | 123
Ivan Lima
www.ivanglima.com
Inside The Machine – Introdução
Quando você pensa na memória do seu servidor, qual é a primeira coisa que
te vem à cabeça? Gigabytes? Terabytes? Enfim, espaço? E quando você
pensa em desempenho, a primeira coisa que você pensa são os Gigahertz da
CPU?
Nessa série de artigos vamos explorar o subsistema de memória de um ponto
de vista um pouco diferente: o foco será a interação entre ele e a CPU.
Falaremos do desempenho da memória e como ela pode afetar – e afeta! –
o desempenho como um todo do seu servidor, e o que você pode – e não
pode – fazer a respeito em relação ao seu banco de dados (ou qualquer outra
aplicação).
V ELOCIDADE DO PROCE SSADOR É TUDO ?
Se você não conhece Martin Thompson, recomendo adicionar o blog ao seu
leitor de RSS favorito e acompanhar o que ele escreve e palestra. Ele é
definitivamente uma das grandes referências no assunto de HPC (High
Performance Computing) e baixa latência e vamos utilizar alguns testes
escritos por ele (e alguns meus) durante essa série, então nada mais justo do
que começar fazendo referência a uma frase sua: “The real design action is
in the memory sub-systems.” [2]
Você já percebeu que ultimamente têm sido bastante falado sobre a
velocidade dos processadores e como seu desempenho parou de evoluir nos
últimos anos em favor do aumento da quantidade de cores? Quem
desenvolve software com certeza já ouviu que deve aprender
desenvolvimento de software com paralelismo para não arriscar ficar sem
emprego no futuro. A famosa frase “the free lunch is over” tem sido repetida
diversas vezes nas últimas conferências mundo à fora desde que o guru de
M V T e c h | 124
C++ Herb Sutter escreveu o seu artigo homônimo em 2005 para o respeitado
journal Dr. Bobb’s [1].
De fato a frequência dos processadores parou de subir, principalmente
devido às questões de economia de energia e dissipação de calor, como é
possível observar claramente no gráfico abaixo tirado do artigo de Sutter:
M V T e c h | 125
Intel CPU Trends 1970-2010. Fonte: The Free Lunch Is Over, Herb Sutter
Mas olhar apenas para os GHz não conta toda a história.
Linha
Modelo
Ops/Sec
Ano de Lançamento
Core 2 Duo
P8600 @ 2.40GHz
1434
2008
Xeon
E5620 @ 2.40GHz
1768
2010
Core i7
i7-2677M @ 1.80GHz
2202
2011
Core i7
i7-2720QM @ 2.20GHz
2674
2011
Podemos observar na tabela acima que o desempenho geral do CPU continua subindo, mesmo que a
frequência esteja, de certa forma, estagnada. Medimos esse desempenho através de IPCs, ou Instructions
per Cycle.
Ou seja, em um processador de 2 GHz capaz de fazer o retirement de até 4 instruções por ciclo (IPC), como
é o caso da microarquitetura Nehalem, no caso ideal o seu desempenho pode chegar a 8 bilhões de
instruções por segundo! Nada mal.
M V T e c h | 126
Single Threaded Performance Trends 1995-2011 [3]
M V T e c h | 127
Então se o desempenho das CPUs efetivamente continua subindo (apesar de claramente em um ritmo
menor) mesmo que os clocks se mantenham estáveis, quem é o responsável por segurar o desempenho geral
dos sistemas?
Refazendo a pergunta anterior de outra forma… Em um workload onde o gargalo não se encontra nem em
I/O nem na CPU, o que impede o seu processador de realizar o trabalho mais rapidamente?
Você provavelmente já deve ter matado a charada: no acesso à memória, ou o que chamamos de latência.
Mas esse fato não parece ser muito óbvio à primeira vista: memória não é só uma questão de quantidade.
putz...
Em relação ao custo de acesso ao disco, a latência do acesso à memória é irrisório.
A memória, porém, é o que previne que o seu sistema rode em seu desempenho máximo. Isso ocorre pois o
acesso à memória é significativamente inferior à velocidade do processador, e essa diferença só cresceu
ainda mais nas últimas décadas. Esse fenômeno é chamado de “Memory Wall“, termo cunhado no paper [4].
Se pudéssemos trabalhar com dados apenas nos registradores, a “memória” com a menor latência no CPU,
o nosso processador poderia utilizar todo o seu potencial computacional. Infelizmente, principalmente em
servidores de bancos de dados, isso está muito longe da realidade. É comum trabalharmos com working sets
de dezenas ou centenas de GB. E por isso pagamos o custo de acesso à memória o tempo todo. Enquanto
esse acesso ocorre, o processador precisa ficar esperando pelos dados até que ele possa voltar a trabalhar,
efetivamente gastando ciclos de clock à toa. Um cache miss pode custar centenas de ciclos de clock do
processador, tempo que ele poderia gastar realizando operações ao invés de esperar por dados para serem
processados.
Com o fim da era de crescimento contínuo dos clocks dos processadores os engenheiros têm evoluído as
microarquiteturas a fim de amenizar o impacto da latência do acesso à memória principal do sistema. Os
processadores se utilizam de diversos artifícios para esconder essa latência, e assim diminuir a penalidade
causada pela disparidade entre o desempenho entre eles. Um deles é o Hyper-Threading (SMT), tópico de
um próximo artigo.
REFERÊNCIAS:
[1] Sutter – The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
[2] Thompson
– Mythbusting modern hardware
to gain “Mechanical Sympathy”
[3]
Moore
–
Data
Processing
in
Exascale-class
Computing
Systems
[4] Wulf, McKee – Hitting the Memory Wall: Implications of the Obvious
M V T e c h | 128
Inside the Machine – Processadores
INTRODUÇÃO
Se você não viu a primeira parte da série, sugiro que leia antes de continuar, pois nessa parte vamos seguir
a linha de pensamento apresentado anteriormente.
P ROCESSADORES
Já que vamos falar sobre mecanismos internos das CPUs precisamos escolher alguma implementação, ou
microarquitetura específica como ponto de partida.
Escolhi a microarquitetura Nehalem [1] pelo simples fato de que tenho processadores baseados nessa
microarquitetura tanto nos servidores do ambiente onde trabalho quanto no meu notebook.
Segundo a Intel, o desenvolvimento dessa microarquitetura custou aproximadamente 12 bilhões de dólares,
incluindo US$ 9 bilhões na construção das fábricas (fabs), US$ 1 bilhão para o design do processo de
fabricação de 45 nanômetros em material dielétrico “High-k” [11], e US$ 2 bilhões no design da
microarquitetura em si [3].
Outra microarquitetura, chamada Westmere é a versão reduzida (shrink) da microarquitetura Nehalem,
seguindo o padrão tick-tock de fabricação da Intel [2]. Esse tem um processo de fabricação de 32nm. A
atualização das fabs para esse shrink custou à Intel mais US$ 7 bilhões [10].
Apesar da Intel já ter lançado novas microarquiteturas desde então – Sandy Bridge, Ivy Bridge e o recémanunciado Haswell – as microarquiteturas Nehalem e Westmere são bastante comuns nos servidores que se
encontram em produção hoje.
O VERVIEW DA M ICROARQUITETURA
Nehalem foi uma microarquitetura particularmente importante em relação a tecnologias Intel. Foi nessa
microarquitetura que a Intel reintroduziu o hyper-threading ao seus processadores, após remover a
funcionalidade nos processadores baseados na microarquitetura Core. Outra tecnologia importante
introduzida pelo Nehalem foi o uso de um interconnect entre os processadores, similar ao que a AMD já
vinha oferecendo, para remover o gargalo do acesso à memória com o Front-Side Bus (FSB). Chamado
de QuickPath Interconnect (QPI), a Intel criou a tecnologia visando recuperar o mercado perdido para a AMD
durante o período.
Falaremos sobre o QPI no futuro, quando entrarmos no assunto de Non-Uniform Memory Access, ou NUMA.
M V T e c h | 129
Primeiro chip Nehalem, Cortesia Intel
C ORE E U NCORE
Na terminologia dos designers e engenheiros de processadores, os processadores são divididos entre Cores
e Uncore.
Cores são desenhados como blocos reutilizáveis de lógica e hardware e não mudam entre um modelo e
outro.
Os cores Nehalem e Westmere possuem 64 KB de cache L1 e 256 KB de cache L2 cada. O cache L3 é
compartilhado entre todos os caches do chip, e o seu tamanho é dependente dos modelos.
O Uncore, por outro lado, são os componentes que não fazem parte do Core. Dependendo da literatura que
você ler isso inclui L3, I/O, IMC e QPI. Outros separam os componentes, portanto teríamos Uncore, QPI, IMC,
etc.
O Uncore pode mudar (e efetivamente muda) de um modelo para outro, mesmo entre modelos da mesma
microarquitetura.
P LANTA
Além disso, os Cores rodam em frequências e voltagens independentes entre si. O Uncore também roda em
uma frequência independente do restante dos cores. Nos slides da Intel, eles se referem ao Uncore e outros
componentes de forma distinta, mas ao se referirem à frequência e voltagem, chamam todos de Uncore
também.
M V T e c h | 130
Particionamento de voltagem e frequência do Nehalem, Cortesia Intel
A diferença na frequência entre Cores e Uncore tem impacto direto no desempenho da máquina, através de
funcionaliades como Turbo Boost e SpeedStep.
Quando estiver abordando um assunto específico de cada modelo (uncore) darei preferência ao Xeon E78870, o modelo com qual trabalho. Conhecido como Westmere-EX, este é o absoluto top de linha da Intel
em arquitetura x86 nesse ciclo de lançamentos.
X EON E7
O Xeon E7-8870 possui aproximadamente 2.6 bilhões (!) de transístores
em uma pastilha de 513 mm²; quatro portas QuickPath Interconnect (fullwidth) em 3.2 GHz rodando a 25.6 GB/s full-duplex; 2 controladoras de
memória DDR3 on-chip dual-channel de 10.83 GB/s cada, totalizando 4
canais e 43.3 GB/s; 10 cores – 20 threads em com hyper-threading – por
socket rodando a uma frequência base de 2.4 GHz. As 4 portas QPI
permitem escalar até 8 sockets em um único sistema e chegar até 2 TB
de memória com DIMMs de até 32 GB.
Processador Intel Xeon E7, Cortesia Intel
M V T e c h | 131
Chip Westmere, Cortesia Intel
Note o aumento de cores na imagem do chip Westmere em relação ao Nehalem apresentado no início do
post. Se olhar atentamente, poderá perceber que se tratam dos mesmos cores, apenas replicados mais 2
vezes. É possível perceber também o aumento nos bancos de cache, abaixo dos cores.
C ORE I 5 460M
Já o meu notebook tem uma configuração bem mais modesta e é organizado de uma forma um pouco
diferente, apesar de ser baseado na mesma microarquitetura.
É um Intel Core i5 460M, codinome Arrendale, rodando a 2.53 GHz. Possui aproximadamente 382 milhões
de transístores divididos entre 2 cores e o LLC (aka L3) de 4 MB, porém somente 3 MB são habilitados para
esse modelo. A controladora de memória (IMC) e o gráfico ficam em outro chip no mesmo package,
interligados com o chip do processador através de uma interface QuickPath Interconnect. A controladora de
memória possui 2 canais DDR3 de 1.333 MHz e suportam DIMMs de até 8 GB.
Na imagem abaixo podemos visualizar o chip do processador (88mm²) e o chip “Northbridge” de aprox. 177
milhões de transístores (114mm²) no mesmo package.
Intel’s Core i5 Arrandale CPU, Cortesia Intel
No diagrama de blocos podemos ver claramente a topologia entre o processador e o GPU, conectados por
uma interface QPI:
M V T e c h | 132
Diagrama de blocos dos Clarkdale/Arrandale, Cortesia Arstechnica
M OORE ’ S L AW
Como eu falei no artigo anterior o clock dos processadores parou de subir mas o desempenho dos cores
continua subindo, embora não no mesmo ritmo que subia anteriormente. Como isso é possível? Através da
lei de Moore.
Gordon Moore [4] é co-fundador da Intel, e a lei leva o seu nome pois ele foi o autor da frase que dizia que
o número de transistors em cada processador dobraria a cada 2 anos. Existem diversas versões e
interpretações das palavras ditas por Moore. Segue a frase original [5]:
“The complexity for minimum component costs has increased at a rate of roughly a factor of two per year.
Certainly over the short term this rate can be expected to continue, if not to increase. Over the longer term,
the rate of increase is a bit more uncertain, although there is no reason to believe it will not remain nearly
constant for at least 10 years.”
A frase pode se encontrada no artigo escrito por Moore [14], mas sem entender a relação entre defeitos,
custo e integração na fabricação de chips a frase é difícil de ser digerida. Uma versão que gosto e que modifica
ao mínimo a frase foi publicada no Arstechnica, em 2008 [13]:
“The number of transistors per chip that yields the minimum cost per transistor has increased at a rate of
roughly a factor of two per year.”
Esse é o sentido original da frase, e a percepção do mercado de chips em geral nas últimas décadas. A frase
foi dita em 1965, e apesar de Moore ter previsto a continuidade por 10 anos, a lei continua em vigor até hoje.
M V T e c h | 133
Gráfico do número de transístores ao longo da história, Cortesia Wikipedia
M V T e c h | 134
Essa quantidade extra de transístores é utilizada pelos engenheiros para aumentar a eficiência dos
processadores. Com cada ciclo de lançamentos, os processadores ficam mais e mais complexos.
Em alguns modelos Nehalem, por exemplo, quase 60% desses transístores são dedicados aos caches,
principalmente no cache L3 [12]. O restante é utilizado para adicionar mais lógica e mais funcionalidades,
aumentando assim a complexidade dos chips.
C OMPLEXIDADE
Vista aérea de Shangai, China
Para se ter uma ideia da complexidade desses
processadores, basta imaginar que a cidade mais
populosa da China, Shangai, possui aproximadamente
16 milhões de habitantes, enquanto o processador Xeon
E7-8870,
como
dito
anteriormente,
possui
aproximadamente 2.6 bilhões de transístores. Ou seja,
se cada morador correspondesse a um transístor,
precisaríamos de 162 Shangais e meia. Isso é o dobro de
toda a população da própria China, o país mais populoso
do mundo.
GPGPU
Uma forma alternativa de utilizar esses transístores seria a criação de núcleos pouco complexos, porém em
quantidades muito maiores do que vistos hoje, como por exemplo um processador com dezenas ou centenas
de cores.
Na verdade esse tipo de arquitetura existe e é muito utilizada. É encontrada em GPUs, que possuem centenas
de núcleos simples (em relação aos núcleos de uma CPU). Em geral, esses núcleos não servem para fazer o
processamento de qualquer tipo de código e operação e portanto não substituem os processadores comuns,
mas podem ser úteis para algoritmos onde é possível fazer paralelismo massivo do processamento. Existem
várias vertentes de desenvolvimento de dispositivos, linguagens e ferramentas para aproveitar melhor esses
recursos como o NVIDIA CUDA, OpenCL e mais recentemente o C++AMP da Microsoft, do qual já falei no
meu blog. Em (http://ivanglima.com/c-em-2012/)
Esse tipo de processamento, chamado de General-purpose computing on graphics processing units, ou
GPGPU, ainda não é utilizado pelos SGBDs, mas já existem pesquisas nesse sentido, como pode ser visto em
[8] e [9].
C ACHE
Agora que já fizemos uma introdução básica às CPUs, no próximo artigo vamos nos aprofundar um pouco no
assunto dos caches.
REFERÊNCIAS
[1]
[2]
http://en.wikipedia.org/wiki/Nehalem_(microarchitecture)
http://en.wikipedia.org/wiki/Intel_Tick-Tock
M V T e c h | 135
[3] http://forwardthinking.pcmag.com/pc-hardware/283044-intel-looks-ahead-nehalem-larrabee-and-atom
[4]
http://en.wikipedia.org/wiki/Gordon_Moore
[5]
http://en.wikipedia.org/wiki/Moore’s_Law
[6]
http://www.xbitlabs.com/articles/cpu/display/core-i7-920-overclocking_3.html
[7]
http://www.extremetech.com/extreme/133541-intels-64-core-champion-in-depth-on-xeon-phi
[8]
http://sacan.biomed.drexel.edu/vldb2012/program/?volno=vol5no13&pid=1004&downloadpaper=1
[9]
http://wiki.postgresql.org/images/6/65/Pgopencl.pdf
[10]
http://asia.cnet.com/blogs/intel-invests-us7-billion-in-32nm-westmere-cpu-manufacturing62114335.htm
[11]
http://www.intel.com/pressroom/kits/advancedtech/doodle/ref_HiK-MG/high-k.htm
[12]
http://upcommons.upc.edu/e-prints/bitstream/2117/13932/1/hybrid_NUCA-hipc11.pdf
[13]
http://arstechnica.com/gadgets/2008/09/moore/
[14]
http://www.computerhistory.org/semiconductor/assets/media/classic-paperspdfs/Moore_1965_Article.pdf
M V T e c h | 136
Inside The Machine - Hyper-Threading (SMT) e SQL Server
O principal fator que vai definir o impacto do HT no seu ambiente é o seu workload – tanto positivamente
quanto negativamente.
A própria Intel limita o ganho teórico do HT a 30% [1]. Isso é, no melhor do melhor dos casos, o máximo de
desempenho que você vai “ganhar” com HT é 30%. É pouco? Não acho. Mas o que eu acho é que HT é muitas
vezes confundido como uma funcionalidade de desempenho quando na realidade é uma funcionalidade que
visa melhorar a eficiência do seu processador. Ele vai utilizar alguns ciclos a mais que teriam sido perdidos
caso não houvesse um “pipeline” substituto pronto para entrar em cena. Não há ganho, e sim “controle de
perda”.
HT nada mais é do que a duplicação de alguns componentes do pipeline do núcleo, permitindo que esse, no
melhor caso, não pare totalmente de trabalhar quando houver uma dependência ainda não disponível
durante a execução, como um acesso de memória que resultou em cache miss, por exemplo.
Pipeline (SMT)
M V T e c h | 137
T EORIA E PRÁTICA
Ok, mas saindo um pouco da teoria e indo para a parte prática, muitas coisas começam a influenciar na
brincadeira.
O próprio escalonamento do Windows (e de tabela o do SQL Server) afeta o desempenho do sistema com
o HT habilitado ou não. Por exemplo, se o algoritmo do scheduler não levar em conta o fato de dois
“núcleos lógicos” (por falta de nome melhor) compartilharem os mesmos ALUs o seu desempenho vai
piorar sensivelmente quando o scheduler escalonar duas threads no mesmo núcleo físico ao invés de
núcleos físicos distintos.
Esse cenário era muito comum nos primórdios do Windows Server [2], quando este não fazia distinção
entre núcleos físicos e lógicos. Ainda vemos algo parecido hoje nos processadores oriundos da
microarquitetura Bulldozer da AMD, que utiliza uma tecnologia que também afeta o comportamento do
pipeline, mas não é exatamente uma implementação do SMT. Os schedulers não estavam preparados
para lidar com isso durante o lançamento dos processadores dessa microarquitetura, fazendo a AMD
sofrer em alguns benchmarks [3].
Trocando em miúdos, existem muitos fatores e o impacto no desempenho final pode ser bem maior do
que os 30% teóricos, tanto positivamente quanto negativamente.
M ITO
Existe um mito que o Hyper-Threading é o mal encarnado para o SQL Server, devido a diversos fatores,
incluindo os citados acima. Um dos causadores (não intencional) desse rumor foi o Slava Oks [4] (ex-time
de produto, SQLOS), e se você quiser ver um ótimo exemplo de como fazer o HT não funcionar, sugiro que
leia o seu post e execute os testes você mesmo.
P ROCESSADORES
Agora vamos para a questão de desempenho de processadores…
Observando o processo do SQL Server (sqlservr.exe) podemos notar que ele possui callstacks bastante
profundas, de pelo menos uns 8 níveis desde o início do processamento de uma consulta, e muitos
branches ao longo da execução dessa consulta, mesmo simples. Servidores OLTP, em geral, costumam ter
um working set de GBs de dados em memória e processar pequenas partes dessa massa à cada segundo,
de forma “aleatória”. Na teoria [5], esses tipos de cenários são excelentes candidatos a fazer um bom uso
do SMT e também são bastante influenciados pelo tamanho dos caches do processador, a latência de
acesso da sua memória RAM e a eficiência do branch predictor. Esses fatores podem até mesmo
influenciar mais que o próprio clock do seu processador… Nada de comprar processadores olhando
apenas os GHz!
M V T e c h | 138
Workloads de OLAP e aplicações científicas , por outro lado, tendem a ser mais sensíveis à “força bruta”
do processador.
Enfim… No final das contas, a única coisa que vai te dizer se o HT pode ou não beneficiar o seu ambiente
é o teste. São fatores demais que influenciam no resultado final para fazer uma previsão para qualquer
direção. Se você tiver um processador com HT, teste seu workload com e sem o HT habilitado e colete
métricas que te dirão qual é preferível.
No caso do seu processador não possuir a funcionalidade, só posso dizer que não se preocupe com isso.
Há formas mais práticas e diretas de influenciar o desempenho do seu ambiente.
REFERÊNCIAS:
[1] http://en.wikipedia.org/wiki/Simultaneous_multithreading#Modern_commercial_implementations
[2]
http://www.hardwaresecrets.com/article/Activating-the-Hyper-Threading/20
[3] http://www.hardwarecanucks.com/news/cpu/microsoft-tries-again-second-win-7-bulldozer-hotfixnow-available/
[4]
http://blogs.msdn.com/b/slavao/archive/2005/11/12/492119.aspx
[5] http://www.cs.washington.edu/research/smt/papers/smtdatabase.pdf
M V T e c h | 139
Fabiano Neves Amorim
www.blogfabiano.com
Join reordering e Bushy Plans
INTRODUÇÃO
Normalmente o otimizador de consultas não considera “bushy plans” (dois operadores se unem ao
resultado de outros joins). Isso significa que o SQL pode não produzir bons planos para alguns tipos de
consultas. Hints (dicas), por si só também não irão fazer isso. Para tal otimização, uma mágica mais
poderosa é necessária.
J OIN REORDERING E B USHY P LANS
Pessoal, atualmente estou sofrendo com meu conflito existencial de “otimizador sucks”, deixa eu explicar
melhor.
Quando você começa a trabalhar e estudar muito sobre o otimizador de consultas do SQL Server (ou de
qualquer outro DB) você passa por vários conflitos existenciais, são eles:
Olha se eu apertar ctrl+l aparece um monte de desenhinhos
Preciso aprender a ler um plano de execução (já não chama mais de desenhinhos)
Mas que raios esse operador faz?
Por quê??? Mas por quê?????
Conor Cunningham (http://blogs.msdn.com/b/conor_cunningham_msft/) é gente boa demais!
Aaaaa, estou começando a entender
Esse Paul White (http://sqlblog.com/blogs/paul_white/default.aspx) é insano!
UAU! Que esperto que o otimizador é!
Odeio esse Paul White (inveja pura!)
Opa, estimou errado!
Ummm, acho que dá pra melhorar esse plano!
Ummm, acho que dá pra melhorar esse plano 2!
Ummm, acho que dá pra melhorar esse plano 3!
M V T e c h | 140
Estatísticas sucks!
Joins sucks!
Otimizador sucks!
...
Pois bem, eu estou no nível “otimizador sucks” .
Não sei o que esta acontecendo (pode ser apenas uma fase), mas ultimamente 60% das consultas em que
trabalho na otimização tem um plano de execução ruim. Ok, muitas vezes isso é culpa de um ser humano
e não do otimizador, por exemplo, o DBA “esqueceu” de atualizar as estatísticas, ou o desenvolvedor
escreveu algum non-sarg. Mas ainda assim temos os casos onde simplesmente a culpa é do otimizador,
consultas onde ele deveria gerar um plano mais eficiente.
Veja bem, eu não estou dizendo que isso é um problema ou bug do SQL Server, essa é uma limitação de
todos os otimizadores existentes no mercado, a quantidade de alternativas para a geração de um plano
pode ser tão grande que fica completamente impossível pro otimizador analisar todas as opções, eu
entendo bem isso.
O otimizador de consultas do SQL Server é baseado em framework chamado Cascades [2], e ele executa
uma serie de explorações em uma consulta para tentar gerar um plano de execução “bom o suficiente”
utilizando a menor quantidade de recursos possíveis e, no menor tempo possível. No SQL Server essas
explorações são divididas em fases, e uma dessas fases é conhecida como “heuristic join reorder” onde o
SQL tenta definir qual será a ordem inicial de execução dos joins. A grande dificuldade no processo de
otimização de uma consulta é fazer isso na menor tempo possível, ou seja, preferencialmente o
otimizador nunca pode levar mais tempo para otimizar uma consulta do que irá gastar para executar o
plano. Isso pode parecer trivial, mas a quantidade de permutações possíveis para acessar uma consulta
com 12 joins seria de aproximadamente 479 milhões e considerando bushy plans teríamos uma variação
de 28 trilhões, ou seja, não da pra testar todas as possibilidades para qual é o melhor plano [5].
Dito isso, que fique claro que com este artigo não quero mostrar o quão ineficiente o otimizador de
consultas do SQL Server é, ou o quanto ele “sucks”, mas quero mostrar que no mundo otimização de
consultas, as coisas são sempre mais complicadas do que parecem .
B USHY P LANS NO SQL S ERVER
Há muitos anos eu tento criar um exemplo prático para falar sobre bushy plans (veja referencias no fim
do artigo) no SQL Server. Em poucas palavras um bushy plan é uma das opções que o Otimizador tem para
poder executar os joins de sua consulta. Para efetuar uma operação de join o otimizador considera
algumas variações de execução de acesso as tabela e ordem de execução dos joins, essa ordem pode
seguir um left-deep (onde o resultado do join é utilizado como outer input para o próximo join) ou right-
M V T e c h | 141
deep (onde o resultado do join é utilizado como inner input para o próximo join), ou um misto entre eles.
(veja a imagem abaixo para visualizar o que estou querendo dizer)
Atualmente o otimizador de consultas do SQL Server valida as opções que mencionei acima, porem existe
outra possibilidade de ordem de leituras das tabelas que não é considerada por default, o bushy trees.
Bushy trees podem ser interessantes em cenários em que o resultado de um join resulta em um filtro
considerável do resultset do join, ou seja, você lê várias linhas, mas depois de fazer o join poucas são
retornadas. Um bushy plan (um plano com uma bushy tree) é um plano que faz o join com base no
resultado de outros dois joins. Deixa eu tentar ilustrar para ver se fica mais claro:
Considerando o seguinte select:
SELECT
FROM
JOIN
JOIN
JOIN
*
A
B ON A.ID = B.ID
C ON A.ID = C.ID
D ON A.ID = D.ID
Podemos ter os seguintes planos:
A primeira árvore de joins contém um join em formato left-deep que executa os joins na seguinte ordem:
JOIN( JOIN( JOIN(A, B), C), D)
E a segunda árvore de joins contém o join em formato bushy que executa os joins na seguinte ordem:
JOIN(JOIN(A, B), JOIN(C, D))
O otimizador do SQL Server não avalia a possibilidade de bushy trees porque ela poderia gerar milhões de
possibilidades na ordem de execução dos joins, portanto para forçar a execução de um bushy plan no SQL
M V T e c h | 142
Server temos 2 opções, usando CTEs (que eu prefiro) ou com uma sintaxe pouco convencional pra fazer
os joins, e ambas devem utilizar o hint FORCE ORDER.
Pois bem agora que você entendeu um pouco sobre bushy plans, deixa eu te mostrar um exemplo prático
de otimização que podemos ter. Suponha o seguinte cenário no banco Northwind, para criar este banco
utilize o meu script do skydrive: http://sdrv.ms/VaTL6W
Antes de começar os testes, vamos cadastrar um cliente novo e uma nova venda para este cliente:
-- Inserir venda para novo cliente
-- Cadastrar cliente "Fabiano Amorim"
INSERT INTO CustomersBig (CityID, CompanyName, ContactName, Col1,
Col2)
VALUES (57, 'Empresa do Fabiano', 'Fabiano Amorim', NEWID(),
NEWID()) -- Cidade 57 = Sao Paulo
-- Cadastrar Venda
INSERT INTO OrdersBig (CustomerID, OrderDate, Value)
VALUES(SCOPE_IDENTITY(), GetDate(), 999)
SET IDENTITY_INSERT Order_DetailsBig ON
INSERT INTO Order_DetailsBig(OrderID, ProductID, Shipped_Date,
Quantity)
VALUES (SCOPE_IDENTITY(), 1, GetDate() + 30, 999)
SET IDENTITY_INSERT Order_DetailsBig OFF
GO
Temos os seguintes índices:
CREATE INDEX ixContactName ON CustomersBig(ContactName) -Indexando WHERE
CREATE INDEX ixProductName ON ProductsBig(ProductName) -Indexando WHERE
CREATE INDEX ixCustomerID ON OrdersBig(CustomerID) INCLUDE(Value)
-- Indexando FK
CREATE INDEX ixProductID ON Order_DetailsBig(ProductID)
INCLUDE(Quantity) -- Indexando FK
GO
E seguinte consulta:
-- Gerar "cold cache"
CHECKPOINT; DBCC FREEPROCCACHE; DBCC DROPCLEANBUFFERS;
GO
SELECT OrdersBig.OrderID,
OrdersBig.Value,
Order_DetailsBig.Quantity,
CustomersBig.ContactName,
ProductsBig.ProductName
M V T e c h | 143
FROM
INNER
ON
INNER
ON
INNER
ON
WHERE
AND
GO
OrdersBig
JOIN CustomersBig
OrdersBig.CustomerID = CustomersBig.CustomerID
JOIN Order_DetailsBig
OrdersBig.OrderID = Order_DetailsBig.OrderID
JOIN ProductsBig
Order_DetailsBig.ProductID = ProductsBig.ProductID
CustomersBig.ContactName = 'Fabiano Amorim'
ProductsBig.ProductName = 'Outback Lager 1EA81379'
Consulta tem o seguinte plano:
A performance é a seguinte:
STATISTICS IO:
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0
Table 'OrdersBig'. Scan count 0, logical reads 11776, physical reads 1, read-ahead reads 11576
M V T e c h | 144
Table 'Order_DetailsBig'. Scan count 1, logical reads 10, physical reads 1, read-ahead reads 14
Table 'ProductsBig'. Scan count 1, logical reads 3, physical reads 3, read-ahead reads 0
Table 'CustomersBig'. Scan count 1, logical reads 3, physical reads 3, read-ahead reads 0
Temos alguns problemas com relação a este plano, o primeiro e mais interessante é que por causa da
ordem que os joins serão efetuados o seek na tabela OrdersBig será executado centenas de vezes, mais
precisamente 2344 vezes, pois esse é o número de linhas que são retornados do join entre ProductsBig e
OrderDetails_Big. Porém sabemos que existe apenas uma “order” para o cliente “Fabiano Amorim”, ou
seja, eu esperava apenas uma operação de seek.
Como em tempo de compilação do plano o SQL Server não sabe qual é o valor de CustomerID do cliente
“”Fabiano Amorim” ele não consegue fazer a estimativa utilizando a estatística por OrdersBig.CustomerID.
Ficou confuso? Deixa eu te mostrar com um exemplo mais simples, imagine a seguinte consulta:
SELECT
FROM
INNER
ON
WHERE
OrdersBig.OrderID, CustomersBig.ContactName
OrdersBig
JOIN CustomersBig
OrdersBig.CustomerID = CustomersBig.CustomerID
CustomersBig.ContactName = 'Fabiano Amorim'
P LANO ESTIMADO :
Repare que a estimativa de linhas que serão retornadas após o seek pelo “Fabiano Amorim” é de 1 linha,
porém ao consultar a tabela de OrdersBig ele estima que 1250000.00 (um milhão duzentos e cinquenta)
linhas serão retornadas, crazy ha? Pois este é um problema bem conhecido no mundo dos otimizadores,
M V T e c h | 145
em tempo de compilação da consulta o SQL Server não sabe qual é o valor que será retornado de
CustomersBig.Contact_ID e por isso ele não consegue estimar corretamente, dai o que ele fez? Adivinha?
Chutou que 30% da tabela será retornada, neste caso como a tabela tem 5 milhões de linhas, ele estimou
um milhão duzentos e cinquenta linhas. Multi-Column Cross-Table Statistics ajudariam e muito neste
cenário, mas ainda não temos isso no SQL Server. Outra forma de resolver isso seria criar uma estatística
filtrada, mas isso não vem ao caso, fica pra outro post.
UPDATE: O SQL não chutou não, ele usou a densidade para obter o valor com base na quantidade média
de linhas duplicadas na distribuição dos dados. Deixe-me explicar melhor.
sp_helpstats OrdersBig
Na tabela OrdersBig temos uma estatística criada automaticamente pelo SQL Server, ou seja, ela foi criada
como uma distribuição de exemplo dos dados na tabela (WITH SAMPLE). Vamos rodar um DBCC
SHOW_STATISTICS para ver mais informações sobre ela:
DBCC SHOW_STATISTICS(OrdersBig, _WA_Sys_00000002_5CA1C101)
Para fazer a estimativa o SQL Server usa essa informação da densidade, ele estimou o seguinte, ele faz
densidade * número de linhas da tabela, ou seja, 0.25 * 5000000 = 1250000, tai o valor estimado,
coincidentemente esse valor é 30% da tabela o que me levou a acreditar nos 30% (my bad).
M V T e c h | 146
Na verdade a densidade da tabela é de 0.2 e não 0.25, se você atualizar a estatística com fullscan vera que
o valor vai mudar, e consequentemente a quantidade de linhas estimadas será de 0.2000 * 5000000, ou
seja, 100000 linhas.
Bom voltando ao plano que estamos analisando, por que o SQL Server estimou que 1.250000 linhas seriam
retornadas ele optou por não fazer o Join de CustomersBig + OrdersBig e isso está errado, sabemos que
apenas 1 linha será retornada ele deveria ter feito o seek em CustomersBig e apenas 1 seek em OrdersBig.
O mesmo se aplica para o join entre ProductsBig e Order_DetailsBig, porém neste caso o SQL estimou
utilizando a densidade da coluna Order_DetailsBig.ProductID, dai os 2328 estimados (veja no plano
estimado da consulta completa), só pra confirmar:
-- Calculando densidade
SELECT (1.0 / COUNT(DISTINCT ProductID)) FROM Order_DetailsBig
-- Calculando estimativa com base na densidade
SELECT ROUND(0.000465549348 * 5000000, 0)
Temos:
Neste caso estimar utilizando a densidade foi excelente, pois o número de linhas retornadas foi de 2344,
ou seja, bem próximo do estimado que foi de 2328.
A Fabiano, mas e o Bushy plan? Calma ai, vamos lá, sabendo que o Join entre CustomersBig + OrdersBig
irá retornar 1 linha, e o join entre ProductsBig + Order_DetailsBig irá retornar 2344 linhas, podemos forçar
a execução da seguinte ordem dos joins JOIN(JOIN(CustomersBig, OrdersBig), JOIN(ProductsBig,
Order_DetailsBig)), vamos testar utilizando CTEs:
GO
;WITH JoinEntre_CustomersBig_e_OrdersBig
AS
(
OrdersBig.Value,
CustomersBig.ContactName
FROM CustomersBig
M V T e c h | 147
INNER JOIN OrdersBig
ON OrdersBig.CustomerID = CustomersBig.CustomerID
),
JoinEntre_ProductsBig_e_Order_DetailsBig
AS
(
SELECT
Order_DetailsBig.OrderID,
FROM ProductsBig
INNER JOIN Order_DetailsBig
ON Order_DetailsBig.ProductID = ProductsBig.ProductID
)
SELECT JoinEntre_CustomersBig_e_OrdersBig.OrderID,
JoinEntre_CustomersBig_e_OrdersBig.Value,
JoinEntre_ProductsBig_e_Order_DetailsBig.Quantity,
JoinEntre_CustomersBig_e_OrdersBig.ContactName,
JoinEntre_ProductsBig_e_Order_DetailsBig.ProductName
FROM JoinEntre_CustomersBig_e_OrdersBig
INNER JOIN JoinEntre_ProductsBig_e_Order_DetailsBig
ON JoinEntre_CustomersBig_e_OrdersBig.OrderID =
JoinEntre_ProductsBig_e_Order_DetailsBig.OrderID
WHERE JoinEntre_CustomersBig_e_OrdersBig.ContactName = 'Fabiano
Amorim'
AND JoinEntre_ProductsBig_e_Order_DetailsBig.ProductName =
'Outback Lager 1EA81379'
OPTION (FORCE ORDER, MAXDOP 1)
GO
Temos o seguinte plano:
M V T e c h | 148
Como você pode observar, escrevendo as CTEs exatamente na ordem em que quero que os joins sejam
executados e utilizando o hint force order, conseguimos o plano que faz um merge join entre o resultado
dos dois joins.
A performance é a seguinte:
STATISTICS IO:
M V T e c h | 149
A diferença é enorme, a consulta com o BushyPlan roda em meio segundo, isso é 24 vezes mais rápido
que a query original, porém essas duas operações de SORT (veja no plano) para fazer o Merge Join são de
assustar, SORT é uma das operações mais pesadas para fazer no banco de dados, principalmente se o
SORT for feito em disco. Para confirmar como esse sort é pesado, vamos fazer um teste utilizando um
CustomerName que retorna mais Orders e outro ProductName, ou seja, mais linhas serão ordenadas.
Query original sem bushy plan:
GO
OrdersBig.Value,
FROM OrdersBig
INNER JOIN CustomersBig
ON OrdersBig.OrderID = Order_DetailsBig.OrderID
INNER JOIN ProductsBig
WHERE CustomersBig.ContactName = 'Karl Jablonski 1E663869'
AND ProductsBig.ProductName = 'Ravioli Angelo D01AFCFC'
GO
950 linhas são retornadas e a performance é:
STATISTICS IO:
M V T e c h | 150
Query com o BushyPlan:
GO
AS
(
OrdersBig.Value,
CustomersBig.ContactName
FROM CustomersBig
),
AS
(
SELECT
FROM ProductsBig
)
INNER JOIN JoinEntre_ProductsBig_e_Order_DetailsBig
WHERE JoinEntre_CustomersBig_e_OrdersBig.ContactName = 'Karl
Jablonski 1E663869'
'Ravioli Angelo D01AFCFC'
M V T e c h | 151
GO
950 linhas são retornadas e a performance é:
STATISTICS IO:
Table 'Order_DetailsBig'. Scan count 1, logical reads 9, physical reads 2, read-ahead reads 6, lob logical
reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'ProductsBig'. Scan count 1, logical reads 3, physical reads 3, read-ahead reads 0, lob logical reads
0, lob physical reads 0, lob read-ahead reads 0.
Table 'OrdersBig'. Scan count 1, logical reads 5720, physical reads 4, read-ahead reads 5728, lob logical
Table 'CustomersBig'. Scan count 1, logical reads 3, physical reads 3, read-ahead reads 0, lob logical reads
0, lob physical reads 0, lob read-ahead reads 0.
Ainda que o número de reads seja menor, o tempo foi de 13 segundos, contra 7 do plano sem bushy plan,
também podemos perceber que existe um sort warning no profiler, ou seja, a operação de sort foi escrita
em disco, provavelmente esse foi o motivo da performance ser tão ruim, o que podemos tentar fazer é
evitar esse SORT, como? Forçando o JOIN entre os resultados ser executado utilizando o algoritmo de
HASH JOIN, vejamos a diferença:
GO
AS
(
OrdersBig.Value,
CustomersBig.CityID
FROM CustomersBig
M V T e c h | 152
),
AS
(
SELECT
FROM ProductsBig
)
INNER HASH JOIN JoinEntre_ProductsBig_e_Order_DetailsBig
WHERE JoinEntre_CustomersBig_e_OrdersBig.ContactName = 'Karl
Jablonski 1E663869'
'Ravioli Angelo D01AFCFC'
GO
Vejamos a performance:
STATISTICS IO:
M V T e c h | 153
Repare que ainda que tenhamos a presença de um Hash Warning indicando que parte da operação de
hash utilizou tempdb (disco) ainda assim temos performance melhor que a consulta sem bushy join, neste
caso o tempo foi de de 4 segundos.
O que precisamos ter em mente é o seguinte, quanto menos linhas forem retornadas dos joins, melhor
será a performance do bushy plan, se você por exemplo utilizar um filtro de cliente ou produto que não
existe terá uma performance sensacional.
CONCLUSÃO
N OTA IMPORTANTE :
A demonstração acima é meramente ilustrativa, eu não estou dizendo pra você sair utilizando FORCE
ORCER ou qualquer outro hint em todas as consultas do seu ambiente, meu objetivo é te apresentar a
funcionalidade e dizer para usar com consciência, se não entendeu, não use, o efeito do mal uso dessa
técnica ou do uso de qualquer outro hint pode ser desastroso, portanto cuidado.
Bom é isso pessoal, o mundo otimização de consultas é enorme e muitas vezes consistem no processo de
tentativa e erro, porém conhecer bem as alternativas existentes e como o otimizador de consultas
funciona, nos ajuda a minimizar este processo árduo de tentar otimizar um plano.
Espero que você tenha chegado até aqui e gostado do artigo, trabalhei com conceitos importantes do
otimizador de consultas e saiba que nem sempre o resultado real é o que foi estimado.
That’s all folks.
REFERÊNCIAS:
ACM Paper: Left-deep vs. bushy trees: an analysis of strategy spaces and its implications for query
optimization
G. Graefe. The Cascades framework for query optimization. Data Engineering Bulletin, 18(3), 1995.
Microsoft Research: Polynomial Heuristics for Query Optimization
Itzik Ben-Gan: T-SQL Deep Dives: Create Efficient Queries
Benjamin Nevarez: Optimizing Join Orders
Wikipedia: http://en.wikipedia.org/wiki/Query_optimizer
M V T e c h | 154
Sulamita Dantas
www.sulamitadantas.com.br
Policy Based Management
O PBM (Policy Based Management - Gerenciamento Baseado em Política) passou a ser utilizado a partir
da versão do SQL Server 2008, permitindo uma padronização das instâncias, uma vez que nas versões
anteriores, a mesma tinha que ser feita manualmente, ou seja, o BPM permite ao DBA ter o controle do
seu ambiente, aplicando as melhores práticas de organização e segurança, tornando mais fácil o seu
processo de manutenção.
Quando o servidor possui poucas instâncias, tudo bem, dá para o DBA administrar manualmente, mas e
quando são vários servidores e muitas instâncias em cada um deles? Já imaginou o trabalho que o DBA
tem para ter o controle?
Exemplo: se o DBA precisava criar uma rotina com as melhores práticas para saber quais bancos estavam
com o AutoShrink e AutoClose desabilitados, ele tinha quer ir manualmente, e olhar banco por banco nas
instâncias, ou criar scripts enormes para fazer tal verificação.
Através do PBM é possível verificar de imediato quais bancos em uma instância estão com o AutoShrink
e AutoClose desabilitados.
De acordo com Mike Hotek1, O BPM possui alguns conceitos básicos:
Facet - São o objeto básico sobre o qual os padrões são estabelecidos. Definem o tipo de objeto ou opção
a ser verificada, como banco de dados por exemplo.
Condition - São equivalentes a uma cláusula WHERE, que define os critérios que precisam ser verificados.
Policy - É a união da Facet com a Condition
On Change: Prevent - Cria Triggers DDL, para impedir uma alteração que viole a diretiva.
On Change: Log Only - Verifica a diretiva automaticamente quando é feita uma alteração usando a
infraestrutura de notificação de evento.
On Schedule - Cria uma tarefa do SQL Server Agent para verificar a diretiva em um horário definido.
On Demand - Avalia a diretiva quando executada diretamente por um usuário.
1 Hotek, Mike. Kit de treinamento MCTS(Exame 70-432): Microsoft SQL SERVER 2008: Implementação e
manutenção/ Mike Hotek.
M V T e c h | 155
Após entender os conceitos acima, segue abaixo o exemplo: implementar uma política de melhores
práticas para um banco ou vários bancos(AutoShrink e AutoClose desabilitados):
- Abrir Management Studio
- Ao Expandir a aba Management, clique em cima de Condition com o botão direito do mouse, selecione
new condition:
Nos campos abaixo:
Name: coloque o nome da politica
Facet: escolha uma das facetas que deseja usar para criar a política(nesse caso, será a Database).
Expression: nesse campo crie a expressão de acordo com condição desejada.
M V T e c h | 156
Após clicar em ok, já pode verificar que a condição foi criada.
Agora ó próximo passo é criar a policie:
clique com o botão direito do mouse em cima de policie, selecione new policie
M V T e c h | 157
Nos campos abaixo:
M V T e c h | 158
Name: coloque o nome da policie
Check Condition: clique na seta e ache a condição que foi criada.
Against Targets: Selecione Every Database
Evaluation Mode: On Demand
Após clicar em ok, verifique a policie criada
Verificando a política das melhores práticas:
Clicar com o botão do mouse direito em cima da policie criada
Selecionar Evaluate
M V T e c h | 159
Clique na opção view
M V T e c h | 160
Existem várias opções das facets, basta escolher qual deseja e criar!
M V T e c h | 161
Marcelo Fernandes
marcelodba.wordpress.com
Solucionando Problemas: Error Failed to open loopback connection ao
executar SP_READERRORLOG
INTRODUÇÃO
Tenho um ambiente com SQL Server 2008 instalado em um Windows Server 2008 R2 Service Pack 1 em
Cluster, ao executar ao procedure SP_READERRORLOG é exibida uma mensagem de erro Failed to open
loopback connection.
S INTOMA
Ao executar a SP_READERRORLOG o seguinte erro ocorre:
Msg 22004, Level 16, State 1, Line 0
Failed to open loopback connection. Please see event log for more information.
error log location not found
C AUSA
Ao executar o SP_READERRORLOG o SQL Server abre uma conexão com o próprio servidor (loopback) e
neste momento o erro ocorria, para identificar o erro iniciei o ProcessMonitor que pode ser baixado no
site da Microsoft, e ao executar o sp_readerrorlog juntamente com o ProcessMonitor notei o erro abaixo
no ProcessMonitor.
M V T e c h | 162
Observando minha estrutura de cluster, o SQL Server está tentando abrir uma conexão com o nome do
meu recurso de MSDTC.
Sabemos que o SP_READERRORLOG faz uma conexão no loopback, mas por algum motivo recebi uma
tentativa de conexão no nome do recurso de MSDTC (MSDTCP12) do meu cluster, ao observar as
dependências do serviço do SQL observei que o serviço SQL dependia do nome MSDTCP12.
S OLUÇÃO
M V T e c h | 163
Remova a dependência de qualquer recurso name que não seja o nome de sua instância SQL (no meu
caso o nome do DTC)
L EITURAS ADICIONAIS
O Fabricio Catae tem um artigo com o mesmo erro, mas com origens
distintas
http://blogs.msdn.com/b/fcatae/archive/2010/03/03/problema-the-system-detected-apossible-attempt-to-compromise-security-parte-1.aspx
M V T e c h | 164
Error to install SQL Server 2008 on Windows 2012
Hello Friends…
This week I faced an interesting error… My PFE friend Alex Rosa (blog) helped me to fix this problem and
I’m sharing this problem / solution because it might help you.
The environment and Goal
A Windows 2012 R2 on cluster with 2 nodes and my goal was to setup a SQL Server 2008 in cluster.
The problem
Firstly, I must say that since Jul/14 SQL 2K8 is no longer supported, SQL2K8 is in Extended Support.
When SQL Server 2008 was released there wasn’t Windows 2012, so SQL Server was made based on
Windows 2k8, I’m not saying that SQL 2k8 is not supported on Windows 2012, SQL is supported on
Windows 2012. but some functionality were made based on Win2K8.
During the installation of SQL2K8 on Win12 on the first node I faced this error message:
M V T e c h | 165
I do have my Cluster on online status and working well and I ran the cluster validation successfully, but
during the SQL setup I faced a message error saying that my setup couldn’t check my cluster service,
bellow we have part of the detail of the Report Setup Validation:
InstallFailoverClusterGlobalRules: SQL Server 2008 Setup configuration checks for rules group
‘InstallFailoverClusterGlobalRules’
SQLNOD
E1
Cluster_IsOnline
Verifies
that the
cluster
service is
online.
M V T e c h | 166
Faile
d
The
SQL
Server
failover
cluster
services is
not online,
or
the
cluster
cannot be
accessed
from one
of
its
nodes. To
continue,
determine
why
the
cluster is
not online
and rerun
Setup. Do
not rerun
the
rule
because
the
rule
cannot
detect
a
cluster
environme
nt.
SQLNOD
E1
Cluster_SharedDiskF
acet
Checks
whether
the
cluster
on
a
compute
r has at
least one
shared
disk
available
.
Faile
d
The cluster
on
this
computer
does not
have
a
shared disk
available.
To
continue,
at
least
one shared
disk must
be
available.
SQLNOD
E1
Cluster_VerifyForErr
ors
Checks if
the
cluster
has been
verified
and
if
there are
any
errors or
Faile
d
The cluster
either has
not been
verified or
there are
errors or
failures in
the
verification
M V T e c h | 167
failures
reported
in
the
verificati
on
report.
report.
Refer
to
KB953748
or
SQL
Server
Books
Online for
more
informatio
n.
I also tried running the setup from the command line using the SKIP_RULES:
Setup /SkipRules=Cluster_VerifyForErrors /Action=InstallFailoverCluster
And I got the same error…
Looking at the detail of the first error, the message says that the SQL couldn’t verify the cluster service,
the cluster was online but setup couldn’t access my cluster.
I did some research on the web and I found this article:
http://blogs.msdn.com/b/clustering/archive/2012/04/06/10291601.aspx
The author (Rob-MSFT) gave me a clue:
… These are deprecated features (Failover Cluster Command Interface (cluster.exe)
and Failover Cluster Automation Server) in Windows Server 2012 but are made
available, as there are still some applications that may need them, SQL Server being
one of them. Installing it may be necessary for any legacy scripts you have built on
the old Cluster.exe command line interface. …
During the SQL Server 2008 installations the setup tries to check cluster service using a deprecated
feature!
Checking my cluster installations using the articles from Rob I have this:
Get-WindowsFeature RSAT-Cluster*
M V T e c h | 168
These is the features installed by default when we install the Cluster Feature.
The Solution
We just need to enable the Failover Cluster Automation Server, to achieve this you just need to run the
PowerShell command bellow.
Install-WindowsFeature -Name RSAT-Clustering-AutomationServer
After these steps we’ll have success on our setup:
M V T e c h | 169
PS: You need to run these steps on all Cluster nodes.
Regards….
M V T e c h | 170
Token Bloat - Cannot generate SSPI context
Olá amigos, há um tempo atrás enfrente o famoso problema SSPI atípico e sempre adiava este post, bom
finalmente tomei decidi escrever o artigo.
P ROBLEMA
Um usuário sempre conectou ao SQL Server sem problemas, mas um dia ao tentar conectar-se ao mesmo
serviço de SQL ele recebeu a seguinte mensagem:
Não houve nenhuma mudança por parte de infraestrutura e DBAs no servidor, o usuário simplesmente
não consegue conectar mais, e o mais intrigante é que outros usuários conseguem conectar-se e alguns
não.
Bom, na grande maioria das vezes o erro SSPI Context é gerado por falta de SPN em uma tentativa de
conexão via kerberos com o SQL Server e para resolver este problema basta criar o SPN.
Listando os SPN atuais:
No prompt de comando digite o seguinte comando
M V T e c h | 171
SETSPN –L <domínio\conta_de_serviço_do_SQL>
Nota: Se ao executar o comando setspn –L você não receber o SPN para a sua instância de SQL Server,
você deve criar o SPN e você está recebendo o erro de SSPI Context, possivelmente o seu problema será
resolvido com a criação manual do SPN com o seguinte comando:
SETSPN – A MSSQLSvc/fqdn <domínio>\<conta de serviço do SQL>
SETSPN – A MSSQLSvc/fqdn:1433 <domínio>\<conta de serviço do SQL>
Ex. SETSPN –A MSSLSvc/sqlproducao.contoso.com contoso\sqlServiceAcc
Maiores informações no artigo: https://msdn.microsoft.com/pt-br/library/ms191153.aspx
Como podemos observar no resultado do SETSPN –L no meu ambiente eu tenho os SPNs corretamente
criados!
O que justifica algumas conexões conseguirem conectar-se, pois o SPN está ok, e então por que algumas
conexões recebem o SSPI?
Para responder esta questão precisamos analisar o ticket do kerberos, executando a ferramenta tokensz
você poderá evidenciar o problema de token bloat com a seguinte sintaxe
tokensz.exe /compute_tokensize /user:<usuário_com_erro_sspi>
M V T e c h | 172
Como podemos notar na imagem acima, o tamanho máximo do Token é 12000 (12K) e o token do usuário
contoso\usuarioSQL que estou tentando conectar-se ao SQL e estou recebendo o erro SSPI contexto
ultrapassou o limite me 67 Bytes
Um token basicamente contém os grupos e permissões de um usuário e é criado no momento do logon e
este token é repassado aos outros serviços/servidores conforme o usuário necessita autenticar-se para
consumir os serviços (para maiores detalhes sobre kerberos consulte o artigo
https://msdn.microsoft.com/en-us/library/bb742516.aspx)
Pois bem, se em um token temos a ACL (Access control List) vamos investigar os usuários criados:
M V T e c h | 173
Os dois usuários são membros do grupo SQLacesso o qual foi criado o login no SQL Server, mas o segundo
usuário é membro de mais algumas centenas de grupos.
Até o Windows 2008 R2 o tamanho máximo default de um token é de 12K a partir do Windows 2012 este
valor foi alterado para 48K
Dependendo do tamanho de seu ambiente este limite de 12K é facilmente alcançado com um usuário
pertencendo a aproximadamente 150 grupos.
Em uma empresa multinacional onde como boa prática são criados diversos grupos para controlar acessos
a diversos compartilhamentos, servidores, aplicações etc. este limite é alcançado muito rapidamente.
Qual o tamanho de cada grupo?
Para calcular o tamanho do token utilizamos a seguinte formula:
TokenSize = 1200 + 40d + 8s
Onde:
D = (grupos domínio local + grupos universais externos)
S = (grupos globais + Universal)
Existem diversos scripts que automatizam este cálculo, abaixo um bem simples que encontrei no artigo
http://www.cluberti.com/blog/2014/05/26/getting-kerberos-token-size-with-powershell/
# Always credit where due - this was found via
# http://jacob.ludriks.com/getting-kerberos-token-size-with-powershell/
M V T e c h | 174
#Gets max token size
#Run with .\get_tokensize.ps1 -Username "domain\username"
#Reference: http://support.microsoft.com/kb/327825
#tokensize = 1200 + 40d + 8s
Param(
[Parameter(Mandatory=$True)]
[String]$Username
)
$domain = ($username.split("\"))[0]
$user = ($username.split("\"))[1]
Import-Module ActiveDirectory
$rootdse = (Get-ADDomain $domain).distinguishedname
$server = (Get-ADDomain $domain).pdcemulator
$usergroups
=
Get-ADPrincipalGroupMembership
distinguishedname,groupcategory,groupscope,name
-server
$server
$user
|
select
$domainlocal = [int]@($usergroups | where {$_.groupscope -eq "DomainLocal"}).count
$global = [int]@($usergroups | where {$_.groupscope -eq "Global"}).count
$universaloutside = [int]@($usergroups | where {$_.distinguishedname -notlike "*$rootdse" -and
$_.groupscope -eq "Universal"}).count
$universalinside = [int]@($usergroups | where {$_.distinguishedname -like "*$rootdse" -and
$_.groupscope -eq "Universal"}).count
$tokensize = 1200 + (40 * ($domainlocal + $universaloutside)) + (8 * ($global + $universalinside))
Write-Host "
Domain local groups: $domainlocal
Global groups: $global
Universal groups outside the domain: $universaloutside
Universal groups inside the domain: $universalinside
Kerberos token size: $tokensize"
M V T e c h | 175
Outros scripts úteis
http://www.jhouseconsulting.com/2013/12/20/script-to-create-a-kerberos-token-size-report-1041
https://gallery.technet.microsoft.com/scriptcenter/Check-for-MaxTokenSize-520e51e5
C OMO R ESOLVER
Você tem duas maneiras de resolver o problema, aumentando o default do token size ou excluindo grupos
desnecessários.
Para aumentar o token size, você pode seguir as etapas do KB http://support.microsoft.com/kb/938118
E M CADA ESTAÇÃO :
Inicie Regedt32.exe
Localize a chave (HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters)
No menu Edit clique em NEW / DWORD e utilize os parâmetros abaixo:
Nome: MaxTokenSize
tipo: REG_DWORD
Base: Decimal
Valor: 48000
Feche o Editor de Registro
Se executarmos novamente a ferramenta Tokensz teremos o seguinte resultado:
M V T e c h | 176
LEITURAS ADICIONAIS
http://support.microsoft.com/kb/938118
http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-tokenbloat.aspx
http://support.microsoft.com/kb/327825/en-us
http://blogs.technet.com/b/askds/archive/2012/07/27/kerberos-errors-in-network-captures.aspx
http://blogs.technet.com/b/askds/archive/2007/11/02/what-s-in-a-token.aspx
http://blogs.technet.com/b/askds/archive/2012/09/12/maxtokensize-and-windows-8-and-windowsserver-2012.aspx
M V T e c h | 177
Cibelle Castro
cibellecastro.wordpress.com
Auditoria
Descobrindo Auditoria no SQL Server 2008
Abordaremos neste artigo a auditoria em banco de dados, no entanto, antes de falarmos sobre isso, pense
no que a palavra auditoria quer dizer para você. Onde você ouviu falar a primeira vez nessa palavra? Mas
porque todas essas perguntas? O objetivo delas é demonstrar que independente da área que a auditoria
seja implementada, todas desejam um mecanismo para ajudar a descobrir algo sobre alguém, alguma
coisa, alguma ação, nos mostrar que tentaram entrar no sistema, enfim dar segurança aos nossos dados.
Qual DBA nunca se deparou com a seguinte situação: “Ahhhhhh alguém tirou as minhas permissões!” ou
“Quero saber quem alterou a stored procedure que eu fiz, semana passada ela estava funcionando”, ou
qualquer relação que necessitamos rastrear as alterações que foram feitas nos dados. Quem fez, quando
fez e o que foi modificado? Dependendo da empresa, será primordial ter uma auditoria implementada,
seja ela exigida pelo ramo do negócio ou por determinação da lei.
Antes do SQL Server 2008, era necessário utilizar diversos recursos para fazer todo o conjunto de auditoria
para uma instância. Usávamos as triggers DDL como o próprio nome diz faziam a auditoria de alterações
DDL, as triggers DML faziam a auditoria dos dados modificados em tabelas ou views, tinha a opção de usar
o SQL Trace fazia a auditoria de instruções SELECT ou ainda algumas ferramentas de terceiros.
O SQL Server 2008 possui uma ferramenta excelente, o SQL Server Audit combina todos os recursos de
auditoria.
P OR QUE UTILIZAR AUDI TORIA ?
Você poderia estar se perguntando: quais as vantagens de implementar auditoria do SQL Server no meu
ambiente? SQL Server Audit possui várias características e benefícios, dentre elas:
Auditoria em nível de instância e banco de dados;
Auditoria de atividades;
Capacidade de capturar e exibir os resultados da auditoria;
Alta granularidade;
Leve e rápido;
Facilidade de configurar e administrar;
Mais complexo e mais fácil que utilizar triggers;
M V T e c h | 178
Facilidades através do SSMS;
P ODE SER FEITO ATRAVÉS DE S CRIPTS .
N OTA 01:
O SQL Server Audit utiliza Extended Events Engine para capturar os dados da auditoria. Isso resulta em
um rápido desempenho e sobrecarga mínima em comparação ao uso de SQL Trace para capturar esse
tipo de atividade.
C OMO O SQL S ERVER A UDIT TRABALHA ?
Nesta seção, vamos ver uma visão geral de como funciona o SQL Server Audit. O fluxograma mostrado na
Figura 1 deve fornecer uma visão ampla do que está envolvido na criação de auditoria.
Figura 01. Fluxograma que mostra como criar uma nova auditoria de servidor SQL
A auditoria do SQL Server permite que você crie várias auditorias diferentes, atendendo a maior parte
todas das atividades que ocorre dentro do SQL Server.
Existem quatro principais objetos para se configurar a auditoria, Server Audit Object, Target, Server Audit
Specification e o Database Audit Specification, vamos detalhar um pouco mais sobre cada item:
O primeiro passo ao criar uma nova auditoria em uma instância do SQL Server 2008 é criar um SQL Server
Audit Object, que é responsável por coletar e agrupar as ações que serão monitoradas.
M V T e c h | 179
Quando você cria um SQL Server Audit Object, deve-se atribuir um nome, selecionar as opções de
configuração, e dizer qual é o TARGET.
O TARGET é o local onde os dados de auditoria serão armazenados que pode ser um arquivo no disco
(audit file), o log de aplicações do Windows (Application EVENT LOG) ou no log de segurança do Windows
(Security EVENT LOG). Se a forma de armazenamento escolhida for “audit file”, você poderá escolher a
pasta onde esses arquivos serão gerados e poderá especificar o tamanho máximo de um arquivo. Além
disso, é possível alocar previamente espaço em disco para o log de auditoria, em vez de fazer o arquivo
crescer à medida que as linhas de auditoria são adicionadas.
Quando o Application ou o Security Log são especificados, as únicas opções disponíveis para configuração
são:
Queue Delay: quantidade de tempo em milissegundos que os eventos são armazenados antes de serem
armazenados. Para permitir que a entrega de eventos seja síncrona, você deve preencher esse campo
com “0” (QUEUE_DELAY = 0). O valor default é “1000”, o que equivale a 1 segundo. Se especificar um
tempo de atraso, os registros de auditoria poderão ser acumulados, mas mesmo assim deverão ser
gravados dentro do intervalo especificado;
Shutdown on Failure: A ação ON_FAILURE controla como a instância se comporta se os registros de
auditoria não podem ser gravados. A opção default é CONTINUE, a qual permite que a instância continue
a execução e processe as transações. Caso você altere o valor para SHUTDOWN, a instância será encerrada
se os eventos de auditoria não puderem ser escritos no target.
Sintaxe Server Audit:
CREATE SERVER AUDIT audit_name
{
TO { [ FILE (<file_options> [ , ...n ]) ] | APPLICATION_LOG |
SECURITY_LOG }
[ WITH ( <audit_options> [ , ...n ] ) ]
}
[ ; ]
<file_options>::=
{
FILEPATH = 'os_file_path'
[ , MAXSIZE = { max_size { MB | GB | TB } | UNLIMITED } ]
[ , MAX_ROLLOVER_FILES = { integer | UNLIMITED } ]
[ , RESERVE_DISK_SPACE = { ON | OFF } ]
}
<audit_options>::=
{
[ QUEUE_DELAY = integer ]
[ , ON_FAILURE = { CONTINUE | SHUTDOWN } ]
M V T e c h | 180
[ , AUDIT_GUID = uniqueidentifier ]
}
Se você prestar atenção na sintaxe, perceberá que pode ser facilmente configurado.
N OTA 02:
Não é possível escrever no log de segurança no Windows XP;
Um objeto de auditoria sempre inicia desabilitado;
O log de segurança pode ser integrado com o ACS (AUDIT COLLECTION SERVICES) do System Center
Operations Manager 2007;
Qualquer usuário autenticado pode ler/escrever no log de aplicações do Windows. Este log requer menos
permissões e é menos seguro que o log de segurança do Windows.
O segundo passo é criar o que é chamado de Audit Specification. A auditoria do SQL Server oferece dois
tipos diferentes de especificações de auditoria:
SERVER AUDIT SPECIFICATIONS;
DATABASE AUDIT SPECIFICATIONS;
Server e Database Audit Specification são criados de forma diferente. Vamos conhecer um pouco mais o
conceito de cada um desses tipos.
SERVER AUDIT SPECIFICATIONS
Define os grupos de ações (action groups) que ocorrem no nível de instância do SQL Server e os agrupa
em “audit action groups”. Por exemplo, podem ser usados quando você deseja auditar uma atividade, tais
como login, logout, alterações de senhas, quando um comando de backup ou restore é disparada dentre
outas coisas .
Existe um relacionamento um-para-um entre o Server Audit Specification Object e o Server Audit Object.
A regra é simples um SQL Server Audit Object só pode ser associado com um Audit Specification porque
ambos são criados no escopo da instância do SQL Server.
As ações auditadas são enviadas para o SQL Server Audit que grava essas ações no TARGET. Na tabela 01
estão descritos os audit actions groups.
Action Group Name
M V T e c h | 181
APPLICATION_ROLE_CHANGE_PASSWORD_GROUP
AUDIT_CHANGE_GROUP
BACKUP_RESTORE_GROUP
BROKER_LOGIN_GROUP
DATABASE_CHANGE_GROUP
DATABASE_MIRRORING_LOGIN_GROUP
DATABASE_OBJECT_ACCESS_GROUP
DATABASE_OBJECT_CHANGE_GROUP
DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP
DATABASE_OBJECT_PERMISSION_CHANGE_GROUP
DATABASE_OPERATION_GROUP
DATABASE_OWNERSHIP_CHANGE_GROUP
DATABASE_PERMISSION_CHANGE_GROUP
DATABASE_PRINCIPAL_CHANGE_GROUP
DATABASE_PRINCIPAL_IMPERSONATION_GROUP
DATABASE_ROLE_MEMBER_CHANGE_GROUP
DBCC_GROUP
FAILED_LOGIN_GROUP
FULLTEXT_GROUP
LOGIN_CHANGE_PASSWORD_GROUP
LOGOUT_GROUP
SCHEMA_OBJECT_ACCESS_GROUP
SCHEMA_OBJECT_CHANGE_GROUP
SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP
SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP
SERVER_OBJECT_CHANGE_GROUP
SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP
M V T e c h | 182
SERVER_OBJECT_PERMISSION_CHANGE_GROUP
SERVER_OPERATION_GROUP
SERVER_PERMISSION_CHANGE_GROUP
SERVER_PRINCIPAL_CHANGE_GROUP
SERVER_PRINCIPAL_IMPERSONATION_GROUP
SERVER_ROLE_MEMBER_CHANGE_GROUP
SERVER_STATE_CHANGE_GROUP
SUCCESSFUL_LOGIN_GROUP
TRACE_CHANGE_GROUP
Tabela 01 – Audit Action Groups. Fonte: http://technet.microsoft.com/en-us/library/cc280663.aspx
Podemos obter o resultado da Tabela 01 fazendo uma consulta na DMV sys.dm_audit_actions.
SELECT
--Action_in_log -> Indica se uma ação pode ser gravada em
um log de auditoria. Os valores são os seguintes: 1 = Sim e 0 =
Não
Action_in_log,
--Name -> Nome da ação de auditoria ou do grupo de ações de
auditoria. Não pode ser nulo.
Name
FROM
Sys.dm_audit_actions
WHERE
-- Class_desc -> O nome da classe do objeto ao qual a ação
de auditoria aplica-se
Class_desc ='SERVER'
-- Configuration_level ->Indica que a ação ou o grupo de
ações especificado nessa linha são configuráveis no nível do
Grupo ou da Ação
AND Configuration_level ='Group'
ORDER BY
Name
Ao criar qualquer tipo de Audit Specification (Nota 02), você primeiro atribuir-lhe um nome e associa o
Audit Specification com o SQL Server Audit Object criado na primeira etapa. O último passo para criação
de uma especificação de auditoria de servidor é atribuir-lhe um Audit Action type que nada mais é do que
uma atividade pré-definida que acontece dentro do SQL Server e podem ser auditadas.
M V T e c h | 183
N OTA 03:
Sintaxe para criar um Server Audit Specification por T-SQL:
CREATE SERVER AUDIT SPECIFICATION audit_specification_name
FOR SERVER AUDIT audit_name
{
{ ADD ( { audit_action_group_name } )
} [, ...n]
[ WITH ( STATE = { ON | OFF } ) ]
}
[ ; ]
DATABASE AUDIT SPECIFICATIONS
Usado quando você deseja auditar uma atividade dentro de um banco de dados, como quem está
selecionando dados de uma tabela particular.
A regra é a cada Database Audit Specification pode ser associado a apenas um Server Audit Object.
Entretanto um Server Audit Object pode ser associado a apenas um Database Audit Specification por
banco de dados. Ou seja, você pode criar múltiplos Database Audit Speficications por banco de dados
desde que cada um use um Server Audit Object separado. Veja Figura 02.
M V T e c h | 184
Figura 02. Descrição geral de auditoria.
No nível de instância, você pode especificar um ou mais Audit Action Group (para Database Audit
Specification você pode especificar ações de auditoria individual e filtros também).
Na tabela 02 estão descritos as ações ou grupos de ação que podem ser configurados.
Action Name
Action Group Name
DELETE
APPLICATION_ROLE_CHANGE_PASSWORD_GROUP
EXECUTE
AUDIT_CHANGE_GROUP
INSERT
BACKUP_RESTORE_GROUP
RECEIVE
DATABASE_CHANGE_GROUP
REFERENCES
DATABASE_OBJECT_ACCESS_GROUP
SELECT
DATABASE_OBJECT_CHANGE_GROUP
UPDATE
DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP
DATABASE_OBJECT_PERMISSION_CHANGE_GROUP
DATABASE_OPERATION_GROUP
DATABASE_OWNERSHIP_CHANGE_GROUP
DATABASE_PERMISSION_CHANGE_GROUP
DATABASE_PRINCIPAL_CHANGE_GROUP
DATABASE_PRINCIPAL_IMPERSONATION_GROUP
DATABASE_ROLE_MEMBER_CHANGE_GROUP
DBCC_GROUP
SCHEMA_OBJECT_ACCESS_GROUP
SCHEMA_OBJECT_CHANGE_GROUP
SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP
SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP
Tabela 02. Fonte: http://technet.microsoft.com/en-us/library/cc280663.aspx
M V T e c h | 185
Neste objeto podemos coletar dados como DELETE, INSERT, SELECT, UPDATE, EXECUTE, DBCC_GROUP
etc. Para visualizarmos todos os objetos descritos na Tabela 02, basta fazermos uma pesquisa na DMV
sys.dm_audit_actions.
SELECT
--Action_in_log -> Indica se uma ação pode ser gravada em
um log de auditoria. Os valores são os seguintes: 1 = Sim e 0 =
Não
Action_in_log,
--Name -> Nome da ação de auditoria ou do grupo de ações de
auditoria. Não pode ser nulo.
Name
FROM
sys.dm_audit_actions
WHERE
-- Class_desc -> O nome da classe do objeto ao qual a ação
de auditoria aplica-se
class_desc='DATABASE'
-- Configuration_level ->Indica que a ação ou o grupo de
ações especificado nessa linha são configuráveis no nível do
Grupo ou da Ação
AND configuration_level IN ('Action','Group')
ORDER BY name
Ao criar uma especificação de auditoria de banco de dados, você atribui um nome, então associa ao Audit
Specification com o SQL Server Audit Object e especifica o Audit Action Type como foi feito com o Server
Audit Specification. No entanto, além disso, deve-se especificar o Object Class (database, object ou
schema), o nome do objeto auditado e o security principal (ou seja, quem nós vamos auditar).
Uma vez que o Audit Specification for concluído, você deve habilitar o SQL Server Audit Object e o Audit
Specification. Apartir daí os eventos de auditoria começarão a ser coletados para o target designado.
N OTA 03:
Sintaxe para criar um Database Audit Specification por linha de comando:
CREATE DATABASE AUDIT SPECIFICATION audit_specification_name
{
FOR SERVER AUDIT audit_name
[ { ADD ( { <audit_action_specification> |
audit_action_group_name } )
M V T e c h | 186
} [, ...n] ]
[ WITH ( STATE = { ON | OFF } ) ]
}
[ ; ]
<audit_action_specification>::=
{
action [ ,...n ]ON [ class :: ] securable BY principal [
,...n ]
}
P ASSA A P ASSO DE COMO CRIAR U MA A UDITORIA .
Nesse exemplo vamos configurar os três targets disponíveis para configurar o Server Audit Objects. Iremos
demostrar como fazer isso logo abaixo:
a) O primeiro target que criaremos será Windows Application Event Log. Abra o Management Studio vá
em: Security/ Audits/New Audit. Veja Figura 03.
M V T e c h | 187
Figura
03.
Criação auditoria
A primeira coisa que você precisa fazer é atribuir o nome ou usar o nome que é gerado automaticamente.
Preencha a opção Audit Name(aconselho a colocar um nome intuitivo para que possa identificar do que
se trata), no nosso caso estou colocando o nome do target mais a forma que ele esta sendo criado. Ou
seja, ApplicationLog + SSMS = ApplicationLog SSMS . Veja Figura 04.
M V T e c h | 188
Figura 04. Configuração parâmetros de auditoria.
Nesse exemplo estamos configurando o Queue delay para 3000 milissegundos. Na Tabela 03 descreve
todos os parâmetros existentes na Figura 04.
Parâmetros
Descrição
Queue Delay
E informado o valor que indica de quanto em quanto tempo será
descarregado antes das ações de auditoria serem processadas.
M V T e c h | 189
Se essa opção for selecionada e exista uma tentativa de escrever no
Shut down Server on
arquivo de auditoria e ocorrer uma falha ele vai parar o serviço,
audit log failure
evitando assim falhas na auditoria.
Você pode salvar eventos capturados a qualquer um dos seguintes
destinos
Audit Destination
*File
*Application_Log
*Security_Log
File Path
Se o Audit Destination escolhido foi à opção FILE, então você precisa
fornecer o caminho onde os arquivos de auditoria serão salvos.
Maximum Rollover
E informado o numero de arquivos que vão ser gerados.
Maximum File Size
Especifica o tamanho máximo de espaço em disco reservado para cada
arquivo gerado para auditoria. Você pode escolher o botão que
especifica a capacidade em MB, GB, TB ou a opção Unlimited(tome
bastante cuidado ao escolher essa alternativa).
Reserve Disk Space
Ativando essa opção você ira reservar todo espaço em disco rígido
M V T e c h | 190
Na opção Audit Destination selecione “Application Log”. Ao fazer isso os outros parâmetros ficaram
indisponíveis. Clique em OK. Veja Figura 05.
Figura 05. Escolha do Audit destination.
Por default o Server Audit Object é criado desabilitado. Para habilita-lo basta clicar com o botão direito
do mouse em ApplicationLogSSMS e selecionar a opção “Enable Audit”. Veja Figura 06.
M V T e c h | 191
Figura 06. Habilitar Server Audit Object
Para criar o mesmo Server Audit demostrado acima usando T-SQL basta executar os comandos abaixo:
CREATE SERVER AUDIT [TargetApplicationLogTSQL]
TO APPLICATION_LOG
WITH
(
QUEUE_DELAY = 3000,
ON_FAILURE = CONTINUE
)
GO
O parâmetro ON_FAILURE só pode ser configurado para aqueles logins que possuem permissão
SHUTDOWN. Se o usuário que esta tentando executar esse comando não tiver essa permissão, a função
irá falhar com uma mensagem MSG_NO_SHUTDOWN_PERMISSION.
O segundo objeto que vamos configurar é para o Target FILE. Existem algumas opções adicionais que pode
ser especificada. Incluindo qual a pasta que os arquivos de auditoria serão gerados, o número máximo de
rollover files(Esse parâmetro é avaliado sempre que a auditoria é reiniciada ou quando um novo arquivo
é necessário porque o MAXSIZE foi atingido. Se o número de arquivos excede o MAX_ROLLOVER_FILES o
arquivos mais antigo é deletado), o tamanho máximo de cada arquivo e se é para reservar espaço em
disco para o audit file(arquivo de auditoria).
M V T e c h | 192
F AREMOS ESSAS CONFIGU RAÇÕES DO S ERVER A UDIT ATRAVÉS DE TSQL E O M ANAGEMENT S TUDIO .
Faça os passos descritos no item “1a”.
Vamos atribui um nome para opção “Audit name”. No nosso caso o nome será: TargetFileSSMS. Veja
Figura 07.
Figura 07. Atribuição do Audit Name .
Por causa do aumento da latência, devido à rede pode ser necessário aumentar o parâmetro
QUEUE_DELAY para evitar afetar a instância. Colocaremos essa opção como 2000 milissegundos.
Próximo passo será configurar o Audit Destination. Selecione a opção FILE.
No parâmetro “File path” devemos dizer o nome da pasta onde serão armazenados os arquivos da
auditoria. Neste exemplo estamos especificando a pasta de destino para C: \ Auditoria \.
Em MAX_ROLLOVER_FILES digite 3. Pois será o numero máximo de arquivos gerados.
Desabilite o check na opção “Unlimited” do parâmetro “Maximum file size”. Preencha esse campo com
número 3 e deixe selecionado o tamanho MB (megabyte).
Por fim, habite “Reserve disk space”. Veja na Figura 08 como ficaram todas as configurações.
M V T e c h | 193
Clique no botão OK.
Pronto! O Server Audit foi criado com sucesso. Você estar se perguntando: Como posso criar o mesmo
objeto através de comandos TSQL? Veja logo abaixo o script:
USE master
GO
CREATE SERVER AUDIT TargetFileTSQL
TO FILE
(
M V T e c h | 194
FILEPATH = N'C:\Auditoria',
/*MAXSIZE = Especifica o tamanho máximo para o qual o
arquivo de auditoria pode crescer*/
MAXSIZE = 3MB,
/*MAX_ROLLOVER_FILES = Número máximo de arquivos que pode
ser criados. O valor padrão é UNLIMITED. Lembrando que esse valor
deve ser um número inteiro. Portanto o valor UNLIMITED = 0.*/
MAX_ROLLOVER_FILES = 3,
/*RESERVE_DISK_SPACE = Esta opção de pré-aloca o arquivo no
disco para o valor definifo no MAXSIZE. Aplica-se somente se
MAXSIZE não é igual a UNLIMITED. O valor padrão é OFF*/
RESERVE_DISK_SPACE = ON
)
WITH
(
QUEUE_DELAY = 1000,
)
Para visualizarmos os objetos criados (Veja Figura 09) basta utilizar o seguinte consulta:
/*OBJETOS DE AUDITORIA CRIADOS*/
SELECT * FROM SYS.server_audits
Figura 09. Resultado da consulta em sys.server_audits.
Observe que na coluna type_desc descreve o tipo do target de cada Server Audit.
Por fim o terceiro e último Target Windows Security Event Log. Antes de começamos a demonstrar como
faremos a criação desse objeto, será necessário efetuarmos algumas configurações no Windows a fim de
permitir que o SQL Server possa gravar eventos no Security Event Log. O servidor utilizado nessa
demonstração é o Windows Server 2008).
Primeiro clicamos no botão Iniciar \Executar\secpol.msc. Veja Figura 10.
M V T e c h | 195
Figura 10.
Clique em Local Polices\ Audit Policy. Com o botão direito do mouse selecione Audit object access\
Properties. Marque as opções: Success e Failure. Estamos permitindo o acesso ao objeto de auditoria em
casos de sucesso e falha. Veja Figura 11.
Figura 11. Propriedades de acesso ao objeto de auditoria
Precisamos atribuir direito de gerar Security Audits para a conta de serviço do SQL Server. Caso você não
lembre ou não saiba qual usuário esta inicializando o SQL Server basta ir em Iniciar \Microsoft SQL Server
2008 R2 \ Configuration Tools \ SQL Server Configuration Maganer. Selecione o serviço com o botão
direito e clique em Propriedades. Na aba Logon verifique a conta que está configurada o MSSQLSERVER.
Veja Figura 12.
M V T e c h | 196
Figura 12. Parando o Serviço do SQL Server atraves do Configuration Manager.
Depois de descoberto o usuário vamos finalmente atribuir a permissão para ele. Selecione User Rights
Assignment \ Generate security audits. Clique no botão Add User or Group e adicione o usuário
configurado na conta de serviço do SQL Server. Veja Figura 13.
M V T e c h | 197
Figura 13. Adicionando usuário da conta de serviço do SQL.
Uma vez que estas duas alterações foram feitas, reinicie o serviço do SQL Server e então você vai ser capaz
de criar um Server Audit no Windows Security Log. Observe que as opções definidas aqui podem muito
bem serem efetuadas via Group Policy direto no servidor de domínio. Esse tipo de configuração deve ser
discutido com os responsáveis pelo gerenciamento das Politicas de Segurança do Servidor e assim garantir
que os ajustes necessários sejam colocados em vigor para que o SQL Server seja capaz de gravar eventos
no Security Log.
Para criar o Server Audit faça os passos descritos no item “1a”.
Atribua um nome no campo “Audit Name”. O nome que adotaremos será TargetSecurityLogSSMS.
Por default a opção “Queue delay in milliseconds” é preenchida com o valor 1000. Vamos alterar esse
valor para 2000.
Na opção “Audit destination” selecione Security Log. Perceba que as outras opções de configuração são
desabilitadas assim que escolhemos essa opção. Veja Figura 14.
M V T e c h | 198
Figura 14. Configuração Audit destination.
Caso tenha interesse em criar esse mesmo Server Audit através de comandos TSQL faça conforme script
abaixo:
CREATE SERVER AUDIT TargetSecurityLogTSQL
TO SECURITY_LOG
WITH
(
QUEUE_DELAY = 2000,
)
GO
M V T e c h | 199
Como vimos nos exemplos acima, é extremamente simples criar Server Audit Objects no SQL Server 2008
usando TSQL ou SSMS.
C RIANDO UM S ERVER OU S ERVER A UDIT S PECIFICATION .
Agora que criamos o nosso Server Audit Objects precisamos adicionar especificação de auditoria
correspondente. Se quisermos fazer uma auditoria no nível de instância, teremos que criar um Server
Audit Specification. Vamos auditar toda vez que for gerado um backup ou restore no servidor. O nome do
Action Group utilizado nesse exemplo será BACKUP_RESTORE_GROUP.
Vamos criar o Server Audit Specification. Abra o SSMS vá em Security \Server Audit Specification \New
Server Audit Specification.. Veja Figura 15.
Figura 15. Criação do Server Audit Specification.
Preencha o campo “Name”, nesse exemplo coloquei o nome da especificação de auditoria + action group
= ServerAuditSpecificationBackupRestore. . Estou fazendo isso para facilitar o entendimento de que esta
administrando o servidor de banco de dados, ou seja, nós mesmos.
Na opção “Audit” devemos preencher com um dos Server Audit Objects criado anteriormente. Nesse caso
vou querer armazenar os dados auditados no Application Log. Selecione a opção
“TargetApplicationLogTSQL”. Veja Figura 16.
M V T e c h | 200
Figura 16.
No campo Action \Audit Action Type, selecione BACKUP_RESTORE_GROUP. Ao fazer isso as outras opções
de configuração seram desabilitadas. Clique no botão OK. Veja Figura 17.
M V T e c h | 201
Agora vamos habilitar o Server Audit Specification criado, para iniciarmos a coleta dos dados. Podemos
fazer de duas maneiras, clicando com o botão direito em cima do objeto adicionado e selecionando a
opção “Enable Server Audit Specification”, ou via TSQL. Veja Figura 18.
M V T e c h | 202
Figura 18.
Se fosse através de consulta o script ficaria dessa maneira:
ALTER SERVER AUDIT SPECIFICATION
[ServerAuditSpecificationBackupRestore]
WITH (STATE = ON)
GO
Os scripts da Listagem 01 cria um banco de dados, uma tabela, faz a inserção dos dados e por fim faz o
backup e um restore para vermos se os dados realmente estão sendo auditados.
M V T e c h | 203
--CRIAR BANCO DE DADOS AUDITORIA
IF (SELECT DB_ID ('AUDITORIA')) IS NULL
BEGIN
CREATE DATABASE AUDITORIA
END
GO
--CRIAR TABELA
CREATE TABLE TABServerSpecification
(ID
Int Identity(1,1) PRIMARY KEY,
Nome VarChar(250)DEFAULT NewID())
INSERT INTO TABServerSpecification DEFAULT VALUES
GO 10000
--FAZER BACKUP DO BANCO AUDITORIA
BACKUP DATABASE Auditoria
TO DISK = 'C:\Auditoria\Auditoria.bak'
WITH FORMAT;
GO
-- DROP NO BANCO AUDITORIA
DROP DATABASE AUDITORIA
--RETORE BANCO DE DADOS AUDITORIA
RESTORE DATABASE AUDITORIA
FROM DISK = 'C:\Auditoria\Auditoria.bak'
WITH RECOVERY
GO
Vamos verificar se o que acabamos de fazer foi realmente auditado, para isso selecione a guia
Management \SQL Server Logs \ View SQL Server Log. Veja Figura 19.
M V T e c h | 204
Figura 19. Visualização do Log
Selecione a seguinte opção: Windows NT \ Application . Veja Figura 20.
M V T e c h | 205
Figura 20. Dados auditados
Verifique que todas as linhas que possuem uma chave foram os dados auditados, no nosso caso o backup
e o restore que fizemos.
C RIANDO UM S ERVER OU D ATABASE A UDIT S PECIFICATION .
Nos próximo exemplo vamos criar um Database Audit Specification. O objetivo dessa auditoria será
auditar a utilização das clausulas SELECT, INSERT, UPDATE e DELETE em duas tabelas de um único banco
de dados. Você precisará do AdventureWorks instalado, para isso baixa baixar no site do Codeplex
(http://msftdbprodsamples.codeplex.com/releases/view/55926).
A primeira tarefa é criarmos um Server Audit, como nós já criamos na etapa 2b. Utilizaremos mesmo
quando for solicitado.
Para criar um Database Audit Specification você deve escolher o banco de dados que deseja fazer a
auditoria. No nosso caso será o AdventureWorks. Clique com o botão direito em “Database Audit
Specification” e selecione “New Audit Specification”, como mostrado na Figura 21.
M V T e c h | 206
Figura 21. Criar Novo Database Audit Specification.
Na janela “Create Database Audit Specification” você pode aceitar o nome sugerido ou caso queira pode
digitar seu próprio nome. Adotaremos o seguinte:
Em seguida selecione a partir da caixa suspensa o Server Audit Object que armazenaremos os dados da
auditoria. Dessa vez vamos armazenar os dados da auditoria em um arquivo, utilizaremos o Server Audit
Object criado anteriormente. Selecione o Target TargetFileSSMS. Veja Figura 22.
M V T e c h | 207
Figura 22.
Na seção “Audit Action Types”, você deve especificar o tipo de ação de auditoria que deseja capturar. No
primeiro combo selecione a opção SELECT, com o objetivo de gravar toda atividade do comando SELECT
para a tabela Veja Figura 23.
M V T e c h | 208
Figura 23.
Agora devemos escolher “Object Class”. Vamos auditar mais de uma tabela de um banco especifico então
selecione a segunda opção dessa coluna, ou seja, OBJECT.
Devemos selecionar qual o OBJECT será auditado, para isto clique no botão “…” da coluna Object Name.
Veja Figura 24.
M V T e c h | 209
Figura 24.
Na janela “Select Objects” clique no botão “Browse…”
Escolha as tabelas que serão monitoradas do banco AdventureWorks. Selecione as seguintes tabelas:
HumanResources.Employee, Person.Contact, Production.Location e Production.UnitMeasure. Clique no
botão OK (Observe que temos a opção de escolher mais de um database).
A próxima etapa será escolher o “Principal Name”, ou seja, qual o usuário que queremos auditar. Nessa
opção podemos selecionar Users e Roles. Para fazer isso, clique no botão “...” da coluna “Principal Name”
e na janela “Select Objects” clique no botão “Browser..”. Agora você pode ver quais “Principals” pode
escolher, nesse caso nos vamos escolher “ public” , pois o objetivo dessa auditoria é identificar qualquer
pessoas que execute a cláusula SELECT na tabela xx , como mostrado na figura 25.
M V T e c h | 210
Figura 25.
Concluímos o nosso primeiro filtro, vamos repetir as operações descritas acima para os comandos INSERT,
UPDATE e DELETE. Veja Figura 26.
Clique em OK para concluirmos a criação do Database Audit Specification.
Assim como Server Audit Specification a especificação de banco de dados é criado desabilitado, se você
observe vera que ele tem uma seta vermelha indicando que esta desativada, para habilita-la clique sobre
o mesmo como botão direito e escolha a opção “Enable Database Audit Specification”.
Agora vamos selecionar excluir, inserir e atualizar alguns registros das tabelas que estamos auditando
para ver se tudo aquilo que configuramos esta funcionando conforme o esperado. Execute os scripts da
Listagem 02.
--AUDITANDO COMANDO SELECT
USE AdventureWorks;
Select
P.FirstName + ' ' + C.LastName AS 'Nome’,
M V T e c h | 211
E.VacationHours AS 'Férias (horas)',
E.SickLeaveHours AS 'Afastamento por motivo de doença
(horas)',
E.LoginID AS 'Login'
FROM HumanResources.Employee E LEFT JOIN Person.Contact C ON
E.ContactID = C.ContactID
ORDER BY [Nome Completo];
--AUDITANDO COMANDO SELECT
select * from Production.Location
--AUDITANDO COMANDO UPDATE
Update Person.Contact
Set FirstName = 'Cibelle',
emailAddress =
'[email protected]'
Where ContactID = 6
--AUDITANDO COMANDO DELETE
DELETE FROM Production.UnitMeasure WHERE Name = 'Boxes'
--AUDITANDO COMANDO INSERT
INSERT INTO Production.Location
Magazine',0.00,0.00,GETDATE())
VALUES ('SQL
Os dados foram armazenadados em um arquivo que foi gerado na pasta C:\Auditoria. Veja Figura 27.
Figura 27. Arquivo de auditoria gerado em um file.
Vamos vizualizar os dados auditados utilizando a função fn_get_audit_file, que é responsável em retornar
as informações de um arquivo de auditoria. Execute o script da Listagem 03.
M V T e c h | 212
/*Retorna informações de um arquivo de auditoria
Sintaxe:
fn_get_audit_file ( file_pattern, {default | initial_file_name |
NULL }, {default | audit_file_offset | NULL } )
*/
SELECT
convert(varchar(10),event_time,103) as [Data], --Data e
hora em que a ação auditável é acionada
convert(varchar(12),event_time,114) as [Hora], --Data e
hora em que a ação auditável é acionada
server_instance_name as [Nome Instância], --Nome da
instância de servidor no qual a auditoria ocorreu
database_name as [Nome do Banco], --O contexto do banco de
dados no qual a ação aconteceu. Permite valor nulo. Retorna NULL
para auditorias realizadas no nível de servidor.
server_principal_name as [Login], --Logon atual. Permite
valor nulo
object_name, --O nome da entidade na qual a auditoria
ocorreu.
statement as [Consulta Executada],
file_name as [Caminho do Arquivo]
FROM
fn_get_audit_file('C:\Auditoria\TargetFileSSMS_D59592D14057-49EB-A421CF2DF6BB2F47_0_129603920978160000.sqlaudit',DEFAULT,DEFAULT)
CONCLUSÃO
Uma parte essencial de qualquer estratégia de segurança de dados é um plano de segurança que possui
regras com a capacidade de rastrear quem acessou ou tentou acessar dados, mas para ter essas
informações precisamos realizar auditorias regulamente. Isso permite ao DBA a capacidade de detectar
prevenir qualquer ação maliciosa, acessos ilegítimos.
Vimos no decorrer do artigo como criar uma auditoria nos mais diversos seguimentos, vimos também que
o SQL Server Audit é uma ferramenta poderosa que os DBA’s podem utilizar para coletar quase todas as
atividades que acontece dentro dos nossos servidores ou banco de dados ou um objeto especifico.
REFERÊNCIAS
Compreendendo a auditoria do SQL Server
http://msdn.microsoft.com/pt-br/library/cc280386.aspx
Como criar uma auditoria no nível do banco de dados
M V T e c h | 213
Como criar uma auditoria do nível de servidor
Auditing in SQL Server 2008
http://msdn.microsoft.com/en-us/library/dd392015(v=sql.100).aspx
sys.server_audits (Transact-SQL)
M V T e c h | 214
Performance e Desempenho
System Monitor & SQL Profiler
É muito comum nos dias de hoje enfrentarmos problemas com desempenho no trabalho ou até mesmo
no conforto de nossa casa. Você pode está se perguntando como assim? Imagine a seguinte situação:
Uma turma de amigos resolveu marcar um encontro on-line para disputar aquele jogo que acabou de ser
lançado. Caso você não tenha uma boa placa de vídeo, memória e um processador mais ou menos a
reuniãozinha vai ter que ficar para outro dia. Pois o jogo vai ficar lento, a imagem no seu monitor vai ficar
renderizando dentre outas coisas.
Falando no mundo do banco de dados, infelizmente vivemos sujeitos a falhas de hardware, bloqueio de
transações, paginação, dentre outras coisas que acarretam na degradação das nossas aplicações.
Resumindo isso tudo que eu disse é exatamente quando o Service Desk da sua empresa recebe aquelas
ligações: “O meu sistema não abre nada!!”, “Tá muito lento não consigo trabalhar” ou melhor “A culpa é
da TI”.
Diante dessa situação, vou abordar nesse artigo como monitorar seu ambiente de SQL Server e a
diagnosticar tais problemas através de estudo de caso prático. O desafio é reunir o System Monitor com
o SQL Profiler de uma maneira coerente que nos permita fazer uma análise eficiente.
Vou criar um cenário fictício a fim de ajudar na compreensão dos conceitos. Imaginemos que somos
funcionários da AdventureWorks e parte das atribuições destinas a nós dentro da empresa, inclui ficarmos
encarregados de monitorar o ambiente de produção. Ou seja, verificar o desempenho do banco de dados
como um todo. Por exemplo: Analisar se está tendo I/O no disco, como está o processador ou a memória
do servidor, quantas conexões estão ativas, e assim por diante.
Ultimamente nosso atendimento nível 01 está recebendo muitas ligações reportando problemas de
lentidão com as aplicações. Resolvemos então investigar o motivo dessas reclamações.
O QUE É O S YSTEM M ONITOR ?
A primeira coisa que vamos fazer é utilizar o System Monitor, para coletar as informações do servidor de
banco de dados.
O System Monitor mostra graficamente os dados em tempo real de desempenho, incluindo a utilização
do processador, cache, fila de impressão, sincronização, uso da largura de banda e milhares de outras
estatísticas. Ele utiliza uma arquitetura de sondagem para capturar e registrar dados numéricos expostos
pelos aplicativos. O DBA escolhe os contadores a serem capturados para análise de acordo com a análise
que ele necessita fazer. No nosso caso vamos escolher os contadores que nos ajudará a identificar o
motivo da queda de desempenho nas aplicações.
N OTA 1:
M V T e c h | 215
A cada nova versão do Windows às vezes você tem que procurar as ferramentas que utilizava
anteriormente em um lugar diferente. Porque a Microsoft resolveu mudar o nome da ferramenta ou
mudou de lugar. Por exemplo, o System Monitor o pessoal que trabalha com TI há muito tempo conhece
esse utilitário como “Perfmon”, “Performance Monitor” ou “System Monitor”.
O nome “Perfmon” foi dado porque umas das formas de iniciar esse programa é acessando o menu iniciar
> executar e digitando na caixa de texto: perfmon.exe. (Fim Nota1)
No entanto para entendermos como obter as informações desejadas é importante compreender os três
níveis fundamentais para os critérios de monitoramentos. Estes níveis são: object, counter e instance.
Veja a Figura 01.
Figura 01. Contadores de desempenho do Performance Monitor.
OBJECT: Um object é um componente, aplicativo ou subsistema dentro de um aplicativo. Por exemplo,
Processor, Network Interface e SQLServer:Databases são todos objects.
COUNTERS: Counters são um subconjunto de um object. Para um determinado object, você pode ter
vários contadores. Por exemplo, o object Processor tem vários contadores para escolher: % Processor
Time, % User Time, Interrupts/sec, etc.
INSTANCES: Cada counter pode ter uma ou mais instances . Usando o exemplo acima do object Processor,
o %Processor Time teria 47 instâncias de um sistema - um para cada processador (0 até 47). Caso
necessite, você tem a capacidade de monitorar apenas uma instância de um counter de dados.
M V T e c h | 216
N OTA 2:
Lembrando que para que os dados sejam coletados corretamente os únicos tipos de dados permitidos
pelo System Monitor são numéricos. (Fim Nota 2)
Antes de criarmos nosso primeiro Data Collector Sets queria chamar atenção para três contadores em
especial. São eles: System: Processor Queue Length, Network Interface: Output Queue Length e Physical
Disk: Avg Disk Queue Length. Se identificarmos alguma anormalidade neles, teremos sérios problemas no
sistema.
System: Processor Queue Length: Este contador, ao invés de avaliar o uso de um único processador, avalia
o enfileiramento de threads aguardando oportunidade de execução em todos os processadores. Se ele
excede 02 theads por cada processador durante períodos contínuos ou durante um período de
monitorização de 24 horas, você poder ter um gargalo de CPU. Por exemplo, se você possui 06 CPU´s no
seu servidor, o valor deste contador não deve ultrapassar quanto? A resposta é 12, que equivale ao
seguinte cálculo = 06 x 02 = 12. O resultado é a multiplicação de 06 CPU's com 02 theads(valor aceitável
por processador). Se este valor é ultrapassado por um período muito extenso e constante, pode indicar
que seus processadores não estão mais suportando a carga do sistema.
Network Interface: Output Queue Length: Este contador de desempenho indica o tamanho da fila de
pacotes de saída. Ou seja é quantos pacotes estão sendo mantidos em uma fila, esperando para ser
enviada a partir da placa de rede para rede. Geralmente esse valor é zero. Como regra geral, se o Output
Queue Length for superior a 2 por um período de 10 minutos ou mais de uma vez, provavelmente você
tem um problema de desempenho de rede e isso está causando gargalo na rede. As possíveis causas desse
problema pode estar em várias coisas como por exemplo: uma placa de rede lenta, um problema de rede,
um problema no hub ou switch, pode ser que o SQL Server é muito. muito ocupado e a carga é demias
para placa de rede ou até a própria rede.
Physical Disk: Avg Disk Queue Length: Uma thread pode fazer muitos pedidos de uma vez só ao IO
Manager(O IO Manager é orientado a pacotes. Resumindo em poucas palavras, sua função é receber os
pedidos de leitura/gravação dos processos, transformar estes pedidos em um pacote chamado de IRP –
IO Request Packet, e encaminhar este pacote ao driver responsável. Após feita essa operação, o driver
devolverá o IRP ao IO Manager com as informações de como foi o processamento) sem esperar que a
primeira seja completada. O IO Manager não irá recusar esses pedidos, mas irá organizá-los numa fila,
pois o disco só faz uma coisa de cada vez. O comprimento médio dessa fila é o "Avg Disk Queue Length".
O contador Avg. Disk Queue Length se for superior a dois por períodos contínuos (mais de 10 minutos ou
mais durante o período de monitoramento 24 horas) para cada unidade de disco em um array, então você
pode ter um gargalo de I/O para esse array. Você precisará calcular este valor, porque o Performance
Monitor não sabe quantas unidades físicas estão no seu array. Por exemplo, se você tem um array de 6
discos físicos e o Avg Disk Queue Length do disco é de 10 para uma disposição particular, então o Avg.
Disk Queue Length para cada unidade é de 1,66 (Cálculo: 06/10 = 1,66), que está bem dentro da 2
recomendado por disco físico.
M V T e c h | 217
Após a compreensão dos níveis e aprendermos um pouco mais sobre contadores, poderemos em fim criar
o chamado Data Collector Sets, que nada mais é do que um bloco de monitoramento onde vamos colocar
nossos counters. A grosso modo é um conjunto de dados personalizados onde você decide quais
atividades serão monitoradas
C OMO CRIAR UM D ATA C OLLETOR S ETS ?
Quando você usa o System Monitor, é possível ver os contadores de desempenho em tempo real. O Data
Collector Sets pode gravar estes dados para que você possa analisá-lo mais tarde.
Caso tenha um problema de desempenho ou deseja analisar e, possivelmente, melhorar o desempenho
de um servidor, você pode criar um Data Collector Set para recolher dados de desempenho.
No entanto, para a análise ser útil, aconselho a coletar e salvar os registros dos dados no momento da
queda de desempenho. Mas para que fazer isso? Por que podemos comparar como ficou o desempenho
antes de depois dos ajustes.
P ARA CRIAR UM D ATA C OLLETOR S ETS PERSONALIZADO , SIGA OS PASSOS ABAIX O :
Para iniciar o Performance Monitor clique em Iniciar >Executar e digite: perfmon.exe;
Clique em Data Collector Sets > User Defined, com o botão direito do mouse escolha New e em seguida
Data Collector Sets. Veja a Figura 02;
Figura 02. Primeiro passo para criar Data Collector Sets.
M V T e c h | 218
O wizard para criação do Data Collector Sets irá aparecer socilitando que você digite um nome. Logo após
a escolha do nome, teremos duas opções: Create from a template (Recommentded) e Create manually
(Advanced). A opção default é Create from a template (Recommentded), mas no nosso contexto vamos
criar manualmente os contadores que queremos monitorar. Deste modo, selecione a segunda opção e
clique em Next. Veja a Figura 03;
Figura 03.Wizard Data Collector Sets
Agora devemos escolher qual tipo de dados iremos incluir no Data Collector Set. A opção Create data log
> Performance Counter já vem selecionada por default, vamos mantê-lo assim. Clique em Next. (Figura
04);
M V T e c h | 219
Figura 04. Criar Data Collector Sets
Na próxima tela encontramos as seguintes opções: Performance Counter, Event Trace Data e System
configuration information. Selecione Performance Counter. Essa opção permitirá escolher qualquer
contador disponível no Performance Monitor. Feito isso clique em Next;
Clique no botão Add. Selecione os contadores de performance que você deseja. Vamos monitorar a fila
atual dos discos (PhisicalDisk\Current Disk Queue Length) e o processador (Processor \%Processor time).
Em seguida clique em OK. Observe a Figura 05;
M V T e c h | 220
Figura 05. Counter PhysicalDisk
Depois de incluir os contadores, o próximo passo é definir qual o intervalo que eles serão monitorados.
Veja na Figura 06 que existem duas opções a serem configuradas: Sample interval e Units. Em Sample
interval iremos deixar o número 15 e em Units informaremos seconds. Isso irá definir que de 15seg em
15seg será coletadas as informações referente aos contadores adicionados no passo anterior. Clique no
botão Finish.
M V T e c h | 221
Figura 06. Intervalo de tempo do Data Collector Sets
Depois de criar um Data Collector Set você pode salvá-lo no diretório padrão
(C:\PerfLogs\Admin\HostName_AnoMesDia) ou escolher outro local da sua preferência. Veja na Figura
07 que o podemos visualizar o caminho completo ao selecionarmos o SQLMagazine em Data Collector
Sets.
Figura
07.
Diretório Padrão do Data Collector Sets
Com isso nosso coletor de dados está pronto. Para iniciar a armazenamento das informações basta clicar
com o botão direito no Data Colletor Set > SQLMagazine e escolher opção Start. Observe a Figura 08.
M V T e c h | 222
Figura 08. Iniciar Data Collector Sets
Para verificarmos se a coleta começou, selecione Reports > User > Defined >SQL Magazine. Veja a Figura
09.
Figura 09. Relatório Performance Monitor
M V T e c h | 223
M V T e c h | 224
SQL SERVER PROFILER
O Microsoft SQL Server Profiler é uma interface gráfica para a funcionalidade de Rastreamento, com ele
você pode capturar a atividade gerada por uma carga de trabalho em uma instância do SQL Server ou do
Analysis Service.
Podemos utilizar os dados capturados para monitorar os erros de uma instância ou problemas de
concorrência, como também capturar dados que são usados para otimizar o desempenho das consultas
que são executadas no ambiente, seja ele de produção ou de teste.
Para dar continuidade na resolução do problema de performance na aplicação da empresa
AdventureWorks vamos utilizar o Profiler. Vamos criar um trace e fazer uma interseção entre os
contadores do Performance Monitor com os dados retornados no trace.
O QUE É O T RACE ?
SQL Server Profiler é o responsável por criar o chamado Trace. Estes traces incluem todos os scripts T-SQL
que são executados simultaneamente no SQL Server, quanto tempo eles estão levando, o tipo de
bloqueios sendo usado,e quaisquer erros que possam ocorrer no servidor monitorado.
Como o Trace contém todos os scripts T-SQL em execução no SQL Server, muitas vezes tende a se tornar
consideravelmente grande. Por isso, é sempre uma boa prática capturar apenas os dados que são
realmente necessários para análise.
Embora você possa criar um trace usando Transact-SQL (T-SQL), é mais comum usar SQL Server Profiler
para isso. E como fazer isso? Você pode iniciar o SQL Server Profiler através do menu File >New Trace do
SQL Server 2008 e em seguida se conectar em uma instância para começar a configurar um Trace. Veja
na Figura 10.
M V T e c h | 225
Figura 10. Criação Trace
Todo trace é obrigado a ter um nome e pelo menos um evento. Podemos especificar várias propriedades
para um Trace, como por exemplo: nome, modelo, hora de parada, tamanho máximo do arquivo e etc.
Veja Figura 11 .
Figura 11. Propriedades Trace
M V T e c h | 226
Muitas pessoas ignoram os Templates que o SQL Server Profiler fornece. O conhecimento sobre cada um
deles nos permite fazer uma análise útil dos traces. O SQL Server Profiler oferece esses modelos de
rastreamento predefinidos que permitem facilmente configurar as event classes que provavelmente
especificaremos no trace. Na tabela 1 descreve os templates prontos que pode ser utilizado para
rastreamentos sem qualquer modificação ou como ponto de partida para um novo onde podemos
adicionar colunas e eventos diferentes do padronizado.
Template
Blank
Objetivo
Um trace está vazio, ou seja, não possui nenhum evento ou coluna
selecionados para o rastreamento. Permite criar um rastreamento
inteiro a partir do zero.
SP_Counts
Captura cada stored procedure executada para determinar o quanto
cada procedure está sendo executada.
Standard
É o template mais comum para começar pois já possui alguns eventos
slecionados. Captura os seguintes eventos: Security Audit, Sessions,
Stored Procedures e TSQL.
TSQL
Captura uma lista de todas as stored procedures e ad hoc SQL batch
executados, mas não inclui estatísticas de desempenho.
TSQL_Durantion
Captura a duração de cada stored procedure e ad hoc SQL batch
executado.
TSQL_Grouped
Captura login e logout, junto com as stored procedures e todas as
instruções Transact-SQL no momento em que foram emitidos. Use para
investigar consultas de um determinado cliente ou usuário. Não inclui
dados de desempenho.
TSQL_Locks
Captura informações de bloqueio e deadlock, como blocked processes,
deadlock chains, gráficos de deadlock, lock escalation e lock timeouts.
TSQL_Replay
Capta informações detalhadas sobre o Transact-SQL . Se é necessário o
rastreamento pode repetido nos servidores ou diferentes. Este template
é comumente usado para fazer testes de carga e regressão. Por exemplo:
realizar testes de benchmark.
TSQL_SPs
Capta informações detalhadas sobre todos as Stored Procedures em
execução. Use para analisar os passos de componentes dos
procedimentos armazenados. Adicione o evento SP: Recompile se você
suspeitar que os procedimentos estão sendo recompilados.
Tuning
Captura as informações sobre procedimentos armazenados TransactSQL e execução do lote. Use para produzir saída do trace que o Database
Engine Tuning Advisor pode usar como uma workload para ajustar
bancos de dados.
Tabela 1. Descrição Templates.
Por padrão, quando um trace é iniciado usando o SQL Profiler, todos os eventos aparecem em uma grid
dentro da interface. Podemos observe na Figura 12 como os eventos são listados no Trace.
M V T e c h | 227
Figura 12. Events Selection
N OTA 4:
Podemos salvar os dados de um trace em uma tabela, em um arquivo ou em ambos. (Fim da Nota 4)
Você pode encontrar mais de 200 eventos que podem ser capturados no Trace SQL. A principal ação para
configurar um rastreamento é a seleção do conjunto de eventos que precisa ser monitorado. Tais eventos
são classificados em 21 grupos, alguns podem contem mais de 40 eventos. Os grupos de evento
disponíveis estão listados na Tabela 2.
Event Group
Broker
CLR
Cursors
Database
Deprecation
Errors and Warnings
Objetivo
13 eventos para mensagens, filas e conversações do Service
Broker.
01 evento para o carregamento de Common Language
Runtime(CLR) assembly.
07 eventos para criação, acesso e remoção de cursores.
06 eventos para crescimento/diminuição (grow/shirink) de
arquivos de dados/log (data/log), bem como mudanças de estado
do Database Mirroring.
02 eventos para notificar quando um recurso deprecated é usado
dentro da instância.
16 eventos para erros, avisos e mensagens de informação que
estão sendo registradas. Eventos para detectar páginas suspeitas,
processos bloqueados e estatísticas ausentes em colunas.
M V T e c h | 228
Full Text
03 eventos para monitorar o andamento do progresso de um
índice full text.
Locks
09 eventos de aquisição, “escalation”,liberação e deadlocks.
OLEDB
05 eventos para distributed queries (consultas distribuídas) e
chamadas de stored procedure.
Objects
03 eventos que monitoram quando um objeto é criado, alterado
ou eliminado (dropped).
Performance
14 eventos que permitem capturar “show plans”, uso de diretrizes
de plano e paralelismo. Este grupo de eventos também permite
capturar consultas full text.
Progress Report
01 evento para progresso de criação de índice online.
Query Notifications
04 eventos para monitorar os parâmetros, subscriptions e
templates de notificação de consultas.
Scans
02 para monitorar quando uma tabela ou índice é percorrido.
Security Audit
44 eventos para monitorar o uso de permissões, impersonation,
alterações em security objects (objetos de segurança),ações de
gerenciamento executadas em objetos, start/stop de uma
instância e backup/restore de um banco de dados.
Server
03 eventos para a montagem de uma fita, alterar para a memória
do servidor e fechar um trace file (arquivo de rastreamento).
Sessions
03 eventos para conexões existentes quando o trace inicia, assim
como para monitorar a execução de logon triggers e função de
classificação no Resource Governor.
Stored Procedures
12 eventos para execução de uma stored procedure, cache usage,
recompilação e instruções dentro de um procedimento
armazenado (stored procedure).
Transactions
13 eventos para begin, save, commit e rollback de transações.
TSQL
09 eventos para execução de chamadas ad hoc T-SQL ou XQuery.
Evento para um lote SQL inteiro, assim como para cada instrução
dentro de um lote.
User Configurable
10 eventos que você configurar com o SQL Trace.
Tabela 2. Conjunto de Eventos.
Os grupos mais utilizados são: Locks, Performance, Security Audit, Stored Procedures, e TSQL. Os grupos
de evento Stored Procedures e TSQL geralmente são capturados com eventos do grupo Performance para
ter um parâmetro e solucionar problemas de desempenho de consulta. O grupo de eventos Security Audit
é usado para definir auditoria rapidamente entre uma variedade de eventos de segurança embora a nova
“feature” de especificação de auditoria forneça recursos mais seguros e flexíveis. Por fim os eventos do
grupo Locks são comumente usados para solucionar problemas de concorrência.
Como dito anteriormente, é preciso ter cuidado com quais eventos monitorar, pois alguns deles podem
ter uma carga significativa em uma instância. Os eventos que se deve ter muito cuidado são:
Performance | Showplan
M V T e c h | 229
Stored Procedures | SP: StmtCompleted
Stored Procedures | SP: StmtStarting
TSQL | StmCompleted
TSQL | StmStarting
Esses grupos de eventos devem ser incluídos em um trace se e somente se, estiverem em conjunto com
um ou vários filtros restritivos, que limite o trace a um único objeto ou string.
C OMO APLICAR FILTROS NO SQL P ROFILER ?
Após toda essa explicação sobre o que é Profiler, trace, template e grupo de eventos vamos ver como
adicionar filtros em um trace para finalmente começarmos a por a mão na massa e resolvermos o
problema da AdventureWorks.
Um filtro é essencialmente uma cláusula WHERE aplicada nos dados na API do SQL Trace. Os filtros
permitem especificar vários critérios a serem aplicados nas colunas de dados.
As colunas que possuem “character” (dados alfanuméricos) permitem que filtros sejam definidos em uma
string, usando LIKE ou NOT LIKE, que podem conter um ou mais caracteres curingas. Ver Figura 13.
Figura 13. Aplicando filtros no Trace.
M V T e c h | 230
As colunas de dados baseadas em tempo permitem especificar maior que ou menor que. As colunas de
dados numeric permitem especificar igual, diferente, maior ou igual e menor ou igual. As colunas de dados
binários não podem ser filtradas.
Múltiplos filtros para uma única coluna são tratados com a condição OR. Por outro lado os filtros que
possuem várias colunas são tratados com a condição AND.
Você pode iniciar, parar e fazer uma pausa em um trace. Depois que foi iniciado o SQL trace retorna os
eventos correspondentes a sua necessidade e descarta os eventos que não correspondem aos critérios
dos filtros selecionados. Quando um trace é parado, toda a coleta de eventos termina e, se o trace for
reiniciado, todos os dados anteriores do trace são apagados da tela do Profiler. Caso queira suspender a
coleta de dados temporariamente, você pode pausar o trace. Quando tirar do pause os eventos
subsequentes são anexados no final da tela do Profiler.
P ERFORMANCE X M ONITORAMENTO
O SQL Trace é usado para coletar informações que ocorrem dentro de uma instância do SQL Server. O
System Monitor é usado para coletar “performance counters” que fornece o estado dos recursos de
hardware e outros componentes em execução no servidor. O SQL Server não pode funcionar sem acessar
os recursos de hardware. O estado desses recursos afeta o funcionamento de um servidor SQL Server. Por
exemplo, uma query pode estar sendo executada lentamente, mas o Profiler só informa o quanto ela está
lenta. Porém, adicionando os contadores de desempenho (performance counters) você poderia encontrar
a razão que estaria fazendo a query estar lenta. Nesse caso o motivo é porque não existem recursos de
processamento suficientes.
Embora seja possível diagnosticar um problema usando somente System Monitor ou o SQL Trace, quando
usamos simultaneamente os dois conjuntos de dados ambos fornecem o contexto para qualquer análise.
D ICA :
Você só poderá correlacionar um “couter log” (System Monitor) com um “trace file” (SQL Profiler) se tiver
capturado a coluna de dados StartTime no trace.
C RIANDO T RACES
Vamos configurar um trace para estabelecer um parâmetro de desempenho para verificar a execução das
querys no banco de dados afim de descobrirmos o motivo de lentidão na aplicação.
Para fins de demonstração adotaremos o banco exemplo da Microsoft o AdventureWorks. Caso ainda não
os possua você poderá baixar as bases de dados AdventureWorks2008 e AdventureWorksDW2008 no
site do Code Plex.
M V T e c h | 231
Inicie o Profiler. Selecione File > New Trace e conecte-se em sua instância.
Especifique o nome do para: SQL Magazine Trace, template: Blank e opções para salvar em um arquivo,
como mostrado na Figura 14.
Figura 14.Edição do Trace.
Clique na guia Events Selection.
Marque os eventos Lock: DeadLock graph e TSQL: SQL:BatchCompleted. Ver Figura 15.
M V T e c h | 232
Figura 15.Selecionando os Events Selection
Clique em Column Filters e especifique o filtro DatabaseName: AdventureWorks e Duration > Greater than
or equal: 10000. Ver Figura 16.
Figura 16. Editando os filtros do trace.
M V T e c h | 233
Clique em Run.
Inicie o System Monitor clicando em Iniciar > Executar. Digite: perfmon.exe.
Crie um Data Colletor Sets e adicione os seguintes contadores: PhisicalDisk\Current Disk Queue Length,
PhisicalDisk\%Disk Time e Processor\%Processor Time.
Inicie o Data Collector Sets.
Abra o SQL server Management Studio(SSMS), conecte-se na instância e execute as seguinte query.
USE AdventureWorks
GO
--CRIAÇÃO DA TABELA DE TESTE
CREATE TABLE TabTeste(
ID INT IDENTITY(1,1) PRIMARY KEY,
Nome VARCHAR(250) DEFAULT NEWID()
)
-- INSERT DE 10000 REGISTROS
SET NOCOUNT ON
GO
INSERT INTO TabTeste DEFAULT VALUES
GO 10000
Comente o código anterior e escreva as seguintes linhas de código e execute.
DECLARE @I INT
SET @I = 0
WHILE @I < 1000000
BEGIN
IF EXISTS (SELECT ID FROM TabTeste WHERE ID = @I)
BEGIN
PRINT 'ENTROU NO LOOP'
END
SET @I = @I + 1
END
GO
Abra uma new query e execute o código a seguir.
M V T e c h | 234
/*Listagem 1 –
“Update” em Production.Product */
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE*
GO
BEGIN TRANSACTION
UPDATE Production.Product
SET ReorderPoint = 898
WHERE ProductID = 317
WAITFOR DELAY '00:00:11'
Adicione mais uma new query e execute o código a seguir:
/*Listagem 2 – “Update” em Production.ProductInventory e um
“Select” em Production.Product */
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
BEGIN TRANSACTION
UPDATE Production.ProductInventory
SET Quantity = 655
WHERE ProductID = 317
AND LocationID = 1
SELECT
Name,
ReorderPoint
FROM
Production.Product
WHERE
ProductID = 317
Volte para a janela da primeira query e execute o código a seguir:
/*Listagem 3 - “Select” em Production.ProductInventory */
SELECT
*
FROM
Production.ProductInventory
WHERE
ProductID = 317
AND LocationID = 1
M V T e c h | 235
Irá ocorrer um erro de deadlock. Ver Figura 17. Conforme mensagem abaixo:
Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen
as the deadlock victim. Rerun the transaction.
Figura 17. Erro de DeadLock no SSMS .
Verifique no Profile o gráfico gerado pelo deadlock. Ver Figura 18.
Figura 18.Gráfico do DeadLock .
M V T e c h | 236
Pare o Data Collector Sets que você criou no item 8.
Pare o Profiler e salve o trace.
Inicie o Profile novamente e selecione File > Open > Trace File.
Selecione o trace que você salvou.
Clique em File > Import Performance Data. Selecione o counter log criado no System Monitor.
Na janela Performance Counters Limit Dialog, selecione Processor: %Processor Time, .PhysicalDisk:
%DiskTime e Avg.Disk Queue Length. Ver Figura 19.
M V T e c h | 237
Figura 19. Performance Counters Limit Dialog.
Percorra o trace no painel superior e observe as alterações que ocorreram dentro no gráfico do
performance counter e do rastreamento do Profiler. Ver Figura 20.
Figura
20.União entre Performance Monitor e o SQL Profiler.
M V T e c h | 238
Conforme podemos observar no gráfico da Figura 16 o maior consumo de CPU foi à consulta que contém
o loop. À medida que vamos selecionando as linhas do trace o curso que tem no gráfico vai
movimentando-se a fim de mostrar exatamente estava acontecendo no banco de dados. Com isso
conseguimos identificar que o problema de performance da empresa AdventureWorks é uma consulta
mal escrita que está entrando em um loop e mais que isso existe uma outra query que está provocando
deadlock os dois problemas juntos acontecendo várias vezes durante o dia acarretou nas constantes
reclamações ao nosso suporte de primeiro nível. A solução para esse problema é a correção de ambas as
consultas.
D ICA *:
Os níveis de isolamento afetam a maneira como o SQL Server manipula as transações, assim como a
duração dos “locks acquired“(bloqueios adquiridos). O SQL Server possui cinco níveis de isolamento o que
estamos utilizando nesse exemplo é o READ SERIALIZABLE. Esse nível de isolamento emula a execução
serial das transações, como se todas as transações fossem executadas uma após a outra, em série, em vez
de simultaneamente. Nenhuma outra transação pode modificar dados que foram lidos pela transação
atual até que a transação corrente terminar.
CONCLUSÃO
Apresentamos nesse artigo o que é o Performance Monitor, quais os principais contadores de
desempenho, como capturá-los e como analisar os resultados obtidos. Vimos também o SQL Profiler, seus
principais grupos, templates e filtros.
Por fim, podemos observar que a união dessas duas ferramentas nos ajuda a ter uma visão muito mais
ampla dos problemas que estão acontecendo na base de dados.
Como podemos observar são muitas variáveis a serem consideradas, mas o que vai influenciar na escolha
dos contadores ou eventos vai ser o problema que estamos enfrentando. No caso demonstrado no artigo
a dificuldade que a empresa enfrentava era perca de desempenho, mas poderia ser a rede mal
configurada ou um gargalo de CPU, memória, disco e etc. Por isso, deve-se tomar muito cuidado na hora
de averiguar os diversos cenários aparecem no dia a dia, porque a solução do problema vai depender de
uma avaliação bem feita.
REFERÊNCIAS
Monitoring (Database Engine)
M V T e c h | 239
http://msdn.microsoft.com/en-us/library/bb510705.aspx
SQL SERVER – Introduction to SQL Server 2008
http://blog.sqlauthority.com/2009/04/24/sql-server-introduction-to-sql-server-2008-profiler/
Using SQL Server Profiler
http://msdn.microsoft.com/en-us/library/ms187929.aspx
SQL Server - Introduction to SQL Server 2008 Profiler.
http://blog.sqlauthority.com/2009/08/03/sql-server-introduction-to-sql-server-2008-profiler-2/
SQL Server Profiler Templates
http://msdn.microsoft.com/en-us/library/ms190176.aspx
Code Plex (Baixar AdventureWorks 2008):
http://www.codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=18407.
Training Kit – 70-432
M V T e c h | 240
Restore Database com SSIS
Olá Pessoal!
O post de hoje será sobre uma das tarefas fundamentais de um administrador de banco de dados (DBA)
que é garantir que os dados possam ser recuperados no caso de um desastre. No nosso dia a dia,
adquirimos várias coisas que possam nos deixar tranquilos com nossos bens como por exemplo uma
apólice de seguro para carro ou para sua casa. Apesar de caro e rezarmos para nunca usarmos é uma
maneira que escolhemos para nos assegurar contra qualquer “imprevisto”. Enfim, voltando para o nosso
assunto, os backups são as apólices de seguro contra qualquer eventualidade na empresa em que
trabalhamos. O backup será o responsável por recuperarmos os dados que foram perdidos e no final das
contas o negócio voltar a fazer as suas operações empresariais rotineiras. Costumo dizer que ele é o
responsável pelo “final feliz” de qualquer situação. (rsrs).
Muitas vezes precisamos fazer um restore de uma base em um ambiente diferente do que nós temos,
seja ele para fins de teste de backup ou para um ambiente de homologação para que a equipe de
desenvolvimento faça seus testes antes de subir uma versão nova. Nesses casos existem diversas formas
de resolver o problema como fazer um backup remoto e trazer a base para o ambiente que você precisa
ou criar um job para fazer um backup copy only e depois fazer o restore a partir do arquivo gerado. Nesse
post para de atender essa necessidade criaremos um pacote para fazer um restore através de um FTP que
encontra-se em um servidor de domínio diferente para isso utilizaremos o SSIS, WINSCP e um pouco de
powershell.No final da criação do pacote, o mesmo ficará assim:
M V T e c h | 241
FTP COM W IN SCP
Para configurar os FTP devemos primeiro instalar o WinSCP e configurar um site. A imagem abaixo mostra
como ficará após essa configuração:
Agora vamos criar um arquivo de texto contendo os seguintes passos:
Abrir o site criado no WinSCP;
Encontrar o arquivo de backup;
Copiar o arquivo para o diretório na máquina onde será feito o restore
A criação desse arquivo de texto será o que o WinSCP utilizará para pegar o arquivo no diretório que foi
definido para o backup ser salvo e levá-lo para a pasta no outro servidor onde será feito o restore.
Abra o notepad e coloque o seguinte script:
M V T e c h | 242
option batch on
option confirm off
open FTP_DATABASE
get
/BACKUP/DATABASE/NOME_DATABASE_FULL_201411301300.BAK
S:\RESTORE\RESTORE_DATABASE\
exit
Agora com o SQL Server Data Tools aberto vamos colocar um “Execute Process Task” e configurar as
propriedades: Executable, Arguments e WorkingDirectory.
M V T e c h | 243
Executable
Arguments
WorkingDirectory
C:\Program Files (x86)\WinSCP\WinSCP.exe
-script=C:\FTP\ftpdatabase.txt
C:\Program Files (x86)\WinSCP
E XECUTE P ROCESS T ASK
Para alterarmos o nome do arquivo no “.txt” criado no WINSCP, utilizaremos um pouco de powershell. A
necessidade da adição desse passo é porque precisamos recuperar o nome do arquivo exato que o FTP
irá copiar para o diretório S:\RESTORE\RESTORE_DATABASE.
A primeira coisa a fazer é pegar um o “Execute Process Task” e arrastarmos para o Control Flow, conforme
imagem abaixo:
M V T e c h | 244
Antes de modificarmos o “Execute Process Task”, vamos criar o script para modificarmos o arquivo de
texto. A lógica é simples:
Vamos abrir o diretório onde encontra-se o “.txt”;
Procurar a palavra COLOCARDATAAQUI;
Substituir ela por uma data (A data especificada nesse caso é a data que o backup full foi criado);
Salvar o arquivo;
Abra o Windows PowerShell ISE (http://technet.microsoft.com/en-us/library/dd819514.aspx), conforme
a imagem abaixo:
O script para modificar o arquivo de texto é:
M V T e c h | 245
Script:
(Get-Content C:\FTP\ftpdatabase.txt) |
ForEach-Object
{$_
-replace
"COLOCARDATAAQUI",
Date).AddDays(-1).ToString("yyyyMMdd")} |
(Get-
Set-Content C:\FTP\ftpdatabase.txt;
Onde:
Get-Content = Ler e exibir o
conteúdo de um arquivo de
texto de forma rápida.
ForEach-Object=
Fornece
uma
maneira para percorrer e executar
uma ação.
Retorna
do
dia
anterior,
com
o
formato ‘yyyyMMdd’
Uma vez feito o script salve o mesmo com a extensão “.ps1”, no nosso caso foi salvo no mesmo diretório
que está o arquivo de texto.
Clique com o botão direito para abrir a caixa de propriedade do “Execute Process Task” e vamos preencher
os valores e argumentos necessário para editar o arquivo. Na opção “Process” do Execute Process Task
Editor vamos alterar os campos Executable e Arguments, conforme imagem abaixo:
M V T e c h | 246
Executable
Arguments
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
-ExecutionPolicy ByPass -command ". 'C:\FTP\ftppowershell.ps1'"
C RIAÇÃO VARIÁVEIS NO SSIS
Vamos criar algumas variáveis que irão armazenar o nome do arquivo e o diretório que iremos utilizar
para fazer o restore. No menu do SSIS, clique em Variáveis ou clique com o botão direito em qualquer
lugar do Control Flow e selecione a opção “Variables”.
M V T e c h | 247
Clique em 'Add Variable' e atualize os valores nas colunas name, Data Type e Value. Conforme imagem
abaixo:
F OREACH L OOP C ONTAINER
Vamos utilizar um Foreach Loop Container, o mesmo é muito útil em situações onde é necessário
percorrer uma pasta para fazer carga de arquivos ou fazer uma tarefa onde terá que verificar uma lista
mais de uma vez. Dê dois cliques no Foreach Loop Container Task para abrir a janela de configuração e
selecione a opção “Colletion”. Altere o caminho da pasta para “S:\RESTORE\RESTORE_DATABASE” (Crie
essa pasta caso não exista). Altere o tipo dos arquivos para *.bak .
M V T e c h | 248
Na guia Variable Mappings selecione a variável User::NM_ARQUIVO na coluna Variable. O Index 0 mapeia
o resultado do primeiro (e único) enumerador do Foreach. Clique em OK.
M V T e c h | 249
E XECUTE SQL T ASK (DELETE DATABASE)
Vamos adicionar um “Execute Script Task” para darmos alteramos a base para SINGLE_USER, conforme
imagem abaixo:
Script:
USE MASTER
GO
IF
EXISTS
(SELECT
1
FROM
SYS.DATABASES
WHERE
'NOME_DO_DATABASE')
ALTER DATABASE NOME_DO_DATABASE SET SINGLE_USER WITH
IMMEDIATE
GO
M V T e c h | 250
NAME
=
ROLLBACK
Script Task (NM_ARQUIVO)
Vamos adicionar a "Script Task" no pacote SSIS e você configurá-lo abrindo o Script Task Editor. Na opção
General, você deve fornecer um nome e uma descrição para a tarefa. Em seguida, vá para opção "Script"
do editor para configurar as propriedades.
A primeira propriedade que você precisa definir é ScriptLanguage. Você pode criar seus scripts em uma
das duas línguas: Visual Basic 2010 ou Visual C# 2010. Iremos usar o C#, para o verificarmos se o nome do
arquivo e o diretório do backup estão corretos.
A próxima propriedade é EntryPoint. Este é o método (específico para a linguagem de script selecionado)
que o tempo de execução SSIS chama como o ponto de entrada em seu código. O método Main, na
maioria dos casos, deve funcionar bem.
As próximas duas propriedades na página Script são ReadOnlyVariables e ReadWriteVariables. Como os
nomes sugerem, você digita o nome de todas as variáveis SSIS que você deseja usar em seu script. (Separe
M V T e c h | 251
os nomes com vírgulas para múltiplas variáveis de qualquer tipo.) Vamos adicionar a variável
User::NM_ARQUIVO a propriedade ReadOnlyVariables e a variável User::CAMINHO_ARQUIVO à
propriedade ReadWriteVariables. Como resultado, o meu script C# será capaz de recuperar a o diretório
de backup a partir das variáveis.
Clique em “Edit Script..”. Será aberta uma página no Visual Studio para programar o que você precisa, no
nosso caso vamos editar o método Main().
Script:
public void Main()
{
// TODO: Add your code here
String nome;
Dts.Variables["CAMINHO_ARQUIVO"].Value
Dts.Variables["NM_ARQUIVO"].Value.ToString();
nome
Dts.Variables["CAMINHO_ARQUIVO"].Value.ToString();
M V T e c h | 252
=
=
MessageBox.Show(nome);
Dts.TaskResult = (int)ScriptResults.Success;
}
E XECUTE SQL T ASK (RESTORE DATABASE / USER PERMISSION)
Vamos adicionar mais dois “Execute SQL Task”. No primeiro task será a procedure que faz o restore
recebendo o diretório como parâmetro.
Script:
EXECUTE [DBO].[USP_RESTORE_DATABASE] ?
E no segundo “Execute SQL Task” será as permissões para o usuário que acessa a base restaurada.
M V T e c h | 253
Script:
USE NOME_DO_DATABASE
GO
IF EXISTS (SELECT 1 FROM NOME_DO_DATABASE.sys.database_principals
WHERE name = N'user')DROP USER [caedbh]
GO
CREATE USER [user] FOR LOGIN [user] WITH DEFAULT_SCHEMA=[dbo]
GO
M V T e c h | 254
SP_ADDROLEMEMBER 'db_datareader', 'user'
GO
SP_ADDROLEMEMBER 'db_datawriter', 'user'
GO
E XECUTE P ROCESS T ASK (MODIFY NAME FTP FILE)
Por fim, iremos colocar outro “Execute Process Task” para alterar a data colocada no arquivo de texto
responsável de passar o nome do arquivo de backup no FTP. O objetivo dessa task é fazer como que da
próxima vez que o pacote for executado o powershell contido no objeto “MODIFY FTP FILE” encontre a
palavra “COLOCARDATAAQUI”, para isso basta criar outro arquivo “.ps1” e alterar a ordem do script.
Script:
(Get-Content C:\FTP\ftpdatabase.txt) |
ForEach-Object
{$_
-replace
(Get-Date).AddDays(1).ToString("yyyyMMdd"), "COLOCARDATAAQUI"} |
Set-Content C:\FTP\ftpdatabase.txt;
Com a modificação do nome do arquivo concluímos o post com a criação do pacote para restore de bases
via FTP. Espero que todos tenham gosto e qualquer, duvida ou critica só entrar em contato.
M V T e c h | 255
Leandro Ribeiro
www.sqlleroy.com
Fragmentação do Transaction Log - Parte I
Constantemente, apesar de um vasto material sobre o assunto na net, me deparo com problemas de
configuração do Transaction Log, tais como:
Arquivos de Logs armazenados no mesmo disco que o arquivo de Dados.
Uso de nível de RAID não recomendado.
Falta de espaço em disco motivado pelo crescimento do arquivo de log.
Mas principalmente, Arquivos de Log fragmentados.
A fragmentação do Transaction Log é um problema silencioso em seu ambiente e geralmente ocorre
devido a configurações erradas para o arquivo do Transaction Log e em muitos casos, a utilização de
configuração padrão (1MB para FileSize e AutoGrowth de 10%) para o arquivo de log, através de um
CREATE DATABASE simples.
Este assunto motivou a última palestra que fiz com meu amigo Marcus Vinícius Bittencourt [Twitter | Blog]
no SQL Saturday 147 em Recife e abordarei neste post.
Espero que ajude a alguém.
INTRODUÇÃO
Antes de entrarmos no universo do Transaction Log, preciso fazer uma pequena introdução de como os
dados são trabalhados pelo SQL Server.
O Database Engine utiliza dois tipos de gravações: Lógica e Física.
A gravação lógica ocorre quando os dados são alterados em uma página do Buffer Cache.
A gravação física ocorrendo quando a página é armazenada no disco a partir do Buffer Cache.
A partir desta afirmação, temos a seguinte lógica de alteração de uma informação:
Se o dado a ser alterado não está em memória, ele é lido do disco e armazenado no Buffer Cache.
A alteração é efetuada no Buffer cache e a página é marcada como dirty pages (página suja).
O Database Engine utiliza o protocolo Write Ahead Log (WAL) para garantir que as dirty pages sejam
armazenadas primeiro no Transaction Log antes de serem persistidas em disco.
M V T e c h | 256
As dirty pages são armazenadas em disco de modo assíncrono através dos processos Eager
Writing, Lazy Writing e Checkpoint.
A imagem abaixo, ilustra o que foi dito acima.
T RANSACTION L OG
De posse da informação de como os dados são persistidos, temos ideia da carga de trabalho do
Transaction Log que o caracteriza como um componente crítico do SQL Server.
Toda alteração realizada em um Database é registrada nele.
Além de registrar as alterações e garantir o ACID, o Transaction Log é utilizado em:
Database Mirroring
Log Shipping
Replicação Transacional
...
Não entrarei em detalhes do comportamento do Transaction Log em cada modelo recuperação, pois
independente do modelo utilizado, o arquivo de log pode fragmentar.
Internamente, o log é dividido em pequenos blocos chamados de Virtual Log Files (VLF).
Além de ser a unidade de divisão do Transaction Log, o VLF permite o efeito circular do log através de sua
reutilização.
M V T e c h | 257
O tamanho do VLF é definido automaticamente variando de acordo com o crescimento do Log.
A Tabela abaixo, informa como ocorre a divisão (Fonte: Kimberly Tripp)
< 64MB = 4 VLFs
> 64MB < 1GB = 8 VLFs
> 1GB = 16 VLFs
Usando o exemplo de uma carga de dados que force um crescimento do arquivo de Log em 1000MB,
podemos ter:
Em um Growth de 10 MB => 4 VLFs de 2.5MB => Total de 400 VLFs.
Em um Growth de 200MB => 8 VLFs de 25MB => Total de 40 VLFs
Em um Growth de 1000MB => Total de 16 VLFs de 62.5MB
A partir do exemplo acima, fica claro que uma configuração ruim para o Auto Growth do arquivo de Log
gerará muitos VLFs, caracterizando o que chamamos de Fragmentação Interna do Transaction Log.
A fragmentação interna causa impactos em todos os processos que utilizam o Transaction Log e nas
aplicações. (Sim... seus Updates e Inserts!!!)
Lembram que No início do post, informei a configuração default de criação do banco de dados. Lembrase?
M V T e c h | 258
Tamanho Inicial = 1MB com Growth = 10%.
Imagina um arquivo de log de alguns "Gigas" utilizando a configuração default...Ahhh!
Para verificar as informações de VLFs do arquivo de log, utilizamos o comando DBCC LOGINFO.
A quantidade de linhas retornadas é justamente a quantidade de VLFs existentes no Database.
Abaixo, informações das colunas retornadas pelo comando.
Destaque para as colunas:
FileSize - Tamanho do VLF em Bytes.
FSeqNo - Número que define a sequência de utilização dos VLFs.
Status - Em uso = 2, Livre = 0
CreateLSN - LSN no momento da criação dos VLFs. Quando igual a 0 (Zero) são VLFs criados no Create
Database.
Ok. Já sabemos conceitualmente como o Transaction Log fica fragmentado e como analisar informações
internas do arquivo de Log. Mas como resolver a fragmentação?
No próximo post, vamos colocar a mão na massa!
Até o próximo post!
M V T e c h | 259
Fragmentação do Transaction Log - Parte II
No post anterior, abordei sobre o Transaction Log, como ocorre sua fragmentação e como podemos
identificá-la.
Como prometido, neste post vamos verificar como resolver a fragmentação interna do Log.
Mãos à massa!
Para exemplificar, vou criar os Databases LargeVLF_Full, LargeVLF_Simple e SmallVLF com as seguintes
configurações para os arquivos de Log:
LargeVLF_Full com Tamanho de 1MB e File Growth de 10% no recovery model FULL.
LargeVLF_Simple com Tamanho de 1MB e File Growth de 10% no recovery model SIMPLE.
SmallVLF com Tamanho de 8000MB e File Growth de 4000MB no recovery model FULL.
M V T e c h | 260
Após criar os Databases, vamos analisar como estão os VLFs dos arquivos de log através do comando DBCC
LOGINFO.
LargeVLF_Full com 4 VLFs de "256Kb".
LargeVLF_Simple com 4 VLFs de "256Kb".
SmallVLF com 16 VLFs de 500MB.
M V T e c h | 261
Agora, vamos executar o script abaixo em todos os Databases.
M V T e c h | 262
Após a criação da tabela e execução dos inserts, vamos analisar como estão os arquivos de log de cada
Database.
O
Database
LargeVLF_Full
aumentou
de
4
VLFs
para
259
Observe que no modelo de recuperação Full, o status de todos os VLFs estão igual a 2 (Em uso).
M V T e c h | 263
VLFs.
D ICA :
Você pode verificar o que está retendo o arquivo de log (status = 2) e impedindo a reutilização dos VLFs
através
das
colunas
log_reuse_wait
e
log_reuse_wait_desc
na
sys.databases.
Neste caso, é o Backup de Log!
M V T e c h | 264
As possíveis causas de retenção podem ser encontradas neste link. (http://msdn.microsoft.com/enus/library/ms345414%28SQL.105%29.aspx)
O
Database
LargeVLF_Simple
aumentou
de
4
VLFs
para
91
Pela característica do modelo de recuperação Simples, temos os status 0 (Livre) e 2 (Em uso).
VLFs.
No modelo Simple o log é automaticamente truncado, mas isso não o impede de ficar fragmentado.
Cuidado!
Observe que o FileSize dos VLFs nos Databases LargeVLF_Full e LargeVLF_Simple são diferentes a cada
crescimento. Isto é motivado pela configuração do File Growth em percentual.
M V T e c h | 265
O
Database
SmallVLF
continua
com
os
mesmos
Apenas o segundo e terceiro arquivo passaram a ser utilizados (Status = 2).
M V T e c h | 266
16
VLFs.
Podemos afirmar que os Databases LargeVLF_Full e LargeVLF_Simple estão fragmentados! (Utilizo como
"referência" o valor máximo de 50 para quantidade de VLFs. Fonte: Kimberly Tripp)
E em relação aos impactos das operações de Inserts e Updates mencionados no primeiro post por você
Leandro?!
O arquivo de log não se beneficia do recurso Instant File Initialization. Quando é necessário o seu
crescimento, seus Updates e Inserts ficarão bloqueados até a conclusão do crescimento do arquivo de
log.
V AMOS TESTAR !
Para este teste, vamos realizar um update em todos os registros da Tabela nos Databases LargeVLF_Full
e SmallVLF, medindo o tempo de execução.
M V T e c h | 267
A diferença entre os Updates é de 1896ms.
Para verificar o que motivou esta diferença, vamos ao Default trace Log (Se não estiver desabilitado!).
M V T e c h | 268
Só para realizar o Auto Growth do arquivo de Log do Database LargeVLF_Full foram gastos 1486ms.
Dica: Evite crescimentos de arquivo do SQL Server durante o dia!
Bem, espero que tenha ficado claro!
Voltando para a resolução do problema de fragmentação...
Para "arrumar" nosso arquivo de log, devemos realizar os seguintes procedimentos:
Backup de Log.
Shrink do arquivo de Log.
Alteração do File Size e Auto Growth para um tamanho apropriado.
Para facilitar minha vida, criei o script "Analise de Fragmentação" que ao ser executado realiza as
seguintes atividades:
Verifica e exibe os Databases que contenham mais de 50 VLFs.
M V T e c h | 269
Exibe o tamanho e o percentual de utilização dos arquivos de log através do comando DBCC
SQLPERF(LOGSPACE).
Monta através de "Print", os comandos de ajustes para os Databases que apresentam mais de 50 VLFs.
Checkpoint.
Backup de Log se o modelo de recuperação não for Simple.
Shrink (Recuperando o nome lógico do arquivo)
Comando para alterar o File Size e File Growth (Recuperando o nome lógico do arquivo)
Abaixo o retorno da query.
M V T e c h | 270
Após analisar o ambiente e copiar os comandos gerados para uma nova janela de query, informe:
File Size e File Growth para os arquivos de Log identificados no script.
Execute o script de ajustes em um momento propício, ou seja, em uma janela de manutenção.
Execute novamente o script "Análise de fragmentação" para verificar se seu ambiente está normalizado.
Fazer o download dos scripts aqui (http://sdrv.ms/YmYbLK)
I NFORMAÇÃO ADICIONAL
Ter poucos VLFs e de tamanho "considerável" também é prejudicial ao seu ambiente, pois irá impactar na
liberação de espaço do arquivo de Log. VLFs de no máximo 400/500MB é o indicado.
M ELHORES PRÁTICAS :
M V T e c h | 271
Monitore seu ambiente.
Escolha o recovery model ideal para cada ambiente e necessidades de negócio.
Ajuste a frequência de Backup de Log para controlar o tamanho do seu arquivo de Log.
Não faça "BACKUP LOG ... WITH TRUNCATEONLY pois ele quebrará a sequência do Backup de Log.
Utilize transações curtas para que não retenha os VLFs por muito tempo.
Ajuste apropriadamente o File Size e File Growth do seu arquivo de Log.
Monitore seu ambiente.
E aí pessoal, como está o seu ambiente...
Espero que o post ajude.
Até o próximo!
M V T e c h | 272
Luciano Moreira
luticm.blogspot.com
O caso dos snapshots e data cache thrashing
Dia 30/06/2011 foi o último dia do Luan Moreno na Sr. Nimbus e durante o almoço estávamos
conversando sobre o SQL Server (para variar um pouco), quando ele disse uma frase muito interessante
“Quando você lê do snapshot o SQL Server faz a leitura direta no disco”. Fiz uma cara de interrogação e
depois dele explicar melhor entendi o que ele quis dizer: quando você tem um snapshot, as páginas do
banco de dados de origem não são compartilhadas com as do snapshot dentro do data cache.
Muito interessante! O Luan comentou que leu isso junto ao time do SQLCAT (referência fina e confiável),
e esta pequena observação que pode passar despercebida me levou a escrever este artigo, onde podemos
ter um potencial problema de data cache thrashing.
DATA CACHE E O DATABASE SNAPSHOT.
Primeiramente vamos analisar o funcionamento do data cache no SQL Server quando utilizado o database
snapshot. Por simplicidade criamos uma tabela onde cada registro ocupa uma página e inserimos 20.000
páginas de dados (script 1).
S CRIPT 1 – C RIAÇÃO DOS BANCOS DE DADOS
USE master
go
CREATE DATABASE DataCache
go
USE DataCache
go
CREATE TABLE Dados
(ID INT IDENTITY NOT NULL PRIMARY KEY,
Texto CHAR(8000) DEFAULT 'Sr. Nimbus')
GO
INSERT INTO Dados DEFAULT VALUES
GO 20000
M V T e c h | 273
CREATE DATABASE DataCache_Snapshot
ON (Name = 'DataCache',
filename = 'C:\temp\DataCache_Snapshotshot.mdf')
AS SNAPSHOT OF DataCache
GO
Quando o snapshot é criado um arquivo de dados é utilizado e aparentemente possui o mesmo tamanho
do original, mas somente as páginas que foram alteradas desde a criação do snapshot serão levadas para
o novo arquivo (sparse file), conforme a figura 01. Então para o banco de dados DataCache_Snapshot um
mapa de bits é criado em memória, para o SQL Server saber se deve ler uma página do arquivo original
ou do snapshot, indicando onde está a página correta para leitura.
(Figura 01 – Sparse file)
Neste momento não tivemos alteração alguma, então todas as páginas que precisamos para os dois
bancos estão no arquivo original, vamos então executar um DBCC DROPCLEANBUFFERS para limpar o data
cache e executar os comandos abaixo. O que você espera em termos de I/O?
SCRIPT 2 – CUSTO DE IO PARA AS CONSULTAS
SET STATISTICS IO ON
DBCC DROPCLEANBUFFERS
GO
SELECT *
FROM DataCache.dbo.Dados
SELECT *
FROM DataCache_Snapshot.dbo.Dados
go
M V T e c h | 274
No primeiro select temos o esperado, uma série de leituras físicas (seja read-ahead ou não) colocando as
páginas de dados em cache. E a segunda consulta? Já que não houve alterações nos dados nenhuma das
páginas estará no novo arquivo, e como todas as páginas carregadas pelo primeiro SELECT estão em cache,
então não é necessário ler nada do disco, correto?
S CRIPT 3 – R ESULTADO DE IO PARA AS CONSULTAS
(20000 row(s) affected)
Table 'Dados'. Scan count 1, logical reads 20076, physical reads 51, read-ahead reads 20055, lob logical
(20000 row(s) affected)
Table 'Dados'. Scan count 1, logical reads 20075, physical reads 50, read-ahead reads 20075, lob logical
Na verdade não! O data cache referencia as páginas através da combinação: banco de dados, arquivo e
página (dbid, fileid, pageid). Quando procura por uma página do novo banco de dados que não está em
cache, resta a ele fazer uma leitura no disco, referenciando o mapa de bits para saber se deve ler a página
do arquivo original ou do novo.
Se as consultas forem executadas novamente não será necessária nenhuma operação de I/O, pois as
páginas estão em cache. Consultando sys.dm_os_buffer_descriptors (script 4) veremos que temos uma
série de páginas “duplicadas”, com diferença apenas no database_id (figura 2).
S CRIPT 4 – C ONSULTANDO O DATA CA CHE
select *
from sys.databases
where name like '%datacache%'
go
select *
from sys.dm_os_buffer_descriptors
where
database_id
in
(DB_ID('DataCache'),
DB_ID('DataCache_Snapshot')) and file_id <> 2
order by page_id, database_id
go
M V T e c h | 275
Em termos Internals, o SQL Server não reusa a estrutura BUF entre páginas do snapshot e banco de dados,
então as páginas ficarão duplicadas em cache, mesmo que não estejam presentes no arquivo de dados do
snapshot.
Figura 2 – Páginas “duplicadas” em cache
DATA CACHE THRASHING
Até agora foi apresentado o funcionamento do database snapshot em relação ao data cache, mas qual é
o problema que me levou a escrever este artigo? Uma possível pressão no data cache por conta do SQL
Server não reutilizar as páginas entre snapshots!
Imagine um caso onde um DBA decide manter alguns snapshots do banco de dados (ex.: um snapshot por
dia) em um ambiente onde o volume de alterações é pequeno, então o overhead da operação copy-onwrite não é tão significativo. Durante a semana os dados de uma tabela são comparados entre os dias em
que o snapshot é tirado, sendo que isso acontece diversas vezes ao dia. Viu o potencial problema?
Vamos aos scripts, primeiro vamos definir o tamanho do buffer pool do SQL Server para 1GB e criar mais
alguns snapshots. Tendo a tabela 20.000 páginas aproximadamente, temos 8K * 20.000 páginas,
aproximadamente 160MB.
S CRIPT 5 – C RIANDO DIVERSOS SNAP SHOTS E MAX SERVER MEMORY
SP_CONFIGURE 'MAX SERVER MEMORY', 1000
M V T e c h | 276
RECONFIGURE
SHUTDOWN
go
CREATE DATABASE DataCache_Snapshot2
filename = 'C:\temp\DataCache_Snapshotshot2.mdf')
GO
GO
GO
GO
Com cinco snapshots criados, se executarmos uma consulta que obriga o SQL Server a varrer cada página
da tabela, será colocado aproximadamente 960 MB no data cache (script 6). Como todas as páginas
couberam em memória após a execução dos seis primeiros SELECTs (sim, o I/O foi pesado), se eu executar
todas as consultas 10 vezes em seguida o tempo total de execução ficará em torno de 4 segundos.
S CRIPT 6 – U TILIZANDO O ESPAÇO D O DATA CACHE
go
SELECT count(*) FROM DataCache.dbo.Dados
SELECT count(*) FROM DataCache_Snapshot.dbo.Dados
SELECT count(*) FROM DataCache_Snapshot2.dbo.Dados
go
M V T e c h | 277
go 10
E se outro snapshot for criado e aumentarmos uma consulta no nosso batch? Com o limite de memória
definido para o SQL Server não será possível colocar mais 160MB em cache, restando ao SQL Server
começar a tirar as páginas do cache, forçando operações de I/O e claro, diminuindo a expectativa de vidas
das páginas em cache (script 7).
S CRIPT 7 – D ATA C ACHE THRASHING
go
go
go 10
O segundo loop que forçou uma série de operações de I/O demorou entre 2:30 min e 3:00 min em minha
máquina, uma diferença considerável para os 4 segundos. Se você quiser ver um comportamento
diferente, tente alterar a ordem das consultas, para que o SQL Server não favoreça as páginas de alguns
bancos por conta do LRU-K.
Esse efeito eu chamo de data cache thrashing, pois é similar a um memory thrashing em relação ao paging
file. Obviamente foi um exemplo estruturado para mostrar o overhead deste no SQL Server, mas pense
no impacto que isso pode causar no seu ambiente quando colocado em paralelo com outros bancos de
dados disputando um espaço data cache. Se você cria vários snapshots com o objetivo de acelerar as suas
consultas (o que não é justificável), cuidado, você pode ser pego de surpresa pelo caso dos snapshots e o
data cache thrashing.
Abraços e até um próximo artigo!
M V T e c h | 278
Trigger causando deadlocks
Na correria do dia eu recebi uma ligação de um DBA questionando-me sobre um problema de deadlock
e, mesmo com o dia atolado, eu separei uns minutinhos para ajudá-lo. Bom, vamos ao problema:
Cenário: O cliente possui um problema de deadlock em algumas tabelas e depois de adicionar alguns
índices o problema deixou de acontecer. Mas o DBA (de forma bem perspicaz) ainda não está satisfeito
com o resultado e procurou minha ajuda para uma recomendação mais embasada.
P ERGUNTA : INDEXAÇÃO PODE ELIMI NAR PROBLEMAS DE DEADLOCKS ?
Resposta: quase isso! Uma indexação correta pode acelerar as consultas e operações que estavam
entrando em deadlock, resultando em uma possibilidade menor da situação se repetir, então uma
indexação correta pode sim DIMINUIR (não eliminar, talvez somente em um caso ou outro) os deadlocks!
É uma abordagem que utilizamos quando estamos lidando com alguns deadlocks que são "by design", isto
é, não podemos alterar o código que causa o problema.
Segue um script que simula o problema original, foi bater o olho nele que eu já vi o deadlock, mas para
você que quer praticar um pouco, coloque o script em um banco qualquer e mãos à obra!
USE Inside
go
IF OBJECT_ID('DeadlockTrigger') IS NOT NULL
DROP TABLE [DeadlockTrigger]
go
CREATE TABLE [dbo].[DeadlockTrigger](
[Codigo] [int] NOT NULL,
[Marca] [char](12) NULL,
[Numero] [char](12) NULL,
[Qtde] [decimal](10, 3) NULL,
[Numeracao] [int] NOT NULL
) ON [PRIMARY]
GO
ALTER
TABLE
[dbo].[DeadlockTrigger]
ADD
CONSTRAINT
[DF_DeadlockTrigger_Numeracao] DEFAULT (0) FOR [Numeracao]
GO
create
trigger
[dbo].[trgI_DeadlockTrigger]
[dbo].[DeadlockTrigger] for insert as
begin
M V T e c h | 279
on
update
DeadlockTrigger
set
Numeracao
=
(SELECT
MAX(Numeracao)+1 FROM DeadlockTrigger) WHERE Numeracao = (select
Numeracao from inserted WHERE Numeracao=0)
return
end
GO
Como vocês podem notar acima, a trigger é responsável por definir a numeração sequencial dos registros
na tabela, pegando o maior número atual da tabela.
E NTÃO PERGUNTO : AONDE ESTÁ O DEADLOC K ?

E NCONTRANDO O DEADLOC K
Se utilizarmos o SSMS e executarmos um insert simples (script abaixo), o SQL Server vai inserir um registro
na tabela (lock X - exclusivo) e depois executar um select na tabela procurando pelo maior número
existente, que atualizará o registro corrente com esse valor. Essa busca é um table scan e como a própria
transação possui um bloqueio exclusivo no registro que foi inserido, a trigger funciona que é uma beleza!
Veja parte dos planos nas figuras abaixo...
M V T e c h | 280
(Figura 01 – Insert seguido do update da trigger)
(Figura 02 – Plano do update fazendo alguns table scans)
Adicionando um pouco de concorrência no nosso banco de dados, podemos ver o problema acontecendo,
para isso basta disparar o script abaixo em conexões diferentes e depois de alguns segundos vamos ver a
mensagem: “Msg 1205, Level 13, State 45, Procedure trgI_DeadlockTrigger, Line 3 Transaction (Process
ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock
victim. Rerun the transaction.”
WHILE 1=1
BEGIN
INSERT INTO DeadlockTrigger (Codigo, marca, numero, Qtde) VALUES
(1, 'Sr. Nimbus', '61 30102050', 300)
END
Quais foram os recursos que entraram em deadlock? Usando o profiler podemos capturar a seguinte
informação:
M V T e c h | 281
(Figura 03 – deadlock S com X)
Analisando a sequência das operações fica evidente que o temos o cenário onde a transação 1 insere um
registro e logo depois a transação 2 insere mais um registro. No momento em que a transação 1 volta a
executar a trigger e o update faz o select (table scan) a transação 1 fica bloqueada pelo lock exclusivo da
transação 2, quando a transação 2 entra para execução ela fica bloqueada pelo lock exclusivo da transação
01. Como resultado temos um deadlock.
M INIMIZANDO OS DEADLO CKS
A maneira encontrada pelo cliente de minimizar o problema foi criar um índice no campo Numeracao,
conforme o script abaixo:
CREATE
NONCLUSTERED
[dbo].[DeadlockTrigger]
(
[Numeracao] ASC
)
GO
INDEX
[idx_Numeracao]
ON
O que muda com esse índice? Ao invés do update da trigger realizar um table scan, ele passa a fazer um
index seek no idx_Numeracao, então como o registro é inserido com numeração = 0 (constraint default),
ele estará em um ramo do índice diferente do MAX(numeracao), permitindo que a consulta seja feita sem
problema de bloqueio entre S e X (visto na figura 03).
Então estamos livres do problema? Aparentemente sim, mas basta executar novamente os loops
concorrentes que vemos a mesma mensagem 1205!
É o mesmo deadlock? Não! Se capturarmos o problema com o profiler veremos o seguinte:
M V T e c h | 282
(Figura 04 – deadlock U com X)
O problema não está mais com o select MAX(numeracao) do update! Agora o problema está com a
atualização dos registros que possuem numeracao = 0, pois em determinado momento podemos ter dois
registros com o valor zerado (de transações diferentes) e enquanto o SQL Server está varrendo o índice à
procura do objeto (usando o lock de Update) ele vai encontrar um registro bloqueado por outra transação
e vice-versa.
Então a criação do índice nesse caso somente está mudando um pouco o tipo de deadlock que
encontramos, saindo de um X com S para um X com U. E potencialmente, com uma tabela grande, a
chance de encontrarmos um deadlock fazendo um table scan é MUITO maior do que utilizando um index
seek.
Resultado: O cliente pode estar com a falsa impressão de que resolveu o problema de deadlock. O que é
muito ruim, pois esse irá se tornar um erro intermitente, daqueles mais chatos de entender.
Outra abordagem que o pessoal poderia tentar, e vejo muito por aí, seria tentar evitar o problema do
deadlock X com S utilizando uma hint de NOLOCK durante a busca do update, da seguinte forma:
ALTER
trigger
[dbo].[trgI_DeadlockTrigger]
on
[dbo].[DeadlockTrigger] for insert as
begin
update DeadlockTrigger
SET
Numeracao
=
(SELECT
MAX(Numeracao)+1
FROM
DeadlockTrigger with (nolock))
WHERE Numeracao = (select Numeracao from inserted WHERE
Numeracao=0)
return
end
Dessa forma realmente não veríamos mais deadlocks S com X, mas cairíamos novamente no problema do
deadlock X com U e provavelmente com uma freqüência maior que a primeira abordagem, pois sendo um
update menos eficiente a transação toda levaria mais tempo, aumentado a chance do problema ocorrer.
Concorda?
M V T e c h | 283
R ESOLVENDO O PROBLEMA ( DE VERDADE )
Por motivos de negócio ou até históricos é normal vermos algumas soluções que acabam deixando de
lado os recursos da ferramenta, que potencialmente são mais eficientes. No caso acima fica patente que
a utilização de um campo IDENTITY resolveria o problema do cliente, basta criar a tabela com o script
abaixo (e sem a trigger, claro!) que o problema do deadlock vai embora.
IF OBJECT_ID('DeadlockTrigger') IS NOT NULL
DROP TABLE [DeadlockTrigger]
go
CREATE TABLE [dbo].[DeadlockTrigger](
[Codigo] [int] NOT NULL,
[Marca] [char](12) NULL,
[Numero] [char](12) NULL,
[Qtde] [decimal](10, 3) NULL,
[Numeracao] [int] IDENTITY(1,1) NOT NULL
) ON [PRIMARY]
GO
Caso a resolução do problema ainda não seja suficiente para convencer o cliente, podemos ver o lado de
desempenho da solução com a trigger. Após inserir uma pequena massa de dados (13.000 registros) eu
executei um insert e mostro na figura 05 o plano de execução:
M V T e c h | 284
(Figura 05 – Plano de execução do insert)
Note que aqui estou utilizando a versão inicial do problema (sem o índice), onde um table scan pesa muito
no custo relativo de update no batch, isto é, do custo total para se fazer o insert a trigger é responsável
por 95%.
E a solução com índice versus a solução com o campo IDENTITY, qual será mais barata? Para verificar a
resposta dessa questão eu criei o índice idx_Numeracao na tabela e criei a tabela DeadlockTrigger2, que
possui um IDENTITY no campo Numeracao e nenhuma trigger. Veja o resultado na figura 06.
(Figura 06 – custos relativos)
O insert no primeiro caso é responsável por 86% do custo total de batch, enquanto o custo do segundo
insert é de 14%. Claramente podemos notar que a segunda abordagem é mais eficiente que a primeira,
além de resolver o problema de deadlock, então porque não utilizá-la?
CONCLUSÃO
M V T e c h | 285
É importante analisarmos com cuidado quando um problema foi efetivamente resolvido, pois paliativos
podem nos enganar e criar problemas ainda maiores para o futuro. Sempre que existe uma abordagem
de implementação da solução utilizando recursos da própria ferramenta, eu dou preferência a eles, pois
existe uma boa probabilidade de e serem mais eficientes e livres de efeito colateral.
Espero ter ajudado.
Abraços
M V T e c h | 286
VARCHAR(MAX) vs. TEXT (Sintaxe?)
Como vocês já podem ter visto, nós na Nimbus gostamos de detalhes do SQL Server, quanto mais interno
(ou misterioso) mais divertido. Hoje mostro para vocês um pequeno aspecto relacionado aos tipos de
dados, que inclusive já encontramos em um cliente e um ajuste gerou um grande e positivo impacto no
desempenho do ambiente SQL Server.
A dúvida: VARCHAR(MAX) e TEXT são sinônimos no SQL Server? Se você olhar o que o tipo de dados pode
armazenar parecem ser idênticos, então se é só uma diferença de sintaxe tanto faz qual eu utilizo, mas
levando em conta que o TEXT está marcado como deprecated, e só trocar tudo por VARCHAR(MAX) e
correr para o abraço! Calma lá campeão, vamos a um exemplo simples (rode o script 01)...
S CRIPT 01 – D UAS TABELAS IDÊNTICAS , VARCHAR(MAX) E TEXT
USE tempdb
go
IF OBJECT_ID('dbo.TabelaTEXT', 'U') IS NOT NULL
DROP TABLE dbo.TabelaTEXT
GO
CREATE TABLE dbo.TabelaTEXT (
ID INT IDENTITY NOT NULL CONSTRAINT PK_TabelaTEXT PRIMARY
KEY
, Nome VARCHAR(100) NOT NULL DEFAULT ('Sr. Nimbus')
, DataRegistro DATETIME2 NOT NULL DEFAULT(SYSDATETIME())
, Texto TEXT NOT NULL DEFAULT (REPLICATE('A', 2000))
)
GO
IF OBJECT_ID('dbo.TabelaVARMAX', 'U') IS NOT NULL
DROP TABLE dbo.TabelaVARMAX
GO
CREATE TABLE dbo.TabelaVARMAX (
ID INT IDENTITY NOT NULL CONSTRAINT PK_TabelaVARMAX PRIMARY
KEY
, Nome VARCHAR(100) NOT NULL DEFAULT ('Sr. Nimbus')
, DataRegistro DATETIME2 NOT NULL DEFAULT(SYSDATETIME())
, Texto VARCHAR(MAX) NOT NULL DEFAULT (REPLICATE('A',
2000))
)
GO
INSERT INTO dbo.TabelaTEXT DEFAULT VALUES
INSERT INTO dbo.TabelaVARMAX DEFAULT VALUES
M V T e c h | 287
GO 10000
SELECT ID, Nome FROM dbo.TabelaTEXT
SELECT ID, Nome FROM dbo.TabelaVARMAX
go
Quando você executar o script acima vai encontrar o plano esperado para as duas consultas, um clustered
index scan pegando os 10.000 registros. O que pode te pegar de surpresa é o custo relativo, 2% contra
98% (figura 01). Isso mesmo, SÓ essa pequena diferença. Utilizando o STATISTICS IO, vemos o motivo
dessa diferença:
Table 'TabelaTEXT'. Scan count 1, logical reads 68
Table 'TabelaVARMAX'. Scan count 1, logical reads 3348
(Figura 01 – comparando os planos de execução)
Mas qual o motivo dessa diferença? Quando você utiliza o VARCHAR(MAX), caso o seu large object (LOB)
caiba dentro da página de dados de 8K (nesse casso os 2.000 bytes cabem), o SQL Server vai favorecer
essa opção, diferente do TEXT! Isso é, se você está consultando na maioria do tempo outras colunas que
não a sua LOB, o SQL Server está carregando para o data cache páginas com baixa quantidade de registros,
minimizando a eficiência do seu cache e consequentemente, o desempenho geral do SQL Server. Então
existem diferenças e você pode ver o detalhe com algumas DMVs.
M V T e c h | 288
S CRIPT 02 – A NALISANDO AS UNIDADES DE ALOCAÇÃO
SELECT
OBJECT_NAME(object_id) AS ObjectName ,
AU.type ,
AU.type_desc ,
AU.container_id ,
AU.filegroup_id ,
AU.total_pages ,
AU.used_pages ,
AU.data_pages
FROM SYS.system_internals_allocation_units AS AU
INNER JOIN SYS.Partitions AS P
ON AU.Container_id = P.Partition_id
WHERE Object_ID IN (object_id('TabelaTEXT'),
object_id('TabelaVARMAX'))
ORDER BY object_id, type
go
(Figura 02 – Comparando AllocUnits)
Na figura 02 podemos ver que a tabela com TEXT possui poucas páginas de dados (IN_ROW_DATA),
contendo em seus registros ponteiros para unidades LOB onde efetivamente os dados estão. Já no
VARCHAR(MAX) as unidades de alocação de LOB_DATA não estão em uso, com used_pages igual a zero
(ROW_OVERFLOW pode ser ignorado para esse artigo).
Viu a diferença? Pequeno detalhe que pode impactar (e muito!) o seu ambiente. E agora você pode estar
se perguntando, como eu altero esse modo de operação? Simplesmente executar um REBUILD do índice
não vai fazer com que ele mude seu comportamento.
S CRIPT 03 – SP _ TABLEOPTION PARA LARGE VALUES
-- SP_TABLEOPTION!!
M V T e c h | 289
EXEC sp_tableoption 'TabelaVARMAX', 'large value types out of
row', 1
go
-- rebuild
ALTER INDEX PK_TabelaVARMAX
ON dbo.TabelaVARMAX
REBUILD
go
SELECT
AU.type ,
AU.type_desc ,
AU.container_id ,
AU.filegroup_id ,
AU.total_pages ,
AU.used_pages ,
AU.data_pages
go
-- Não?! Outra possibilidade...
UPDATE dbo.TabelaVARMAX
SET Texto = Texto
GO
-- E agora, 100%?
SELECT
AU.type ,
AU.type_desc ,
AU.container_id ,
AU.filegroup_id ,
AU.total_pages ,
AU.used_pages ,
AU.data_pages
M V T e c h | 290
go
-- A diferença dos custos se manteve?
go
-- E o espaço das páginas de dados do índice cluster?
SELECT
AU.type ,
AU.type_desc ,
AU.container_id ,
AU.filegroup_id ,
AU.total_pages ,
AU.used_pages ,
AU.data_pages
go
-- Organizando a casa...
ALTER INDEX PK_TabelaVARMAX
ON dbo.TabelaVARMAX
REBUILD
go
SELECT
AU.type ,
AU.type_desc ,
AU.container_id ,
AU.filegroup_id ,
AU.total_pages ,
M V T e c h | 291
AU.used_pages ,
AU.data_pages
go
-- Agora sim...
Go
-- Diferença ainda existe, mas é gerenciável
SELECT
OBJECT_NAME(object_id) AS ObjectName
, AU.*
, P.*
go
O script acima mostra o uso do sp_tableoption com a opção “large value types out of row”, que definido
Segundo o BOL significa: “1 = varchar(max), nvarchar(max), varbinary(max), xml and large user-defined
type (UDT) columns in the table are stored out of row, with a 16-byte pointer to the root”, exatamente o
que queremos.
Um aspecto curioso que me chamou a atenção quando estávamos resolvendo o caso do cliente, e que
você vai poder notar no script completo que acompanha o artigo, é que uma vez habilitada essa opção o
rebuild do índice NÃO fez a organização que eu esperava. Foi necessário um UPDATE dummy da coluna
VARCHAR(MAX) em todos os registros para o SQL Server colocar efetivamente o ponteiro de 16 bytes para
o LOB nas sua devida unidade de alocação.
Mesmo assim você vai notar que os custos do plano de execução se mantiveram mesmo após o UPDATE,
pois não houve nenhuma operação para organizar os registros no índice cluster, então a baixíssima
densidade de registros por páginas se manteve, com uma gigante fragmentação interna. Com o UPDATE
+ REBUILD conseguimos o que queríamos e os planos agora são bem compatíveis! Ainda ficou uma
diferença entre o número total de páginas no índice cluster, mas agora essa diferença é pequena e
gerenciável, quem sabe não falamos sobre isso em outro post...
M V T e c h | 292
Nilton Pinheiro
www.mcdabrasil.com.br/
Trabalhando com datas e conversões no SQL Server
Uma reclamação bastante comum de muitos desenvolvedores está na aparente dificuldade em se
trabalhar com datas e horas no SQL Server, mais especificamente quando usando os tipos de dados
datetime e smalldatetime. Eu digo aparente dificuldade, porque a grande verdade é que para trabalhar
com data e hora no SQL Server, a primeira coisa a fazer é entender como estes tipos de dados armazenam
seus dados. A partir do momento que você entender como o SQL Server armazena e trata esses dados,
você verá que trabalhar com datetime e smalldatetime é bastante simples.
Então, neste tópico veremos como esses tipos de dados se diferenciam um do outro, como eles
armazenam seus dados e como trabalhar com esses dados. Abordaremos também algumas funções
internas do SQL Server que simplificam muito o trabalho com estes tipos de dados.
O S TIPOS DE DADOS D ATE T IME E S MALL D ATE T IME
Estes são dois tipos de dados bastante utilizados no SQL Server para trabalhar com valores data e hora. A
diferença básica entre os dois, está na quantidade de bytes utilizados para o armazenamento da
data/hora, o range de datas suportadas e suas precisões.
Enquanto o DateTime usa 8 bytes para o armazenamento, o SmallDateTime usa apenas 4 bytes e é por
essa razão que o DateTime consegue armazenar um range maior de datas e também possui uma maior
precisão que o SmallDateTime.
O DateTime armazena datas de 1 de Janeiro de 1753 até 31 de Dezembro de 9999 com uma precisão de
3.33 milissegundos ou 0.00333 segundos, sendo os valores arredondados para incrementos de .000, .003
ou .007 segundos, como mostrado na Tabela 1.
Datas de Exemplo
Arredondamento
01/01/2015 23:59:59.999
02/01/2015 00:00:00.000
01/01/2015 23:59:59.995, 01/01/2015 23:59:59.996,
01/01/2015 23:59:59.997
01/01/2015 23:59:59.997 ou 01/01/2015 23:59:59.998
01/01/2015 23:59:59.992, 01/01/2015 23:59:59.993,
01/01/2015 23:59:59.993
01/01/2015 23:59:59.994
01/01/2015 23:59:59.990 ou 01/01/2015 23:59:59.991
01/01/2015 23:59:59.990
Tabela 1. Exemplos de arredondamento com DataTime
M V T e c h | 293
Observe que os horários com milissegundos entre .990 e .991 foram arredondados para .990. Os valores
entre .992 e .994 foram arredondados para .993 e os valores entre .995 e .998 foram arredondados para
.997
O SmallDateTime armazena datas de 1 de Janeiro de 1900 até 6 de Junho de 2079 com precisão de 1
minuto. Valores SmallDateTime com 29.998 segundos ou menos, são arredondados para o minuto
anterior, valores com 29.999, são arredondados para o minuto superior. Alguns exemplos podem ser
vistos na Tabela 2.
Exemplo
Arredondamento
2014-05-08 12:35:29.998
2014-05-08 12:35:00
2014-05-08 12:35:29.999
2014-05-08 12:36:00
Tabela 2. Exemplos de arredondamento com SmallDataTime
Um ponto importante para ter sempre em mente é que tanto o DateTime quanto o SmallDateTime
representam a data e hora como um valor que é igual ao número de dias decorridos desde a meia-noite
do dia 1 de Janeiro de 1900, conhecida como “data base”. No entanto, como descrito anteriormente, o
SmallDateTime somente pode representar datas a partir desta data base em diante. Já o DateTime,
também pode representar datas que estejam antes de 1 de Janeiro de 1900 e para fazer isso, ele armazena
os valores como números negativos.
Valores DateTime são armazenados internamente pelo SQL Server como sendo 2 inteiros de 4 bytes
(totalizando 8 bytes de armazenamento). Os primeiros quatro armazenam o número de dias decorridos
antes ou após a data base. Os outros quatro armazenam a hora do dia representada como unidades de
0.00333 segundos após a meia noite. Já valores para SmallDateTime são armazenados como sendo 2
inteiros de 2 bytes (totalizando 4 bytes de armazenamento). Os primeiros dois armazenam o número de
dias decorridos desde 1 de Janeiro de 1900. Os outros dois armazenam o número de minutos desde a
meia noite.
E NTENDENDO O ARMAZENA MENTO DOS VALORES DA TA E HORA
Para entender como os valores data e hora são armazenados no SQL Server, divida o valor data e hora em
duas partes a saber: a parte inteira e a parte fracional.
A parte inteira representa o número de dias decorridos desde a data base. A parte fracional representa a
parte horas, decorridas desde a meia-noite da data base.
Para que você possa entender melhor, imagine que estamos em 4 de Janeiro de 1900 ao meio-dia.
Internamente, o valor que representa essa data e hora é armazenado como 3.5. Ou seja, o número inteiro
três representa o número de dias decorridos desde a data base e a fração 0.5 representa a metade do dia
M V T e c h | 294
transcorrido desde a meia-noite. Para simular isso no SQL Server, basta executar a consulta a seguir no
SQL Server Management Studio:
SELECT CAST(CAST('1900-01-04 12:00' AS DateTime) AS Float)
No exemplo, utilizamos a função CAST para converter a string 1900-01-04 12:00 para DateTime e depois
para Float. Como resultado temos o valor 3.5 do tipo Float representando então a data.
Se usarmos o mesmo SELECT passando como string a data 2015-01-30 12:00, teremos como resultado o
valor 42031.5 onde 42032 representa o número de dias decorridos desde a data base e 0.5 a metade do
dia desde a meia noite.
Uma característica destes dois tipos de dados é que eles não podem armazenar datas sem hora e nem
hora sem data. Como consequência, se você armazenar uma data sem informar a parte hora, a parte que
representa a hora será definida como 0.
Isso será representado como meia-noite utilizando o formato 00:00:00 se estiver utilizando um campo do
tipo SmallDateTime ou 00:00:00.000 se estiver utilizando um campo DateTime. Similarmente, se você
armazenar apenas a hora sem informar uma data, a parte que representa a data será definida como 0.
Isso será representado como 1 de Janeiro de 1900 para ambos os tipos de dados. Para entender melhor,
execute o código a seguir no SQL Server Management Studio:
CREATE TABLE TB_DATAS (
Parte_Data DateTime,
Parte_Hora SmallDateTime)
GO
INSERT TB_DATAS VALUES ('2015-01-30','15:10')
INSERT TB_DATAS VALUES ('11:00','2015-01-30')
GO
SELECT * FROM TB_DATAS
O script cria a tabela TB_DATAS com as colunas Parte_Data (DateTime) e Parte_Hora (SmallDateTime) e
resultado de sua execução pode ser visto na Figura 1. No primeiro INSERT, observe que para na coluna
Parte_Data é informada apenas a parte referente à data (a hora está como 00:00:00.000) e para a coluna
Parte_Hora, apenas a parte referente à hora (a data está como 1900-01-01). No segundo INSERT é feito o
processo inverso.
Figura 1. Salvando dados em colunas DateTime e SmallDateTime
M V T e c h | 295
Observe que para ambos os tipos de dados, para as datas informadas sem a parte hora o SQL Server
considerou a hora como sendo 0 ou meia-noite. Já para as datas sem a parte data o SQL Server considerou
a data como sendo 1 de Janeiro de 1900. Ou seja, a data base.
É importante notar que o mesmo acontece quando você faz um SELECT em um campo data que usa estes
tipos de dados. Vejam o exemplo a seguir:
SELECT CAST('2015-01-30' AS DateTime) As Parte_Data,
CAST('10:00' AS DateTime) AS Parte_Hora
SELECT CAST('2015-01-30' AS SmallDateTime) AS Parte_Data,
CAST('10:00' AS SmallDateTime) AS Parte_Hora
O resultado é mostrado na Figura 2.
Figura 2. Exemplo de Select em um campo Data
No exemplo, o primeiro SELECT utiliza a função CAST para converter a string representando a data para o
tipo DateTime, enquanto o segundo converte para o tipo SmallDateTime.
Observe que o primeiro CAST passa uma data sem informar a parte hora (2015-01-30), então o SQL Server
entende que a parte hora é meia-noite ou 00:00:00.000. O segundo CAST informa apenas a parte hora
(10:00), então o SQL Server entende que a data é 1 de Janeiro de 1900.
T RABALHANDO COM A PAR TE DATA
Entendido como o SQL Server trata e armazena as datas para estes tipos de dados, vamos ver então como
fazer pesquisas com datas no SQL Server. Para um melhor entendimento, considerem uma tabela de
pedidos com os registros apresentados na Figura 3.
M V T e c h | 296
Figura 3. Dados de exemplo da tabela de pedidos
O script para criação da tabela e população dos dados de exemplo encontra-se na Listagem 1.
L ISTAGEM 1. S CRIPT PARA CRIAÇÃO E POPULAÇÃO DA TABELA DE PEDIDOS
CREATE TABLE TB_PEDIDO(
ID_Pedido int,
ID_Cliente VarChar(10),
Data_Pedido DateTime,
Data_Envio SmallDateTime)
GO
INSERT TB_PEDIDO
VALUES (1,'NILTON','2014-02-28 10:00:00.000','2014-02-28
16:20:00')
INSERT TB_PEDIDO
VALUES (2,'NILTON','2014-02-15 13:58:32.823','2014-02-16
00:00:00')
INSERT TB_PEDIDO
VALUES (3,'JORGE','2014-02-27 00:00:00.000','2014-02-27
16:00:00')
INSERT TB_PEDIDO
VALUES (4,'JORGE','2014-02-27 10:15:56.833','2014-02-28
00:00:00')
INSERT TB_PEDIDO
VALUES (5,'CARLOS','2014-08-10 00:00:00.000','2014-08-10
00:00:00')
INSERT TB_PEDIDO
VALUES (6,'CARLOS','2014-08-10 10:21:15.637','2014-08-10
17:20:00')
Uma pesquisa muito comum quando trabalhamos com data e hora é pesquisar por registros de uma
determinada data independente da hora. Usando os dados da tabela de pedidos, um exemplo seria
pesquisar por todos os pedidos enviados no dia 10-08-2014.
M V T e c h | 297
Se a data na coluna estiver sendo armazenada com a parte hora sendo 0 (como no caso do registro 5),
não haverá problemas pois como vemos, quando você pesquisa por uma data sem informar a parte hora,
o SQL Server considera a hora como sendo 0 ou meia-noite. Dessa forma buscará por todos os registros
que contenham a data 10-08-2014 e a parte hora como 00:00:00.
No entanto, como podemos ver nos dados de exemplo, tanto a coluna Data_Pedido quanto a Data_Envio
são usadas de forma inconsistente, ou seja, as vezes a parte hora é informada e as vezes não. Isso pode
indicar que o objetivo do desenvolvedor era armazenar somente a parte data, mas isso não foi forçado
pela aplicação e acabou gerando registros com a parte hora diferente de 0.
A conseqüência disso é que se você disparar uma consulta querendo saber todos os pedidos com data de
envio igual a 10-08-2014 (sem informar a parte hora), o resultado obtido não será o esperado.
O SELECT para a obtenção desses registros seria:
SELECT * FROM TB_PEDIDO WHERE Data_Envio = '2014-08-10'
Ao executar, o resultado mostra somente o registro 5 quando o desejado seria retornar os registros 5 e 6.
Isso acontece porque como a parte hora não foi informada na pesquisa, o SQL Server pesquisará pela data
onde a parte hora seja 0. Uma vez que a hora para o registro 6 é 17:20:00, o mesmo não é retornado.
Sendo assim, como podemos fazer para contornar esse problema? Se esse tipo de consulta for muito
utilizada por sua aplicação, a sugestão é que você passe a trabalhar com range de valores. Exemplo:
SELECT * FROM TB_PEDIDO
WHERE Data_Envio BETWEEN '2014-08-10'
AND '2014-08-10 23:59:59.997'
Lembre-se que a cláusula BETWEEN obtém valores que estão entre o primeiro e o segundo valor
informado (também conhecidos como limites inferior e superior). Você não pode definir o limite superior
como 2014-08-10. Se o fizer, novamente obterá como retorno apenas o registro 5, pois o SQL Server
tratará a hora como sendo 0.
Observe que no exemplo, o limite superior foi definido como “2014-08-10 23:59:59.997”. Com isso, o SQL
Server buscará por todos os registros entre “2014-08-10 00:00:00.000” e “2014-08-10 23:59:59.997”,
pegando assim todo o range de horário do dia “2014-08-10” e obtendo então todos os registros deste dia.
Veja o resultado na Figura 4.
M V T e c h | 298
Figura 4. Dados corretamente retornados
Um outro caminho para obter o resultado esperado é usando operadores de comparação >= (maior igual)
e < (menor), como demonstrado no código:
WHERE Data_Envio >= '2014-08-10' AND
Data_Pedido < '2014-08-11'
Nesse caso o SQL Server interpretará as datas como “2014-08-10 00:00:00.000” e “2014-08-11
00:00:00.000”. Como o filtro busca por registros com data de pedido menor que “2014-08-11
00:00:00.000”, então o SQL Server retornará apenas os registros do dia 10-08-2014 até o horário de
23:59:59.997.
F UNÇÕES E C ONVERSÕES
Uma prática comum de muitos desenvolvedores é fazer uso de algumas funções internas do SQL Server
para simplificar o trabalho com datas e algumas das funções mais comuns estão listadas na Tabela 3.
Função
DATEDIFF()
DATEPART()
DATEADD()
Descrição
Calcula o intervalo entre duas
datas. Sintaxe:
DATEDIFF
(datepart,
startdate, enddate )
Exemplo
-- Retorna o dia da data especificada
SELECT DATEDIFF(day, ‘2014-10-17’, ‘2014-10-18’)
Para datepart você pode usar: Year, quarter, Month,
dayofyear, Day, Week, Hour, minute, second e millisecond.
Retorna partes específicas de -- Retorna o minuto da data especificada
uma data.
SELECT DATEPART(minute, ‘2014-10-18 15:22:56.567’)
Sintaxe:
DATEPART (datepart, date)
Para datepart você pode usar: Year, quarter, Month,
dayofyear, Day, Week, Hour, minute, second e millisecond.
Retorna uma nova data -- Adiciona 3 dias à data especificada
baseado na adição de um SELECT DATEADD(day, 3, ‘2014-10-18 15:22:56.567’)
intervalo para uma data
especificada.
Sintaxe: Para datepart você pode usar: Year, quarter, Month,
DATEADD (datepart, number, dayofyear, Day, Week, Hour, minute, second e millisecond.
date)
M V T e c h | 299
DAY()
MONTH()
YEAR()
CAST()
CONVERT()
Retorna
um
inteiro
representando a parte dia de
uma data. Sintaxe: DAY (date)
Retorna
um
inteiro
representando a parte mês
de uma data. Sintaxe:
MONTH (date)
Retorna
um
inteiro
representando a parte ano de
uma
data.
Sintaxe:
YEAR(date)
Converte um tipo de dados
para outro. Sintaxe: CAST
(expression AS data_type)
-- Retorna o valor 18
SELECT DAY(‘2014-10-18 15:22:56.567’)
SELECT MONTH(‘2014-10-18 15:22:56.567’)
SELECT YEAR(‘2014-10-18 15:22:56.567’)
-- Converte a string data para o tipo de dados DateTime e
depois para Float, obtendo a data como um valor Float (3.5)
SELECT CAST(CAST(‘1900-01-04 12:00’ AS datetime) AS
float)
Similar ao CAST. Sintaxe: -- Converte a string data para o tipo de dados DateTime e
CONVERT
(data_type depois para VarChar de 10 posições, obtendo apenas a
[(length)] , expression [style]) parte data no formato dd/mm/yyyy (04/01/1900).
SELECT CONVERT(VarChar(10), CAST(‘1900-01-04 12:00’ AS
datetime), 103)
Existem várias opções de style (opcional), mas os mais
utilizados são:
103: Retorna apenas a parte hora no formato dd/mm/yyyy,
108: Retorna apenas a parte hora no formato hh:mm:ss,
114: Retorna apenas a parte hora no formato
hh:mi:ss:mmm(24h)
* Para ver outros estilos consulte o Books Online do SQL
Server.
Tabela 3. Funções do SQL Server
Caso sua consulta seja utilizada com pouca frequência, você pode realmente fazer uso de algumas dessas
funções para simplificar o trabalho com as datas. No entanto, de uma forma geral esta não deve ser
considerada uma boa prática. Isso porque embora a utilização de funções permita obter os resultados de
forma relativamente simples, quando você usa uma função em uma condição de busca, você acaba
matando o índice da tabela caso um índice exista sobre a coluna do tipo data. Ou seja, o SQL Server acaba
não usando o índice para otimizar a pesquisa ou acaba fazendo um SCAN no índice.
Usando ainda os dados de exemplos da tabela de pedidos (Figura 3), uma opção seria utilizar a função
CONVERT para obter todos os registros com Data_Pedido igual a 10-08-2014.
M V T e c h | 300
WHERE CONVERT(VarChar(10),
Data_Pedido, 103) = '10/08/2014'
Neste exemplo a função converte o campo Data_Pedido para um VarChar de 10 posições, pegando assim
apenas a parte data no formato dd/mm/yyyy e comparando com o valor 10/08/2014. Como resultado, o
SELECT retornará os registros 5 e 6, os mesmo retornados na Figura 4. Porém, ao verificar o plano de
execução desta consulta (Figura 5) é possível ver claramente que o SQL Server executou um “Index Scan”
sobre o índice existente para a coluna Data_Pedido.
Figura 5. Index Scan sendo executado sobre o índice da coluna Data_Pedido
Observe então na Figura 6 que isso já não acontece quando uma função de conversão não é utilizada.
Podemos verificar isso com o script abaixo.
WHERE Data_Envio >= '2014-08-10' AND
Data_Pedido < '2014-08-11'
Figura 5. Index Seek sendo executado sobre o índice da coluna Data_Pedido
M V T e c h | 301
Um outro exemplo para obter os mesmos resultados seria utilizar as funções MONTH e DAY e YEAR:
WHERE DAY(Data_Pedido)=10 AND
MONTH (Data_Pedido)=08 AND
YEAR (Data_Pedido)=2014
Novamente, embora o uso de funções seja uma solução possível, sua utilização deve ser extremamente
evitada. Isso porque como vocês devem imaginar a função será chamada para cada registro da tabela,
matando então o índice da tabela e gerando um alto consumo dos recursos do servidor. Para uma tabela
com milhões de registros, essa prática certamente resultará em possíveis impactos na performance.
Minha sugestão é que procurem utilizar a solução com o BETWEEN ou os operadores de comparação >=
(maior igual que) e < (menor que)
T RABALHANDO COM A PAR TE HORA
Realizar uma consulta que busque por uma hora específica é semelhante a realizar uma consulta que
busque apenas por uma data (sem a hora). Se a coluna armazenar apenas a parte referente a hora, a
busca pela hora será simples.
No entanto, diferente dos valores data, o valor referente a hora é representado por um valor numérico
aproximado. Podemos ver isso facilmente ao executarmos a seguinte instrução, onde o valor retornado
será 0,983321759259259:
SELECT CAST(CAST('23:35:59' AS DateTime) AS Float)
Para ilustrar a pesquisa apenas pela hora, considerem uma tabela de apontamento de horas com os
registros apresentados na Figura 6.
Figura 6. Dados de exemplo da tabela de apontamento de horas
M V T e c h | 302
O script para criação da tabela e população dos dados de exemplo encontra-se na Listagem 2.
Listagem 2. Script para criação e população da tabela de apontamento de horas
CREATE TABLE TB_HORA (ID int,
Funcionario VarChar(10),
Data SmallDateTime,
Hora_Entrada DateTime,
Hora_Saida DateTime)
INSERT
VALUES
INSERT
VALUES
INSERT
VALUES
INSERT
VALUES
INSERT
VALUES
INSERT
VALUES
INTO TB_HORA
(1, 'NILTON','2014-10-10','08:30:00','12:30:15')
INTO TB_HORA
(2, 'NILTON','2014-10-10','13:32:00','17:38')
INTO TB_HORA
(3, 'CARLOS','2014-10-11','2014-10-11 08:30','12:30')
INTO TB_HORA
(4, 'CARLOS','2014-10-11','2014-10-11 13:30','17:30')
INTO TB_HORA
(5, 'CARLOS','2014-10-12','08:30:01.997','12:30')
INTO TB_HORA
(6, 'CARLOS','2014-10-12','13:30','17:30')
Aqui a coluna Hora_Entrada é utilizada de forma inconsistente, ou seja, algumas vezes armazenando
somente a hora (a parte data é definida como 1 de Janeiro de 1900), outras vezes armazenando a data e
a hora (registros 3 e 4).
Com isso, se você utilizar a consulta a seguir para obter apenas os registros com hora de entrada igual a
08:30, você terá como resultado apenas o registro de ID 1:
SELECT * FROM TB_HORA WHERE Hora_Entrada = '08:30'
O registro de ID 3 não é retornado porque quando se pesquisa apenas pela hora o SQL Server entende
que a parte referente à data deve ser 1900-01-01 (zero), o que equivale à data base. Por outro lado, o
registro de ID 5 não é retornado porque embora o valor esteja bastante próximo, o mesmo não é 08:30.
Com a execução do código a seguir é possível ver como o SQL Server entende esses dois horários em
formato numérico:
M V T e c h | 303
SELECT CAST(CAST('08:30' AS DateTime) AS Float),
CAST(CAST('08:30:01.997' AS DateTime) AS Float)
Caso execute o código acima você notará que a hora 08:30 é entendida pelo SQL Server como o valor
numérico 0,354166666666667, enquanto que a hora 08:30:01.997 é entendida como
0,354189776234568. Ou seja, realmente são bem diferentes.
Nesses casos, para ignorar a parte data de uma coluna DateTime ou SmallDateTime, você pode utilizar a
função CONVERT para separar o valor hora de seu componente data:
SELECT * FROM TB_HORA
WHERE CONVERT (VarChar(5),Hora_Entrada, 108) = '08:30'
Conforme apresentado na Figura 7, o SELECT retorna os registros 1, 3 e 5.
Figura 7. Resultado do SELECT usando a função de conversão para o campo hora
Se a parte hora for armazenada de forma inconsistente, então você também poderá considerar a
realização de pesquisas por range de valores hora. A seguinte instrução também retorna os registros 1, 3
e 5:
WHERE CONVERT (VarChar(5),
Hora_Entrada, 108) >= '08:20' AND
CONVERT (VarChar(5), Hora_Entrada, 108) <='08:40'
Infelizmente, para obter a parte hora não existe uma maneira de obter esse resultado sem usar uma ou
mais funções, mas como dito anteriormente, por razões de performance evite a utilização de funções em
campos utilizados em busca.
Se a parte hora for armazenada de forma consistente, ou seja, sem a parte referente a data, como é o
caso da coluna Hora_Saida. Você poderá evitar a utilização de funções fazendo uso de consultas como as
M V T e c h | 304
apresentadas abaixo. Mas lembre que neste caso será retornado apenas os registros onde a parte data é
1900-01-01.
WHERE Hora_Saida BETWEEN '17:30' AND '17:40'
WHERE Hora_Saida >= '17:30' AND Hora_Saida <='17:40'
Nestes exemplos, ambas as consultas retornam os registros 2, 4 e 6. Um outro caminho para trabalhar
mais facilmente com valores hora é usar o data type SmallDateTime no lugar do DateTime.
Uma vez que o SmallDateTime sempre arredonda a parte hora para o minuto mais próximo (acima ou
abaixo), as horas que estiverem entre 08:59:29.999 e 09:00:29.998 serão armazenadas como 09:00. Se
esse tipo de arredondamento for possível para sua aplicação, então o uso do SmallDateTime evitará a
necessidade de buscas por range de valores hora.
CONCLUSÃO
Como vimos no decorrer deste artigo, o trabalho com data no SQL Server é relativamente simples quando
entendemos como o servidor armazena e trata os valores. Um dos primeiros pontos a saber quando
trabalhamos com data é se realmente precisará de uma precisão de milissegundos.
Com isso você já decidirá entre o tipo de dados DateTime ou SmallDateTime. Lembre-se que o DateTime
ocupa mais espaço (8 bytes) que o SmallDateTime (4 bytes) e quando seu objetivo é tratar apenas a parte
hora, pode lhe obrigar a trabalhar com ranges de valores hora.
O segundo ponto é sempre garantir a consistência dos valores, ou seja, quando o importante é a parte
data tente manter a parte hora sempre como 0, quando o importante for a parte hora, tente manter a
parte data sempre como 1 de Janeiro de 1900. Com certeza esses cuidados simplificarão muito seu
trabalho com valores data e hora.
Um abraço e até a próxima.
M V T e c h | 305
Monitorando alterações de Dados com a Cláusula OUTPUT
Uma necessidade bastante comum em um ambiente SQL Server está em monitorar as operações DML
executadas sobre uma tabela. A partir dpo SQL Server 2008 isso pode facilmente ser alcançado com o uso
do CDC (Change Date Capture). No entanto, isso também pode ser facilmente alcançado usando a cláusula
OUTPUT.
Então, para demonstrar a utilização da cláusula OUTPUT, usaremos como exemplo a tabela
CartaoDeCredito que pode ser criada em qualquer banco de dados utilizando o script da Listagem 1. O
script cria a tabela e a popula com dois regsitros e em nosso exemplo, esta será a tabela a ser auditada. A
auditoria tem como objetivo monitorar os usuários que fizeram alterações nos números dos cartões de
crétido.
CREATE TABLE dbo.CartaoDeCredito (
[CreditCardID] [int] IDENTITY(1,1) NOT NULL,
[CardType] [nvarchar](50) NOT NULL,
[CardNumber] [nvarchar](25) NOT NULL,
[ExpMonth] [tinyint] NOT NULL,
[ExpYear] [smallint] NOT NULL,
[ModifiedDate] [datetime] NOT NULL
CONSTRAINT [DF_ModifiedDate] DEFAULT (getdate()),
CONSTRAINT [PK_CreditCardID] PRIMARY KEY CLUSTERED
([CreditCardID] ASC))
GO
INSERT dbo.CartaoDeCredito
(CardType,CardNumber,ExpMonth,ExpYear,ModifiedDate)
VALUES ('Visa','11111111111111',12,2014,'20090305'),
('MasterCard','22222222222222',12,2020,'20150105')
Listagem 1: Script para criação da tabela CartaoDeCredito
Conhecendo os objetivos e a estrutura da tabela a ser auditada, é preciso então ter uma segunda tabela
que será usada para armazenar os dados da auditoria, chamaremos aqui de "tabela espelho". Uma
observação muito importante sobre esta tabela é que para receber as linhas da cláusula OUTPUT ela não
pode possuir triggers, check contraints ou qualquer foreign key referenciando suas colunas ou colunas de
outras tabelas.
Então, com o script apresentado na Listagem 2 é possível criar a tabela que armazenará os dados
auditados durante as operações de INSERT, UPDATE e DELETE sobre a tabela CartaoDeCredito. Notem
que esta tabela possui duas entradas para cada coluna da tabela a ser auditada. A coluna com o prefixo
INSERT armazenará os dados inseridos e a coluna com o prefixo DELETE os dados excluídos. Outro ponto
a ser observado são as duas últimas colunas do script (INSERT_Usuario e DELETE_Usuario). Estas colunas
existem apenas na tabela espelho e serão utilizadas para guardar a informação referente ao nome do
M V T e c h | 306
usuário que modificou o registro na tabela CartaoDeCredito. Para obter esta informação será usada a
função de sistema SUSER_SNAME() que retorna o nome do usuário que executou a operação.
CREATE TABLE dbo.CartaoDeCredito_Espelho (
AuditoriaID int IDENTITY(1,1) NOT NULL PRIMARY KEY,
ComandoDML varchar(10),
INSERT_CreditCardID int NULL,
DELETE_CreditCardID int NULL,
INSERT_CardType [nvarchar](50) NULL,
DELETE_CardType [nvarchar](50) NULL,
INSERT_CardNumber [nvarchar](25) NULL,
DELETE_CardNumber [nvarchar](25) NULL,
INSERT_ExpMonth [tinyint] NULL,
DELETE_ExpMonth [tinyint] NULL,
INSERT_ExpYear [smallint] NULL,
DELETE_ExpYear [smallint] NULL,
INSERT_ModifiedDate [datetime] NULL,
DELETE_ModifiedDate [datetime] NULL,
INSERT_Usuario varchar(50) NULL DEFAULT SUSER_SNAME(),
DELETE_Usuario varchar(50) NULL DEFAULT SUSER_SNAME()
)
Listagem 2: Script para criação da tabela CartaoDeCredito_Espelho
Agora que você conhece a estrutura da tabela espelho, com o script da Listagem 3 é possível executar um
INSERT sobre a tabela CartaoDeCredito para populá-la com um registro.
-- INSERT
-- Início bloco OUTPUT
OUTPUT 'INSERT',
Inserted.CreditCardID,
Inserted.CardType,
Inserted.CardNumber,
Inserted.ExpMonth,
Inserted.ExpYear,
Inserted.ModifiedDate
INTO dbo.CartaoDeCredito_Espelho
(ComandoDML,INSERT_CreditCardID,INSERT_CardType,INSERT_CardNumber
,INSERT_ExpMonth,INSERT_ExpYear,INSERT_ModifiedDate)
-- Fim bloco OUTPUT
VALUES ('Amex','33333333333333',12,2020,'20150105')
Listagem 3: Script para carregar a tabela CartaoDeCredito
Note que a cláusula OUTPUT esta posicionada entre as palavras chaves INSERT e VALUES (em negrito na
Listagem 3). Em verdade, observando atentamente é possível notar que a instrução de INSERT é muito
semelhante a uma instrução de INSERT qualquer, a grande diferença no uso da cláusula OUTPUT está no
M V T e c h | 307
fato de ter que acrescentar o código destacado entre os comentários “—Início bloco OUTPUT e –Fim bloco
OUTPUT). Tirando este bloco, a instrução de INSERT ficaria como abaixo:
VALUES ('Amex','33333333333333',12,2020,'20150105')
Outro ponto importante, notem na Listagem 3 que após o INTO dbo.CartaoDeCredito_Espelho tem-se
então a lista das colunas da tabela CartaoDeCredito_Espelho onde os dados devem ser inseridos. Como a
operação de INSERT utiliza apenas a tabela virtual INSERTED, a lista de colunas possui apenas as colunas
correspondentes.
Assim como uma trigger de INSERT, a cláusula OUTPUT também faz uso da tabela virtual INSERTED para
obter os dados afetados pela operação DML de INSERT. Quando usamos uma trigger, esta faz uso de duas
tabelas chamadas INSERTED e DELETED. Estas tabelas são tabelas virtuais que existem apenas durante o
tempo de execução da trigger e podem ser usadas para capturar o antes e depois de uma operação DML.
As tabelas são afetadas de forma diferente dependendo da operação DML executada. Na Tabela 1 temos
o que contém em cada tabela de acordo com a operação DML.
Operação
Tabela INSERTED contém
Tabela DELETED contém
DELETE
Não possui registros
Registros excluídos
INSERT
Novos registros
Não possui registros
UPDATE
Novos registros
Registros antigos
A cláusula OUTPUT faz uso destas mesmas tabelas virtuais, então quando você executa um INSERT a
tabela virtual INSERTED possui o dados inseridos na tabela auditada, e a cláusula OUTPUT utiliza a tabela
virtual para capturar os dados e inserí-los na tabela CartaoDeCredito_Espelho.
O resultado da operação de INSERT executada sobre a tabela CartaoDeCredito com o script da Listagem
3 pode ser visto na Figura 1. Resultado da execução do script abaixo.
SELECT TOP 5 * FROM dbo.CartaoDeCredito ORDER BY ModifiedDate
DESC
GO
SELECT
ComandoDML,INSERT_CreditCardID,INSERT_CardType,INSERT_CardNumber,
INSERT_ExpMonth,
INSERT_ExpYear, INSERT_ModifiedDate, INSERT_Usuario
FROM dbo.CartaoDeCredito_Espelho
M V T e c h | 308
Observe que o novo registro foi inserido sobre a tabela Sales.CartaoDeCredito e ao mesmo tempo um
registro também foi inserido sobre a tabela Sales.CartaoDeCredito_Espelho indicando ainda o usuário
que executou a operação.
Figura 1: Resultado de uma operação de INSERT sobre a tabela CartaoDeCredito
Para uma operação de UPDATE, o que muda é que deve-se pegar os dados não apenas da tabela
INSERTED, mas também os da tabela DELETED. Isso porque quando ocorre uma operação de UPDATE o
que ocorre na prática é a exclusão do dados antigos e a inclusão dos novos dados sendo inseridos. Com
isso, durante uma operação de UPDATE a tabela INSERTED armazena os novos dados e a tabela DELETED
armazena os dados antigos ou excluídos.
Observando o script da Listagem 4 você notará que na lista de colunas passadas para a cláusula OUTPUT
é usado não apenas a tabela INSERTED, mas também a DELETED (bloco do OUTPUT). Bem como, após o
INTO dbo.CartaoDeCredito_Espelho é informado não apenas as colunas de prefixo INSERT, mas também
as de prefixo DELETE.
-- UPDATE
UPDATE dbo.CartaoDeCredito
SET CardNumber= '11111111112015'
OUTPUT 'UPDATE',
Inserted.CreditCardID,
Deleted.CreditCardID,
Inserted.CardType,
Deleted.CardType,
Inserted.CardNumber,
Deleted.CardNumber,
Inserted.ExpMonth,
Deleted.ExpMonth,
Inserted.ExpYear,
Deleted.ExpYear,
Inserted.ModifiedDate,
Deleted.ModifiedDate
(ComandoDML,INSERT_CreditCardID,DELETE_CreditCardID,INSERT_CardTy
pe,DELETE_CardType,
INSERT_CardNumber,DELETE_CardNumber,INSERT_ExpMonth,DELETE_ExpMon
th,INSERT_ExpYear,DELETE_ExpYear,
INSERT_ModifiedDate,DELETE_ModifiedDate)
WHERE CreditCardID=3
Listagem 4: Script para executar um UPDATE sobre a tabela CartaoDeCredito
M V T e c h | 309
O resultado da operação de UPDATE pode ser visto na Figura 2. Note que na tabela CartaoDeCredito o
número do cartão de crédito para o CreditCardID 3 foi alterado de 33333333333333 para
11111111112015. Na tabela de auditoria CartaoDeCredito_Espelho podemos notar que tanto as colunas
de prefixo INSERT quanto as colunas de prefixo DELETE foram preenchidas. Na coluna DELETE_CreditCrad
temos então o número antes da alteração e na coluna INSERT_CredtCard o novo número do cartão de
crédito.
O resultado é obtido ao executar o script abaixo:
SELECT TOP 5 * FROM dbo.CartaoDeCredito ORDER BY ModifiedDate DESC
SELECT
ComandoDML,INSERT_CreditCardID,INSERT_CardType,
INSERT_CardNumber,INSERT_ExpMonth,INSERT_ExpYear,
INSERT_ModifiedDate, INSERT_Usuario
SELECT
ComandoDML,DELETE_CreditCardID,DELETE_CardType,
DELETE_CardNumber,DELETE_ExpMonth,DELETE_ExpYear,
DELETE_ModifiedDate, DELETE_Usuario
Figura 2: Resultado de uma operação de UPDATE sobre a tabela CartaoDeCredito
Para finalizar, um exemplo demonstrando o uso da cláusula OUTPUT em uma operação de DELETE. Como
você já deve ter notado, para uma operação de DELETE apenas as colunas com prefixo DELETE para a
tabela CartaoDeCredito_Espelho serão preenchidas. O script para a operação de DELETE pode ser visto na
Listagem 5 e o exemplo exclui o registro de CreditCardID 3 da tabela dbo.CartaoDeCredito
-- DELETE
DELETE FROM dbo.CartaoDeCredito
OUTPUT 'DELETE',
Deleted.CreditCardID,
Deleted.CardType,
Deleted.CardNumber,
Deleted.ExpMonth,
Deleted.ExpYear,
Deleted.ModifiedDate
(ComandoDML,DELETE_CreditCardID,DELETE_CardType,
DELETE_CardNumber,DELETE_ExpMonth,DELETE_ExpYear,
DELETE_ModifiedDate)
WHERE CreditCardID=3
Listagem 5: Script para executar um DELETE sobre a tabela CartaoDeCredito
M V T e c h | 310
Podemos ver o resultado da operação na Figura 3. Note que o registro de CreditCardID 3 foi excluído da
tabela principal CartaoDeCredito. Para a tabela CartaoDeCredito_Espelho podemos notar também que as
colunas de prefixo INSERT estão como NULL e isso ocorre porque para as operações de DELETE não há
inserção de novos dados. Já para as colunas de prefixo DELETE, temos o registro dos dados excluídos e
quem o excluiu.
Figura 3: Resultado de uma operação de DELETE sobre a tabela CartaoDeCredito
D ICAS PARA A UTILIZAÇ ÃO DO OUTPUT
Como vocês devem ter notado, a cláusula OUTPUT pode ser utilizada nas instruções Transact-SQL de
INSERT, UPDATE ou DELETE. Isso proporciona uma excelente flexibilidade, pois podemos utilizá-la apenas
nas instruções que desejamos monitorar. Desta forma, qualquer processo que tenha permissão para
modificar uma tabela pode usar a cláusula OUTPUT para popular a tabela de auditoria. Algumas boas
práticas para a utilização da cláusula OUTPUT são as seguintes:
1) Remover qualquer permissão de acesso direto à tabela auditada;
2) Escrever todas as operações de INSERT, UPDATE e DELETE dentro de stored procedures;
3) Atribuir as permissões apenas nas stored procedures;
Seguir estas boas práticas garantirá que o usuário só conseguirá executar as operações através das stored
procedures e consequentemente não executará nenhuma operação sem passar pela auditoria. O ponto
de atenção ao trabalhar com a cláusula OUTPUT está em ficar sempre atento para não esquecer e fazer
as devidas modificações nas procedures quando houver mudanças na estrutura da tabela auditada ou até
mesmo não esquecer da cláusula OUTPUT quando estiver escrevendo novas procedures. Para evitar estes
problemas, minha sugestão é que sejam criadas regras que definam os passos envolvidos para a
modificação ou criação de operações que envolvam tabelas que precisem ser auditadas.
É verdade que ao invéz de trabalhar com a cláusula OUTPUT você também poderia executar esta auditoria
usando triggers sobre a tabela a ser auditada. No entando, quando trabalhamos com triggers, além de
termos os problemas de overhead sobre as tabelas afetas ainda temos que nos preocupar em lembrar
das trigger sempre que modificamos as tabelas ou geramos scripts de criação das tabelas. Este problema
não existe com a utilização da cláusula OUTPUT pois tudo está dentro das próprias stored procedures que
executam as operações de INSERT, UPDATE e DELETE. Se você alterar a tabela auditada, certamente terá
que alterar também as procedures que executam estas operações e neste momento verá a cláusula
OUTPUT. Se você gerar script de criação das tabelas, muito possivelmente irá gerar também os scripts de
criação das stored procedures e mais uma vez estará lá a cláusula OUTPUT.
M V T e c h | 311
Abraços
Nilton Pinheiro
M V T e c h | 312
Tiago Balabuch
www.tiagobalabuch.com
PERFORMANCE COUNTER - SUBSISTEMA DE DISCOS
Os administradores de storages estão constantemente tentando maximizar o desempenho de acesso ao
disco e problemas podem ser o resultado de qualquer coisa a partir de um componente configurado
incorretamente até um volume de carga extremamente grande. E aqui entra, na minha visão, a “briga”
entre o DBA e o Administrator de Storage mas essa é uma história longa. Voltando ao assunto, os bancos
de dados estão armazenados em discos (ou pelo menos até a chegada do SQL Server 2014, o recurso de
IN-Memory OLT, conhecido também por HEKATON, passa a armazenas dados em memória) que ao
contrário da memória RAM, são mídias não-voláteis.
U TILIZAÇÃO DE D ISCO
A utilização do recurso de disco pode ser medida através de:
Operações de I/O por segundo (IOPS) – Número de operações realizadas por segundo
Taxa de Transferência (Throughput) – Quantidade de dados (em Megabytes) transferidos
O S CONTADORES UTILIZADOS PARA MEDIR AS IN FORMAÇÕES SÃO :
Logical Disk: Disk Reads/sec e Disk Write/sec – São respectivamente ao número de operações de leitura
e escrita realizadas no volume ou disco. Valores abaixo de 100 IOPS são considerados baixos.
Logical Disk: Avg. Disk Read Bytes/Sec e Avg. Disk Write Bytes/Sec – Taxas de transferência para escrita e
leitura no subsistema de disco. Valores abaixo de 20MB são considerados baixos.
M V T e c h | 313
Gráfico 1 – Total de IOPS
O gráfico 1 mostra o consumo de IO do subsistema de disco, onde a utilização máxima chega perto dos
20 mil IOPS. Também é possível notar que a maior concentração na utilização do subsistema de disco para
leitura, visto que a gravação de dados consome pouco recurso.
Figura 2 – Total de Throughput
T EMPO DE R ESPOSTA
Podemos definir latência ou tempo de resposta como: uma medida de delay (tempo de atraso) desde o
momento de uma requisição de IO é criado, até ao momento em que a requisição de IO é completada.
Através de indicadores abaixo é possível dimensionar o impacto da utilização do subsistema de disco.
Logical Disk: Avg. Disk sec/Read e Avg. Disk sec/Write – É o tempo médio gasto em leitura e escrita de
uma operação de I/O no disco. Esse indicador corresponde ao tempo de resposta do disco, sendo
recomendado valores inferiores a 0.020 – equivalente a 20 milissegundos.
Logical Disk: Current Disk Queue Lenght – Informa a fila de cada volume ou disco. O valor ideal da fila de
disco é zero, porém, existe uma tolerância de até 2 operações de I/O por disco físico.
M V T e c h | 314
Gráfico 3 – Tempo de Resposta
O gráfico 3 mostra que a fila de disco está alta porém o tempo de resposta do subsistema de disco não
ultrapassa 8 milissegundos ou 0.08. Nesse caso o enfileiramento de disco não está atrapalhando o tempo
de resposta de IO.
REFERÊNCIAS:
Windows Performance Monitor Disk Counters Explained
http://blogs.technet.com/b/askcore/archive/2012/03/16/windows-performance-monitor-diskcounters-explained.aspx
Measuring Disk Latency with Windows Performance Monitor (Perfmon)
http://blogs.technet.com/b/askcore/archive/2012/02/07/measuring-disk-latency-with-windowsperformance-monitor-perfmon.aspx
M V T e c h | 315
PROBLEMAS DE REDE – ASYNC_NETWORK_IO
Há um tempo atrás, fiz uma análise em conjunto com um amigo, Rafael Carneiro Machado, de problemas
com lentidão em um site. O Rafael trabalha comigo, porém no time de Web e ajudou a identificar o
problema que estávamos tendo, assim como a escrever o texto abaixo.
O BJETIVO
Diagnosticar e identificar as possíveis causas de lentidão em um site que estavam ocorrendo. O
diagnóstico iniciou-se de forma geral nos ambientes de Web e Banco de Dados e os contadores de
performance foram sendo refinados de acordo com as evidências encontradas.
Depois da análise realizada, foram identificadas evidências de um problema na rede que interliga os
ambientes de Web e Banco de Dados. Dessa maneira nossos esforços foram direcionados para tanto.
Incidente Reportado: Lentidão e timeout em alguns momentos do acesso ao site
A NÁLISE I NICIAL – B ANCO DE D ADOS :
Foi realizada uma análise em cima da instância de banco de dados, que hospedava o site e foi identificado
um alto tempo de espera do tipo ASYNC_NETWORK_IO, quase 15%. Porque esse valor é alto? Em
particular, nunca tinha visto esse tipo de espera com um valor alto e isto me chamou a atenção, pois
sempre vi um valor próximo a 0% ou no máximo a 2%. Aqui foi o ponto que levou a nossa investigação a
se concentrar que poderia existir um problema relacionado à rede, mas o que era exatamente nesse
momento ainda não sabíamos.
Figura 1
Esse tipo de espera indica que o SQL Server está respondendo para a aplicação, porém a mesma não está
conseguindo processar no tempo correto.
M V T e c h | 316
Figura 2
Algumas ações que podemos tomar para tentar identificar a causa raiz do problema:
Identificar results sets grandes e verificar com a equipe de sistema se isso realmente está de acordo com
o negócio.
Se nem todas as linhas do result set serão necessárias, devemos alterar o código para restringir essa
quantidade de linhas.
Devemos verificar as configurações de placa de rede e verificar se não existe nenhum problema.
Validar os componentes de rede entre a aplicação/cliente e a instancia do SQL Server
A NÁLISE I NICIAL – WEB:
Não foi identificado nenhum time-out no ambiente Web, o que tínhamos era a demora do Banco de Dados
em responder as requisições dos servidores de aplicação. Isso pode ser identificado pela quantidade de
conexões com o estado “SYN_SENT”, porém esta informação apenas indica que a primeira ação do ThreeWay-Handshake foi iniciada, onde a origem informou ao destino que deseja iniciar uma comunicação.
Normalmente não vemos este estado de conexão, pois as comunicações de SYN, SYN-ACK e ACK ocorrem
quase de forma instantânea exceto em casos como este, onde o servidor de destino demora a enviar a
resposta do SYN à origem, porém não existia registro de time-out. Monitoramos os pacotes entre os
servidores de aplicação e banco de dados e pudemos ver que o servidor de banco de dados estava
demorando para enviar a resposta, mas respondia a requisição dos servidores de aplicação:
M V T e c h | 317
Figura 3
Nesse momento, suspeitávamos que o problema pudesse estar ocorrendo por falta de portas TCP para
realizar a comunicação devido a um alto trafego de dados. Foi realizado um monitoramento e a média de
conexões TCP em portas distintas em cada servidor era de 800, independente do destino. Se levarmos em
conta que por padrão a quantidade de portas dinâmicas no Windows 2008 é de 16384 portas (49152 a
65535), ainda sobram mais de 15 mil portas livres:
Figura 4
Figura 5
O que poderia estar acontecendo era uma limitação nas portas dinâmicas dos servidores de banco. Essa
nossa suspeita não se confirmou, pois dificilmente o problema estava na falta de “portas altas” nos
servidores de aplicação.
Outro detalhe importante que não poderíamos deixar de lado, era que o tráfego entre Web e Banco de
Dados passava por um appliance de balanceamento, um intrusion prevention system (IPS), Firewall e
outros equipamentos de rede física.
A NÁLISE DETALHADA
Após análise inicial, foi constatada a possibilidade de um problema de rede, a partir desse ponto uma
nova investigação foi realizada com foco neste quesito utilizando as ferramentas de análise de
performance do próprio sistema operacional, o Perfmon.
O S CONTADORES UTILIZADOS FORAM :
Network Interface
% Network Utilization
M V T e c h | 318
Output Queue Length
% Network Utilization Sent
% Network Utilization Received
Packets Outbound Errors
Bytes Total/sec
Current Bandwidth
Packets/secPackets Sent/sec
Packets Received/sec
Packets Received Unknown
Packets Received Discarded
Packets Outbound Discarded
Packets Sent Unicast/sec
Processor
% DPC Time
DPCs Queued/sec
TCPv4
Connection Failures
Segments/sec
Connections Established
Connections Reset
Segments Received/sec
Connections Passive
Connections Active
Segments Retransmitted/sec
Segments Sent/sec
AMBIENTE DE BANCO DE DADOS
M V T e c h | 319
Figura 6
Os itens que mais se destacaram foram a quantidade de pacotes recebidos descartados e com erro, além
disso, o número de segmentos TCP retransmitidos e de conexões com falha também estão altos.
Figura 7
M V T e c h | 320
Figura 8
A figura 8 mostra os segmentos TCP que precisaram ser retransmitidos por algum erro de rede.
Outro ponto de destaque é a quantidade de conexões TCP com falha. O fabricante recomenda que este
contador não ultrapasse o número de 10 conexões TCP com falha por hora. No ambiente de banco de
dados este valor está com uma média de 20. As figuras 9 e 10 mostram esse comportamento.
Figura 9
M V T e c h | 321
Figura 10
AMBIENTE WEB
Figura 11
No ambiente Web não tínhamos qualquer indício na camada física de erros, porém o mesmo problema
identificado no ambiente de Banco de Dados ocorre no ambiente Web. Esse problema trata-se da camada
de transporte, várias conexões com falha e retransmitidas.
M V T e c h | 322
Figura 12
O padrão de segmentos retransmitidos se repete no ambiente Web, consequência das conexões TCP com
falhas.
Figura 13
Esse comportamento no ambiente web foi detectado em todos os servidores da farm.
R ESOLUÇÃO
Esse comportamento foi enviado para equipe de rede, que realizou as ações necessárias na camada física
dos equipamentos fazendo assim com que o trafego de pacotes ocorresse com sucesso. O site em questão
apresentou uma melhora significante, onde seu carregamento inicial passou de 14 segundos para apenas
2,8 segundos.
CONCLUSÃO
Por algum motivo relacionado a rede, o Banco de Dados estava com muitos pacotes com erros e
descartados e isso gerava a necessidade de retransmissão dos mesmos, ocasionando demora na entrega
M V T e c h | 323
das informações que a aplicação demandava. O resultado final era a lentidão no acesso e carregamento
do
site.
Foi constatado que até mesmo para iniciar a comunicação entre Web e Banco de Dados o problema
ocorria.
O servidor Web enviava o pacote de SYN, o qual o servidor de banco de dados recebia o pacote e enviava
o ACK. Este pacote de ACK estava sendo corrompido em algum ponto e a aplicação informava ao banco
de dados que ainda não havia recebido sua confirmação (ACK), fazendo com que o Banco de Dados
tentasse enviá-lo novamente.
Este período entre tentativas e falhas até que o ACK seja enviado corretamente e a comunicação
estabelecida, é um exemplo de como a retransmissão de pacotes TCP pode impactar na performance do
site. Essa retransmissão não ocorre apenas durante o processo de “Three Way Handshake”, mas também
quando a comunicação já está estabelecida e efetivamente os dados estão sendo enviados do banco de
dados para os servidores de aplicação.
REFERÊNCIAS:
http://en.wikipedia.org/wiki/Handshaking
M V T e c h | 324
Suspect database - MSDTC in-doubt transaction
Em uma bela madrugada, onde todas as coisas obscuras aparecem, um dos servidores de um cluster
falhou e executou um failover para um outro nó. Até esse momento nada de estranho e esse é o
comportamento esperado.
PROBLEMA
Ao verificar os bancos de dados da instancia que sofreu o failover me deparei com o status de “suspect”
em um deles. Nesse ponto começou a investigação de como isso aconteceu e como resolver!
CONSEGUI ENCONTRAR NO ERRORLOG AS SEGUINTES MENSAGENS:
Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational
message only. No user action is required.
QueryInterface
failed
for
“DTC_GET_TRANSACTION_MANAGER_EX::ITransactionDispenser”:
0x80004005(failed to retrieve text for this error. Reason: 15105).
QueryInterface failed for “ITransactionDispenser”: 0x80004005(failed to retrieve text for this error.
Reason: 15105).
Attempting to initialize Microsoft Distributed Transaction Coordinator (MS DTC). This is an informational
message only. No user action is required.
SQL Server detected a DTC/KTM in-doubt transaction with UOW {07372A47-24B9-4BC3-A6510260624FFF8E}. Please resolve it following the guideline for Troubleshooting DTC Transactions.
An error occurred while recovering database ‘XXX’. Unable to connect to Microsoft Distributed
Transaction Coordinator (MS DTC) to check the completion status of transaction (0:-222014414). Fix MS
DTC, and run recovery again.
An error occurred during recovery, preventing the database ‘XXX’ (database ID 5) from restarting.
Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not
corrected or expected, contact Technical Support.
A aplicação que utilizava essa database também utilizava Microsoft Distributed Transaction Coordinator
(MSDTC) e tudo indicava que alguma coisa se perdeu no caminho da comunicação entre o MSDTC da
aplicação e do banco de dados.
No meu caso eu tinha um agravante: o cluster não possuía uma instância do MSDTC, ou seja, utilizava o
MSDTC local.
M V T e c h | 325
Quando uma instância do SQL Server 2008 ou superior é inicializada em um cluster, ela tenta encontrar
uma instância do MSDTC para comunicação na seguinte ordem:
Dentro do grupo do cluster onde reside o recurso do SQL Server
Dentro de outros grupos do cluster
Instância MSDTC local
RESOLUÇÃO
Eu não sabia o que tinha acontecido com MSDTC e resolvi tomar uma ação para deixar meu banco de
dados online e depois tentar resolver qualquer problema.
Utilizei o comando abaixo:
sp_configure ‘show advanced options’, 1
go
reconfigure
go
sp_configure ‘in-doubt xact resolution’, 2
go
reconfigure
go
sp_configure ‘show advanced options’, 0
go
reconfigure
go
E depois trouxe o banco de dados ONLINE.
Podem existir outras formas de resolver esse problema, porém essa ação permitiu que meu banco de
dados ficasse online e pude executar um DBCC CHECKDB que para meu alivio retornou sem nenhum erro!
Antes de liberar meu banco de dados para produção novamente voltei a configuração padrão
M V T e c h | 326
sp_configure ‘in-doubt xact resolution’, 0
go
reconfigure
go
Outra alterativa seria visualizar a view sys.dm_tran_active_transactions, essa view mostra algumas
informações sobre as transações com uso do MSDTC.
Os campos: transaction_uow, transaction_state, dtc_state são campos que devem ser olhados com
cuidado em uma análise pois contem informações importantes.
Assim você pode identificar o status da sua transação e pode tomar a ação necessária que cabe ao seu
ambiente.
CONCLUSÃO
Quando a instância SQL Server executou um failover para o outro nó do cluster, a instância passou a se
comunicar com o MSDTC local do novo nó, que não tinha informações das transações registradas no nó
anterior.
Ao tentar iniciar o processo de recovery do banco de dados, o SQL Server encontrou informações sobre
transações distribuídas que não haviam sido terminadas (confirmadas ou abortadas) antes da falha. O SQL
Server entrou no processo de validar as informações do LOG e questionou o MSDTC a respeito das
transações, e o novo MSDTC local não tinha informações a respeito destas transações. Por esse motivo o
SQL Server não foi capaz de resolve-las e desta forma interrompeu o processo de recovery ocasionando o
estado de “suspect”
A melhor solução para que isso não ocorra é ter uma instancia do MSDTC dentro do cluster.
M V T e c h | 327
R EFERÊNCIAS :
How to configure DTC for SQL Server in a Windows 2008 cluster
Opção de configuração de servidor in-doubt xact resolution
sys.dm_tran_active_transactions
M V T e c h | 328
Felipe Ferreira
www.templar.com.br/blogs/Felipe
A carreira de DBA está morrendo?
Com a popularidade da nuvem crescendo a cada dia uma das perguntas que eu recebo frequentemente
é: “a carreira de DBA está morrendo? O que você vai fazer da vida no futuro?”
Neste artigo eu irei dar a minha opinião pessoal sobre o futuro da nossa amada profissão e tentar acalmar
aqueles que já começaram a procurar uma nova carreira.
A primeira coisa que eu gostaria de falar é que quando a gente começou a trabalhar com TI nós sabíamos
que esta era uma carreira diferente de muitas outras. Uma carreira dinâmica e empolgante que se
reinventa o tempo todo, com novidades tecnológicas aparecendo todos os anos e mudando todo o
panorama da área. Nós escolhemos uma profissão que nos obriga a continuar estudando, aprendendo e
evoluindo. E esse é o pensamento que eu gostaria que vocês leem este artigo.
O papel do Administrador de Banco de Dados não está desaparecendo, nós não somos uma espécime
ameaçada de extinção e não entraremos nesta lista em um futuro próximo. A nuvem não é a nossa
inimiga. O mercado de dados está apenas evoluindo e a nuvem está trazendo diversas novidades que irão
nos dar mais poder, mais opções.
N O MERCADO DE HOJE NÓS TEMOS DOIS PROBLEM AS MUITO COMUNS :
1. As empresas não conseguem encontrar profissionais suficiente
Todos sabemos disso. Eu tenho certeza que todos conhecem
diversas empresas que tem vagas em aberto a diversos meses, já
entrevistaram dezenas de pessoas e simplesmente não conseguem
encontrar ninguém adequado para a vaga.
2. As empresas querem manter os seus custos o mais baixo possível
As empresas querem ter lucro e nós acabamos de sair de uma
grande crise mundial. Isso significa que as empresas estão
constantemente tentando encontrar formas de melhorar a sua
produtividade e manter os seus custos o mais baixo possível.
Em um cenário como esse as ferramentas que a nuvem nos fornece servem tanto para melhorar nossa
produtividade como DBA e também para ajudar a empresa a economizar dinheiro. Vamos pensar um
pouco, quantas tarefas a gente realiza diariamente que não trazem nenhum valor real para o negócio?
Sem dúvida que quando estamos planejando uma nova solução de alta disponibilidade ou realizando
performance tuning naquela consulta lenta nós podemos ver o valor que isso irá trazer para a empresa.
M V T e c h | 329
No primeiro caso, irá garantir que todas as aplicações estejam de pé e rodando quando a empresa precisa
e o segundo irá ajudar com que o servidor aguente a carga de trabalho, execute mais sessões
simultaneamente e fazer com que nossos clientes internos e externos fiquem mais felizes. Mas e aquele
tempo que você perdeu tentando encontrar mais espaço em disco para os seus bancos de dados?
Tentando encontrar espaço em disco para armazenar os backups porque o banco de dados cresceu mais
do que o previsto. E o tempo que você gasta instalando atualizações no Windows e no SQL? Em algumas
grandes empresas nós temos times de administradores de storage e infra-estrutura que irão se preocupar
com essas tarefas que usei como exemplo, mas essa não é a realidade de todo mundo. A grande maioria
de pequenas e médias empresas possui apenas um pequeno time que é responsável por múltiplas áreas.
E porque isso? Volte alguns parágrafos acima nos itens 1 e 2 da minha lista que você irá entender. Eu
espero você ler.
Agora vamos tentar imaginar uma outra realidade. Vamos imaginar um mundo onde eu recebo um alerta
de falta de disco para armazenar os meus backups. A nossa empresa adquiriu a pouco tempo uma outra
empresa, o que fez com que o crescimento dos bancos fosse muito maior do que o previsto originalmente
e nós ficamos sem espaço em disco. Então ao invés de esperar dias/meses por um processo de compra
de mais discos eu vou até um portal Web e alguns cliques do mouse depois eu tenho 1TB extra de disco
disponível. Tudo que preciso fazer agora é abrir o SQL Management Studio e alterar os meus Jobs de
backup para utilizar a nova área de disco. Problema resolvido em menos de 15 minutos.
Vamos imaginar um mundo onde eu possa pegar todos aqueles banco de dados pequenos que eu tenho,
bancos que não são muito importantes para o negócio (sim, nós todos temos vários desses bancos, não
tente mentir para você mesmo) e agora vamos mover esses bancos para a nuvem para economizar
recursos do servidor local para as bases mais críticas. Quem sabe eu consiga até diminuir o número de
servidores necessários localmente assim eu não preciso me preocupar com licenças, suporte, aplicar
patches naquela máquina. Isso não seria ótimo? E que tal se livrar completamente dos ambientes de
homologação e testes e substituir eles por máquinas virtuais na nuvem que eu posso simplesmente
desligar quando não estiverem em uso, economizando dinheiro para a empresa? E aquelas tabelas
enormes, que contem milhões de registros e nos causam problemas todos os dias, não seria ótimo
substituir aquela solução complexa de particionamento que nós desenvolvemos para gerenciar dados
históricos ou pouco acessados e ao invés disso permitir que o SQL Server gerencie automaticamente esses
dados, movendo os registros antigos para a nuvem, enquanto mantem os dados acessíveis para o cliente
de forma transparente?
A nuvem realmente é algo que vai mudar a carreira de muitos, mas não algo que irá matar o papel do
administrador do banco de dados e destruir famílias. Mas ao invés disso, é algo que irá nos tornar mais
eficientes, que irá nos fornecer ferramentas e opções que permitam que a gente nos foque em tarefas
que irão trazer realmente valor para a empresa, utilizar de forma mais eficiente o hardware existente,
para tornar nossas vidas mais fáceis. Então abrace as mudanças, da mesma forma que abraçamos todas
as outras novas tecnologias que vieram antes dela e use cada tecnologia como uma ferramenta para te
ajudar a ter sucesso no seu trabalho.
M V T e c h | 330
Criando um datawarehouse para testes
Para fazer testes com bases de diferentes tamanhos eu utilizo o datawarehouse dos testes da TPC.
Rapidamente, para quem não conhece, a Transaction Processing Performance Council, ou TPC para os
íntimos (não pergunte o que aconteceu com o outro P), é a organização que define alguns benchmarks
que todos os fabricantes utilizam para fazer testes de performance, com isso ela mantem a lista das
configurações de Hardware + Software com a melhor performance, o melhor custo x benefício e assim
por diante.
Para os meus testes eu utilizo o TPC-H, que é um teste de Decision Support, ou seja, utiliza uma base no
formato datawarehouse, e não a base OLTP. Se você deseja fazer esse teste com uma base OLTP acredito
que possa usar o mesmo procedimento com o teste TPC-E, apesar de nunca ter procurado. Temos N
formas de criar as bases de dados da TPC-H, irei partir para a mais manual de todas por nos dar maior
liberdade para fazer N testes.
Então mãos na massa. Toda a estrutura da base de dados e tabelas está na documentação oficial do
bechmarch
TPC-H,
que
vocês
podem
encontrar
no
endereço
http://www.tpc.org/tpch/spec/tpch2.14.0.pdf. Mas vamos facilitar as coisas.
P ASSO 1:
- Criar nossa base de dados. Aqui eu não vou colocar nada de dicas, melhores práticas de como criar, quais
opções habilitar e desabilitar na base de dados, porque isso vai ficar de lição de casa para vocês, testar
carregar os dados com diversas opções e ver a diferença de tempo entre uma forma e outra. Irei fazer
outros posts fazendo essas comparações futuramente. Então vamos apenas criar nossa base com os 2
filegroups que precisaremos para os próximos passos, o filegroup LOAD_FG será nosso filegroup de
Staging, muita gente cria uma base de dados separada para ser a área de Staging, nesse caso, estamos
criando na mesma base de dados em um filegroup separado; o filegroup DATA_FG é o filegroup com os
dados já tratados, nosso datawarehouse final.
1: CREATE DATABASE TPCH
2: ON PRIMARY
3: (
NAME
= tpch1g_root,
4:
FILENAME
= "D:\TPC\tpch1g.mdf",
5:
SIZE
= 10MB,
6:
FILEGROWTH
= 10MB),
7: FILEGROUP
DATA_FG
8:
(name=tpch1g_data1,filename='D:\TPC\tpch1g.ndf',size=2048mb,fileg
rowth=1024Mb),
9:
10: FILEGROUP
LOAD_FG
11:
(name=tpch1g_load1,
filename='D:\TPC\load1g.ndf',size=2048mb,filegrowth=1024mb)
M V T e c h | 331
12:
13: LOG ON
14:
(name=tpch1g_log,
filename='C:\TPC\tpch1G.ldf',size=1024mb)
Obs.: Lembre-se da dica do post anterior do Instant File Initialization para criar grandes bases de dados e
realizar as cargas: http://www.templar.com.br/blogs/felipe/2013/02/24/instant-file-initialization/
P ASSO 2:
- Criar nossas tabelas no Filegroup LOAD_FG, o nosso filegroup de staging.
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
USE TPCH
GO
create table PART
(P_PARTKEY
P_NAME
P_MFGR
P_BRAND
P_TYPE
P_SIZE
P_CONTAINER
P_RETAILPRICE
P_COMMENT
on LOAD_FG
int
varchar(55)
char(25)
char(10)
varchar(25)
int
char(10)
float
varchar(23)
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null)
create table SUPPLIER
(S_SUPPKEY
S_NAME
S_ADDRESS
S_NATIONKEY
S_PHONE
S_ACCTBAL
S_COMMENT
on LOAD_FG
int
char(25)
varchar(40)
int
char(15)
float
varchar(101)
not null,
not null,
not null,
not null,
not null,
not null,
not null)
create table PARTSUPP
(PS_PARTKEY
PS_SUPPKEY
PS_AVAILQTY
PS_SUPPLYCOST
PS_COMMENT
on LOAD_FG
int
int
int
float
varchar(199)
not null,
not null,
not null,
not null,
not null)
create table CUSTOMER
(C_CUSTKEY
C_NAME
C_ADDRESS
C_NATIONKEY
int
varchar(25)
varchar(40)
int
M V T e c h | 332
not
not
not
not
null,
null,
null,
null,
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
C_PHONE
C_ACCTBAL
C_MKTSEGMENT
C_COMMENT
on LOAD_FG
char(15)
float
char(10)
varchar(117)
not null,
not null,
not null,
not null)
create table ORDERS
(O_ORDERKEY
O_CUSTKEY
O_ORDERSTATUS
O_TOTALPRICE
O_ORDERDATE
O_ORDERPRIORITY
O_CLERK
O_SHIPPRIORITY
O_COMMENT
on LOAD_FG
bigint
int
char(1)
float
date
char(15)
char(15)
int
varchar(79)
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null)
create table LINEITEM
(L_ORDERKEY
L_PARTKEY
L_SUPPKEY
L_LINENUMBER
L_QUANTITY
L_EXTENDEDPRICE
L_DISCOUNT
L_TAX
L_RETURNFLAG
L_LINESTATUS
L_SHIPDATE
L_COMMITDATE
L_RECEIPTDATE
L_SHIPINSTRUCT
L_SHIPMODE
L_COMMENT
on LOAD_FG
bigint
int
int
int
float
float
float
float
char(1)
char(1)
date
date
date
char(25)
char(10)
varchar(44)
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null,
not null)
create table NATION
(N_NATIONKEY
N_NAME
N_REGIONKEY
N_COMMENT
on LOAD_FG
int
char(25)
int
varchar(152)
not null,
not null,
not null,
not null)
create table REGION
(R_REGIONKEY
R_NAME
R_COMMENT
on LOAD_FG
int
char(25)
varchar(152)
not null,
not null,
not null)
P ASSO 3:
M V T e c h | 333
Feito isso já temos nossa base de dados e as tabelas no nosso filegroup de staging, agora precisamos dos
dados para carregar nessas tabelas. Para isso vamos usar o DBGen, a ferramenta fornecida pela TPC para
gerar os arquivos de dados. A TPC fornece esse aplicativo como uma solução do Visual Studio em C++,
você pode fazer o download do código fonte aqui, como sei que nem todos os DBA’s possuem o Visual
Studio completo instalado, então vou disponibilizar os executáveis já compilados aqui no blog, você pode
baixar o aplicativo compilado aqui.
Para utilizar é só descompactar (ou compilar caso você tenha baixado o código fonte), abrir um prompt
de comando, navegar até a pasta com o código compilado e executar:
dbgen –vf –s 1
Sendo o –s 1, a quantidade de GB que você deseja gerar, no exemplo, serão criados arquivos para popular
todas as tabelas acima, totalizando 1Gb em tamanho. Para criar uma base de 10Gb, 50Gb, 100Gb você só
precisa alterar o valor no parâmetro
Os outros dois parametros, –vf é verbose para mostrar todos os passos na tela e o f de force para
sobreescrever arquivos existentes no disco. Digite dbgen –? para ver todas as opções.
P ASSO 4:
Carregar os dados! Aqui temos N opções, e é aqui que a brincadeira começa.. se você quiser pode
simplesmente usar um BULK INSERT e carregar direto os dados para as tabelas do filegroup LOAD_FG e
depois criar pacotes do SSIS ou scripts T-SQL para mover os dados para o filegroup Data_FG, pode criar
pacotes do Integration Services para carregar tudo, pode usar o BCP, enfim.. pode usar toda a criativade
que Odin lhe deu… para ajudar as pessoas que só querem fazer as consultas, testar desempenho, tentar
criar um columnstore index, etc, aqui vai a sintaxe do comando BULK INSERT:
1: bulk insert
(FieldTerminator =
2: bulk insert
(FieldTerminator =
3: bulk insert
(FieldTerminator =
4: bulk insert
(FieldTerminator =
5: bulk insert
(FieldTerminator =
6: bulk insert
(FieldTerminator =
7: bulk insert
(FieldTerminator =
REGION from 'C:\tpc\Region.tbl' with
'|', RowTerminator ='|\n',tablock)
CUSTOMER from 'C:\tpc\Customer.tbl' with
NATION from 'C:\tpc\nation.tbl' with
PART from 'C:\tpc\part.tbl' with
SUPPLIER from 'C:\tpc\SUPPLIER.tbl' with
PARTSUPP from 'C:\tpc\partsupp.tbl' with
ORDERS from 'C:\tpc\orders.tbl' with
M V T e c h | 334
8: bulk insert LINEITEM from 'C:\tpc\LINEITEM.tbl' with
(FieldTerminator = '|', RowTerminator ='|\n',tablock)
E é isso pessoal, no arquivo compilado acima eu também adicionei o QGEN que gera 22 consultas pesadas
para vocês testarem os servidores. Só digite na linha de comando QGEN.exe > consultas.sql que ele irá
gerar a consulta, ou abra os arquivos .SQL que estão na pasta e editem os filtros/etc.
Nos próximos posts vou usar essa base de dados para realizar testes de carga e comparações de
desempenho.
M V T e c h | 335

SQL Server: Além do Conceito

Transcrição

Documentos relacionados

Importar um arquivo CSV para o SQL Server usando Bulk Insert

o controle de acesso

Academic Year: 2015/2016 Course: WebGIS Coordinator

rierge suite x4

Mídia kit público

Untitled

objetivo resumo de qualificações atividades escolaridade

Linked Server entre o SQLServer e o PostgreSQL

Acronis® Recovery™ for MS SQL Server

br-mediakit-2016 copy