SQL Server 2014 a caminho!

A Microsoft anunciou ontem durante o TechEd North America 2013 que a nova versão do SQL Server já tem previsão para release: Início de 2014. O nova versão se chamará... SQL Server 2014 !

Em 2014 será também lançado o novo Windows Server 2012 R2, aka Windows Blue Server, e logo em seguida o SQL Server 2014 será liberado. Segundo informações do site techtarget.com, um preview  estará disponível ainda este mês.

A grande estrela na nova versão do SQL Server 2014 é o Hekaton, porém teremos melhorias no AlwaysOn, a possibilidade de utilizar SSDs para guardar cache de dados utilizados frequentemente, novos parâmetros para deixar a manutenção de índices mais flexivel, dentre outros...

Deixo aqui alguns links com mais informação, com destaque para o Brent Ozar, que fez um artigo bem completo sobre estas nova features:




SQL Server 2014 ?!?!

Isso mesmo pessoal! Ontem no TechED North America foi anunciado o SQL Server 2014. Algumas coisas bem interessantes foram comentadas, mas muito ainda estará por vir! A imagem ilustra bem o foco que a Microsoft deu ao produto e isso … Continuar lendo

VLDB, Auto Update Statistics e Virtual Log Files (VLF)

Na passada terça-feira fiz uma apresentação sobre Very Large Databases (VLDB) no grupo “SQL Port”. Os slides podem ser baixados aqui.

Aproveito para ponderar alguns pontos que foram discutidos durante a apresentação:

Auto Update Statistics
Ficou no ar a dúvida se a opção “Auto Update Statistics” estiver activa, as estatísticas são actualizadas antes ou depois da execução da query, efectivamente.

Confirmei os seguintes pontos:

O “query optimizer”, baseando-se nos predicados da query, verifica se existem estatísticas desactualizadas antes de compilar a query e antes de executar um plano que já esteja em cache.
 Com a opção “Auto Update Statistics” activa, a query sempre sera compilada e executada com estatísticas actualizadas.
Quando as estatísticas estão desactualizadas, o “query optimizer” espera pela actualização das mesmas para depois compilar e executar a query.



Se a opção “Auto Update Statistics Async“ estiver activada, este comportamento altera-se:

A query é executada mesmo se as estatísticas estiverem desactualizadas.
O “query optimizer” pode escolher um outro plano de execução, que não seria o melhor para dada query em condições normais, porém no panorama de estatísticas desactualizadas é mais eficiente.
Ao mesmo tempo que a query é executada, uma operação em background é lançada com o objective de actualizar as estatísticas, assim sendo, outras queries que sejam executadas nas mesmas condições irão tirar benefício de estatísticas actualizadas.


Em resumo:


OpçãoActivadoComportamento
Auto Update Stats (Sync)SIM·       Actualização síncrona (antes da execução).
·       A primeira query após uma grande modificação pode ter a performance afectada.
Auto Update Stats AsyncNÃO
Auto Update Stats (Sync)SIM·       Actualização assíncrona (em background).
·       A query não terá a performance afectada por actualização de estatísticas…
·       …porem não tira proveito das estatísticas actualizadas.
·       A estatística é actualizada em background.
Auto Update Stats AsyncSIM
Auto Update Stats (Sync)NÂO·       Auto update stats estará desactivado.
Auto Update Stats AsyncSIM
Auto Update Stats (Sync)NÃO·       Auto update stats estará desactivado.
Auto Update Stats AsyncNÃO


Virtual Log File (VLF)
Uma das recomendações que fiz na apresentação, foi controlar correctamente o crescimento do ficheiro de T-Log, o que ajuda a evitar problemas com a fragmentação des VLFs.

Eu tinha uma ideia errada do número possível de VLFs em um transaction log, e resolvi pesquisar.

De uma forma resumida, quando o SQL Server tem a necessidade de expandir o t-log, isso é feito baseado em virtual log files (VLF).
Um VLF pode ser encarado como um ficheiro muito pequeno dentro do ficheiro principal do t-log. Em um t-log existem N VLFs.

Existe uma regra para saber o número de VLFs alocados a cada growth:
·      Para uma expansão até 64Mb, 4 VLFs serão criados.
·      Para uma expansão de 65MB até 1GB temos 8 VLFs.
·      Para expansões superiores a 1GB, serao alocados 16 VLFs.

Um número incorrecto de VLFs (para mais ou para menos) pode causar problemas de performance, e até retardar o recovery de uma base de dados, assim como fazer com que também os backups sejam ineficientes.

Mas quantos VLFs devemos ter? Como sempre, isso depende! Mas, a ideia principal é que o tamanho dos VLFs seja bem definido. Sabendo a regra do número de VLFs que serão alocados Vs. o tamanho da expansão do log é fácil controlar o número de VLFs.

Com uma rápida pesquisa no Google podemos também encontrar scripts para verificação do estado do nosso t-log, e a partir daí tomar decisões.

Minha ideia aqui não é dedicar um post a este assunto, pelo menos por agora, porém temos boa informação nestes artigos:

Transaction Log VLFs – too many or too few?
Transaction Log Physical Architecture

Até a próxima!

Summer Performance Palooza

Olá Pessoal, No dia 27 de junho entre 12:00 a 20:00 o PASS promoverá o Summer Performance Palooza. O evento é hosteado pelo Virtual PASS de performance e terá palestras de alto nivel. Lembrando que o evento será pela plafatorma da Citrix GoToWebinar então é bom se registrarem antes para se familiarizar com a mesma. […]

Compilando um codigo C# para o SQL Server

Olá pessoal, Esses dias precisava gerar uma DLL de um codigo C# para um projeto que estou fazendo no SQL Server. Como eu não sou um expert em desenvolvimento eu pedi para que alguns dos meus amigos DEV’s me ajudassem nisso. Até o momento eu pensava que compilar um codigo e gerar uma DLL só […]

Episódio XIi – O nascimento de uma estatistica

No último SQLPort surgiu uma questão relativa ao momento em que uma estatistica é criada e actualizada. Hoje iremos analisar algumas situações para perceber o momento em que esta informação, preciosa para o Optimizer, é gerada e actualizada. Vamos começar por criar duas tabelas sendo que uma é Clustered e outra uma Heap:



De notar que temos os 3 AUTO (stats) activados e, como tal, podemos verificar que foi criada uma estatistica para um indice clustered mas que a mesma não se encontra actualizada. Vamos preencher as tabelas e verificar o que acontece às estatisticas:

Podemos observar que não foram criadas novas nem actualizadas as estatisticas existentes. De certa forma isto indicia que as estatisticas só serão criadas aquando da realização de uma consulta à tabela como podemos verificar:


sendo que o mesmo acontece para as tabelas Heaps


Mas um fenómeno interessante acontece quando inserimos mais 100 registos em cada tabela e executamos a mesma consulta:


Podemos verificar que as estatisticas não foram actualizadas não obstante termos duplicado o tamanho da tabela e realizado uma consulta. E se inserirmos mais 10.000 registos em cada tabela ?


Podemos verificar que as estatisticas continuam sem ser actualizadas.

Não obstante o número de actualizações realizadas à tabela, o MSSQL não actualizará as estatisticas, embora já esteja mais do que na hora, porque simplesmente não necessita delas. Isto deve-se ao facto do Execution Plan já existir para o comando que estamos a executar. Se fizermos um comando de consulta equivalente, mas diferente, vamos constatar que o Optimizer irá forçar a actualização das estatisticas para criar um novo Execution Plan:


A questão de quando são criadas as estatisticas torna-se importante, especialmente em tabelas de maior dimensão que sofrem muitas actualizações e são utilizadas em muitas consultas, pelo facto de que este processamento pode criar um delay na criação dos Planos de Execução. Existe ainda uma opção, a nível da BD, que pode ser activada que irá protelar a criação de estatisticas para um momento posterior: Auto Update Stats Async. Esta opção levanta alguma controvérsia mas essa (a controvérsia) fica para outra ocasião...



Sessão online sql 2012!



Relativamente á sessão online de SQL 2012 (vejam aqui post anterior) do próximo dia 6, a pedido de alguns aqui fica uma ementa que pode ainda ser alterada (reduzida):
        Presentation: Introduction to SQL Server 2012
        Introducing SQL Server 2012 Transact-SQL Improvements
        Introducing SQL Server 2012 Columnstore Indexes and Table Partitioning Improvements
        Introducing SQL Server Data Tools for Visual Studio 2010 and SQL Server 2012 Data-Tier Application Improvements
        Introducing SQL Server 2012 Integration Services Improvements
        Introducing SQL Server 2012 MDS Improvements, DQS and SSAS Tabular

O nível de dificuldade é difícil indicar mas não estamos a falar de uma sessão deep level. O que pretendo fazer é falar das novidades no geral e depois dar exemplos de grande parte dos tópicos listados.
Por isso, se ainda não mexeram a sério em SQL2012 e querem ver algumas destas novidades, inscrevam-se!
O evento é gratuito. Faz parte do plano que temos na Rumos para difundir novos canais e mostrar que podemos ter formação com muita qualidade desta forma.
Outra mais-valia, é poderem aceder ao link (que vão receber durante a próxima semana) em dispositivos moveis. Não utilizem o browser mas as seguintes aplicações:


Ainda esta semana assisti a uma formação RH por este canal, e tudo decorreu muito bem.
Ainda estou a pensar se vamos permitir muita interação na sessão, mas prometo que todas as questões que não tivermos tempo para abordar durante a sessão, vão ser tratadas\respondidas logo que possível após a sessão. Assim como o código que utilizar.
Inscrevam-se aqui e apareçam!

Inscrições: http://formacao.rumos.pt/noticia.rumos?id=1799

Alteração de Data

Pessoal, devido ao feriado e feriadão como muitos devem ter aproveitado e queremos oferecer o máximo de conhecimento nas melhores condições… Optamos por alterar a data do webcast do 4º Encontro do Grupo para a próxima semana dia 6 de … Continue reading

ARQUITETURA SQL Server Parte 5: SQL Server Workers


Pessoal no segundo post para hoje vou falar sobre os Workers!
Uma worker pode ser tanto uma fibra quanto uma thread gerenciada por um scheduler. Cada scheduler contém um número de workers limitado baseado no parâmetro “max worker threads” ou pela arquitetura, o parâmetro “max worker threads” pode determinar o número de workers que serão criadas, desde que seja ajustado para um valor diferente de 0, o que não é recomendado. Se o valor de “max worker threads” estiver ajustado para 0, o número máximo de workers que podem ser criadas é baseado na arquitetura e no número de processadores que a instância do SQL Server está enxergando. Cada scheduler é responsável por criar e destruir as suas workers conforme seja necessário. Uma worker não se movimenta entre os schedulers, porem como são criadas e destruídas, pode parecer que elas estão migrando por entre os schedulers. 


Quando um scheduler recebe uma nova requisição e ele não encontra uma worker disponível, uma nova é criada por ele. Existem basicamente duas condições para que uma worker seja destruída: se ela ficar 15 minutos sem utilização ou se a instância do SQL Server estiver sob pressão de memória. Em sistemas 32 bits uma worker utiliza ao menos 500 KB de memória e em 64 bits pelo menos 2 MB.


Normalmente o SQL Server gerencia muito bem as workers, mesmo em sistemas extremamente carregados, o número de workers acaba ficando bem abaixo do máximo configurado através do parâmetro Max Worker Threads. O número máximo de workers para a instância do SQL Server é determinado da seguinte forma:


Arquitetura
Processadores lógicos
Max Worker Threads
x86
Até 4
256
x86
Mais de 4
256 + ((# Procs – 4) * 8)
x64
Até 4
512
x64
Mais de 4
512 + ((# Procs – 4) * 16)



                Para saber quantas workers podem ser criadas numa instância do SQL Server utilize a query abaixo:



SELECT max_workers_count

FROM sys.dm_os_sys_info



O parâmetro “max worker threads” você pode configurar usando o sp_configure:







 

Links de referência utilizados para o post:









Livro de referência utilizado para o post:



Microsoft SQL Server 2008 Internals – Kalen Delaney 

Até a próxima galera!
http://www.virtualpass.com.br/

ARQUITETURA SQL Server Parte 4: Execution Model



Pessoal primeiramente peço desculpas pela demora em postar coisas novas, o assunto deste post é mais delicado e acabei demorando mais tempo para escreve-lo, Execution Model do SQL Server, vamos começar pelas requisições para que fique explicado da melhor forma possível desde o começo!

Quando uma requisição de usuário é enviada ao SQL Server, conhecida como SPID ou SESSION_ID, é feito um controle sobre ela através do UMS (User Mode Scheduler), antes de falar sobre ele é importante manter em mente sobre as requisições que:


1. Uma conexão está mapeada para um sessão após o login (SPID ou SESSION_ID).

2. Cada sessão submete requisições (requests) para execução.

3. Cada requisição (ou batch) é mapeada para uma ou mais tarefas (tasks).

4. As tarefas (tasks) são submetidas para os schedulers para execução, com base no fator de carga.

5. No scheduler a tarefa é mapeada para um thread, e continua com esta thread (running, suspended, runnable) até que seja finalizada.


 Voltando ao UMS, este não substitui o scheduler do Windows, apenas garante que as threads submetidas para execução privilegiam o modelo de execução do SQL Server. 


Cada requisição (ou tarefa) é submetida para um UMS para execução e associada a uma thread. Formalmente, o UMS está associado a uma CPU específica apenas quando o affinity mask está definido. Existe um UMS (ou scheduler) para cada CPU visível para uma instância do SQL Server. O UMS é composto por algumas filas e listas, que são usadas para gerenciar as suas threads (workers) e requisições associadas. 


Cada UMS ira ter no máximo uma requisição executando, uma fila chamada de runnable queue, a qual mantem as requisições executando porém que já gastaram seu tempo na CPU e estão aguardando a mesma ficar disponível novamente para voltarem a efetivamente executar, uma lista chamada de waiter list, a qual armazena as requisições que aguardam por demais recursos, por exemplo, uma query com status RESOURCE_SEMAPHORE está aguardando um “grant” de memória, e por último, uma “work queue”, fila de requisições aguardando por worker threads. 
  
Cada worker thread está associado a uma thread do Windows e junto com outras, são agrupadas nos schedulers. O fluxo, resumidamente, seria mais ou menos o abaixo:
 
            Uma requisição rodando que precisa esperar por algo (disco por exemplo) é movida para a Wait Queue > Se houver alguma requisição na Runnable Queue ela será colocada para executar > As requisições da Wait Queue que já possuem os recursos para executar entram no final da Runnable Queue.


    Acredito que uma boa analogia seja um jogo de vôlei:


Imagine que o jogador na quadra está em “running” porem já esgotou suas forças (atingiu o quantum de CPU) e precisa descansar e então é substituído (enviado para a Runnable Queue), um jogador que estava fora mais que já havia jogado volta à quadra (sai da Runnable Queue), os jogadores que estavam se aquecendo já estão prontos para irem a quadra (saem da Waiter list) e esperam apenas o chamado do técnico (vão para o final da Runnable Queue).


Este mecanismo que fez nascer uma metodologia relacionada a tuning chamada de Waits and Queues, irei falar mais pra frente das esperas mais importantes, mais detalhes vocês também encontram no documento do link abaixo que também foi usado para a escrita deste post:





Outras referências: 


Livro Microsoft SQL Server 2008 Internals – Kalen Delaney



Qualquer dúvida estou à disposição pessoal! Um abraço!
http://www.virtualpass.com.br/
Go to Top