#21 – Para que serve


Olá, pessoal, bom dia.

Tudo bem? E a i como esta a loucura na sua cidade, devido a esta paralisação dos caminhoneiros em todo Brasil? Posso dizer que aqui em São Roque, interior do estado de São Paulo não esta nada fácil.

Independente da falta de combustível, gás de cozinha, entre outras coisas, não me pode faltar força de vontade e disposição para estar aqui no meu blog, publicando mais um post da sessão Para que serve, sendo este o post de número 21.

É a vida de um DBA e MVP não é fácil, mesmo com o Brasil muito prejudicado e praticamente parado, tenho alguns afazeres para hoje, por este e outros motivos, acordei bem cedo para compartilhar com vocês um dos novos recursos adicionados ao Microsoft SQL Server 2017.

Como todos nós já sabemos, a cada nova versão que a Microsoft disponibilizado do SQL Server, uma nova avalanche de conceitos, funcionalidades, comandos e diversidade de possibilidades são adicionadas ao produto, no post de hoje vou apresentar propriamente uma nova funcionalidade deste fascinante Sistema Gerenciador de Banco de Dados, que veio justamente para ser um divisor de águas em uma das principais atividades de qualquer DBA, o tão temido processo de reindexação(reindex) ou reconstrução(rebuild) de índices em nossos ambientes de bancos de dados.

Acredito que você Administrador de Servidores, DBA ou Profissional de TI, já deve ter se deparado por algum momento em situações que necessitavam ou requeriam o processamento de atividades relacionadas aos procedimentos de manutenção de um ou mais índices existentes em um banco de dados, e ai aquela tão ingrata pergunta.

A que horas vamos realizar este procedimento sem impactar em nossos ambientes? E logicamente você já se deparava em seus pensamentos: “Meu deus, vou ter que passar mais uma noite acordado, fazendo manutenções….” Posso dizer por experiência própria que esta é uma da mais duras realidades que eu já enfrentei nesta minha longa jornada de profissional de TI desde 1994… Mas seguinte em frente, a partir do Microsoft SQL Server 2017 isso mudou, o time de engenheiros e desenvolvedores desta nova versão adicionaram um novo recurso denominado “Resumable Online Index Rebuilds”, em uma simples tradução “Reconstrução Online de Índice resumível”, ou seja, a possibilidade de reconstruir um índice de forma online de acordo com a sua necessidade, tendo a possibilidade de interromper o processo de reconstrução sem correr qualquer risco de perda.

Isso não é coisa de outro mundo? A resposta é não, isso é coisa do Microsoft SQL Server 2017.

Sendo assim, chegou a hora de conhecer um pouco mais sobre o post de número 21 da sessão Para que serve. Então seja bem vindo ao #21 – Para que serve – Resumable Online Index Rebuilds.

Espero que você goste….


Introdução

Quando decidimos trabalhar na área de tecnologia, em diversos momentos temos que saber que esta é um das diversas áreas profissionais que no decorrer da nossa carreira somos obrigados a praticamente abrir mão de nossa vida sociais, familiar e até mesmo pessoal.

Trabalhar na área de tecnologia da informação, nos dias de hoje tem mudado muito se comparado ao início dos anos 80, 90 e provavelmente a partir dos anos 2000 isso mudou mais ainda, principalmente para aqueles que optaram assim como eu para trabalhar com banco de dados, quem nunca teve que passar horas e horas madrugada a dentro realizando manutenções em seus ambientes de bancos de dados, com a “simples” missão de tudo estar funcionando a partir de um determinado horário, é parece fácil, parece ser algo simples, parece ser algo suportável, mas não é, e pensando nisso(demorou) que a partir da versão 2017 do Microsoft SQL Server, nós Administradores de Bancos de Dados e Profissionais de Tecnologia, temos a possibilidade de realizar algumas das mais preocupantes atividades de administração de bancos de dados de uma maneira mais usual, simples e pode-se dizer “humana” que é a atividade de reconstrução de índice.

As atividades relacionadas a manutenções de bancos de dados, ainda mais aquelas relacionadas diretamente a índices, são por diversas vezes as mais demoradas, atividades que dependem totalmente do uso de CPU e Disco, recursos físicos de hardwares que podem apresentar em algum momento sobrecarga de processamento, ocasionando situações de contenção “gargalos”, lentidão na leitura e escrita de dados, que nos obrigam a ter que interromper as atividades em execução ou planejadas a posterior.

Legal, acredito que você já tenha conhecido um pouco sobre este recurso de forma conceitual, vamos agora colocar a mão nos teclados e conhecer de forma prática como fazer dele, para isso vamos preparar nosso ambiente a partir de agora.

Criando o Ambiente

Para realizar nossa simples prática, começaremos pela execução do Bloco de Código 1, responsável por criar a seguinte estrutura:

  • Database: ResumableOnlineIndexRebuilds;
  • Table: ResumableOnlineIndexRebuildsTable;
  • Clustered Index: PK_ResumableOnlineIndexRebuildsTable_Codigo; e
  • Data Compression: Page.

— Bloco de Código 1 —
— Criando o Banco de Dados —
Create Database ResumableOnlineIndexRebuilds
Go

— Acessando o Banco de Dados —
Use ResumableOnlineIndexRebuilds
Go

— Criando a Tabela ResumableOnlineIndexRebuildsTable —
Create TABLE ResumableOnlineIndexRebuildsTable
(Codigo int IDENTITY(1,1) NOT NULL,
Cliente int NOT NULL,
Vendedor varchar(30) NOT NULL,
Quantidade smallint NOT NULL,
Valor numeric(18, 2) NOT NULL,
Data date NOT NULL
Constraint [PK_ResumableOnlineIndexRebuildsTable_Codigo] Primary Key (Codigo))
WITH(Data_Compression=PAGE)
Go

Perfeito, ambiente criado, vamos para o próximo passo, Bloco de Código 2, responsável por inserir um massa de dados aleatória, com uma quantidade de linhas de registros que pode variar de 1 até 1.ooo.ooo(milhão de linhas), contar quantas linhas temos em nossa tabela e seu espaço de alocado:

— Bloco de Código 2 —
— Inserindo a Massa de Dados na Tabela ResumableOnlineIndexRebuildsTable —
Declare @Texto Char(130),
@Posicao TinyInt,
@ContadorLinhas Int

Set @Texto = ‘0123456789@ABCDEFGHIJKLMNOPQRSTUVWXYZ\_abcdefghijklmnopqrstuvwxyzŽŸ¡ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖÙÚÛÜÝàáâãäåæçèéêëìíîïðñòóôõöùúûüýÿ’ — Existem 130 caracteres neste texto —

Set @ContadorLinhas = Rand()*1000000 — Definir a quantidade de linhas para serem inseridas —

While (@ContadorLinhas >=1)
Begin

Set @Posicao=Rand()*130

If @Posicao <=125
Begin
Insert Into ResumableOnlineIndexRebuildsTable (Cliente, Vendedor, Quantidade, Valor, Data)
Values(@ContadorLinhas,
Concat(SubString(@Texto,@Posicao+2,2),SubString(@Texto,@Posicao-4,4),SubString(@Texto,@Posicao+2,4)),
Rand()*1000,
Rand()*100+5,
DATEADD(d, 1000*Rand() ,GetDate()))
End
Else
Begin
Insert Into ResumableOnlineIndexRebuildsTable (Cliente, Vendedor, Quantidade, Valor, Data)
Values(@ContadorLinhas,
Concat(SubString(@Texto,@Posicao-10,1),SubString(@Texto,@Posicao+4,6),SubString(@Texto,@Posicao-12,3)),
Rand()*1000,
Rand()*100+5,
DATEADD(d, 1000*Rand() ,GetDate()))

End

Set @ContadorLinhas = @ContadorLinhas – 1
End

Observação: A quantidade de linhas e tempo de processamento vai depender única e exclusivamente do hardware que você esta utilizando.

— Contando a quantidade de linhas da Tabela ResumableOnlineIndexRebuildsTable —
Select Count(*) From ResumableOnlineIndexRebuildsTable
Go

— Descobrindo o tamanho da Tabela Pedidos —
Exec sp_spaceused ‘ResumableOnlineIndexRebuildsTable’
Go

Por enquanto nenhuma novidade, acredito que você deve ter conseguido executar os blocos de código de forma simples e tranquilo, nosso próximo passo é conhecer e aplicar o processo de rebuild de índice através deste novo recurso, para isso vamos começar utilizando o Bloco de Código 3 apresentado abaixo:

— Bloco de Código 3 —
Alter Index [PK_ResumableOnlineIndexRebuildsTable_Codigo] ON ResumableOnlineIndexRebuildsTable
Rebuild With(ONLINE=ON, RESUMABLE=ON)
Go

Note que estamos fazendo uso neste procedimento de rebuild de dois novos parâmetros adicionados ao comando Alter Index, sendo eles:

  • OnLine: Determina que o processo de rebuild será feito de forma online (por páginas) ou não. Vale ressaltar que o Resumable index rebuild tem suporte somente para o rebuild online, sendo assim, este parâmetro é obrigatório e   devemos sempre utilizar o parâmetro ONLINE=ON.
  • Resumable: Orienta o Database Engine a definir se o rebuild será feito permitindo ou não o uso da opção de Pause/Resume.

Além destes dois principais parâmetros, foram também adicionados outros três como complementares:

  • Max_Duration: Permite definir em minutos, a quantidade de tempo que o rebuild irá executar antes de ser suspenso automaticamente. Esse valor deve ser maior que 0 e menor ou igual a 10080 (1 semana), algo que poderá lhe permitir estabelecer um janela de trabalho e aplicar o procedimento de rebuild de forma programada.
  • Pause: Utilizando esse parâmetro, a operação de rebuild será pausada e ficará aguardando uma nova instrução Alter Index para este índice dar continuidade ao processo ou então o comando ABORT, para interromper o rebuild.
  • Abort: Parâmetro utilizado para interromper o rebuild do índice.

Importante

Dependendo do conjunto de parâmetros utilizados e seus respectivos valores, o Database Engine poderá apresentar algumas mensagens de erros dentre elas:

Mensagem 1 – Informa que você fez uso do parâmetro Resumable=On, mas o parâmetro Online=Off.

Msg 11438, Level 15, State 1, Line 2
The RESUMABLE option cannot be set to ‘ON’ when the ONLINE option is set to ‘OFF’

Mensagem 2 Orienta e informa caso o tempo limite informado acima seja atingido e processo de rebuild ainda não foi concluído e mesmo será interrompido:

Msg 3643, Level 16, State 1, Line 20
The operation elapsed time exceeded the maximum time specified for this operation. The execution has been stopped.
Msg 596, Level 21, State 1, Line 19
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 19
A severe error occurred on the current command. The results, if any, should be discarded.

Seguindo em frente, vamos agora similar um processo de resumo (resume) do nosso índice. Vamos então realizar o processo de resume através do Bloco de Código 4:

— Bloco de Código 4 —
Alter Index [PK_ResumableOnlineIndexRebuildsTable_Codigo] ON ResumableOnlineIndexRebuildsTable
Resume
Go

Nota: Uma forma simples e prática de simular um processo de interrupção do Resumable Index é interromper a execução da query clicando no botão Cancel Executing Query.

Outro detalhe importante, estamos fazendo uso do parâmetro Resume o qual deverá informar ao Database Engine que o procedimento de alteração do nosso índice deverá ser resumido. Quando o comando resume for utilizado e no respectivo momento não existir um procedimento de resumable index aplicado, será retornada a seguinte mensagem de erro:

Msg 10638, Level 16, State 1, Line 70
ALTER INDEX ‘RESUME’ failed. There is no pending resumable index operation for the index ‘PK_ResumableOnlineIndexRebuildsTable_Codigo’ on ‘ResumableOnlineIndexRebuildsTable’.

Monitorando através da sys.index_resumable_operations

Cada alteração aplicada aos nossos índices pode ser monitorada em tempo real através do uso da visão de sistema: sys.index_resumable_operations, a qual teve o acréscimo de uma nova coluna denominada is_resumable, que apresenta a função de informar se o respectivo índice possui o procedimento de resumable aplicado.

O próximo passo consiste no procedimento de pausa (pause), ou seja, realizar uma pausa na execução do resumable index aplicado ao nosso índice, para tal vamos utilizar o Bloco de Código 5 abaixo:

— Bloco de Código 5 —
Alter Index [PK_ResumableOnlineIndexRebuildsTable_Codigo] ON ResumableOnlineIndexRebuildsTable
Pause
Go

Ao realizar o procedimento de pause interrompendo o rebuild de um índice, a sessão responsável pela execução da operação de rebuild irá receber a mesma mensagem de erro de quando o rebuild é pausado:

Msg 1219, Level 16, State 1, Line 17
Your session has been disconnected because of a high priority DDL operation.
Msg 1219, Level 16, State 1, Line 17
Your session has been disconnected because of a high priority DDL operation.
Msg 596, Level 21, State 1, Line 16
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 16
A severe error occurred on the current command. The results, if any, should be discarded.

 

Vale ressaltar que ao realizar o procedimento de pausa (Pause) a um determinado índice, o mesmo será adicionado na visão sys.index_resumable_operations, tendo a coluna state_desc preenchida com o PAUSED, sendo assim, este rótulo será mantido até que uma outra instrução de Resume ou Abort venha a ser aplicado ao mesmo.

Por fim, nosso último passo consiste em similar o processo de interrupção do procedimento de resumable index, fazendo com que o mesmo deixe de ser mantido como um índice resumível de forma online, através da parâmetro Abort, para isso vamos utilizar o Bloco de Código 6 a seguir:

— Bloco de Código 6 —
Alter Index [PK_ResumableOnlineIndexRebuildsTable_Codigo] ON ResumableOnlineIndexRebuildsTable
Abort
Go

De forma idêntica realizada pelo parâmetro Pause, ao realizar o procedimento de Abort, interrompendo o rebuild de um índice, a sessão responsável pela execução da operação de rebuild irá receber a mesma mensagem de erro de quando o rebuild é pausado:

Msg 1219, Level 16, State 1, Line 17
Your session has been disconnected because of a high priority DDL operation.
Msg 1219, Level 16, State 1, Line 17
Your session has been disconnected because of a high priority DDL operation.
Msg 596, Level 21, State 1, Line 16
Cannot continue the execution because the session is in the kill state.
Msg 0, Level 20, State 0, Line 16
A severe error occurred on the current command. The results, if any, should be discarded.

Mas que beleza, conseguimos realizar o procedimento de abort, neste momento nosso índice não esta mais sendo reconhecido como resumable index, desta forma, o mesmo não poderá ser utilizado com um índice online resumível a qualquer momento.

Praticamente chegamos ao final deste post, falta um pouquinho para encerrar, pois, ainda tenho um último detalhe importante para compartilhar com você a seguir.

Limitações

Pois bem, como tudo em nossas vidas, sempre nos deparamos com situações ou condições que podem nos limitar de fazer uso ou realizar determinadas ações e isso não é diferente com o Resumable Online Index Rebuilds:

  • Suporta somente índices no formato Row Store;
  • Não possui suporte nativo para indexação online aplicada ao system database TEMPDB, ou seja, SORT_IN_TEMPDB do Alter Index não é aplicável;
  • Não possui suporte nativo para colunas do tipo TimeStamp;
  • Não possui suporte nativo com colunas calculadas (computadas);
  • Não é possível utilizar esse recurso em índices desativados; e
  • O Resumable OnLine Index Rebuil não pode ser utilizada dentro de uma transação de usuário, somente em transações relacionadas a atividades de manutenção de índices aplicadas diretamente ao escopo de banco de dados.

Agora sim, chegamos ao final, mas que trabalheira danada deu este post.

Espero que você tenha gostado, eu acredito que sim.


Referências

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-index-resumable-operations

https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-index-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-db-file-space-usage-transact-sql

https://docs.microsoft.com/pt-br/sql/t-sql/statements/create-index-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-index-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/drop-index-transact-sql

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/2018/04/12/20-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2018/01/02/19-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/12/15/18-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/11/24/17-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/10/01/16-para-que-serve/

Conclusão

Em algum momentos, a otimização de desempenho do banco de dados é sempre uma tarefa chave para o DBA. A manutenção de índice desempenha um papel vital na otimização do desempenho do banco de dados.

Às vezes, em ambientes OLTP (Online Transaction Processing ou Processamento de Transações em Tempo Real) que apresentam um longo tempo de processamentos, temos janelas de manutenção muito limitada e se um índice é grande, pode não ter tempo suficiente para reconstruir o índice.

Analisando estas situações, o Resumable Online Index Rebuilds se apresenta como uma solução de extrema importância e grande aliada na vida do DBA SQL Server, a sua adoção e aplicabilidade pode melhorar drasticamente as rotinas de reconstrução (rebuild) de índices, no que diz respeito ao seu volume de dados, por consequência seu tamanho e claro o quanto este elemento representa nas tarefas de pesquisa de dados realizadas pelas aplicações que fazem acesso a ele.

Realizar uma boa manutenção em qualquer ambiente de banco de dados, é algo que nos traz tranquilidade, saber que estamos adotando soluções para manter nossos ambientes protegidos, íntegros e organizados e papel fundamental para qualquer profissional responsável direta ou indiretamente por esta área.

Neste post, você pode conhecer este novo recurso adicionado a partir do Microsoft SQL Server 2017, o Resumable Online Index Rebuilds, uma importante melhoria adicionada ao produto, que com certeza vai permitir que muitos profissionais de tecnologia e DBAs possam passar noites de mais tranquilas.

E isso ai, este é o fantástico Microsoft SQL Server, que a cada versão ou atualização também esta preocupado com a qualidade de vida daqueles que assim como eu são apaixonados por este produtos…

Vai SQL Server, Vai SQL Server….

Agradecimentos

Mais uma vez obrigado por sua ilustre visita, sinto-me honrado com sua presença, espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Um forte abraço, até o próximo post da sessão Para que serve…..

Uma ótima segunda – feira e boa semana.

Valeu.

Anúncios

#20 – Para que serve


Olá pessoal, bom dia(ou talvez boa madrugada).

Não se espante com o horário, mas neste exato momento são 02:06(duas horas e seis minutos da manhã) quinta – feira dia 12/04, ou seja, um novo dia esta começando.

É a vida de um DBA e MVP não é fácil, sei que nesta quinta terei um dia repleto de afazeres, por este e outros motivos estou aqui no meu blog para compartilhar com vocês um dos novos recursos adicionados ao Microsoft SQL Server nos últimos meses.

Logicamente a cada nova versão que a Microsoft disponibilizado do SQL Server, uma nova avalanche de conceitos, funcionalidades, comandos e diversidade de possibilidades são adicionadas ao produto, mas no post de hoje, não vou apresentar propriamente uma nova funcionalidade deste fascinante Sistema Gerenciador de Banco de Dados, ao contrário, vou destacar uma nova ferramenta adicionado ao Microsoft SQL Management Studio a partir da versão 17.5 lançada no mês de fevereiro de 2018, conhecida como Descoberta e Classificação de Dados ou Data Discovery and Classification disponível para uso a partir da versão 2008.

Talvez você já deve ter ouvido falar de algo relacionado com proteção de informações organizacionais, ou quem sabe a sigla GDPR (General Data Protection Regulation)? Falando de formas gerais, trata-se de uma regulamentação geral de proteção de dados, criada inicialmente a partir de 2016, como uma possível normatização de padrões para proteção de dados organizacionais, respeitando regulamentações mundiais.

Caso ainda não tenha conhecimento ou obtida alguma informação sobre este assunto, recomendo acessar: https://www.gdpr.associates/what-is-gdpr/

Continuando, não vou me aprofundar no conceito, normas e padrões estabelecidos pelo GDPR, mas sim quero compartilhar com vocês esta recurso existente no Management Studio, que pode justamente ser muito útil para possibilitar uma melhor organização dos seus dados, como também, estabelecer uma nova maneira de categorizar os mesmo.

Sendo assim, chegou a hora de conhecer um pouco mais sobre o post de número 20 da sessão Para que serve. Então seja bem vindo ao #20 – Para que serve – Descoberta e Classificação de Dados.


Introdução

Adicionado a partir da versão 17.5 do Management Studio, o recurso Data Discovery and Classification se estabelece com uma nova ferramenta existente internamente no produto, com objetivo de nos permitir discovering (descobrir), classifying (classificar), labeling (rotular) e reporting (relatar) os dados confidenciais em seus bancos de dados.

No qual esta capacidade de descoberta e  classificação dos chamados dados confidenciais, sejam eles relacionados as áreas de negócios, financeiros, de serviços de saúde, marketing ou produção, podem desempenhar um papel fundamental na dimensão da proteção de informações organizacionais. A adoção desta nova funcionalidade implementada no Microsoft SQL Management Studio possível de ser utilizada a partir da versão 2008 e disponível até as atuais versão, nos possibilidade adotar:

  • Padrões de privacidade de dados e aos requisitos de conformidade regulamentar, como o GDPR; e
  • Controlar o acesso, fortalecendo a segurança de bancos de dados/colunas que contêm dados altamente confidenciais.

Data Discovery and Classification apresenta um conjunto de funcionalidades internas, que representam uma coleção de parametrizações para identificação e categorização de dados, que estabelecem uma camada de proteção de informações aplicadas de forma direta e transparente em nossos bancos de dados armazenados diretamente no Microsoft SQL Server, possibilitando e objetivando a proteção dos dados, não apenas do banco de dados, como também para os seguintes elementos:

  • Discovery & recommendations (Descobertas e Recomendações) – Através do mecanismo de classificação, é realizada uma verificação no banco de dados, permitindo identificar as possíveis colunas que contenham dados elegíveis a serem considerados confidenciais.
  • Labeling (Rótulos e Identificações) – Basicamente reconhecida como uma etiqueta ou rótulo de classificação de confidencialidade que estabelecem marcas de persistência em colunas, característica que nos ajuda e diferenciar estes dados de um outro dado “considerado comum”; e
  • Visibility (Visibilidade) – Estado de classificação do banco de dados que permite ser exibido em um relatório detalhado que pode ser impresso/exportado para ser usado para fins de auditoria e conformidade, bem como para outras necessidades.

Acredito que até aqui esteja tudo tranquilo, espero que você possa estar entendendo os conceitos, para que possamos evoluir a partir de agora na prática, que também será bastante simples de ser utilizada.

Como descobrir, classificar e rotular colunas confidenciais

Vamos então conhecer de forma prática como podemos estabelecer esta forma de classificação e rotulação dos nossos dados, no qual utilizaremos o Microsoft SQL Server Management Studio, tendo como base um banco de dados muito propicio para o ano de 2018.

Pois bem, em nossa prática vamos utilizar um banco de dados denominado Fifa2018 que possui todos os dados existentes no game Fifa 2018 produzido pela EASports, jogado mundialmente nos principais consoles de videogame. Caso você queria fazer o download deste banco de dados disponível para o SQL Server 2016 ou 2017, utilize este link Fifa2018.bak (por questões de compatibilidade com a plataforma wordpress, o arquivo de backup foi renomeado, tendo em seu nome o acréscimo da extensão .doc, sendo assim, basta após realizar o download remover a respectiva extensão).

Mas antes de realizarmos a classificação de forma prática, vale ressaltar que existem dois elementos muito importantes a serem entendidos, denominados:

  1. Labels (Rótulos) – os atributos de classificação principais, são usados para definir o nível de confidencialidade dos dados armazenados na coluna; e
  2. Information Types (Tipos de informações) – Nos fornecem uma granularidade adicional para o tipo dos dados armazenados na coluna, elemento que nos permite identificar de uma maneira mais especifica cada dado contido em sua respectiva coluna.

Passo 1

Dando continuidade, seguimos em frente, agora realizando de maneira prática os processos de descoberta, classificação e rótulo dos nossos dados, posteriormente vamos gerar um relatório que nos permitirá entender de forma gráfica as categorizações atribuídas para nossos respectivos dados, para tal recomendo que você acesso seu Management Studio e conecte em sua instância, procedimento o qual eu já realizei, conforme a Figura 1 abaixo apresenta:

Figura 1 – Instância local do Microsoft SQL Server 2017 conectada.

Passo 2

Nosso próximo passo será selecionar banco de dados Fifa2018, clicando com o botão da direita, posteriormente na opção Task e por último na opção Classify Data conforme ilustra a Figura 2 a seguir:

Figura 2 – Acessando a ferramenta Classify Data existente no Management Studio.

Passo 3

Ótimo, a partir deste momento, o Management Studio acaba de abrir a ferramenta Classify Data, que nos permite realizar os procedimentos de descoberta, classificação e identificação do dados existentes nas tabelas que compõem do banco de dados Fifa2018, conforme apresenta a Figura 3 abaixo:

Figura 3 – Data Classification disponível para classificação dos dados.

Analisando a Figura 3 apresentada acima, podemos observar que em sua barra de status é exibida uma mensagem informando que existem 5 colunas neste base dados que possivelmente podem ser reconhecidas como colunas de dados confidencias.

Você pode estar se perguntando como esta ferramenta realiza este tipo de análise, a resposta é bem simples, neste caso, a análise foi realizada tendo com base as simulações que eu executei justamente para poder escrever este post, por padrão ao ser inicializada pela primeira em um determinado banco de dados a Classify Data não possui informações suficientes para descobrir estas possíveis colunas.

Passo 4

Legal, o próximo passo será muito simples e tranquilo, para poder realizar a classificação dos dados, vamos clicar no botão Add Classification, existente barra de ferramentas.

Ao clicar no botão Add Classification, será apresentada uma nova ribbon chamada Data Classification ao lado direita da sua tela, a qual permitirá que você realiza das respectivas categorizações dos seus dados, de acordo com a tabela, coluna, tipo da informação e rótulo de importância ou sensibilidade do dado (Sensitivity Label), conforme apresenta a Figura 4:

Figura 4 – Barra de Ferramenta – Botão Add Classification e Ribbon – Data Classification.

De posse desta ribbon, você poderá criar suas respectivas classificações de dados, para tentar de ajudar e padronizar nossa prática, a Figura 5 a seguir ilustra o conjunto de classificação dos dados que eu realizei que podem servir como base para que você estabeleça em seu ambiente as respectivas classificações:

Figura 5 – Data Classification realizada.

Importante: Analisando a Figura 5, podemos notar a utilização de cinco colunas diferentes em nossa prática, todas existentes na tabela PlayerAllData, além disso, a coluna Sensitivity Label apresenta rótulos de sensibilidade diferentes para cada coluna, o que nos permite justamente identificar a existência de diversos rótulos, sendo este, um elemento importante para vai nos permitir ou não mostrar este dado em determinados procedimentos aos quais nosso banco de dados venha a ser envolvido.

Passo 5

Muito bem, você conseguiu, agora vamos avançar mais um pouco, já estamos quase no final, nosso próximo e extremamente importante passo consiste em salvar este conjunto de classificação de dados realizado anteriormente, para isso, nada mais claro e óbvio que clicar no botão Save “salvar” existente na barra de ferramentas da Classify Data, sendo assim, mãos no mouse e clique no botão Save.

Após realizar o procedimento de salvar, temos a partir de agora um conjunto de classificação e rotulamento de dados definido em nosso ambiente, o que nos permite realizar análise do nível se importância, confidencialidade e sensibilidade dos dados aqui definidos de acordo com nossas regras de negócio.

Passo 6

Nosso último passo esta relacionado com a capacidade de análise que esta nova ferramenta Classify Data nos permite fazer, tendo a disponibilidade de gerar um relatório contendo as informações referentes ao conjunto de classificação de dados que nós definimos no Passo 4, com isso, possibilitando estabelecer uma possível análise para posterior tomada de decisão no que se relacionada as colunas selecionadas como possíveis dados confidenciais ou dados organizacionais.

Para realizar este passo, vamos clicar no botão View Report (Exibir Relatório), procedimento que realizará o processamento e apresentação do relatório criado pelo Classify Data contendo o conjunto de informações relacionadas a nossa classificação de dados, conforme apresenta a Figura 6 abaixo:

Figura 6 – Data Classification Report – Relatório de Classificação de Dados.

Pronto, ai esta nosso relatório, simples, rápido e prático, nosso conjunto de classificação de dados apresentado, nos permitindo entender de forma gráfica os procedimentos de descoberta, classificação e rotulagem de dados.

Com isso chegamos ao final do post de número 20 da sessão Para que serve. Gostou?

Fale a verdade este post foi fácil, tranquilo? Não é mesmo!


Referências

https://docs.microsoft.com/pt-br/sql/relational-databases/security/sql-data-discovery-and-classification

https://docs.microsoft.com/en-us/sql/relational-databases/security/sql-data-discovery-and-classification

https://docs.microsoft.com/en-us/sql/relational-databases/security/dynamic-data-masking

https://docs.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-database-engine

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/2018/01/02/19-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/12/15/18-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/11/24/17-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/10/01/16-para-que-serve/

Conclusão

Estamos vivendo um mundo cada vez mais tecnológico, conectado, rápido, evolutivo e muito agressivo no que se diz respeito ao valor de uma informação para nós usuário e principalmente para empresas.

Atender justamente a este conjunto de exigência diárias, satisfazendo também os órgãos mundiais em suas definições, normas e obrigações acabam exigindo de qualquer empresa um constante acompanhamento e cumprimento de deveres. Desta forma, a Microsoft esta se adequando uma nova realidade e preocupação que cresce a cada dia, como proteger de forma mundial os dados e futuras informações geradas a todo os momentos por cada um dos indivíduos e organizações existentes em nosso planeta, sabendo da importância de se respeitar as leis, normas e padrões organizacionais e governamentais.

Neste post, você conheceu pouco sobre como o Microsoft SQL Server esta preparado para atender estas leis, através da nova ferramenta adicionada internamente no Management Studio, chamada de Data Discovery and Classification, na qual nos permite através do recurso Classify Data estabelecer a classificação dos nossos dados armazenados em cada coluna existente em um banco de dados, e não somente isso, definir o nível de importância deste dado, como também, a sensibilidade do mesmo para ser apresentado ou envolvido em algum tipo de procedimento de acesso ou manipulação, visando garantir e fortalecer que esta dado deve ser tratado de forma diferenciada em comparação com um possível “dado comum”.

Sem dúvida uma grande ferramenta adicionada ao Microsoft SQL Server, que mostra o quanto a Microsoft e seus respectivos times de produto estão envolvidos preocupados em atender e respeitar todas as possíveis leis, normas e regras.

Agradecimentos

Mais uma vez obrigado por sua ilustre visita, sinto-me honrado com sua presença, espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Um forte abraço, até o próximo post da sessão Para que serve…..

Boa noite e uma ótima quinta – feira.

Até mais.

 

 

 

#19 – Para que serve


Salve galera, boa tarde.

Feliz Ano Novo, Feliz 2018, o tempo passou e hoje dia 02/01 nos encontramos no primeiro dia útil para grande maioria da população mundial, mas que dureza pensar que temos mais 365 dias pela frente para superarmos, por outro lado que bom pensar assim.

Neste primeiro post de 2018 não vou trazer nenhuma novidade relacionada ao Microsoft SQL Server ou banco de dados, mas sim compartilhar como faço em alguns momentos, conceitos já conhecidos da grande maioria.

Hoje quero trazer para vocês um dos assuntos mais discutidos quando estamos trabalhando com nossos servidores de banco de dados, estou me referindo ao período de processamento do comando select dentro de um bloco de transação conhecido como Ciclo de Vida de Query através do comando Select.

Sendo assim, chegou a hora de conhecer um pouco mais sobre o primeiro post de 2018, post de número 19 da sessão Para que serve. Então seja bem vindo ao #19 – Para que serve – Ciclo de Vida de Query através do comando Select.


Introdução

Um dos comandos mais utilizados em qualquer Sistema Gerenciador de Banco de Dados ou propriamente um Banco de Dados é o comando Select, sendo este responsável em recuperar linhas do banco de dados e permite a seleção de uma ou várias linhas ou colunas de uma ou várias tabelas, no Microsoft SQL Server isso não é diferente.

Basicamente ao se executar um comando Select podemos estar trabalhando com uma simples query ou conjunto de querys que podem formar uma ou mais transações, é com base neste cenário que o comando Select composto por sua conjunto de argumentos e opções permite estabelecer um ciclo de vida dedicado exclusivamente ao seu período de compilação, execução e encerramento.

Desta forma, algumas perguntas podem surgir decorrentes do seu processo de processamento, dentre as quais destaco:

  1. Quais são as etapas para o processamento de um select? 
  2. Onde inicia e onde termina cada processo?

De uma maneira bastante simples e direta vou tentar responder estas questões, iniciando pela organização da estrutura de componentes utilizadas pelo comando Select, conhecidos como:

  • Relation Engine;
  • Storage Engine; e
  • Buffer Pool.
  1. Relational Engine é responsável pelos processos de Query Optmizer, Query Executor e Parse entre outros, avaliando toda a parte algébrica, sintaxe e plano de execução da Query.
  2. Storage Engine é o cara do I/O, responsável pelo gerenciamento e requisições de disco, alocações, Access Methods Code, Buffer Manager e Transaction MGR.
  3. Buffer Pool tem vários papeis, mas, um dos mais importantes é o gerenciamento de memória para o plano de execução e alocação de páginas no data cache.

A Figura 1 apresentada abaixo ilustra um modelo básico da estrutura de relação entre estes componentes:

Figura 1 – Estrutura dos componentes utilizados pelo comando select.

Logicamente, dentro de cada componente podemos encontrar diversos subcomponentes que formam sua estrutura, responsáveis por diversas ações e procedimentos, formando um ecossistema único para cada elemento, dentre eles destaco o Query Optimizer com suas diversas fases de otimização para gerar o plano de execução mais assertivo.

O Ciclo (Select)

O primeiro passo é estabelecer a conexão entre aplicação (ERP, CRM, Web, etc…) e o SQL Server. Para isso, é utilizado um protocolo chamado Network Interface (SNI). No fundo o SNI utiliza um outro protocolo, na verdade, podem existir vários protocolos e o mais conhecido é o famoso TCP/IP.

A Figura 2 abaixo ilustra o inicio do ciclo de vida do comando select através do acesso feito por uma aplicação:

Figura 2 – Representação do inicio do ciclo de vida do comando select.

Ao realizar a conexão através da comanda e do protocolo (TCP/IP), os pacotes TDS (Tabular Data Stream Endpoints) são encaminhados ao Protocolo Layer, que tem como papel “reconhecer e interpretar” o pacote e validar a informação, assim como sua origem (client). Após isso o conteúdo (SQL Command) do pacote é enviado ao Command Parse.

A Figura 3 apresenta o comportamento do Command Parse após o processo de reconhecimento e interpretação do pacote contendo o comando select ser realizado:

Figura 3 – Comportamento do Command Parse após o processo de reconhecimento dos pacotes.

Neste cenário o CMD Parser vai fazer o seu trabalho, primeiro validando o T-SQL, checando sintaxe, nomes de objetos, parâmetros, palavras chaves. A segunda parte é procurar no Buffer Pool se já existe um plano de execução compatível para está query, se sim, ele recupera este plano e executa (Query Executor), caso contrário, passa o result da análise (Query Tree) para o Query Optmizer que é o responsável por gerar o Execution Plan (plano de execução) que será usado na execução (próxima etapa) do ciclo.

Ao receber as instruções o Query Optimizer,  identifica a query realizando diversas etapas (fases 0,1,2) de otimização, afim de encontrar o plano mais eficiente, com base no “cost-based” (I/O, CPU). Nesta etapa as estatísticas são utilizadas servindo como Input de informação para tomada de decisão do Query Optimizer. Após o termino desta etapa, o plano de execução está pronto, passando o bastão para o Query Executor

O Query Executor é quem executa a Query, na verdade ele executa o plano de execução, colocando os operadores para trabalhar. É neste ponto também que ocorre a interação com a Storage Engine via interface Access Methods (OLE DB).

Seguindo em frente, Access Methods passa a solicitação para o Buffer Manager recuperar a página de dados, se a página especifica estiver em memória, o Buffer Pool solicita ao Data Cache que recupere a pagina, e retorna ao Access Methods (leituras logicas). Ao contrário, os dados são recuperados do disco (leituras físicas), colocados em cache e devolvendo o controle para o Access Methods. 

De posse dos dados, o Access Methods devolve a informação para o Relational Engine que será enviada ao Client que a solicitou, assim o resultando do comando select é apresentado na tela da aplicação exibindo assim os dados solicitados pelo usuário. Desta maneira, nosso ciclo ou melhor o ciclo de vida do comando select esta concluído, conforme a Figura 4 apresenta abaixo:

Figura 4 – Ciclo de vida do comando select concluído e dados apresentados para o usuário.

Com isso chegamos ao final do primeiro post de 2018 e post de número 19 da sessão Para que serve.


Referências

https://docs.microsoft.com/en-us/sql/t-sql/queries/select-transact-sql

https://technet.microsoft.com/en-us/library/ms189559(v=sql.90).aspx

http://www.sqlservergeeks.com/sql-server-architecture-part-2-the-relational-engine/

https://blogs.msdn.microsoft.com/tcaserta/2016/01/04/sql-server-fundamentos-storage-engine-parte-i/

https://blogs.msdn.microsoft.com/tcaserta/2016/01/04/sql-server-fundamentos-storage-engine-parte-i/

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/2017/12/15/18-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/11/24/17-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/10/01/16-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/06/28/15-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/04/30/14-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/03/25/13-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

Conclusão

Como sempre a Microsoft e toda sua equipe nos surpreende com sua capacidade de trabalho, fortalecendo cada vez mais o Microsoft SQL Server não somente com um SGBD ou ferramenta de banco de dados, mas sim um ambiente completo para qualquer tipo de análise, desenvolvimento e administração que esteja relacionada com dados.

Este é o fantástico Microsoft SQL Server, surpreendente em todos os sentidos…

Agradecimentos

Mais uma vez obrigado por sua ilustre visita, sinto-me honrado com sua presença, espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Um forte abraço, até o próximo post da sessão Para que serve…..

Valeu.

#18 – Para que serve


Olá você, boa noite.

Tudo bem?

Este é mais um post da sessão Para que serve, nesta última sexta-feira de aulas aqui na Fatec São Roque, hoje meu queridos pimpolhos não estão presentes, final de semestre é sempre assim eles somem, mas eu estou aqui vivinho da silva e pronto para compartilhar um pouco do conhecimento adquirido nos alguns dias.

Hoje não vou destacar novidades adicionadas ao Microsoft SQL Server em suas últimas versões, ao contrário quero trazer para você um exemplo de código que poderá lhe ajudar muito ainda mais com um novo ano que esta se aproximando rapidamente. Sempre nesta época do ano diversos estabelecimentos comerciais, lojas e demais locais de compra e venda gostam de ofertar aos seus clientes aquele tradicional folhinha ou calendário mensal do próxima ano.

É justamente isso que este novo post da sessão Para que serve tem o objetivo de trazer, apresentar como podemos através de um script desenvolvido no Microsoft SQL Server criar um calendário mensal ou anual igualzinho aqueles que ganhamos nos finais de ano.

O melhor ainda neste calendário é que nossa tabela será estrutura respeitando rigorosamente os dias da semana e seus respectivos nomes. Sendo assim, chegou a hora de conhecer um pouco mais sobre estas novas funções, desta forma, seja bem vindo ao #18 – Para que serve – Criando um calendário mensal com dias da semana.


Introdução

Um dos elementos mais comuns de se encontrar nas casas, apartamentos, escolas e demais locais de convivência é um calendário ou folhinha de meses e dias pregada nas paredes, afixada em geladeiras, portas retratos entre outros locais de fácil acesso e visualização para todos.

O elemento chamado de calendário criado a milhares de anos tem como principal função ajudar nós pessoas a nos identificar no tempo, ou seja, trata-se de um recurso tão básico mas de extrema importância no que diz respeito ao dia-a-dia das pessoas e suas atividades.

Este tipo de recurso não poderia estar ausente no Microsoft SQL Server, não que ele esteja totalmente presente, mas através das funcionalidades existentes na linguagem Transact-SQL ou simplesmente T-SQL temos total capacidade de criarmos o nosso calendário mensal ou até mesmo anual contendo os dias da semana, o número da semana e posteriormente demais dados necessários que possam compor o seu calendário.

Para que você possa acompanhar o processo de criação deste calendário personalizado, vamos utilizar como base para nosso cenário uma simples tabela denominada CalendarioMensal, nome mais do que sugestivo, começamos então pela criação desta tabela conforme apresenta o Bloco de Código 1 a seguir:

— Bloco de Código 1 – Criando a Tabela CalendarioMensal —

Create Table CalendarioMensal
(Contador TinyInt Identity(1,1) ,
Semana SmallInt,
Segunda TinyInt Null,
Terca TinyInt Null,
Quarta TinyInt Null,
Quinta TinyInt Null,
Sexta TinyInt Null,
Sabado TinyInt Null,
Domingo TinyInt Null)
Go

Show nossa tabela CalendarioMensal esta criada e pronta para ser utilizada, nosso próxima passo é começar a estruturar o ambiente para darmos inicio a inserção dos dados que vão compor o calendário, neste caso, vamos estabelecer o dia inicial da semana e evitar a contagem de linhas a cada manipulação de dados, para tal vamos o Bloco de Código 2 conforme apresentado abaixo:

— Bloco de Código 2 – Definindo o dia inicial da semana e evitando a contagem de linhas —

— Definindo o dia inicial da semana —
Set DateFirst 7
Go

— Desativando a contagem de linhas após manipulação de dados —
Set NoCount On
Go

Observações:

  1. Ao utilizar a diretiva Set DateFirst temos a possibilidade de definir de acordo qual deverá ser o primeiro dia da semana dentro da sessão ou transação que estamos trabalhando independente do idioma, linguagem ou configurações regionais do seu sistema operacional. Neste caso, estou definindo através do número 7 que qualquer semana terá inicio no sétimo dia, ou seja, no sábado.
  2. Ao utilizar a diretiva Set NoCount informando o valor de On estamos orientando o Database Engine enviar uma instrução para o Query Processor que ao final do processamento da transação ou bloco de transação não deverão ser informadas em tela a quantidade de linhas processadas ou manipuladas pelo Database Engine.

Nosso próximo passo consiste na declaração das variáveis que iremos utilizar para definir o período de dias ou período mensal que queremos criar, desta forma, vamos utilizar as variáveis: @InicioDeMes, @FinalDeMes e @Contador, conforme o Bloco de Código 3 apresentado abaixo:

— Bloco de Código 3 – Definição e atribuição das variáveis —

— Declarando e definindo as variáveis —
Declare @InicioDeMes Datetime,
@FinalDeMes Datetime,
@Contador TinyInt

— Atribuindo os valores para as variáveis —
Set @InicioDeMes = ‘2018-01-01’
Set @FinalDeMes = ‘2018-01-31’
Set @Contador = 1

Note que estou definindo o período de dias que correspondem ao mês de janeiro de 2018, sendo assim, nosso calendário mensal será criado respeitando a quantidade de dias e períodos de semana específicos do próximo mês de janeiro.

Ufa, estamos caminhando bem, vamos em frente, agora já se aproximando do processo de inserção do respectivo período de dias informado anteriormente e na sequência a atualização de cada dia de acordo com o exclusivo e respectivo dia da semana, vamos então conhecer o Bloco de Código 4 apresentado abaixo, não se esqueça de executar este bloco pois ele é o mais importante:

— Bloco de Código 4 – Loop para inserção e atualização dos dias referentes ao mês informando —

While @InicioDeMes <= @FinalDeMes
Begin

— Inserindo os valores na Tabela Calendário —
Insert Into CalendarioMensal Default Values

While 1<=@Contador
Begin

Update CalendarioMensal
Set Semana = IsNull(DatePart(Week, Segunda),Year(GetDate()-1)),
      Segunda = Case When DatePart(WeekDay,@InicioDeMes) = 2 Then DatePart(Day,@InicioDeMes) Else Segunda End,
       Terca = Case When DatePart(WeekDay,@InicioDeMes) = 3 Then DatePart(Day,@InicioDeMes) Else Terca End,
       Quarta = Case When DatePart(WeekDay,@InicioDeMes) = 4 Then DatePart(Day,@InicioDeMes) Else Quarta End,
       Quinta = Case When DatePart(WeekDay,@InicioDeMes) = 5 Then DatePart(Day,@InicioDeMes) Else Quinta End,
       Sexta = Case When DatePart(WeekDay,@InicioDeMes) = 6 Then DatePart(Day,@InicioDeMes) Else Sexta End,
        Sabado = Case When DatePart(WeekDay,@InicioDeMes) = 7 Then DatePart(Day,@InicioDeMes) Else Sabado End,
        Domingo = Case When DatePart(WeekDay,@InicioDeMes) = 1 Then DatePart(Day,@InicioDeMes) Else Domingo End              
Where Contador = @Contador
And DatePart(Month,@InicioDeMes) = DatePart(Month,@FinalDeMes)

  If DatePart(WeekDay,@InicioDeMes) = 1
   Break
    Set @InicioDeMes = Dateadd(Day,1,@InicioDeMes)
   End

  Set @InicioDeMes = Dateadd(Day,1,@InicioDeMes)
  Set @Contador = @Contador + 1
End
Go

Observações:

  1. Talvez você possa estar na dúvida do motivo ao qual estou utilizando o comando Insert dentro do loop de inserção de dados em nosso calendário, na verdade se você analisar a cada volta realizada pelo loop será inserido um conjunto de valores novas em nossa tabela CalendarioMensal, com base, neste novo conjunto de valores teremos a capacidade de distribuir os valores de acordo com a sua respectiva coluna, ou melhor dia da semana.
  2. Estou utilizando o comando Update no Bloco de Código 4, como elemento subsequente dos valores inseridos através do comando Insert, fazendo uma rápida análise após o conjunto de valores correspondentes ao dia do mês, é estabelecido tratamento para cada valor de acordo com o dia da semana de forma única para, possibilitando assim identificar o valor inserido que posteriormente estará atrelado ao determinado dia da semana, desta forma é feita a atualização do dia na coluna ao qual ele corresponderia na calendário impresso.

Já estamos no final, o mais complicado e talvez difícil de ser feito foi realizado e espero que tudo tenha ocorrido corretamente que se relaciona a inserção dos dados na tabela CalendarioMensal, se você chegou até é porque conseguiu, então vamos avançar mais um passo e agora ver como nossos dados forma inseridos e serão apresentado em tela, para tal procedimento utilize o Bloco de Código 5 declarado na sequência:

— Bloco de Código 5 – Visualizando o Calendário Mensal e seus respectivos dias e semanas —

Select Semana As ‘Numero da Semana’,
            Segunda As ‘Segunda-Feira’,
            Terca As ‘Terça-Feira’,
            Quarta As ‘Quarta-Feira’,
            Quinta As ‘Quinta-Feira’,
            Sexta As ‘Sexta-Feira’,
            Sabado As ‘Sábado’,
            Domingo As ‘Domingo’
From CalendarioMensal
Go

Afim de ilustrar e comprovar o resultado apresentado pelo Bloco de Código 5, apresento a seguir a Figura 1 abaixo:


Figura 1 – Calendário Mensal correspondente ao mês de janeiro de 2018.

Show, show, sensacional é isso ai, conseguimos, chegamos ao final de mais um post da sessão Para que serve.


Referências

https://docs.microsoft.com/en-us/sql/t-sql/statements/insert-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/queries/update-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/case-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/functions/datepart-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/functions/getdate-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/functions/year-transact-sql

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/2017/11/24/17-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/10/01/16-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/06/28/15-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/04/30/14-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/03/25/13-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

Conclusão

Como sempre a Microsoft e toda sua equipe nos surpreende com sua capacidade de trabalho, fortalecendo cada vez mais o Microsoft SQL Server não somente com um SGBD ou ferramenta de banco de dados, mas sim um ambiente completo para qualquer tipo de análise, desenvolvimento e administração que esteja relacionada com dados.

Através da diversidade de recursos e funcionalidades existentes no Microsoft SQL Server temos a capacidade de criar e manipular diversos tipos de objetos existentes no mundo real e que fazem parte do dia-a-dia das pessoas, e neste post você pode mais uma vez comprovar que isso é possível ser implementado, como visto aqui a criação e inserção de valores que representam a estrutura básica de um calendário impresso.

Este é o fantástico Microsoft SQL Server, surpreendente até nas funcionalidades e recursos mais básicos, produto mais do que bão e igual não existe so…..

Agradecimentos

Mais uma vez obrigado por sua ilustre visita, sinto-me honrado com sua presença, espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Quero também aproveitar para me despedir de vocês neste ano de 2017 e dizer que nos encontramos em breve, mas breve mesmo pois 2018 já esta batendo a porta.

Um forte abraço, até o próximo post da sessão Para que serve…..

Valeu.

#17 – Para que serve


Olá você, boa noite.

Tudo bem? Este é mais um post da sessão Para que serve, plena sexta – feira, enquanto meus alunos da Fatec São Roque estão quebrando a cabeça e gastando um pouco dos neurônios na resolução de exercícios, estou aqui para compartilhar um pouco do conhecimento adquirido nos alguns dias.

Quando eu falei sobre conhecimento adquirido, estou me referindo a algumas novidades adicionadas na nova versão do Microsoft SQL Server, neste caso mais especificamente a versão 2017. E ai você já realizou o download? Espero que a resposta seja positiva e você já esteja utilizando, pois caso contrário o post de hoje talvez não seja a solução da dúvida ou problema que você esta esperando.

Mas antes de falar do post, vamos destacar um pouco sobre o Microsoft SQL Server 2017. Acredito que você deva saber que no último mês de outubro, a Microsoft realizou mais um lançamento de uma nova versão do Microsoft SQL Server, estou me referindo a versão 2017. Por acaso você estão utilizando esta nova versão? Caso ainda não tenha feito, aproveite e faça agora mesmo acessando o link: https://www.microsoft.com/en-us/sql-server/sql-server-2017.

Se você, assim como eu realizou o download no mesmo dia do lançamento, ou seja, dia 02/10, pode ter um certo tempo para notar que a cada nova versão, o produto esta evoluindo, tanto no seu processo de instalação que realmente é fantástico e muito prático, como também, na quantidade de recursos, funcionalidades e componentes internos apresentados a partir desta da versão 2017.

Voltando para o post de hoje, como de costume a cada nova versão a Microsoft em conjunto com o seu time de engenheiros e desenvolvedores tem o hábito de adicionar um conjunto novo de funcionalidades e recursos, dentre eles alguns voltados especificamente para a área de desenvolvimento, no caso de comandos, stored procedures e functions adicionadas a grande linguagem Transact-SQL.

Logicamente na versão 2017 isso não seria diferente, e justamente pensando neste tipo de oportunidade para aquisição de conhecimento que o post de hoje será dedicado a duas novas funções adicionadas a partir desta versão sendo elas: Concat_WS e Translate.

E ai por acaso você já as conhece, espero que não, mas caso já tenha encontrado alguma informação ou até mesmo tenha feito uso, fique a vontade para contribuir com este post deixando seu comentário.

Seguindo em frente, chegou a hora de conhecer um pouco mais sobre estas novas funções, desta forma, seja bem vindo ao #17 – Para que serve – Novas String Functions Concat_WS e Translate adicionadas ao Microsoft SQL Server 2017.

Introdução

Em diversos momentos trabalhando com diversos dados armazenados em nossas tabelas temos a necessidade de realizar a concatenação entre eles, ou seja, estabelecer uma possível forma de união destes diversos valores e apresentar de uma única coluna ou até mesmo linha de registro.

Procedimento que até a versão 2012 do Microsoft SQL Server nos exigia um pouco de linhas de código para realizar esta atividade, sendo que, a mesma agora na versão 2o17 tornou-se ainda mais simples e fácil através da nova string function Concat_WS.

Você pode estar pensando, mas qual o motivo do tipo de engenheiros do SQL Server em adicionar uma função similar a Concat, na verdade não existe um motivo, o que existe e posso dizer é que a Concat e a Concat_WS podem ser consideradas irmãs ou até mesmo funções que se complementam.

Neste sentido o WS pode ser reconhecido como o argumento (concatenate with separator) separador, aquele caracterer que será utilizado para separar um valor string do outro mais ao mesmo tempo estará fazendo parte do conjunto de valores que serão concatenados.

Para que você possa entender e conhecer melhor a função Concat_WS, vou apresentar alguns exemplos:

— Exemplo 1 – Obtendo informações sobre as tabelas, utilizando o hífen como separador —
SELECT CONCAT_WS( ‘ – ‘, name, OBJECT_ID, create_date, modify_date) AS TablesInfo
FROM sys.tables
Go

Após a execução do Exemplo 1, você deverá obter um resultado similar conforme apresenta a Figura 1 abaixo:


Figura 1 – Dados concatenados e separados pelo sinal de hífen.

— Exemplo 2 – Concatenando caracteres utilizando o sinal de dois pontos como separador —
Select CONCAT_WS(‘ :: ‘, ‘Pedro Antonio Galvão Junior’, ‘Idade:37’, ‘MVP desde 2007’) As Info
Go

Após a execução do Exemplo 2, você deverá obter um resultado similar conforme apresenta a Figura 2 abaixo:


Figura 2 – Dados concatenados e separados pelo sinal de dois pontos.

Observação: Note que nos dois exemplos apresentados acima o primeiro argumento ou parâmetro obrigatório que deve ser especificado na função Concat_WS é justamente o elemento separador, o qual vai estar envolvido diretamente entre cada conjunto de valores informados sequencialmente na função.

Dando continuidade, vamos conhecer a função Translate, inicialmente fazendo uma rápida analogia ao seu nome parece que esta nova função seria algo similar a um tradutor de texto, na verdade ela tem um papel entre aspas próximo em relação a tradução de um valor ou sentença de valores string, mas dizer que ela realiza a tradução não é o entendimento correto.

Na verdade esta função realiza em tempo de execução retorna uma nova sentença de valores string com base no conjunto de argumentos declarados em sua sintaxe, sendo que obrigatoriamente o primeiro argumento representa a sentença de valores que deverá ser utilizada, para posteriormente servir como base para nova sentença que será resultando da “tradução”.

Vamos então conhecer um pouco mais sobre esta função, através dos exemplos apresentados a seguir:

— Exemplo 1 – Equação de 2º Grau — Substituindo a letra x pelo número 4 —Select ‘x² – 10x + 24 = 0’ As ‘Antes’
Go

Select Translate(‘x² – 10x + 24 = 0’, ‘x’, ‘4’) As ‘Depois’
Go

Após a execução do Exemplo 1, você deverá obter um resultado similar conforme apresenta a Figura 3 abaixo:


Figura 3 – Uso da função Translate aplicada em uma equação de segundo grau.

— Exemplo 2 – Método de Bhaskara – Substituindo as letras A e C pelos valores 1 e 8 informados respectivamente com grupos de valores em cada argumento —
Select N’∆ = b² – 4 * a * c’ As ‘Antes’

Go

Select Translate(N’∆ = b² – 4 * a * c’ , ‘ac’, ’18’) As ‘Depois’
Go

Após a execução do Exemplo 2, você deverá obter um resultado similar conforme apresenta a Figura 4 abaixo:


Figura 4 – Uso da função Translate aplicada ao método de bhaskara.

Observação: Note que nos dois exemplos apresentados anteriormente argumento ou parâmetro obrigatório que deve ser especificado na função Translate corresponde ao valores ou sentença string, o qual será utilizada como elemento base para “tradução” e apresentação do novo conjunto de valores ou sentença após sua execução. 

Muito bem, desta forma, chegamos ao final de mais uma post da sessão Para que Serve….


Referências

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

https://docs.microsoft.com/en-us/sql/t-sql/functions/concat-ws-transact-sql

https://docs.microsoft.com/pt-br/sql/t-sql/functions/translate-transact-sql

https://docs.microsoft.com/pt-br/sql/t-sql/functions/string-functions-transact-sql

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/2017/10/01/16-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/06/28/15-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/04/30/14-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/03/25/13-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

Conclusão

Como sempre a Microsoft e toda sua equipe nos surpreende com sua capacidade de trabalho, fortalecendo cada vez mais o Microsoft SQL Server não somente com um SGBD ou ferramenta de banco de dados, mas sim um ambiente completo para qualquer tipo de análise, desenvolvimento e administração que esteja relacionada com dados.

Destacando as novas funções apresentadas neste post Concat_WS e Translate, atividades como concatenação de dados que já havia se tornada mais fácil a partir da versão 2o12, agora se tornou algum praticamente irrelevante no que diz respeito a complexidade.

Sem se esquecer da função Translate que através de um simples argumento nos permite “realizar uma possível tradução de caracteres” muito similar a antiga e útil função Replace, mas que trabalha de uma forma mais ágil independente da posição do caracter dentro do conjunto de valores apresentados.

Este é o fantástico Microsoft SQL Server, eita produto bão so……

Agradecimentos

Chegou a hora do descanso, se preparar para um novo dia que daqui a pouco estará raiando, espero que você possa fazer o mesmo, aproveitar o seu dia ainda mais, tentar viver um pouco sem se preocupar com os problemas.

Mais uma vez obrigado por sua ilustre visita, sinto-me honrado com sua presença, espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Um forte abraço, até o próximo post da sessão Para que serve…..

Valeu.

 

 

#16 – Para que serve


Fala galera, boa noite.

Último dia do mês de setembro e como costumo dizer o tempo esta passando a cada dia de uma maneira mais rápida que não conseguimos nos deparar com tudo o que acontece ao nosso redor.

São exatamente 22:07 hrs da noite de um sábado que já esta chegando ao fim e com ele o final também de mais um mês de muita luta e trabalho neste ano de 2017, eita ano complicado.

Mas se você esta lendo este post é porque de alguma maneira acabou chegando até aqui, muito obrigado por sua visita, sendo este o post de número 16 da sessão Para que serve, já estava passando da hora de publicar mais um conteúdo exclusivo para esta sessão.

O conteúdo de hoje é um assunto que eu pouco trabalhei em toda minha carreira de DBA, olha que já fazem 17 anos que venho me dedicando diariamente a esta função, mas o recurso que será destacado hoje não é assim “tão velhinho” como eu (kkkkk).

Hoje vou destacar um pouco sobre índices, ai você pode se perguntar, poxa vida você pouco trabalhou com índices, como assim? Pois é, a resposta tem uma pequena parte de verdade, o tipo de índice ao qual eu me refiro pois adicionado ao Microsoft SQL Server a partir da versão 2012, agora acredito que ficou fácil saber de qual índice estou me referindo, se você ainda não se lembrou ou não se atentou para a dica, estou me referindo ao ColumnStore Index. Agora, tenho a certeza que você se lembrou desta nova forma de armazenamento de dados criada pelo time de engenheiros do Microsoft SQL Server a partir da versão 2012 e que ao longo das próximas versões sofreu diversas atualizações e melhorias.

Se a sua resposta é não ou sinceramente você não conhece esta “nova maneira” de trabalhar com índice, não fique preocupado, como de costume vou fazer uma breve introdução sobre este recurso, como também, vamos fazer alguns comparativos em relação a espaço em disco ocupado e custo de processamento em relação aos tradicionais índices Clustered e NonClustered, sendo estes conhecidos como índices Row Store.

Então chegou a hora de conhecer um pouco mais sobre este recurso, desta forma, seja bem vindo ao #16 – Para que serve – Algumas características e comportamentos do ColumnStore Index.

Introdução

Segundo a documentação oficial do Microsoft SQL Server,  índice columnstore é o padrão para armazenar e consultar grandes tabelas de fatos de repositório de dados. 

Um columnstore index é uma tecnologia para armazenamento, recuperação e gerenciamento de dados usando um formato de dados colunar, chamado columnstore.

Ele usa armazenamento de dados baseado em coluna e processamento de consultas para alcançar um desempenho de consulta até 10 vezes melhor no data warehouse em relação ao armazenamento tradicional orientado por linha e até 10 vezes mais compactação de dados em relação ao tamanho dos dados descompactados.

A partir do SQL Server 2016, os índices columnstore permitem a análise operacional, a capacidade de executar análises de alto desempenho em tempo real em uma carga de trabalho transacional. 

ColumnStore Vs RowStore

Um columnstore são dados logicamente organizados como uma tabela com linhas e colunas e fisicamente armazenados em um formato de dados com reconhecimento de coluna.

Um rowstore são dados logicamente organizados como uma tabela com linhas e colunas e fisicamente armazenados em um formato de dados com reconhecimento de linha. No SQL Server, rowstore refere-se à tabela em que o formato de armazenamento de dados subjacente é um heap, um índice clusterizado ou uma tabela com otimização de memória.

Característica 1: Por padrão até a versão 2012 todo e qualquer índice do tipo Clustered e NonClustered ao ser criado era associado ao mesmo uma estrutura de armazenamento de dados utilizando a tecnologia de RowStore, neste caso, ao invés de conter somente a coluna relacionada ao índice o mesmo possuía a linha por completa o que acarretava um aumento considerável de espaço em disco, como também, um custo de processamento maior para o SQL Server quando o dado solicitado era pesquisado.

Seguindo em frente, já sabemos um pouco sobre esta nova maneira de se armazenar dados contidos em um índice, característica muito importante e que pode nos trazer grandes benefícios.

Quais podem ser os outros benefícios ou características nativas existentes no ColumnStore Index que podem nos fazer adotar este tipo de tecnologia? Esta e muitas outras perguntas que eu mesmo sempre fiz em relação á este tipo de índice serão respondidas a seguir, através do ambiente que estaremos utilizando neste post.

Ambiente

Para que possamos entender ainda mais sobre o ColumnStore Index, nada melhor do que colocar em prática este recurso, para tal vamos começar a montar nosso ambiente de teste, composto por três tabelas similares denominadas:

  • MassaDeDadosCompressaoPorRow;
  • MassaDeDadosCompressaoPorPage; e
  • MassaDeDadosCompressaoColumnStore.

Estes três tabelas serão formadas por duas simples colunas denominadas:

  • Record; e
  • Number.

Onde a coluna Record será utilizada como identificar das linhas de registros que estão sendo manipuladas, sendo seu valor preenchido de forma automática através da propriedade Identity().

A coluna Number corresponde ao número que será inserido de forma aleatório neste coluna, esta será a coluna que iremos utilizar para a construção dos respectivos índices em cada tabela.

Vamos então através do Bloco de Código 1 realizar a criação de cada tabela, suas colunas e seus respectivos índices. Vale ressaltar que além de índices nas tabelas MassaDeDadosCompressaoPorRow e MassaDeDadosCompressaoPorPage estamos também utilizando compressão de dados aplicada a linha e compressão de dados aplicada a página de dados respectivamente. 

A seguir apresento o Bloco de Código 1:

— Bloco de Código 1 —

Use TempDB
Go

Create Table dbo.MassaDeDadosCompressaoPorRow
(Record Bigint Identity(1,1),
 Number BigInt
 Index IND_MassaDeDadosCompressaoPorRow Clustered (Number))
WITH (DATA_COMPRESSION = ROW)
Go

Create Table dbo.MassaDeDadosCompressaoPorPage
(Record Bigint Identity(1,1),
 Number BigInt
 Index IND_MassaDeDadosCompressaoPorPage Clustered (Number))
WITH (DATA_COMPRESSION = PAGE)
Go

Create Table dbo.MassaDeDadosCompressaoPorColumnStore
(Record Bigint Identity(1,1),
 Number BigInt,

 INDEX IND_MassaDeDadosCompressaoPorColumnStore Clustered  ColumnStore)
Go

Por enquanto nada de muito inovador ou diferente do que você pode estar acostumado a fazer, mas uma segunda característica do ColumnStore Index pode ser identificada após a criação das tabelas.

Característica 2: Ao realizar a criação de um índice ColumnStore, o Storage Engine mecanismo utilizado pelo Microsoft SQL Server para armazenamento físico de dados, realiza a alocação de um espaço mínimo inicial para armazenar a estrutura base da coluna relacionada ao índice, ou seja, mesmo não possuindo não dado armazenado no ColumnStore um pequeno espaço em disco é ocupado por sua estrutura e respectiva coluna. Para comprovar esta característica utilizamos o Bloco de Código 2 apresentado abaixo:

— Bloco de Código 2 —

Select s.Name As SchemaName, t.Name As TableName, p.rows As RowCounts,
            Cast(Round((Sum(a.used_pages) / 128.00), 2) As Numeric(36,2)) As Used_MB,
             Cast(Round((Sum(a.total_pages) – SUM(a.used_pages)) / 128.00, 2) As Numeric(36, 2)) As Unused_MB,
            Cast(Round((Sum(a.total_pages) / 128.00), 2) As Numeric(36, 2)) As Total_MB
From sys.tables t Inner Join sys.indexes i
                                 On t.OBJECT_ID = i.object_id
                                Inner Join sys.partitions p
                                 On i.object_id = p.OBJECT_ID And i.index_id = p.index_id
                                Inner Join sys.allocation_units a
                                On p.partition_id = a.container_id
                                 Inner Join sys.schemas s
                                 On t.schema_id = s.schema_id
Where t.object_id >1
Group By t.Name, s.Name, p.Rows
Order By s.Name, t.Name
Go 

Agora que você executou o Bloco de Código 2, deve ter obtido como resultado ao similar ao apresentado na Figura 1 a seguir:


Figura 1 – Espaço ocupado pelo ColumnStore Index mesmo são a existência de linhas de registro.

Legal, mas ainda temos algumas coisas para analisar em relação ao ColumnStore Index, nosso próximo passo será realizar o armazenamento de uma massa de dados em cada tabela, aonde estará identificando o tempo de processamento decorrido para inserir um milhão de linhas de registro, valor hoje considerado pouco para se trabalhar com qualquer banco de dados e principalmente para estruturas ColumnStore, mas o suficiente para nossas análises e comparações.

Vamos então trabalhar com o Bloco de Código 3 a seguir:

— Bloco de Código 3 —

— Inserindo 1.000.000 na Tabela MassaDeDadosCompressaoPorRow –|

Declare @Contador Int = 1

While @Contador <=1000000
Begin
Insert Into dbo.MassaDeDadosCompressaoPorRow (Number)
Values (Rand()*1000000000000)

Set @Contador +=1
End
Go

— Inserindo 1.000.000 na Tabela MassaDeDadosCompressaoPorPage —

Declare @Contador Int = 1

While @Contador <=1000000
Begin
Insert Into dbo.MassaDeDadosCompressaoPorPage (Number)
Values (Rand()*1000000000000)

Set @Contador +=1
End
Go

— Inserindo 1.000.000 na Tabela MassaDeDadosCompressaoPorColumnStore —

Declare @Contador Int = 1

While @Contador <=1000000
Begin
Insert Into dbo.MassaDeDadosCompressaoPorColumnStore (Number)
Values (Rand()*1000000000000)

Set @Contador +=1
End
Go

Neste momento nossas tabelas já estão totalmente populadas com 1.000.000 de linhas de registros armazenadas em cada uma delas, vamos então identificar mais duas características presentes no ColumnStore Index, começando pela número 3.

Característica 3: ColumnStore Index apresentam em alguns cenários de armazenamento de dados dependendo do tipo de dados utilizado por ele uma ligeira perda de performance em comparação com o mesmo tipo de dados utilizado em índices que utilizam tecnologia RowStore.

Para comprovar e ajudar a entender esta diferença de comportamento apresento a seguir a Tabela 1 que exibe os dados coletados durante os três processos de inserir realizado pelo Bloco de Código 3 declarado anteriormente.

Tabela Operação Tempo Decorrido
MassaDeDadosCompressaoPorRow Insert 00:00:22
MassaDeDadosCompressaoPorPage Insert 00:00:22
MassaDeDadosCompressaoPorColumnStore Insert 00:00:28

Tabela 1 – Comparativo de tempo decorrido para inserção de 1.000.000 de linhas de registro em cada tabela.

Nossa próxima característica esta relacionada ao espaço físico ocupado em disco para cada índice de acordo com a tecnologia de armazenamento utilizada e a forma de compressão aplicada.

Característica 4: Tabelas que possuem índice do tipo ColumnStore ocupam um espaço físico em disco infinitamente menor que tabelas que possuem índices RowStore, o que representa que o espaço ocupado em disco por índices que utilizam tecnologia ColumnStore podem apresentar uma economia de espaço em disco entre 70 e 90%, algo que devemos considerar em muito quando vamos trabalhar com um volume consideravelmente grande de dados.

A Tabela 2 apresentada abaixo ilustra esta diferença de espaço em disco ocupada por cada tabela:

Dados coletados pelo SP_SpaceUsed
Tabela Linhas Espaço Reservado  Dados Índices Não Utilizado
dbo.MassaDeDadosCompressaoPorRow 1000000 18592 KB 18448 KB 104 KB 40 KB
dbo.MassaDeDadosCompressaoPorPage 1000000 17312 KB 17192 KB 96 KB 24 KB
dbo.MassaDeDadosCompressaoPorColumnStore 1000000 28904 KB 28696 KB 144 KB 64 KB

Tabela 2 – Dados coletados pela System Stored Procedure SP_SpaceUsed.

Observação: Se analisarmos os dados da Tabela 2 podemos notar que a compressão por página de dados para este cenário de 1.000.000 de linhas de registro foi um pouco superior em relação a economia de espaço em disco se comparada com a compressão por linha de dados, essa é uma característica interessante quando trabalhamos com compressão de dados fazendo uma análise de minimal space entre Row Compression e Page Compression.

Uma outra possibilidade para notar esta diferença considerável de espaço alocado, reservado e ocupado fisicamente em disco poderia ser obtido através de uma nova execução do Bloco de Código 2 apresentado anteriormente, para tal a Tabela 3 apresenta o resultado desta nova execução:

Dados coletados através do Bloco de Código 2
Tabela Linhas Espaço Ocupado em MBs Espaço Não Utilizado em MBs Total MBs
MassaDeDadosCompressaoPorRow 1000000 18.12 0.04 18.16
MassaDeDadosCompressaoPorPage 1000000 16.88 0.02 16.91
MassaDeDadosCompressaoPorColumnStore 1000000 0.02 0.05 0.07

Tabela 3 – Dados coletados através da execução do Bloco de Código 2.

Observação: No que diz respeito a minimal space quando trabalhamos com o ColumnStore Index em comparação com Row Compression ou Page Compression a diferença é extremamente assustadora, aonde o ColumnStore Index aplica uma técnica de armazenamento de dados muito interessante que possibilita esta ganho de espaço e consequentemente ganho de performance. Esta técnica é conhecida como Row Group.

Estamos quase no final, vamos agora identificar mais uma importante característica presente em um ColumnStore Index, relacionada a performance algo que este tipo de tecnologia apresenta como principal vantagem e benefícios em relação a índices RowStore ainda mais quando trabalhamos com grandes volumes de dados em ambientes relacionais.

Nossa análise será iniciada através da execução da Bloco de Código 4 declarado abaixo, observe que estaremos habilitando os contadores de estatísticas de processamento relacionados a Tempo e Input/Output denominados:

Através do uso destes contadores o Management Studio ira nos retornar na guia de mensagens um conjunto de dados relacionados ao tempo de processamento, quantidade de leituras lógicas e físicas demandadas por cada transação que estaremos processando, com base, nestes e outros dados poderemos identificar quando será o diferença do ColumnStore Index em comparação com os outros índices existentes em nossas tabelas.

Outro elemento importante que estaremos utilizando, consiste na quantidade de linhas pesquisadas em cada tabela, você poderá notar que para cada Select declarado no Bloco de Código 4 estaremos filtrando e limitando nosso result set na faixa de valores existentes entre as linhas de registro 525.000 e 789.000.

Vamos então executar o Bloco de Código 4, recomendo que faça a execução de cada select de forma separada, anote os dados retornados pelos contadores Time e IO:

— Bloco de Código 4 —

Set Statistics Time On
Set Statistics IO On
Go

Select * from dbo.MassaDeDadosCompressaoPorRow
Where Record Between 525000 And 789000
Go

Select * from dbo.MassaDeDadosCompressaoPorPage
Where Record Between 525000 And 789000
Go

Select * from dbo.MassaDeDadosCompressaoPorColumnStore
Where Record Between 525000 And 789000
Go

Set Statistics Time Off
Set Statistics IO Off
Go

Ufa, estamos quase lá, nosso Bloco de Código 4 foi apresentado, tenho a certeza que você executou cada Select de forma individual, anotando os respectivos valores de tempo de processamento e input/output retornados pelo SQL Server, muito bem, agora vamos analisar a Tabela 4 apresentada abaixo e identificar o comportamento apresentado pelo ColumnStore Index.

Tabela Operação Tempo Decorrido CPU Time Elapsed Time Scan Count Logical Reads Physical Reads
MassaDeDadosCompressaoPorRow Select 00:00:02 110 ms 769 ms 1 2316 0
MassaDeDadosCompressaoPorPage Select 00:00:02 203 ms 830 ms 1 2158 0
MassaDeDadosCompressaoPorColumnStore Select 00:00:01 125 ms 911 ms 2 3599 0

Tabela 4 – Conjunto de dados coletados e apresentados pelos contadores TIME e IO durante a execução dos selects declarados no Bloco de Código 4.

Característica 5: Índice do tipo ColumnStore sempre serão mais rápidos que índice RowStore mesmo apresentando alguns dados que valores superiores, dentre eles: Scan Count e Logical Reads.

Analisando os dados apresentados anteriormente na Tabela 4, fica mais fácil observar alguns comportamentos presentes em índices ColumnStore, nos quais a quantidade de leituras lógicas pode estar mais presente neste tipo de índice devido justamente a sua forma de armazenamento de dados, além disso, o número de contagem de varreduras conhecidos como Scan Count, outro fator que também esta relacionado ao armazenamento do dados no índice na forma de coluna ao invés de linha como no RowStore.

Mas o elemento mais importante esta vinculado ao tempo decorrido na busca dos dados solicitados, tanto a tabela MassaDeDadosCompressaoPorRow como também a MassaDeDadosCompressaoPorPage demandaram 00:00:02 segundos para identificar, filtrar e apresentar 264.001 mil linhas de registro.

Nesta mesma comparação, os dados pesquisados na tabela MassaDeDadosCompressaoPorRow foram retornados em tela em 00:00:01 segundo, ou seja, uma ligeira diferença no tempo de processamento, o que pode parecer muito insignificante para o atual volume de dados que estamos trabalhando, mas imagine este ganho de processamento quando estivermos manipulando bilhões, trilhões ou quatrilhões de linhas de dados, mesmo que o elapsed time do processamento tenha sido um pouco maior que os demais. 

Desta forma, os dados apresentados na Tabela 4 em conjunto com os demais dados presentes em cada análise realizada neste post, nos traz a seguinte certeza, que índices ColumnStore podem e devem ser analisados, o que nos permite também dizer que o uso deste tipo de tecnologia poderá ser de grande avaliar e benefícios no que se relaciona a armazenamento e processamento de dados.

Com isso chegamos ao final deste post, olha foi surpreende e desafiador….


Referências

https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/row-compression-implementation

https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/page-compression-implementation

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-table-transact-sql-identity-property

https://docs.microsoft.com/en-us/sql/relational-databases/data-compression/data-compression

https://docs.microsoft.com/en-us/sql/relational-databases/system-stored-procedures/sp-spaceused-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-overview

https://docs.microsoft.com/en-us/sql/t-sql/statements/set-statistics-time-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/set-statistics-io-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-tables-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-indexes-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-partitions-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/sys-allocation-units-transact-sql

https://docs.microsoft.com/en-us/sql/relational-databases/system-catalog-views/schemas-catalog-views-sys-schemas

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/2017/06/28/15-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/04/30/14-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/03/25/13-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

Conclusão

Identificar a melhor forma de armazenar nossos dados em um Sistema Gerenciador de Banco de Dados não é um tarefa das mais fáceis e comum de se realizada, escolher qual tecnologia de armazenamento visando economia de espaço e performance muito menos.

A partir da versão 2012 do Microsoft SQL Server esta tarefa começou a ficar um pouco mais interessante e amigável com a adoção da tecnologia de armazenamento de dados existentes em um índice no formato de coluna ao invés de linha, tecnologia conhecida e denominada como ColumnStore Index.

O uso do ColumnStore Index deve ser avaliado, sua principal característica relaciona-se ao capacidade de processamento de um grande volume de dados com baixo custo de tempo, mesmo em ambientes relacionais, o que nos permite dizer que utilizar um índice ColumnStore poderá lhe trazer benefícios tanto no espaço ocupado em disco, bem como, no tempo de processamento na pesquisa de dados.

Agradecimentos

Antes de finalizar, são 00:46hrs da madrugada, já estamos no dia 01/10, ou seja, um novo mês esta começando neste domínio.

Chegou a hora do descanso, se preparar para um novo dia que daqui a pouco estará raiando, espero que você possa fazer o mesmo, aproveitar o seu dia ainda mais um domingo, tentar viver um pouco sem se preocupar com os problemas.

Mais uma vez obrigado por sua ilustre visita, sinto-me honrado com sua presença, espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Um forte abraço, até o próximo post da sessão Para que serve…..

Valeu.

#15 – Para que serve


Bom dia, bom dia, bom dia!

Oi gente, tudo bem? Você que esta acessando mais um post do meu blog, pode estar se perguntando. Cara como pode um pessoa ás 6:30hrs de uma quarta – feira esta acordado escrevendo mais um post.

A resposta será bem simples, isso se chama profissionalismo e respeito aos seus compromissos, e escrever algo para o meu blog é mais que um compromisso é um grande prazer, por isso estou aqui ás 6:32hrs da manhã terminando este parágrafo (kkkkk).

Dando continuidade, este é o novo post da sessão Para que serve, sendo o post de número 15, muito bom, lentamente esta sessão esta ganhando corpo e força com os meus seguidores.

Nos últimos dias pesquisei novidades, recursos, comandos, enfim algo que poderia trazer para vocês hoje e sinceramente falando tive bastante dificuldade para encontrar algum conteúdo que fosse ao mesmo tempo interessante porém simples, e por incrível que pareça acabei me lembrando de algo lançado já faz um tempinho na versão 2014 do Microsoft SQL Server.

Poxa vida, versão 2014 do SQL Server sendo que já estamos na versão 2017 prestes a ser lançada, então não sempre algo que foi lançado a algum tempo pode ser considerado novo muito menos totalmente conhecido, sempre temos alguma coisa nova para conhecer, aprender e descobrir com produtos e suas versões mais antigas e foi justamente pensando nisso que estou trabalhando no conteúdo para este post.

Seguindo como a costumeira apresentação, vou destacar neste post um dos recursos mais importantes adicionados ao SQL Server a partir da versão 2014 conhecido como Native Backup Encryption ou Backup Nativo Encriptado, talvez você nunca tenha ouvido falar sobre ele ou não tenha até o presente momento a necessidade de usar, mas tenha a certeza um é um recurso de fácil utilização.

Então chegou a hora de conhecer um pouco mais sobre esta funcionalidade, sua forma de uso, características, importância, limitações, entre outros.

Desta forma, seja bem vindo ao #15 – Para que serve – Native Backup Encryption.

Introdução

Quando pensamos nas possibilidades de perda de dados ou informações, normalmente um dos recursos mais conhecidos e utilizados por todos é o bom e velho backup, capacidade que ao longo dos anos também evoluiu muito e hoje pode ser feito de maneira muito simples, tanto para um pen-drive como diretamente para um repositório disponibilidade de maneira on-line não tão falada e prosperada Cloud Computing.

Mas se fazer o backup é algo simples, imagine então o processo de restauração deste conteúdo que também se torna cada vez mais ágil, rápida e fácil. Você já pensou nisso? Não adianta fazer o backup e pensar “estou seguro, fiz o backup do meu banco de dados, quando eu precisar basta restaurar”, parece ser algo que nunca vai acontecer, mas não é o que atualmente estamos vendo.

Pensando neste sentido seu eu que pergunto: “E se por acaso o seu backup foi roubado, sequestrado, enfim alguém mal intencionado acabou se apoderando dos seus dados?” Isso parece ser bastante assustador e perigoso, foi justamente pensando nisso que a partir da versão CTP2 do Microsoft SQL Server 2014, o time de engenheiros, desenvolvedores e especialistas da Microsoft decidiram adicionar de forma nativa a capacidade de criarmos backups diretamente em uma instância ou servidor SQL Server fazendo uso de criptografia de dados através dos já conhecidos algoritmos, por mais simples que isso possa parecer até a versão 2012 do Microsoft SQL Server não tínhamos esta funcionalidade disponibilidade no produto de forma nativa e totalmente suportada para nossos bancos de dados, tínhamos a necessidade de utilizar ferramentas de terceiros para aplicar este tipo de recurso.

Native Backup Encryption

Através desta nova funcionalidade ao executar um procedimento ou rotina de backup de banco de dados, o Microsoft SQL Server sabendo da escolha deste recurso além de criar um arquivo contendo todo conteúdo estabelecido para o banco de dados selecionado, também realizará para o mesmo arquivo que esta sendo criado a aplicação de uma camada de criptografia de dados, onde de uma maneira direta o conteúdo armazenado neste arquivo de backup estará totalmente criptografado.

Dentre as principais características existentes para esta funcionalidade, para que esta capacidade de adicionar uma camada de criptografia diretamente para todo o backup, torna-se necessário o uso de alguns recursos adicionais em nosso banco de dados para que seja possível criarmos backups criptografados, estou me referindo ao uso de certificados e chaves assimétricas em conjunto com os algoritmos suportados pelo SQL Server sendo eles:

  • AES 128;
  • AES 192;
  • AES 256; e 
  • Triple DES.

Utilizando o Native Backup Encryption

Como já destacado anteriormente, antes de criarmos um backup criptografado de nosso banco de dados, temos a necessidade de criamos um certificado de segurança para garantir que todo conteúdo existente esta sendo validado e possui um mecanismo de segurança.

Para começarmos, vamos realizar o primeiro passo que consiste na criação do nosso Banco de Dados chamado NativeBackupEncryption, em seguida criaremos nossa chave assimétrica e na sequência o certificado denominado CertNativeBackupEncryption. Vale ressaltar, que tanto o certificado como também a chave assimétrica serão obrigatoriamente armazenadas na banco de dados de sistema Master. Para isso utilizaremos o Bloco de Código 1 apresentado a seguir:

— Bloco de Código 1 —
Create Database NativeBackupEncryption
Go

Use Master
Go

Create Master Key Encryption By Password = ‘Backup@@01’
Go

Create Certificate CertNativeBackupEncryption
With Subject = ‘Certificado para Criptografia de Backup’;
Go

Perfeito o primeiro passo já foi realizado e podemos observar nas árvores de recursos do nosso banco de dados que tanto o certificado como principalmente a chave assimétrica estão criadas, conforme ilustra a Figura 1 apresentada abaixo:

Figura 1 – Certificado CertNativeBackupEncryption criado.

Nosso segundo passo também é um dos mais importantes, para conseguirmos aplicar a criptografia em nosso backup de dados, consiste basicamente no procedimento de backup da nossa chave assimétrica em conjunto com o backup do certificado CertNativeBackupEncryption, para que posteriormente seja possível realizar o backup criptografado.

Vale ressaltar que se este procedimento não venha a ser realizado o Microsoft SQL Server durante o processo de Backup Database emitirá um alerta informando a necessidade que este procedimento venha a ser realizado.

Vamos então executar o segundo passo através do Bloco de Código 2 apresentado na sequência:

— Bloco de Código 2 —

Backup Certificate CertNativeBackupEncryption
To File = ‘S:\MSSQL-2016\Backup\Backup-Certificate-CertNativeBackupEncryption.cert’
With Private Key
(
File = ‘S:\MSSQL-2016\Backup\Backup-Master-Key-File.key’,
Encryption By Password = ‘Backup@@01’
)
Go

Legal, legal, conseguimos realizar o backup da nosso Certificado e também do nossa Chave Assimétrica, observe que no procedimento de backup do certificado estamos informando o uso do nossa chave assimétrica na instrução With Private Key, passando como parâmetros os mesmos valores informados para o backup da chave.

A Figura 2 ilustra o local de armazenamento dos arquivos gerados após o backup da chave assimétrica e do certificado:

Figura 2 – Arquivos de backup da chave e certificados criados e armazenados.

Importante: Por questões de facilidade os arquivos de backup foram criados no mesmo local, mas pensando em segurança e boas práticas é altamente recomendável que cada arquivo de backup seja criado e armazenado em locais distintos por questões óbvias de segurança.

Agora que os backups de chave assimétrica e certificados foram realizados, vamos executar nosso último passo que consiste justamente na realização do Backup do nosso banco de dados NativeBackupEncryption aplicando as técnicas de compressão de dados para economia de espaço em disco e principalmente o uso da opção Encrytpion que nos permite escolher o algoritmo de criptografia e qual certificado a nível de servidor vamos utilizar, sendo assim, podemos executar o Bloco de Código 3 apresentado a seguir:

— Bloco de Código 3 —
Backup Database NativeBackupEncryption
To Disk = ‘S:\MSSQL-2016\Backup\Backup-NativeBackupEncryption.Bak’
With Compression,
Encryption
(Algorithm = AES_256,
Server Certificate = CertNativeBackupEncryption)
Go

Muito bem, como todo procedimento de backup, ao final da execução do comando Backup Database o Management Studio apresenta aquele tradicional conjunto de informações relacionadas ao nosso backup, algo que também não é diferente quando fazendo uso de um backup criptografado. A Figura 3 apresentado o arquivo de backup Backup-NativeBackupEncryption.Bak criado e armazenado após a conclusão da execução do comando Backup Database:

Figura 3 – Arquivo NativeBackupEncryption.Bak criado e armazenado em disco.

Estamos quase no final, continuando mais um pouco, vamos garantir e comprovar que realmente nosso backup foi criptografado. Você pode estar querendo ter a certeza que nosso backup esta criptografado, para realizarmos as conhecida prova dos nove, vamos fazer uso do tradicional comando Restore HeaderOnly, através do Bloco de Código 4 declarado abaixo:

— Bloco de Código 4 —

Restore HeaderOnly
From Disk = ‘S:\MSSQL-2016\Backup\Backup-NativeBackupEncryption.Bak’
Go

Para ilustrar o resultado obtido apos a execução do bloco de código 4, podemos observar os valores apresentados nas colunas: KeyAlgorithm, EncryptorThumbprint e EncryptorType, conforme apresenta a Figura 4.

Figura 4 – Informações referentes ao uso da criptografia no arquivo de backup.

Note que estão sendo apresentados para as respectivas colunas o algoritmo que utilizamos no procedimento de backup e seus respectivos encryptors, mecanismos utilizados para aplicar a criptografia.

Sensacional, conseguimos criar um backup com criptografia de seu conteúdo de forma nativa, sem ter a necessidade de utilizar ferramentas ou recursos de terceiros, fazendo uso total das funcionalidades e características existentes no Microsoft SQL Server. Mesmo assim, alguns pontos importantes devem ser destacados antes de concluirmos mais um post, a seguir destaco os benefícios e limitações do Native Backup Encryption.

Benefícios

  1. O uso deste tipo de recurso com certeza poderá trazer aos organizações e profissionais de banco de dados um grande benefício no que se relacionada as questões de segurança e armazenamento de dados após o processo de backup.
  2. Caso você esteja utilizando atualmente uma ferramenta de terceiros para backups criptografados, você pode comparar essa ferramenta com a funcionalidade e o desempenho de backups criptografados nativos e ver se isso preenche sua exigência.

Limitações

  1. O Native Backup Encryption não esta disponível nas edições Express e Web do Microsoft SQL Server.
  2. O processo de appending capacidade de abrir um arquivo de backup já existente e adicionar o novo conteúdo ao seu final não é suportado para backups criptografados.

Referências

https://blogs.technet.microsoft.com/dataplatforminsider/2013/10/17/sql-server-2014-ctp-2-now-available/

https://www.pythian.com/blog/sql-server-2014-ctp-2-native-backup-encryption/

https://docs.microsoft.com/en-us/sql/t-sql/statements/backup-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/restore-statements-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-certificate-transact-sql

https://docs.microsoft.com/en-us/sql/t-sql/statements/restore-statements-headeronly-transact-sql

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/2017/04/30/14-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/03/25/13-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

Conclusão

Durante muito tempo este foi um dos recursos mais esperados e aguardos pelos profissionais do Microsoft SQL Server, principalmente pela necessidade até então da aquisição de ferramentas de terceiros, o que gerava custos, bem como, para realizar um procedimento simples trabalhar com dois produtos distintos ao mesmo tempo, o que para alguns pode parecer dificultoso.

Neste post fizemos uso do algoritmo AES_256 considerado por muitos profissionais um dos mais seguros, mas vale a pena fazer uso e comparação dos demais para justamente identificar suas diferenças de comportamento ainda mais se levarmos em consideração diferenças no tempo de execução de um backup criptografado com outro algoritmo.

Mas esse desafio e análise vou deixar para você!!!

Agradecimentos

Antes de finalizar, são 8:54hrs da manhã, estou terminando o post, mas com um lindo dia me esperando para estudar e trabalhar, faça você isso também aproveite a sua vida, pois ela passa muito rápido.

Espero que este conteúdo possa lhe ajudar e ser útil em suas atividades profissionais e acadêmicas.

Um forte abraço, até o próximo post da sessão Para que serve…..

Valeu.

#14 – Para que serve


Olá, boa noite….

Final de noite de domingo, véspera de feriado e nosso Brasil desde a última sexta – feira dia 28/04 vivendo fortes emoções na política, economia, esporte e principalmente cidadania. Alias dia 28/04/2017 uma das datas mais importantes da minha vida, neste dia comemorei mais uma primavera como gostam de dizer alguns dos meus familiares, já se vão 37 anos, muitos destes anos dedicados a minha esposa, filhos, filha, trabalho e principalmente a áreas de educação e tecnologia.

Aproveito para agradecer a todos os amigos, colegas, familiares, alunos, enfim pessoas que por algum momento passaram pela minha vida nestes últimos 37 anos.

Dando continuidade, este é o novo post da sessão Para que serve, sendo o post de número 14, muito bom, lentamente esta sessão esta ganhando corpo e força com os meus seguidores.

Hoje vou destacar um conteúdo bastante simples e direto, mas muito interesse e bastante útil, que consiste basicamente em como através da linguagem Transact-SQL podemos identificar ou até mesmo descobrir quais portas de rede estão em uso em uma instância ou servidor SQL Server baseadas no protocolo TCP/IP e na versão IPV4 do protocolo IP.

Isso pode parecer algo bastante simples de ser feito, na verdade é mesmo, mas até a versão do SQL Server 2008 R2 SP1 era um pouco chato e até mesmo complexo para se obter esta simples informação, cenário que muito drasticamente a partir da versão 2012 e se mantem presente na versão 2016.

Desta forma, seja bem – vindo ao #14 – Para que serve – Identificando as portas de rede TCP/IP através da DMV – sys.dm_tcp_listener_states.

Introdução

Obter informações sobre as portas de rede utilizadas por uma instância ou servidor SQL Server, por mais simples que parece ser era considerada por muitos profissionais de bancos de dados uma das tarefas mais chatas e até mesmo tediosas pelo simples fato de não existir especificamente uma ferramenta da Microsoft dedicada para este cenário, mesmo assim existem algumas possibilidades que podemos ou não considerar práticas ou inseguras.

A seguir apresento as possibilidades mais conhecidas:

BPCheck: Não pode ser considerada dentre as possibilidades a mais conhecida, muito menos a mais simples, mas sim a mais completa no conjunto de dados retornados para o usuário. O BPCheck – Best Practices and Performance Check, criado em 28-07-2011 por Pedro Lopes (Senior Program Manager for the Microsoft SQL Server Product Group – Tiger Team), com base na versão 2005 do SQL Server e mantido até as versões atuais.

Posso dizer, que este é um daqueles scripts mágicos criados pelos maiores profissionais do SQL Server espalhados pelo mundo, dentre os quais o Pedro Lopes faz parte, o nível de complexidade existente no código fonte deste arquivo comprova o grau de conhecimento e capacidade técnica que este profissional apresenta.

Microsoft SQL Server 2008 e 2008 R2: Microsoft trabalhou e adicionou a partir da versão 2008 R2 SP1 uma forma não muito usual, nem muito interessante de se obter informações sobre as portas de rede fazendo uso da DMV – Dynamic Management View (Visão de Gerenciamento Dinâmico): sys.dm_server_registry, onde era possível coletar informações com base nas chaves de registro do Windows, o que sinceramente não podemos dizer que é algo muito indicado ou até mesmo seguro, mesmo assim era a única forma direta através do Management Studio de se encontrar estas informações. Esta DMV apresenta o seguinte conjunto de colunas:

Nome da coluna Tipo de dados Descrição
registry_key nvarchar(256) Nome da chave do Registro. Permitir valor nulo.
value_name nvarchar(256) Nome do valor da chave. Este é o item mostrado na coluna Nome do Editor do Registro. Permitir valor nulo.
value_data sql_variant Valor dos dados da chave. Este é o valor mostrado na coluna Dados do Editor do Registro para uma determinada entrada. Permitir valor nulo.

Microsoft SQL Server 2012: Talvez pode ser considerada até o presente momento a forma mais de se obter através de uma ferramenta gráfica neste caso o Management Studio as informações relacionadas a portas e protocolos de rede TCP/IP, fazendo-se uso da DMV – Dynamic Management View (Visão de Gerenciamento Dinâmico): sys.dm_tcp_listener_states, introduzida neste versão do SQL Server. Esta DMV apresenta o seguinte conjunto de colunas:

Nome da coluna Tipo de dados Descrição
listener_id int A ID interna do ouvinte. Não permite valor nulo.

Chave primária.

ip_address nvarchar48 O endereço IP do ouvinte que está online e está sendo escutando no momento. IPv4 ou IPv6 é permitido. Se um ouvinte possuir os dois tipos de endereços, eles serão listados separadamente. Um curinga de IPv4, exibido como “0.0.0.0”. Um curinga de IPv6, exibido como “::”.

Não permite valor nulo.

is_ipv4 bit Tipo de endereço IP

1 = IPv4

0 = IPv6

port int O número da porta na qual o ouvinte está escutando. Não permite valor nulo.
Tipo tinyint Tipo de ouvinte, um dos seguintes:

0 = Transact-SQL

1 = Service Broker

2 = Espelhamento do banco de dados

Não permite valor nulo.

type_desc nvarchar(20) Descrição do tipo, um dos seguintes:

TSQL

SERVICE_BROKER

DATABASE_MIRRORING

Não permite valor nulo.

state tinyint O estado do ouvinte do grupo de disponibilidade, um dos seguintes:

1 = Online. O ouvinte está escutando e processando solicitações.

2 = Reinício pendente. o ouvinte está offline, pendente de uma reinicialização.

Se o ouvinte do grupo de disponibilidade estiver escutando na mesma porta que a instância do servidor, esses dois ouvintes sempre terão o mesmo estado.

Não permite valor nulo.

Observação Observação
Os valores desta coluna são oriundos do objeto TSD_listener. A coluna não dá suporte a um estado offline porque, quando o TDS_listener está offline, ele não pode ser consultado para obter o estado.
state_desc nvarchar(16) Descrição do estado, um dos seguintes:

ONLINE

PENDING_RESTART

Não permite valor nulo.

start_time datetime Carimbo de data/hora que indica quando o ouvinte foi iniciado. Não permite valor nulo.

Bom, agora que já conhecemos as possibilidades de se coletar as informações relacionadas a portas e protocolos de rede, vamos colocar a mão na massa ou melhor no teclado e por em prática o uso das DMVs: sys.dm_server_registry e sys.dm_tcp_listener_states.

Exemplos

1 – Identificando a Default Port através da sys.dm_server_registry:

SELECT MAX(CONVERT(VARCHAR(15),value_data)) As ‘Default Port’ FROM sys.dm_server_registry

WHERE registry_key LIKE ‘%MSSQLServer\SuperSocketNetLib\Tcp\%’

AND value_name LIKE N’%TcpPort%’

AND CONVERT(float,value_data) > 0

Go

 

 2 – Identificando a Dynamic Port através da sys.dm_server_registry:

SELECT MAX(CONVERT(VARCHAR(15),value_data)) As ‘Dynamic Port ‘ FROM sys.dm_server_registry

WHERE registry_key LIKE ‘%MSSQLServer\SuperSocketNetLib\Tcp\%’

AND value_name LIKE N’%TcpDynamicPort%’

AND CONVERT(float,value_data) > 0

Go

 

3 – Obtendo a relação de Listeners, Ports, Protocols e demais dados relacionadas a network através da sys.dm_server_registry:

select Registry_key, Value_Name, Value_Data FROM sys.dm_server_registry

where registry_key like ‘%SuperSocketNetLib%’

Go

 

4 – Identificando a Default Port através da sys.dm_tcp_listener_states:

SELECT port As ‘Default Port’ FROM sys.dm_tcp_listener_states

WHERE is_ipv4 = 1

AND [type] = 0

AND ip_address <> ‘127.0.0.1’

Go

 

5 – Obtendo a relação de Listeners, Ports e Protocols através da sys.dm_tcp_listener_states:

Select listener_id, ip_address, is_ipv4,

Port, Type, type_desc, state_desc,

start_time

from sys.dm_tcp_listener_states

Go

Show de bola, legal, legal, aqui estão os exemplos, se você obter realmente o uso da DMV sys.dm_server_registry em comparação com a DMV sys.dm_tcp_listener_states pode ser considerado bem mais complexo e confuso, pois torna-se necessário conhecer um pouco da estrutura de chaves de registro do Windows, bem como, o que representa a sequência de valores apresentados na coluna Registry_Key o que para muitos profissionais não é algo são comum de ser entendido.

Referências

https://blogs.msdn.microsoft.com/sql_server_team/programmatically-find-sql-server-tcp-ports/

https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-tcp-listener-states-transact-sql

https://msdn.microsoft.com/en-us/library/hh204561.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/2017/03/25/13-para-que-serve/

https://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

Conclusão

Mesmo com todas as possíveis dificuldades, falta de ferramenta exclusiva ou facilidade para se conseguir obter uma simples informação relacionadas as portas de rede e protocolos, sempre vai existir alguma maneira de se conseguir encontrar o que deseja no Microsoft SQL Server, seja através de um script mágico como o destacado hoje neste post ou através de um recurso não muito usual, independente da maneira que possa ser dentro da estrutura, do coração do SQL Server em suas tabelas internar em conjunto com o uso das DMVs torna-se totalmente viável coletar qualquer tipo de dado desejado.

Neste post, você pode comprovar como é possível encontrar os dados relacionados á protocolos, portas, listeners e demais elementos envolvidos nos processos de network, onde uma simples aplicação, website, aplicativo ou ERP venha a necessitar acessar, consumir e trocar dados via pacotes de rede com o Microsoft SQL Server.

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á….

#13 – Para que serve


Muito boa noite galera, tudo bem?

Noite de sábado, temperatura agradável, galera curtindo uma pizza, balada entre outras coisas e eu estou aqui para compartilhar com você mais um post da minha sessão Para que serve, hoje o post de número 13. Você esta pensando, post de número 13 não é nada muito “ospicioso” como diária um personagem de novela (kkkkk).

Que nada vamos em frente não se preocupe com este número, tenho a certeza que este post será muito legal e apresentará informações de alto astral relacionada ao novo Microsoft SQL Server 2016.

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 #13 – Para que serve de hoje, tenho a certeza que você vai gostar.

No post de hoje, vou a destacar uma das mais aguardados melhorias relacionadas ao SQL Server, estou me referindo a capacidade de consultor os histogramas de estatísticas de processamento de forma programada, isso mesmo, agora a partir da nova atualização cumulativa do SQL Server 2016 SP1, conhecida como Cumulative Update 2, temos duas novas DMF – Dynamic Management Function – Função de Gerenciamento Dinâmico que nos permitem de forma direta através do uso do comando Select obter informações sobre os histogramas e dados estatísticos.

Vou fazer um pequeno suspense, não vou revelar o nome de ambas as DMFs, somente no decorrer deste post você vai conhece-las.

Muito bem, após deixar este gostinho de quero mais, chegou a hora de conhecer estas novas funcionalidades e ver como podemos aplicar isso no nosso ambiente.

Como aqui o #13 – Para que serve – Uma nova e mais fácil maneira de obter informações sobre o histograma de estatísticas no Microsoft SQL Server 2016 SP1 –

Introdução

Quando se referimos a estatísticas de bancos de dados, estatísticas de processamento ou estatísticas de consumo de operadores do plano de execução, estamos na verdade se referindo ao bom e velho conceito de estatísticas, o qual devemos voltar no tempo para entender melhor se realmente quisermos saber a importância deste assunto, para este post este não é o foco, na verdade o que eu quero é mostrar que a partir da nova atualização cumulativa aplicada para o Service Pack 1 do SQL Server 2016 os times de engenheiros e desenvolvedores do SQL Server introduziram no produto duas novas DMF denominadas sys.dm_db_stats_histogram e sys.dm_db_stats_properties, onde através do uso destas novas DMFs podemos obter todas as informações relacionadas as estatísticas de processamento de nossas querys e principalmente o histograma de maneira mais rápida, fácil e principalmente legível, pois particularmente falando ler o histograma através do comando DBCC Show_Statistics não era nada fácil(kkkkk).

Vamos conhecer um pouco mais sobre cada DMF para entender melhor seu funcionamento:

sys.dm_db_stats_histogram: Retorna o histograma de estatísticas para o objeto de banco de dados especificado (tabela ou exibição indexada) no atual SQL Server banco de dados. Semelhante ao DBCC SHOW_STATISTICS WITH HISTOGRAM.

Ao executar esta nova DMF o Microsoft SQL Server 2016 apresentará uma tabela de resultado contendo o seguinte conjunto de colunas, conforme a Tabela 1 ilustra:

Nome da coluna

Column name
Tipo de dados Description
object_id int ID do objeto (tabela ou exibição indexada) para o qual as propriedades do objeto de estatísticas serão retornadas.
stats_id int ID do objeto de estatísticas. É exclusiva na tabela ou exibição indexada. Para obter mais informações, veja sys.stats.
step_number int O número da etapa do histograma.
range_high_key sql_variant Valor da coluna associada superior de uma etapa do histograma. O valor da coluna também será denominado um valor de chave.
range_rows real Número estimado de linhas cujo valor de coluna fica dentro de uma etapa do histograma, excluindo-se o limite superior.
equal_rows real Número estimado de linhas cujo valor de coluna é igual ao limite superior da etapa do histograma.
distict_range_rows bigint Número estimado de linhas com um valor de coluna distinto dentro de uma etapa do histograma, excluindo-se o limite superior.
average_range_rows real Número médio de linhas com valores de colunas duplicados em uma etapa de histograma, exceto o limite superior (RANGE_ROWS / DISTINCT_RANGE_ROWS para DISTINCT_RANGE_ROWS > 0).

sys.dm_db_stats_properties: Retorna propriedades de estatísticas para o objeto de banco de dados especificado (tabela ou exibição indexada) no banco de dados do SQL Server atual. Para tabelas particionadas, consulte a DMF sys.dm_db_incremental_stats_properties.

Ao executar esta nova DMF o Microsoft SQL Server 2016 apresentará uma tabela de resultado contendo o seguinte conjunto de colunas, conforme a Tabela 2 ilustra:

Nome da coluna Tipo de dados Description
object_id int ID do objeto (tabela ou exibição indexada) para o qual as propriedades do objeto de estatísticas serão retornadas.
stats_id int ID do objeto de estatísticas. É exclusiva na tabela ou exibição indexada. Para obter mais informações, veja sys.stats.
last_updated datetime2 Data e hora da última atualização do objeto de estatísticas.
rows bigint O número total de linhas da tabela ou exibição indexada na última atualização das estatísticas. Se as estatísticas forem filtradas ou corresponderem a um índice filtrado, o número de linhas talvez seja menor do que o número de linhas na tabela.
rows_sampled bigint O número total de linhas amostradas para cálculos de estatísticas.
etapas int O número de etapas no histograma. Para obter mais informações, veja DBCC SHOW_STATISTICS.
unfiltered_rows bigint O número total de linhas da tabela antes da aplicação da expressão de filtro (para estatísticas filtradas). Se as estatísticas não forem filtradas, unfiltered_rows será igual ao valor retornado na coluna de linhas.
modification_counter bigint Número total de modificações da coluna de estatísticas principal (a coluna em que o histograma é criado) desde que as últimas estatísticas de tempo foram atualizadas.

Essa coluna não mantém informações para tabelas com otimização de memória.

Agora que o segredo foi revelado, podemos começar a pensar na maneira que estas novas DMFs podem ser utilizadas, para tal vamos fazer uso do banco de dados analítico: AdventureworksDW2016CTP3 disponível para download através do link: http://www.microsoft.com/en-us/download/details.aspx?id=49502

Utilizando as novas DMFs

Seguindo em frente vamos começar nossa prática, para tal a primeira coisa a fazer é executar o bloco de código 1 declarado abaixo, antes clique no botão Include Actual Execution Plan em seu Management Studio, pois vamos realizar uma análise após a execução.

— Bloco de Código 1 —

Figura 1 – Instrução select declarada para o bloco de código 1.

Após a execução deste bloco de código obtemos o seguinte conjunto de dados relacionados ao operador Clustered Index Scan, conforme a Figura 2 apresentada abaixo:

Figura 2 – Dados relacionadas ao operador Clustered Index Scan.

Note que estou destacando na figura os dados referentes aos seguintes elementos:

  • Number of Rows Read;
  • Actual Number of Rows;
  • Estimated Number of Rows; e
  • Estimated Number of Rows to be Read.

Você pode estar se perguntando, o porque o Junior Galvão acabou destacados estes valores na Figura 2? A resposta é muito simples, uma das maneiras para tentar entender o comportamento do SQL Server no processamento de seus operadores e procurar ter uma ideia de estatísticas de processamento é justamente através da leitura e entendimento destes quatro conjunto de dados, o que posso dizer que não é a melhor forma para se encontrar informações sobre processamento e estatísticas.

Agora imagine que todas as vezes que você desejar obter informações sobre as estatísticas de processamento e como elas estão armazenadas e seus status, pois bem, é justamente neste ponto que agora no novo SQL Server 2016 SP1 CU 2 você terá facilmente a capacidade de fazer isso acontecer, para tal vamos executar o bloco de código 2 fazendo uso da nova DMF, sys.dm_db_status_histogram.

— Bloco de Código 2 —

Figura 3 – Bloco de código 2.

Observe que estamos fazendo uso da nova DMF sys.dm_db_status_histogram e neste momento nosso Management Studio deverá ter retornado um conjunto de linhas conforme a Figura 4 abaixo ilustra:

Figura 4 – Conjunto de dados estatísticas referentes ao processamento do bloco de código 2.

Ao analisarmos a Figura 4 podemos notar facilmente o conjunto de linhas de retornado contendo todas as informações relacionadas ao histograma da estatísticas de número 2 para a tabela [dbo].[FactResellerSales]. Tenho a certeza que você tão surpreso quanto eu quando executei pela primeira vez este mesmo bloco de código, realmente é assustador a facilidade que temos agora em entender o histograma.

Sensacional, mas como o SQL Server consegui apresentar estes dados desta maneira? Como de costume a resposta é simples, através da capacidade de utilizar em tempo de execução uma Table Valued Function denominada DM_DB_STATS_HISTOGRAM, ou seja, uma função que armazena valores em uma determinada tabela utilizada especificamente para esta nova DMF, a comprovação disso esta na Figura 5 que ilustra o plano de execução utilizado para o processamento do bloco de código 2.

Figura 5 – Plano de execução gerado para o processamento do bloco de código 2.

Continuando nossa jornada, o próximo passo é fazer uso da outra DMF, no caso a sys.dm_db_stats_properties, onde a qual vamos nos permitir obter o mesmo conjunto de valores referente ao cabeçalho da estatística o mesmo realizado através do comando DBCC SHOW_STATISTICS com a opção WITH STATS_HEADER.

Vamos então executar o bloco de código 3 apresentado a seguir:

Figura 7 – Bloco de código 3.

E qual será o resultado obtido após o processamento do bloco de código 3? A resposta é apresentada na Figura 7 a seguir:

Figura 7 – Resultado do processamento do bloco de código 3.

Show de bola, temos exatamente o mesmo conjunto de dados retornados pela DMF sys.dm_db_stats_properties da mesma forma que teríamos se estivéssemos utilizando do bom e velho DBCC SHOW_STATISTICS, não é realmente fantástico, só de imaginar a capacidade de possibilidades que teremos de utilizar estes dados a partir de agora realmente é algo surreal.

Da mesma forma que o SQL Server 2016 SP1 CU2 utiliza uma Table Valued Function para armazenar e apresentar os consumidos e coletados pelo processamento da sys.dm_db_status_histogram, também é utilizada uma outra Table Valued Function para o processamento da sys.dm_db_stats_properties denominada DM_DB_STATS_PROPERTIES.

Para finalizar nossa brincadeira e mostrar como estas novas funcionalidades podem nos ajudar, vamos utilizar o bloco de código 4 para através dele conseguir especificar uma determinada range_key existe em nossas estatísticas. Poxa vida especificar em um comando select qual determinada faixa de valores estatísticas nós queremos obter dados realmente é acima do que estávamos pensando, por incrível que isso possa parecer, é totalmente possível de ser feito a partir de agora.

— Bloco de Código 4 —

Figura 8 – Retorno de dados referentes ao filtro da faixa de valores.

Putz, que coisa louco, meu deus, temos com base no bloco de código 4 a comprovação que podemos através do uso de outras DMFs inline retornado dados estatísticos com base em filtros ou predicados declarados na cláusula where existente na linha 26 onde, a coluna sh.range_high_key é justamente uma coluna pertencente a nova DMF sys.dm_db_stats_histogram.

Que loucura isso, fora de série esta nova capacidade do SQL Server, fantástico, inimaginável, fora do comum o que o time de engenheiros do SQL Server fizeram desta vez, show.

Referências

https://msdn.microsoft.com/library/mt794645.aspx

https://blogs.msdn.microsoft.com/sql_server_team/easy-way-to-get-statistics-histogram-programmatically/

https://support.microsoft.com/en-us/help/4013106/cumulative-update-2-for-sql-server-2016-sp1

http://msdn.microsoft.com/library/jj553546.aspx

http://msdn.microsoft.com/library/ms174384.aspx

https://msdn.microsoft.com/pt-br/library/mt761751.aspx

https://msdn.microsoft.com/pt-br/library/ms177623.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/2017/01/23/12-para-que-serve/

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

A maneira como nossos dados estão constantemente sendo processados é algo que a cada dia um DBA ou profissional de banco de dados se pergunta. Saber em qual momento uma determinada query, transação ou simplesmente um comando select pode ocasionar algo tipo de impacto em nosso ambiente ainda é mais preocupante. Foi justamente pensando nisso que a Microsoft e seu time de profissionais que trabalham com o SQL Server buscaram responder a partir da disponibilidade das duas novas DMFs: sys.dm_db_stats_histogram e sys.dm_db_stats_properties recursos adicionados na versão 2016 SP1 e disponível também para próximas versão do SQL Server, dentre elas a SQL Server vNext.
Esta nova maneira de acessar e consultar os dados coletados e armazenados no histograma poderá ajudar em muito os profissionais de banco de dados e desenvolvedores a entender como seus estatísticas de processamento de dados estão sendo afetadas com base nos processos de manipulação.
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á…..

#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á…..