No último post, comentei sobre um erro relacionado à falta de memória no servidor SQL Server. Essa era a mensagem de erro:

Msg 6624, Level 16, State 7, Procedure sp_xml_preparedocument, Line 1
XML document could not be created because server memory is low. Use sp_xml_removedocument to release XML documents.

Como próximo passo, minha sugestão foi investigar as sessões do servidor.

select session_id, memory_usage from sys.dm_exec_sessions
where status = 'sleeping' and is_user_process = 1

Assim, suspeitamos que a sessão 56 era culpada porque estava alocando 3080 páginas de 8Kb alocadas (24MB).

Algo Estranho!

Repetindo:

“… suspeitamos que a sessão 56 era culpada porque estava alocando 3080 páginas de 8Kb alocadas (24MB)”

Esse parece um comportamento diferente…

Como que 24MB pode afetar causar falta de memória em um servidor com GB de memória?

Algo estranho…

Monitorando Memória

Monitorar o consumo de memória usando a sys.dm_exec_sessions não é um método confiável. Essa DMV apresenta toda a memória consumida de forma exclusiva por uma sessão. A palavra “exclusiva” é chave no entendimento, porque isso significa que parte da memória não é considerada. Na realidade, a maior parte da memória é compartilhada. Por exemplo:

• Buffer Pool
• Procedure Cache
• Security Token Cache
• Pools de Memória
• Caches em geral

A forma correta é acompanhar o consumo de memória é utilizar os Memory Clerks.

select * FROM sys.dm_os_memory_clerks

Aqui descobrimos que o problema está relacionado com o MEMORYCLERK_SQLGENERAL (normalmente associado ao compilador).

No próximo post, vamos abordar o MemObj – esse é o subcomponente do Memory Clerk. Vamos concluir com 100% de certeza que o problema está relacionado com os documentos XML.

Existe uma forma “hardcore” para acompanhar todas as alocações de memória no SQL Server. Podemos criar um pacote XEvent e acompanhar o evento “XeSosPkg::page_allocated” e gerar um stack trace (stack dump). Por exemplo, nas alocações de memória na procedure sp_xml_preparedocument, observamos as alocações de memória realizadas pelo componente MSXMLSQL.

14d9dc3c 781181f8 sqllang!CIMallocYieldWrapper::Alloc
14d9dc58 7811eb23 MSXMLSQL!_MemAlloc+0x27
14d9dc94 7811de7e MSXMLSQL!Document::newDocument+0x18
14d9dccc 7811df2a MSXMLSQL!_createDOMDocument+0x19
14d9dcf4 78117d1b MSXMLSQL!CreateDOMDocumentVI+0x3b
14d9dd0c 6f77ecb0 MSXMLSQL!ClassFactory_CreateInstance+0x50
14d9ddfc 6f777b1f sqllang!CXMLDocsList::LoadDocument+0x149
14d9de48 6f777d6b sqllang!CXMLDocParamInfo::Load+0xaa
14d9df5c 6f46d61a sqllang!SpXmlPrepareDocument+0x1ab
14d9e004 6f46cd77 sqllang!CSpecProc::ExecuteSpecial+0x25b
14d9e380 6ecb463f sqllang!CXProc::Execute+0x14e
14d9e448 6f492a97 sqllang!CSQLSource::Execute+0x910
14d9e480 6f4925a4 sqllang!CStmtExecProc::XretLocalExec+0x1e0
14d9eb30 6f4902aa sqllang!CStmtExecProc::XretExecExecute+0x527
14d9eb4c 6ec3a882 sqllang!CXStmtExecProc::XretExecute+0x27
14d9ebe4 6ec3bd9c sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x352
14d9ed0c 6ec3b664 sqllang!CMsqlExecContext::FExecute+0x878
14d9ede0 6ec3fc40 sqllang!CSQLSource::Execute+0x7d5
14d9efa0 6ec3ede9 sqllang!process_request+0x3fa
14d9f100 6dc80941 sqllang!process_commands+0x38c
14d9f64c 6dc80d6d sqldk!SOS_Task::Param::Execute+0x292
14d9f694 6dc80b9e sqldk!SOS_Scheduler::RunTask+0xa2
14d9f6f4 6dc583e6 sqldk!SOS_Scheduler::ProcessTasks+0x316
14d9f780 6dc58514 sqldk!SchedulerManager::WorkerEntryPoint+0x2e7
14d9f7a0 6dc57f3a sqldk!SystemThread::RunWorker+0xae
14d9f814 6dc58268 sqldk!SystemThreadDispatcher::ProcessWorker+0x2fe
14d9f888 7770495d sqldk!SchedulerManager::ThreadEntryPoint+0x20b

Nem sempre é possível utilizar stack traces para acompanhar o consumo de memória. Por isso, existe uma série de mecanismos (Broker, Clerks, MemObj) que auxiliam na tarefa de monitoração de recursos.

Tudo começou com a discussão de XML.

Memory Leak usando OPENXML
http://blogs.msdn.com/b/fcatae/archive/2014/02/18/sp-xml-preparedocument-leak.aspx

Existem duas procedures:

• sp_xml_preparedocument
• sp_xml_removedocument

A primeira serve para reservar a memória para o documento, enquanto que a segunda libera o recurso. Existe uma forma de causar um Memory Leak chamando várias vezes a procedure de “prepare” e esquecendo de liberar a memória com “remove”.

Em todos os problemas de alto consumo de memória, recomendo que utilize a monitoração de Memory Clerk.

Monitorando Memória com os Clerks
http://blogs.msdn.com/b/fcatae/archive/2014/02/25/monitorando-memoria.aspx

Se mesmo assim não for possível descobrir, podemos acompanhar o consumo de memória através dos MemObj.

Cada Memory Clerk é composto por uma série de alocações feitas pelo subcomponente chamado MemObj. Experimente rodar a query abaixo:

select *
from sys.dm_os_memory_objects mo join
     sys.dm_os_memory_clerks mc
on mo.page_allocator_address = mc.page_allocator_address
where mc.type = 'MEMORYCLERK_SQLGENERAL'
order by pages_in_bytes desc

Na query exemplo, estamos procurando os MemObj responsáveis pelo alto consumo do Memory Clerk.

O resultado apresenta os principais subconsumidores de memória:

Agora podemos afirmar com 100% de certeza que o principal responsável é o MEMOBJ_MSXML. Sim – o problema de Memory Leak foi causado pelo XML!

Nos últimos posts, falamos sobre o Memory Clerk e o MemObj.

Monitorando Memória com os Clerks
http://blogs.msdn.com/b/fcatae/archive/2014/02/25/monitorando-memoria.aspx

Usando os Memory Objects
http://blogs.msdn.com/b/fcatae/archive/2014/03/05/memoria-memory-object.aspx

Nesse artigo vou utilizar um post do Bob Dorr sobre o CMemThread

How It Works: CMemThread and Debugging Them
http://blogs.msdn.com/b/psssql/archive/2012/12/20/how-it-works-cmemthread-and-debugging-them.aspx

Operador new

O SQL Server, assim como grande parte dos programas escrito em C++, utiliza o operador new para criar objetos.

obj = new CClass( );

Essa rotina é transformada em uma chamada a um objeto MemObj. Podemos dizer que esse comando é equivalente a:

obj = memObj.AllocateMemory( sizeof(CClass) );

// Seguido pela chamada ao construtor da classe

Como cada MemObj pertence a uma classe de Memory Clerk (sempre assim), então é possível sumarizar o consumo total de memória usando a DMV sys.dm_os_memory_clerks. A muito grosso modo, podemos dizer que o Memory Clerk é o somatório de toda memória utilizada pelo MemObj.

Memory Objects (MemObj)

Existem objetos MemObj dedicados por sessão, objeto, processador, etc. Em outras palavras, o SQL Server utiliza uma grande quantidade de MemObj em seu processo. Quer confirmar? Rode o comando:

select * from sys.dm_os_memory_objects

Observe que foram retornados 686 MemObj diferentes! Os objetos MemObj utilizam “page allocators”, que são as interfaces de acesso ao Memory Clerk – semelhante a um proxy.

Alocação de Memória Single-Threaded

Apesar de existir múltiplos MemObj, há uma restrição de acesso em paralelo. Todos esses objetos são single-threaded e serializam a chamada de alocação por memória. Se um MemObj for compartilhado entre sessão, então observamos a “contenção por MemObj” e será visível ao administrador de sistema.

select * from sys.dm_exec_requests

No exemplo, observamos que uma das sessões está alocando memória (55), enquanto que há sessões esperando (56, 57, 58, 59, 60).

Famoso CMEMTHREAD

A origem do nome CMEMTHREAD é decorrente de um lock interno do SQL Server. Utilizando um dump de memória, podemos observar o problema em detalhe. Note que na linha 08 existe uma referência a CMemThread<CMemObj>.

Se fosse possível ler o código do SQL Server, então haveria algo assim:

CMemThread<CMemObj>::Alloc( size )
{
    if( inUse ) {
        wait( CMEMTHREAD );
    }
   
    latch_get ();
    
    CMemObj.internal_allocate_memory (size);

    latch_release ();
}

Trace Flag 8048

A chance de ocorrer uma contenção de memória no objeto MemObj é mínima, mas sempre existe a possibilidade de isso acontecer e impactar diretamente o desempenho da instância.

Existem 3 tipos de distribuição de MemObj:

• 1 global
• 1 por NUMA Node
• 1 por CPU lógico

Uma forma de aliviar a contenção é criar objetos MemObj por CPU. Nesse caso, fica quase impossível haver concorrência de acesso. Esse comportamento é habilitado através do Trace Flag 8048.

SQL Server 2008/2008 R2 on Newer Machines with More Than 8 CPUs Presented per NUMA Node May Need Trace Flag 8048
http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus-presented-per-numa-node-may-need-trace-flag-8048.aspx

Hoje foi lançado oficialmente o SQL Server 2014. General Availability (GA) será no dia 1 de abril. Nessa data a mídia será liberada, assim como a imagem da VM no Windows Azure.

The Official Microsoft Blog: SQL Server 2014 released to manufacturers, will be generally available April 1
http://blogs.technet.com/b/microsoft_blog/archive/2014/03/18/sql-server-2014-released-to-manufacturers-will-be-generally-available-april-1.aspx

Essa é uma excelente notícia não somente para os técnicos, mas também para todo o time de Marketing de SQL. Isso porque nunca tivemos um apelo tão forte quanto a questão do “in-memory database” – funcionalidade capaz de melhorar o desempenho em 5x, 10x e até em 50x.

Afinal, o que seria esse conceito de “in-memory” e por que não tínhamos essa funcionalidade antes? Os dados não ficavam cacheados em memória?

SQL Server 2014 traz duas funcionalidades que compõe o conceito do “in-memory”:

• xVelocity v2– Conhecido como ColumnStore porque, ao contrário do armazenamento baseado em linhas (row based), o xVelocity guarda os dados por colunas (column store). Esse novo formato permite obter grande taxas de compressão nas tabelas e, portanto, redução no consumo de disco e tempo de acesso. xVelocity v2 é uma evolução da primeira versão disponível no SQL 2012, sendo possível criar índices Clustered e Read/Write.
• Hekaton - Conhecido por “in-memory OLTP”. Esse é um engine completamente diferente do tradicional, no qual os dados são armazenados em arquivos especiais (diferentes dos conhecidos MDF e NDF) e utilizam um cache isolado (não é o Buffer Pool). O gerenciamento de memória é realizado em um Memory Broker dedicado (XTP – eXtreme Transaction Processing).

Ambas as tecnologias assumem uma grande quantidade de memória disponível para a instância SQL Server. Dessa forma, não é preciso se preocupar tanto com o Buffer Pool. A grosso modo seria dizer que antigamente o banco de dados passava mais tempo no disco e hoje em dia, devido a quantidade de memória dos servidores, podemos deixar o banco de dados em memória – isso torna possível utilizar os recursos “in-memory”.

Gostaria de destacar as funcionalidades escondidas e que merecem um post dedicado a cada uma delas.

• Resource Governor
• Delayed Transactions
• Buffer Pool Extension
• TempDB local

Além dessas funcionalidades, há uma série de melhorias no Availability Groups. Você sabe dizer qual foi a principal funcionalidade introduzida no SQL Server 2014 relacionada ao AlwaysOn? Eu tenho uma opinião… antes deixe o seu palpite nos comentários!

Semana passada alguém me perguntou sobre esse “Ring Buffer”. É incrível a coincidência de que sempre que falo sobre memória, alguém comenta sobre esse recurso. Esse assunto sempre volta a tona, eu mesmo já escrevi um post sobre Ring Buffer e agora estou escrevendo novamente.

O que é um Ring Buffer?
A tradução literal é um log circular.

Esse é um componente base disponibilizado pelo SQLOS para os demais componentes do SQL Server. Qualquer funcionalidade pode registrar uma informação no log circular. Essas informações ficam em memória e são perdidas em caso de restart do serviço.

Como posso enxergar os logs?

Utilize a DMV sys.dm_os_ring_buffers para observar todas as entradas. Nesse caso, temos 3140 registros cadastrados.

Quantos logs circulares existem?

Existe uma única DMV chamada sys.dm_os_ring_buffers (note que “buffers” está no plural), que representa vários logs circulares. Para identificar todos os diferentes logs circulares, podemos usar o campo “ring_buffer_type”:

Embora a DMV represente a união de todos os registros, cada tipo (ring_buffer_type) representa um “log circular físico”. É semelhante a uma view, que referencia a várias tabelas.

Como ler as informações?

Os dados ficam armazenados na coluna record, enquanto que a hora é registrada em timestamp.

Podemos transformar o campo record em tipo XML, facilitando o uso de XQuery para as consultas.

Em relação ao timestamp, é preciso fazer uma mágica para apresentar o formato de data/hora.

SELECT
    DATEADD (ms,
        [timestamp] - (SELECT ms_ticks FROM sys.dm_os_sys_info),
        GETDATE()) AS timestamp

FROM sys.dm_os_ring_buffers order by timestamp desc

Conclusão

A análise dos logs circulares é bem interessante e permite identificar uma série de comportamentos do SQL Server. Embora esses logs já existam nativamente, é possível criar logs customizados usando XEvents. A partir daí que temos grandes poderes para compreender como funciona as minúcias do SQL Server.

Encontrei um exemplo nos meus arquivos. Não sei exatamente quem me passou ou se encontrei no documento de performance, mas vou deixar registrado no blog. Frequentemente utilizo o script para lembrar da sintaxe do XQuery e da conversão de timestamp.

SELECT CONVERT (varchar(30), GETDATE(), 121) as runtime,
DATEADD (ms, -1 * (sys.ms_ticks - a.[Record Time]), GETDATE()) AS Notification_time, 
  a.* , sys.ms_ticks AS [Current Time]
  FROM
  (SELECT x.value('(//Record/ResourceMonitor/Notification)[1]', 'varchar(30)') AS [Notification_type],
  x.value('(//Record/MemoryRecord/MemoryUtilization)[1]', 'bigint') AS [MemoryUtilization %],
  x.value('(//Record/MemoryRecord/TotalPhysicalMemory)[1]', 'bigint') AS [TotalPhysicalMemory_KB],
  x.value('(//Record/MemoryRecord/AvailablePhysicalMemory)[1]', 'bigint') AS [AvailablePhysicalMemory_KB],
  x.value('(//Record/MemoryRecord/TotalPageFile)[1]', 'bigint') AS [TotalPageFile_KB],
  x.value('(//Record/MemoryRecord/AvailablePageFile)[1]', 'bigint') AS [AvailablePageFile_KB],
  x.value('(//Record/MemoryRecord/TotalVirtualAddressSpace)[1]', 'bigint') AS [TotalVirtualAddressSpace_KB],
  x.value('(//Record/MemoryRecord/AvailableVirtualAddressSpace)[1]', 'bigint') AS [AvailableVirtualAddressSpace_KB],
  x.value('(//Record/MemoryNode/@id)[1]', 'bigint') AS [Node Id],
  x.value('(//Record/MemoryNode/ReservedMemory)[1]', 'bigint') AS [SQL_ReservedMemory_KB],
  x.value('(//Record/MemoryNode/CommittedMemory)[1]', 'bigint') AS [SQL_CommittedMemory_KB],
  x.value('(//Record/@id)[1]', 'bigint') AS [Record Id],
  x.value('(//Record/@type)[1]', 'varchar(30)') AS [Type],
  x.value('(//Record/ResourceMonitor/Indicators)[1]', 'bigint') AS [Indicators],
  x.value('(//Record/@time)[1]', 'bigint') AS [Record Time]
  FROM (SELECT CAST (record as xml) FROM sys.dm_os_ring_buffers
  WHERE ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR') AS R(x)) a
CROSS JOIN sys.dm_os_sys_info sys
ORDER BY a.[Record Time] ASC

Tenho mais um script utilizando XEvent gravando os registros no Ring Buffers. Vou procurar e postar em seguida.

No mês de março tive o privilégio de escrever para o Editorial do MSDN Newsletter. Tenho acompanhado um pouco o cenário de Big Data e, com um pouco de conhecimento do mercado corporativo, decidi falar sobre onde o SQL Server se encaixa. Segue o texto na íntegra:

Neste mês anunciamos o lançamento oficial do SQL Server 2014, que estará disponível comercialmente em 1° de Abril.

Em meio a todo o alvoroço do Big Data, qual seria a importância de um banco de dados relacional como o SQL Server? Todos falam de Big Data como uma estratégia diferencial para as empresas. A fim de me manter atualizado sobre esse assunto, tenho estudado NoSQL e Hadoop para saber como empregar melhor essas tecnologias no nosso dia a dia. Estava curioso para saber se seriam essas as ferramentas que levariam à adoção do Big Data em massa. A realidade é que muitas empresas têm interesse, mas o caminho mais fácil parece ser através de um tradicional banco de dados relacional.

Ambientes corporativos possuem uma variedade de sistemas interligados. Desde sistemas usando tecnologia de ponta como também aplicações legadas que não podem ser desativadas. É arriscado jogar todos os sistemas no lixo e começar do zero um sistema unificado. Em raras ocasiões há justificativa para tamanho investimento. Portanto, a convivência de diferentes sistemas é um requisito primordial nas empresas. É nesse meio que o banco de dados relacional brilha. Além das características essenciais como auditoria, controle de acesso e backup de dados, ele possui o conceito de separação do modelo lógico e físico.

O modelo lógico de dados foi concebido por Codd (1970), no qual o banco de dados relacional é composto por tabelas e relacionamentos usando chaves primárias e estrangeiras. O desenvolvedor utiliza comandos padronizados SQL ou extensões específicas como T-SQL. O modelo físico de dados permite definir as estruturas de armazenamento, que a grosso modo seria a definição dos índices necessários para suportar as consultas.

A modelagem física, ao contrário da modelagem lógica, é um processo iterativo e pode ser ajustada no dia a dia. Um administrador de banco de dados pode extrair métricas de uso dos dados e otimizar a forma de armazenamento sem a necessidade de alterar o código da aplicação. SQL Server 2014 trará agora o diferencial da tecnologia "in-memory", capaz de melhorar o desempenho em 10 vezes e reduzir o espaço consumido pelos dados. Todas essas funcionalidades podem ser adotadas pelas aplicações baseadas no banco de dados SQL Server, bastando migrar para a nova versão e ajustando o modelo físico.

Ao observar essa evolução, minha conclusão é que as tecnologias possuem seu nicho específico e nenhuma delas canibaliza as demais. Big Data é o grande "hype", que estende as funções analíticas sobre os dados armazenados, gerando a demanda por novas tecnologias. Enquanto que o NoSQL especializa a tarefa de aquisição de dados em escala, o Hadoop evolui a ideia de "map-reduce" para aumentar a capacidade analítica. O banco de dados relacional continua firme em sua posição e mais vivo do que nunca como uma plataforma crítica de integração de sistemas.

Com o lançamento oficial do SQL Server 2014, estou trabalhando em uma surpresa. Fiquem ligado!

Estava em um reunião para definir a estratégia de storage do cliente, quando alguém comentou (não lembro das palavras exatas, mas era similar a):

“Vocês querem usar um JBOD para guardar os dados?”

Que raios seria um JBOD? Essa é uma sigla curiosa… mais curioso é o seu significado: Just a Bunch of Disks. Essa história já faz 6 anos e vou dizer que foi um grande aprendizado, porque não tinha a menor ideia sobre Storage. Essa foi uma das grandes motivações que levou a estudar esse assunto e curiosamente meus primeiros posts eram relacionados a disco.

A primeira tentativa foi traduzir a sigla JBOD para o português: ABDD – Apenas um Bando De Discos, ou seja, não possui absolutamente nenhum significado.

Logo em seguida, um colega me explicou o básico sobre discos e como que o servidor enxergava. A explicação foi bem didática e começou falando sobre como os discos eram fisicamente adicionados em um servidor. Na realidade, o servidor (a máquina física) não tem espaço para adicionar dezenas de discos, por isso, existe um gabinete específico para adicionar esses discos.

Esse gabinete estava ligado a um servidor, que enxergava esses discos normalmente como “apenas um bando de discos”. Isso significa que haveria um monte de letras D:, E:, F:, G:, etc… cada um representando um disco físico. Portanto, essa é uma organização de discos denominada JBOD.

Agora sempre que me falam de JBOD (Just a bunch of disks), imagino que seja literalmente a foto acima: um monte de discos disponiveis para o sistema operacional.

Em geral, no mundo SQL Server, não gostamos do modelo JBOD – queremos algo que forneça uma redundância da informação. Daí surge a expressão RAID - Redundant Array of Independent Disks, que fornece a capacidade de paridade ou espelhamento dos discos.

Por fim, deixo uma pergunta para ver se o conceito está claro. Qual a diferença entre o JBOD e RAID 0?

Ouvi recentemente o comentário: “comprei um computador novo com 1TB de disco, agora sim vai ficar rápido”. A questão é como podemos dizer se o disco é rápido ou lento?

Resolvi escrever esse post para explorar um pouco mais esse assunto. Por exemplo: qual desses discos abaixo traria melhor desempenho ao banco de dados?

Na primeira foto, são vários discos Serial SCSI de 15k RPM com capacidade de 72GB. Enquanto que na segunda foto, os discos são Fiber Channel de 15k RPM e com capacidade de 300 GB.

Qual possui melhor desempenho?

Sem olhar a especificação do disco é difícil determinar qual deles é melhor. Normalmente o banco de dados requer baixa latência de acesso, que normalmente se traduz em maior velocidade de rotação. Logo, a primeira consideração de desempenho é verificar quantas rotações por segundo que eles fazem: 7200, 10000 ou 15000 (quanto maior, melhor). Existem outras condições que afetam a latência de disco: desde o tamanho do disco ou o tempo de deslocamento do cabeçote, assim como a densidade dos setores e diferença na localização dos dados. Poderíamos ficar discutindo por dias aqui, por isso, prefiro resumir esse tópico aos RPM’s que cada disco apresenta. No caso ambos são de 15000 RPM, ou seja, a latência é igual.

Um segundo ponto é verificar a taxa de transferência medida em MB/s. Em geral, esse comportamento é desejável para operações sequenciais e normalmente utilizadas para as operações de scan em índices e tabelas, assim como em backup dos dados. Nesse momento entra em questão a decisão da interface Fiber Channel ou Serial attached SCSI (SAS) – são tecnologias diferentes e que estão evoluindo em paralelo.

Na linguagem popular, seria perguntar qual o melhor “cabeamento” entre o disco e o PC?

Já houve o tempo que o Fiber Channel era claramente superior ao SCSI, mas já não sei se podemos dizer isso. Vamos a um comparativo do Wikipedia:

Wikipedia - SCSI
http://en.wikipedia.org/wiki/SCSI

Veja que as taxas de transferências variam de 200MB/s a 1600MB/s, embora um disco dificilmente ultrapassa 300 MB/s. Podemos ignorar a questão de FC ou SAS? Quando falamos de apenas 1 disco sim. O cenário muda quando estamos falando de JBOD ou RAID, que conectam vários discos simultaneamente a uma máquina.

Por fim, observamos uma diferença entre os discos apresentados: um deles possui 72GB e outro, 300GB. Nessa questão, o número não influencia no desempenho de forma direta. Um disco maior não é necessariamente mais rápido que um disco menor.

A conclusão curiosa desse post é que o desempenho do disco está diretamente associado a velocidade de rotação. Muitos vão discordar disso e com razão! Há uma série de pontos não cobertos e simplificações aqui… Por exemplo, a primeira coisa que me vem a cabeça é que 288GB (formados por 4 discos de 72GB) é 4x mais rápido que um disco de 300GB.

Enfim, o objetivo é mostrar que tamanho (capacidade) de disco não representa melhor desempenho.

Esse post vou comentar um pouco sobre a virtualização de Hardware usando a tecnologia Hyper-V. O fato é que sempre gostei de máquinas físicas ligadas a storages dedicados. Afinal, sistemas de missão crítica necessitam o máximo de desempenho.

Entretanto, confesso que tenho mudado de opinião. Desde o começo do ano tenho usado cada vez mais a plataforma do Azure para montar laboratórios e fazer demonstrações. A questão é a simplicidade para fazer o deployment de servidores. É impressionante a facilidade com que podemos criar máquinas virtuais, usar os serviços e depois apagar tudo! O desempenho da máquina é adequado e compensa a praticidade de manter na nuvem.

Resolvi rever minha opinião sobre a virtualização de hardware também. Comecei fazendo alguns testes de laboratório usando Hyper-V e, sério, não pude notar a diferença de desempenho. Lógico que existe alguma variação, mas não consegui identifica-la. Em seguida comecei a olhar as novidades do SMB v3.0 e suas funcionalidades:

• Capacidade de scale-out de servidores
• Failover automático
• Distribuição de carga
• Canal de comunicação criptografado

Sinceramente, o que me convenceu foi ver um PERFORMANCE MONITOR AO VIVO:

SENSACIONAL!!! NÃO SEI COMO DESCREVER A EMOÇÃO DE VER 16GB/S!!!

Foi exatamente isso que me convenceu de que é possível ter um sistema com altíssima performance usando a virtualização de hardware e storage. Nunca tinha visto alguém conseguir transferir 16 gigabytes por segundo. A efeito de comparação: um cabo Fiber Channel típico (4Gb) atinge míseros 0,4 GB/s.

Estou bastante confiante em uma arquitetura de virtualização de hardware e storage! Roubei até um slide do Jose Barreto para ilustrar a ideia:

Por fim, na sexta-feira, participarei como convidado de uma apresentação do mestre Fabio Hara: “SQL Server over SMB - Como tirar vantagem das melhorias no Windows Server 2012 R2”.

Até a próxima!

Decidi começar um experimento diferente, que vai além do blog, que é uma série de vídeos explicativos sobre o funcionamento do SQL Server. Há muito tempo tenho pensado nessa ideia e finalmente se tornou realidade. A série estréia no Channel 9.

http://channel9.msdn.com/Series/SQL-Fundamentos

Ainda não planejei o número exato de vídeos. Gostaria de fechar em 10 módulos para cobrir os principais conceitos de banco de dados e começando o assunto com a arquitetura do SQL Server.

É uma nova experiência e que me trará muitos aprendizados.

Confiram e vejam o que acham!

Sphynx, Shiloh, Yukon, Katmai, Kilimanjaro, Denali.. você já ouviu falar desses nomes?

Eles são os codinomes do SQL Server.

Quer saber mais? Acabei de publicar o vídeo da apresentação "A evolução do SQL Server 7.0 ao 2014".

http://channel9.msdn.com/blogs/fcatae/Evolucao-SQL-Server

Finalmente publicado o primeiro vídeo da série Fundamentos de Banco de Dados.

http://channel9.msdn.com/Series/SQL-Fundamentos/Arquitetura-do-SQL-Server

Nesse episódio vamos falar sobre as grandes famílias de componentes. Para quem já viu minhas palestras, deve ter notado que sempre comento sobre a separação entre Relational Engine (Linguagem, compilação e execução) e Storage Engine. Além disso, temos a família de Protocols (campeão dos problemas de conectividades) e o SQLOS (a família de componentes underground).

Essa semana me surpreendi com o SQL Saturday #325. Fiquei tão empolgado que resolvi investir um tempo para escrever esse post. A escolha do tema foi através de uma conversa no twitter. Obrigado @DemetrioSQLDBA e @SQLInsane pela sugestão.

Frequentemente associamos o SQL Server às operações transacionais. Todas as informações são consistentes graças ao Transaction Log.

Entretanto, existe um serviço nativo do Windows chamado Microsoft Distributed Transaction Coordinator (MSDTC). Esse serviço executa as transações utilizando o protocolo chamado 2-Phase Commit. Qualquer recurso pode participar de uma transação distribuída. Por exemplo:

• SQL Server (claro!)
• Servidores Oracle
• Filas IBM MQSeries
• Componentes COM+

A arquitetura do MSDTC é composta por dois grandes componentes: Transaction Manager (TM) e Connection Manager (CM).

Transaction Manager

O componente do Transaction Manager (TM) é responsável por implementar o protocolo 2-Phase Commit. Embora ninguém fale desse jeito, gosto de pensar que as fases são:

1. Persistência de dados – TM garante que as informações estão gravadas em disco
2. Disponibilidade – O serviço do TM estará disponível para efetivar a modificação

Portanto, quando uma transação distribuída ocorre, todas as informações devem ser gravadas em seu respectivo storage em uma primeira fase. SQL Server armazena a informação no Transaction Log. Da mesma forma, imagino que o Oracle guarda os dados no Redo Log e o MQSeries armazena a mensagem em disco. Embora as informações estejam gravadas em log, elas ainda não estão disponíveis para a aplicação.

Durante a segunda fase, o MSDTC efetiva todas as transações.

• Se qualquer recurso falhou na “fase 1 – persistência de dados”, então todas os recursos falham e fazem o ROLLBACK da informação. Parece estranho pensar que o SQL Server faz rollback do Transaction Log, mas é exatamente isso que ocorre no 2-Phase Commit.
• Se *TODOS* os recursos conseguiram gravar os dados em disco, então é declarada a efetivação dos dados (COMMIT).

Observamos que o principal objetivo do MSDTC é coordenar os recursos transacionais (SQL, Oracle, MQ) usando o conceito de COMMIT ou ROLLBACK. Aqui existe a curiosa situação da transação IN-DOUBT:

• Falhas durante a primeira fase causam o ROLLBACK
• Falhas durante a segunda fase não afetam as transações, que já foram declaradas como COMMIT
• Indisponibilidade de máquina na primeira fase tornam a transação IN-DOUBT – e a resolução é feita quando a máquina volta ao ar

Connection Manager

Em geral, existe um Transaction Manager (TM) por máquina. O serviço do MSDTC utiliza o protocolo RPC para se manter conectado com os demais TM.

RPC é um protocolo antigo e complexo. Todas as máquinas devem disponibilizar o serviço do RPC Locator na porta TCP 135, além de alocar dinamicamente uma porta TCP aleatória. Isso sempre causa dor de cabeça na hora de configurar o firewall. Já cansei de recomendar o artigo abaixo.

Configurando Microsoft coordenador de transações distribuídas (DTC) para trabalhar por meio de um firewall
http://support2.microsoft.com/kb/250367

Em geral, os problemas do MSDTC relacionados à conectividade podem ser facilmente diagnosticados com o DTCPing.

MSDTC não suportado?

Vou deixar como um desafio: você sabe por que o MSDTC não é suportado em um ambiente com Database Mirroring ou Availability Group? A explicação é similar ao motivo de não recomendarmos MSDTC local em instâncias clusterizadas.

De volta ao blog de SQL Server!

Quero aproveitar para falar um pouco do TechEd 2015, evento que ocorrerá nos dias 20 e 21 de maio de 2015.

TechEd 2015
http://www.microsoftinsights.com.br/

Lembro do Osvaldo Daibert e Vinicius Apolinário anunciando o evento em outubro do ano passado.

O tempo passou muito rápido! Fechamos o Call for Papers na semana passada e fiquei muito feliz com o grande número de sessões submetidas para a track de "Plataforma de Dados e Business Intelligence". No próximo post começo a falar um pouco mais sobre a agenda que estamos programando para o TechEd e também um pouco sobre SQL Server.

Semana passada tive a difícil tarefa de escolher as sessões do TechEd 2015. A dificuldade começou pelo fato de que há apenas 8 slots de palestras. Separamos 4 palestras para cobrir o tema de SQL Server relacional, enquanto que Business Intelligence (BI) e Analytics (BA) ficam com as outras. Uma das palestras está reservada para falar do SQL15!

O processo de seleção foi feito com um foco:

• Atualmente existem eventos dedicados para SQL Server e eles não deixam nada a desejar em relação ao nível técnico das palestras. O último SQL Saturday em São Paulo (SQL#325) foi muito bom! Igualmente posso falar dos eventos internacionais, que é o caso do SQLPASS. Excelente evento e material de primeira. Não adianta querer competir com eventos dedicados à SQL Server, então o objetivo do TechEd será apresentar os principais temas que o DBA moderno deve conhecer. Com esse objetivo em mente, fui obrigado a rejeitar a palestras muito específicas como, por exemplo, Policy Based Management e Transparent Data Encryption.

Está claro que as palestras deverão cobrir funcionalidades importantes. Essas seriam:

• Database Infrastructure
• In-Memory Database
• AlwaysOn (HADRON)
• Troubleshooting

Além dessas 4 tópicos, tem uma palestra para fazer um overview do que vem no SQL15. A divulgação oficial das palestras será feito no site oficial do TechEd.

MS TechEd
http://www.microsoftinsights.com.br/

Entrarei em contato com as pessoas que tiveram a palestra aprovada para iniciar o processo e reuniões pré-evento. Infelizmente muitas pessoas da comunidade SQL Server não foram selecionadas – MSFT, MVP, MTAC, etc. Se você submeteu uma palestra e não foi aprovado, ou se você tem interesse em falar em uma futura edição do TechEd, entre em contato para conversarmos.

Enquanto isso, continuamos nossa contagem regressiva para o TechEd 2015. Não perca!

Esse ano de 2015 vai ter mudanças! A primeira grande mudança é que estou voltando OFICIALMENTE ao blog de SQL Server.

Meu post técnico falando sobre Hekaton:

A História do Hekaton – Parte 1
http://www.lab27.com.br/a-histria-do-hekaton-parte-1/

Algo que me incomoda demais é ouvir as pessoas comparando com o DBCC PINTABLE, dizendo que são funcionalidades parecidas. Coloquei alguns argumentos para fundamentar o abismo de diferença entre essas duas funcionalidades. NAAAOOO!!!

Estou postando meu primeiro artigo no Lab27, o blog dos evangelista técnicos da Microsoft Brasil. Como o blog ainda não é muito conhecido, peço a ajuda de todos para que contribuam para divulgar esse endereço. Isso vai ajudar muito a justificar meu trabalho no mundo SQL Server e continuar escrevendo.

Abraços, Fabricio

Durante o processo de entrevista para PFE sempre procurei seguir uma linha de raciocínio para avaliação do candidato. O processo de entrevista era uma pressão para o candidato e também para o entrevistador. Afinal, o entrevistador deve ser rápido e certeiro na avaliação. O time de RH enviava dezenas de currículos para serem revisados, demandando o trabalho de mais de um entrevistador. Por outro lado, os gerentes cobravam consistência entre os entrevistadores: a pior situação era um aprovar, enquanto que o outro reprovava.

O primeiro passo para padronizar o processo de entrevista foi criar um banco de perguntas para identificar quais eram os candidatos com os conhecimentos necessários. Isso criava uma segunda questão: o que aconteceria se essas questões vazassem? O que aconteceria com nosso processo de entrevista se as pessoas decorassem as respostas?

Logo escrevemos o “guia de entrevista para PFE SQL” – o objetivo principal era avaliar o conhecimento do candidato. Estou compartilhando com todos esse documento para que conheçam as perguntas. (Download)

Agora vem a segunda pergunta: por que disponibilizar esse guia de entrevista?

Acredito que todos os DBA’s deveriam ter conhecimentos sobre 1) Query Plan, 2) Performance de Servidor, 3) Manutenção de banco de dados, 4) Storage e cluster. Portanto, esse profissional saberá o que significa SARG, Heap, sql_handle, PAGEIOLATCH, HBA, RAID5, Quorum. Se alguém decorar todas essas siglas, estudando exemplos e cenários, lendo os blogs e artigos… essa pessoa estaria “roubando”?

Não. Uma pessoa que dedica tempo e estuda todos esses assuntos seria um ótimo profissional e conheceria fundamentos importantes do SQL Server. Na verdade, ficaria contente em ver esse tipo de informação difundido na comunidade. Assim, espero que esse guia ajude nos estudos de SQL e, quem sabe, faça você se juntar ao time da Microsoft.

Apenas como nota final, esse guia foi usado durante anos, mas agora está um pouco defasado. Faltam conceitos importantes como, por exemplo, a compactação de linhas/páginas, controle de recursos pelo Resource Governor, a alta disponibilidade usando o Always On, os recursos de In-memory database (Hekaton e Columnstore), etc. Por isso, o processo de entrevista atual não segue mais esse guia.

Após uma longa espera, o TechEd está de volta. Na edição de 2015 teremos uma agenda especial misturando os temas de “cientista de dados” e “administrador de banco de dados”. A agenda foi publicada há algum tempo no site e agora queria comentar um pouco sobre a escolha dos temas:

Primeiro dia

Vamos falar sobre a revolução dos dados. Já vi muita gente dizendo que o termo de “big data” é apenas uma palavra da moda e que deveria ser resumido apenas como “Business Intelligence v2.0” (BI v2.0). De certa forma concordo em parte com essas pessoas… afinal, o objetivo é armazenar um grande volume de dados em um Data Warehousing e depois fazer um Data Mining, termos típicos do BI tradicional.

Por outro lado, existem grandes diferenças em relação à tecnologia empregada. Atualmente, os dados podem ser armazenados de forma não-estruturada (ex: Hadoop e NoSQL) ou processados em memória (tecnologia do VertiPaq ou PowerBI). Indo um pouco além, nem precisamos organizar os dados em modelos star ou snowflakes. Os dados podem ser analisados através de algoritmos genéricos de Machine Learning (seriam esses o Data Mining v2.0?) em tempo real ou em batches.

Esse é uma área em pleno crescimento e que está amadurecendo de forma muito rápida. Aos poucos, vemos mais posições de Data Scientist (analista de dados) aparecendo no mercado.

https://www.microsoftinsights.com.br/trail/trail/Day/1

Ciência de dados com o Microsoft Azure (Big Data) - Luciano Caixeta Moreira e Ivan Lima

Novidades do SQL Server 2016 para Business Intelligence - Diego Nogare

Prevendo o futuro usando modelo de Machine Learning - Thiago Zavaschi

Segundo dia

Apesar de gostar de Machine Learning e Data Analytics, sempre trabalhei com banco de dados relacional. No segundo dia, temos reservado uma agenda cobrindo os temas: Roadmap, Performance, Segurança, Alta disponibilidade e Hardcore.

Assim, começamos com uma visão geral do produto, quando o Rober vai falar de SQL Server 2016 e novidades. Depois resolvi trazer uma palestra de Performance do Roberto Cavalcanti, que vi em um evento interno da Microsoft e me fez relembrar os bons tempos de tuning de SQL nos detalhes. Teremos uma sessão de Alta Disponibilidade com o Nilton e o Marcelinho sobre um assunto que ainda não vi ninguém falar no PASS, que seria sobre clusters de baixo custo. Luan vai falar sobre segurança do SQL Server e tenho muita expectativa sobre essa palestra! Por fim, teremos uma sessão hardcore sobre o Hekaton com o Fred e Alberto, ambos do time do Suporte Premier.

https://www.microsoftinsights.com.br/trail/trail/Day/2

SQL Server em Azure Virtual Machines (Performance) - Roberto Cavalcanti

O que há de novo - SQL Server 2016 - Rober Torres

In-Memory Database Internals - Frederico dos Santos, Alberto Lima

Protegendo o SQL Server de Hackers - Luan Moreno Medeiros Maciel

Estratégias avançadas com Always On (Alta Disponibilidade) - Nilton Pinheiro, Marcelo Fernandes

Estamos a um mês do TechEd 2015 e já comecei a revisar as apresentações! Estamos a todo vapor para entregar um material de alto nível – quem sabe igual ou maior que o PASS!

E quem estiver por lá, vamos aproveitar para conversar.

Fabricio