#12 – Para que serve


Boa tarde, boa tarde…. Olá pessoal, tudo bem?

Mais uma semana começando, para alguns volta as aulas (kkkkk)…. é a mamata esta acabando e o futuro deste país tem que voltar para sua realidade, no mundo capitalista que estamos vivendo, sem o mínimo de educação civica e moral não somos nada.

Deixando de lado este pequeno pensamento, seguindo em frente este é o post de número 12 dedicado exclusivamente a sessão Para que serve, que lentamente esta atraindo novos seguidores ao meu Blog.

Como você já deve ter percebido os posts relacionados a esta sessão tem o objetivo de apresentar ou demonstrar como  códigos de exemplo, aplicativos, utilitários, enfim recursos relacionados diretamente á banco de dados ou gerenciadores de bancos de dados podem ser utilizados como uma possível solução de problemas, bem como, orientar na sua forma de utilização.

Após esta tradicional saudação, chegou a hora de falar sobre o #12 – Para que serve de hoje, tenho a certeza que você vai gostar.

No post de hoje, vou a destacar uma alteração que a Microsoft introduziu no novo SQL Server 2016, que a partir desta versão alterar de maneira direta o comportamento padrão existente atualmente para alocação de dados e autocrescimento para os bancos de dados de usuário ou para o system database TEMPDB.

Em contra partida, neste post vou destacar um pouco sobre a relação das Trace Flag 1117 e 1118 para com estes dois recursos que compõem o SQL Server, sabendo que durante anos ambas foram recomendadas pelas equipes de engenheiros da Microsoft como técnicas para alterar este comportamento padrão, que a partir da versão 2016 poderá ser realizado de uma maneira bem diferente ou até mesmo de forma automática.

Vamos lá….começa aqui o #12 – Para que serve – Alterando o comportamento padrão para alocação de dados e autocrescimento no Microsoft SQL Server 2016 –

Introdução

Até a versão 2014 o Microsoft SQL Server apresentava o mesmo padrão definido desde a versão 2000 para alocação de dados e autocrescimento de banco de dados, comportamento que poderia ser alterado através do uso de recursos externos entre deles as tão conhecidas e temidas trace flags.

Para um melhor entendimento, vou abordar brevemente os dois conceitos, visando esclarecer um pouco o papel de cada um deles, começando por:

Alocação de Dados: Quando se referimos a alocação de dados em uma instância ou servidor SQL Server, estamos fazendo referência a dois recursos de extrema importância que forma o SQLOS, me refiro ao Database Engine e Storage Engine, sendo estes responsáveis em possibilitar o armazenamento, contenção e consumo de dados manipulados pelo SQL Server.

Como destacado anteriormente o Microsoft SQL Server até a versão 2014 não apresentava a capacidade de criar páginas de dados iniciais ou as primeiras oito páginas de dados conhecidas como extended (extensão) identificadas internamente como páginas ou extensões mista, no qual as primeiras páginas ou extended deveriam se iguais, uniforme, do mesmo tipo e apresentar a mesma estrutura contendo somente informações relacionadas a tabelas ou índices.

Você pode estar se perguntando, mas isso não era possível de ter alterado nas versões mais antigas? A resposta simples e direta é SIM, e para tal finadade eramos obrigados a utilizar a Trace Flags 1118 (se quiser saber mais sobre ela acesse: https://www.brentozar.com/archive/2014/06/trace-flags-1117-1118-tempdb-configuration/)

Mas isso na versão 2016 não é mais necessário, para oferecer e permitir esta mudança de comportamento o time de engenheiros da Microsoft dedicados ao SQL Server aplicaram uma pequena mudança na estrutura da Dynamic Management View: sys.databases existente desde as primeiras versões do produto, na qual foi adicionada uma nova coluna chamada is_mixed_page_allocation_on, que pode ser utilizada através do comando ALTER DATABASE. Falarei um pouco mais sobre esta nova coluna posteriormente.

Dando continuidade, vamos conhecer um pouco sobre AutoGrow (Autocrescimento):

Autocrescimento: Opção aplicada aos bancos de dados que define qual deverá ser a fator e forma de crescimento de um banco de dados, também sofreu algumas mudanças.

A partir do SQL Server 2016 todo processo de autocrescimento e alocação de dados será realizado de forma automática, no qual o Database Engine e parceria com o Storage Engine serão autosuficientes capazes de identificar a necessidade de mudar a forma de alocação e autocrescimento do banco de dados, sem recorrer a necessidade de fazer uso da trace flag 1117.

Desta forma, de acordo com a distribuição dos dados alocados em seus respectivos arquivos de dados ou filegroups permitirá que quando um arquivo de dados crescer todos os demais arquivos relacionados ao banco de dados ou filegroup deverão crescer ao mesmo tempo, sendo este o novo comportamento adotado para este banco de dados, algo revolucionará se levarmos em consideração do processo desempenho pelo Storage Engine para alocar e contar os dados.

Esta mudança de comportamento pode ser considerada uma peça chave para o SQL Server no que se relaciona a performance, pois de maneira simultânea teremos arquivos alocados ao mesmo tempo na mesma transação, oferecendo uma redução no tempo estimado para contenção de alocação de dados, o que no final das contas provacará uma sensível diminuição para o Storage Engine controlar o número de pontos de marcação de dados relacionado ao que está alocado para uso.

MIXED_PAGE_ALLOCATION

Nova opção adicionada ao comando ALTER DATABASE que permite aplicar aos bancos de dados de usuário e system database TEMPDB a nova forma de alocação de dados adotada para a versão 2016 do SQL Server, denominada Mixed Page Allocation ou Alocação de Páginas Mistas, na qual destacado anteriormente será possível alocar para toda estrutura de um banco de dados o uso de páginas ou extended mistas, aplicada de implícita para tabelas e índices.

A coluna is_mixed_page_allocation_on apresenta dois valores, sendo eles:

  • 0 = A estrutura de tabelas e índices será alocada de forma uniforme e não permitirá que as primeras páginas de dados ou a primeira extended possa ser formada por uma estrutura mista.
  • 1 = A estrutura de tabelas e índices poderá ser alocada de forma mista permitindo que as primeras páginas de dados ou a primeira extended possa ser formada por uma estrutura mista.

Vale ressaltar que ao realizar uma simples consulta na DMV sys.databases, valor padrão apresentado na coluna is_mixed_page_allocation_on para os bancos de dados de usuário é 0(zero), e para os bancos de dados de sistema: Master, Model e MSDB é 1(Hum) sendo que para este bancos de dados não é permitido alterar a forma de alocação.

Perguntas e respostas

Muito bem, você pode estar coçando a sua cabeça e ainda contendo algumas dúvidas sobre ese possível novo comportamento entre outros conceitos aqui apresentados, no intuito de tentar ajudar, elaborei algumas perguntas:

1. Afinal esta nova opção Mixed_Page_Allocations possui alguma relação com as trace flags 1117 e 1118?
Respondendo de bate pronto: SIM possuem total relação.

2. Esta nova opção substituio uso de ambas as traces flags?
Sim, tem este finalidade mas aplicada somente a partir da versão 2016.

3. Após alterar a forma de alocação para Mixed Page Allocation posso voltar ao formato anterior?
Sim, sem nenhum tipo de risco ou impedimento.

Além das questões a Tabela 1 apresentada abaixo poderá lhe ajudar a entender em qual cenário você poderá fazer uso da mixed_page_allocation ou das trace flags 1117 e 1118:

Database TF 1117 TF 1118
tempdb Não requerida (default) Não requerida (default)
user databases Por padrão será realizada o autocrescimento de forma simples, ou seja, de um único arquivo por vez. Use ALTER DATABASE <dbname> MODIFY FILEGROUP [PRIMARY] AUTOGROW_ALL_FILES para habilitar o crescimento para todos os arquivos de forma simultânea Não requerida. Use ALTER DATABASE <dbname> SET MIXED_PAGE_ALLOCATION  ON para voltar a utilizar alocação mista.
Other system databases (master, model, msdb) -NA- Alocação de páginas em modo mista não pode ser alterada para estes bancos de dados.

Tabela 1 – Cenários para uso da alocação mista ou mudança no autocrescimento.

Referências

https://technet.microsoft.com/pt-br/library/ms190969(v=sql.105).aspx

https://msdn.microsoft.com/en-US/library/bb522682.aspx

https://support.microsoft.com/en-us/kb/2964518

https://msdn.microsoft.com/en-us/library/ms178534.aspx

https://msdn.microsoft.com/en-us/library/bb522469.aspx

https://msdn.microsoft.com/en-us/library/ms187782.aspx

Links

Caso você ainda não tenha acessado os posts anteriores desta sessão, fique tranquilo é fácil e rápido, basta selecionar um dos links apresentados a seguir:

https://pedrogalvaojunior.wordpress.com/2016/12/16/11-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2016/11/15/10-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2016/10/08/09-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2016/08/06/07-para-que-serve/

Conclusão

Cuidar da vida de nossos dados é algo muito importante, mas saber como e de que forma estes podem ser armazenados esta bem acima de qualquer outra preocupação, pensando nisso a Microsoft permitiu a partir da versão 2016 alterar de forma simples, rápida e segura a maneira com nossos bancos de dados podem crescer no decorrer do tempo, bem como, as estruturas internas podem ser criadas e alocadas, capacidade que nos permite melhrorar de maneira sensível atividades relacionadas a como nossos dados podem estar alocados para consulta, possibilitando ganhos de processamento de dados.
Neste post você pode mais uma vez observar que o Microsoft SQL Server esta em constante evolução, um dos produtos mais prestigiados pela Microsoft, buscando sempre trazer melhorais e inovações, algo de extrema importância para qualquer profissional que trabalha com esta tecnologia.

Agradecimentos

Mais uma vez obrigado por sua visita, agradeço sua atenção, fique a vontade para enviar suas críticas, sugestões, observações e comentários.

Nos encontramos em breve, até lá…..

Microsoft SQL Server Migration Assistant 7.2


A Microsoft disponibilizou para download no dia 23 de dezembro o SQL Server Migration Assistant 7.2. Disponível para MySQL, Sybase, Oracle Database, IBM DB2 e Access, o Microsoft SQL Server Migration Assistant é uma ferramenta gratuita que simplifica o processo de migração destes produtos para o SQL Server e Azure SQL.

A ferramenta automatiza todos os aspectos da migração. A versão 7.2 inclui o suporte para:

– Migração do MySQL 4.1 e posteriores para todas as edições do SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016 e Azure SQL DB.

– Migração do Access 97 e posteriores para todas as edições do SQL Server 2012, SQL Server 2014, SQL Server 2016 e Azure SQL DB.

– Migração do Sybase ASE 11.9 e posteriores para todas as edições do SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016 e Azure SQL DB.

– Migração do Oracle Database 9.07.3 e posteriores para todas as edições do SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, SQL Server 2014, SQL Server 2016 e Azure SQL DB.

– Migração do IBM DB2 9.0 e 10.0 no z/OS e das versões 9.8 e 10.1 no Linux/Unix/Windows para o SQL Server 2012, SQL Server 2014, SQL Server 2016 e Azure SQL DB.

Nota: A versão 7.2 também traz suporte preliminar para o SQL Server vNext CTP para Windows e Linux.

Microsoft SQL Server Migration Assistant 7.2

Baixe o Microsoft SQL Server Migration Assistant 7.2

Download da versão 7.2 para MySQL
Download da versão 7.2 para Sybase
Download da versão 7.2 para Oracle Database
Download da versão 7.2 para Access
Download da versão 7.2 para IBM DB2

O Microsoft SQL Server Migration Assistant 7.2 é compatível com o Windows 10 , Windows 7, Windows 8, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2. Ele também requer o .NET Framework 4.0 ou posterior.

As páginas de download também listam alguns requisitos específicos, como MySQL Connector/ODBC v5.1 e Sybase OLEDB/ADO.Net/ODBC provider.

Fontes e Direitos Autorais: Baboo.com

Dica do Mês – Conhecendo a nova DMF sys.dm_exec_input_buffer no Microsoft SQL Server 2016


Bom dia, bom dia, bom dia….. Feliz 2017

Salve, salve comunidade, estou retorno hoje, conforme o prometido após alguns dias de “descanso mental”. Espero que todos tenham passado um ótimo fim de ano e estejam preparados para os desafios de 2017.

Estamos completando o primeiro ano da sessão Dica do Mês, sendo este o post de número 12, poxa vida muito legal ver o quanto de conteúdo e conhecimento já foi transmitido nesta sessão.

Hoje dia 16 de Janeiro primeiro post de 2017 dedicado mais uma vez ao Microsoft SQL Server, dentre os quais voltados exclusivamente a versão 2016, vou destacar um assunto bem conhecido de qualquer DBA denominado Input Buffer.

Não vou destacar do que se trata este conceito mais sim apresentar como a partir do SQL Server 2016 podemos recurperar e coletar as informações relacionado a ele de uma maneira diferente se comparado com as versões anteriores.

Então vamos lá, seja bem vindo ao Dica do Mês número 12……

Introdução

Reconhecer e identificar o que esta sendo transacionado dentro do seu servidor ou instância do Microsoft SQL Server para muitos é coisa de outro mundo, para outros coletar estes dados não passa de um simples comando que você pode executar.

Na verdade os lados da moeda tem a sua verdade, identificar e entender o que esta sendo transacionado não é uma tarefa fácil por isso pode ser considerado algo fora da terra, como também, coletar e armazenar é algo muito simples, e realmente é!!!

Desde as versões mais antigas do SQL Server a maneira mais comum e menos consumista de se obter informações sobre o Buffer ou Input Buffer dentro de um servidor ou instância era através do comando DBCC Input Buffer, onde bastava simplesmente executar este comando para se obter a informações sobre o buffer de uma sessão específica.

Agora na versão 2016 desta RC0 a Microsoft de um novo jeitinho para se obter estes dados através do uso da nova DMF – Dynamic Management Function ou Função de Gerenciamento Dinâmico chamada Sys.dm_exec_input_buffer.

Ao executar pela primeira vez esta DMF, pensei que seria um recurso substituto ao bem e velho DBCC Input Buffer, ao começar a brincar um pouco mais com ela  observei que existe uma pequena similaridade entre ambos.

Similaridade que se tornou mais clara na maneira que a sys.dm_exec_input_buffer apresentar os dados coletados que estão sendo transacionados, o que também acabou ficando somente nisso, durante as diversas execuções que realizei, foi possível  reconhecer algumas pequenas diferenças que podemos reconhecer como vantagens no uso da sys.dm_exec_input_buffer em comparação ao DBCC InputBuffer.

Sys.dm_exec_input_buffer x DBCC Input Buffer

Basicamente a forma de uso de ambos os recursos não posso dizer que seja algo muito diferente, o DBCC InputBuffer você executa de forma direta passando o SID da sessão a qual você deseja obter o buffer, já a sys.dm_exec_input_buffer o mínimo a favor é executar um comando Select direcionado para esta DMF.

Falando das vantagens destaco abaixo as mais fáceis de se identificar:

  1. Ao executar a dmf o resultado é apresentado diretamente como um conjunto de linhas, o que permite em uma bloco de código obter os input buffers de diversas sessões, uma grande vantagem se comparada com o DBCC Input Buffer;
  2. Outra diferença clara é a capacidade de realizar joins com outras DMFs dentre elas: sys.dm_exec_sessions, sys.dm_exec_connections e sys.dm_exec_requests através do uso do operador Cross Join;
  3. Através da execução de uma simples query através do comando select podemos recuperar o buffer de diversas entradas de sessões distintas sem a necessidade de criar um script, tabela temporária ou tabela auxiliar; e
  4. Possibilidade armazenar o resultado da relação de buffers coletados em uma nova tabela.

Exemplos

Como já mencionei anteriormente a forma de uso da sys.dm_exec_input_buffer é bem simples e fácil, como também, a apresentação dos dados coletados, os dois exemplos apresentados a seguir demonstram como podemos fazer uso desta nova DMF no Microsoft SQL Server 2016:

— 1 – Executando um simples Select —
SELECT * FROM sys.dm_exec_input_buffer(52, 0);

dica-12-01Figura 1 – Buffer coletado da sessão 52.

— 2 – Utilizando o operador Cross Apply —
SELECT es.session_id, ib.event_info
FROM sys.dm_exec_sessions AS es
CROSS APPLY sys.dm_exec_input_buffer(es.session_id, NULL) AS ib
WHERE es.session_id > 50;

dica-12-02Figura 2 – Buffers coletados após a execução do exemplo 2.

Referências

Conclusão

Como de costume a cada nova versão ou atualização a Microsft esta apresentando diversas inovações e melhorias no Microsoft SQL Server, mantendo o produto no seu mais alto nível de funcionalidades, recursos e inovações.

Neste post você pode perceber que mais uma vez isso esta presente, uma nova maneira de se obter informações sobre os buffers que estão sendo transacionados e processados dentro de um servidor ou instância do SQL Server através da DMF sys.dm_exec_input_buffers.

Agradecimentos

Mais uma vez obrigado por sua visita, agradeço sua atenção, fique a vontade para enviar suas críticas, sugestões, observações e comentários.

Conto com a sua presença em mais este ano aqui no meu blog….

Feliz 2017!!!