Arquivo da categoria: Para que serve

Sessão dedicada a apresentar recursos, funcionalidades, scripts, e curiosidades existentes no Microsoft SQL Server.

#22 – Para que serve


Oi, bom dia, tudo bem?

Seja bem-vindo a mais um post da sessão Para que Serve, sendo este o de número 22, mais um dia de muito trabalhando começando, repleto de atividades, compromissos, reuniões, enfim tudo aquilo que normalmente estamos acostumados a nos deparar em nossos convívio diário.

E eu (parece música), estou aqui, como faço normalmente, acordando bem cedinho, para poder aproveitar da melhor maneira possível meu precioso tempo livre, colocando em prática algo que adoro fazer, publicar um post novo em meu blog mantendo a tradição de querer renovar e compartilhar as experiências e aprendizados adquiridos em minhas atividades profissionais e acadêmicas.

No post de hoje, não estarei compartilhando um conteúdo que pode ser considerado novo, ao contrário, quero destacar uma das mais antigas propriedades existentes em bancos de dados criados no Microsoft SQL Server desde suas versões mais antigas, mais especificamente falando da versão 2000 (é muito importante entender o passado, aprender com ele, para podemos melhorar e ofertar um futuro melhor) em diante.

Estou se referindo a propriedade denominada Page_Verify, a qual tem um papel de extrema importância no comportamento de um banco de dados de usuários, algo que pode impactar na forma de armazenamento, leitura e escrita das páginas de dados que formam a estrutura física e lógica de nossas tabelas e por consequência de nossos bancos de dados.

No decorrer deste post serão destacadas as respectivas opções existentes para esta propriedade, como também, será realizado uma análise comparativa no que diz respeito ao tempo de processamento de dados tendo como parâmetro um simples bloco de código inserindo 100.000 (Cem mil linhas de registros lógicos) com dados aleatórios.

Destaco antecipadamente que esta análise comparativa em nenhum momento leva em consideração características de Hardware, versão de Sistema Operacional ou uso de uma aplicação específica. Na verdade o objetivo desta simples análise é elucidar o que o uso desta propriedade, suas opções e respectivos algoritmos de processamento podem influenciar diretamente nos processos de escrita e leitura de dados.

Sendo assim, chegou a hora de conhecer um pouco mais sobre o post de número 22 da sessão Para que serve. Mas uma vez, bem vindo ao #22 – Para que serve – Propriedades de Bancos de Dados – Page_Verify e suas opções.

Espero que você esta animado para conhecer um pouco mais sobre esta propriedade, caso já conheça, continue lendo este post, sempre podemos aprender algo novo….


Introdução

Criar uma nova tabela para alocar dados em qualquer banco de dados existente no Microsoft SQL Server, pode ser considerada uma tarefa ou procedimento de fácil compreensão, muito simples de ser realizada tanto por linha de comando como também por interface gráfica, mas por trás “dos panos” diversos procedimentos internos são realizados pelo Sistema Gerenciador de Banco de Dados e seus diversos recursos e componentes internos.

Imagine então a tarefa de criação de um novo banco de dados, não parece também ser algo muito, mas muito simples! Teoricamente sim, mas se começarmos a analisar, entender e de preferência estudar cada uma das diversas propriedades que formam e orientam o Mecanismo de Bancos de Dados na execução da instrução de criação de um novo banco, teremos a total certeza que isso não tão simples como pensamos.

Pensando justamente neste cenário, decidi então identificar uma propriedade que por muitas vezes me passou totalmente despercebida e nos últimos dias acabou sendo motivo de estudos, como já destacado anteriormente estou me referindo a propriedade Page_Verify, sendo esta um das mais antigas propriedades existentes em bancos de dados desde a versão 2000 ou nível de compatibilidade 80, inicialmente apresentava como conjunto de opções os valores: None e Torn_Page_Detection e a partir da versão 2005 do Microsoft SQL Server ganhou uma nova opção conhecida como CheckSum e por consequência um novo algoritmo.

Vamos então conhecer um pouco mais sobre esta propriedade.

Propriedade de Banco de Dados Page_Verify

Propriedade existente em bancos de dados criados no Microsoft SQL Server que possui basicamente a função de permitir ao Sistema Gerenciador de Banco de Dados identificar e informar as chamadas Páginas de Dados Incompletas (Incomplete Pages) ou Páginas de Dados Suspeitas (Suspect Pages), através de dados internos catalogados e coletados na tabela suspect_pages existente dentro do banco de dados de sistemas MSDB.

Outra característica muito importante apresentada pela Page_Verify, relaciona-se ao método de verificação que garante ao Microsoft SQL Server que as páginas de dados que compõem um determinada tabela podem ser consideradas integras e completas, esta capacidade esta totalmente relacionada ao uso de um algoritmo pertencente a esta propriedade de acordo com o tipo de verificação de página que deve ser aplicada.

Esta tão importante característica, deve ser levada em consideração, mesmo tendo diversas funcionalidades que nos permitem identificar se a estrutura física e lógica de um banco de dados pode ser considerado integra. Em inúmeros cenários um banco de dados pode aparentemente estar apresentando falhas na estrutura interna que define uma respectiva página de dados sem necessariamente existir ou que tenha ocorrida uma falha física nas unidades de disco que armazenam tal página de dados.

A identificação se uma página de dados pode ou não ser considerada incompleta, suspeita ou quebrada é feita através da identificação de bits armazenados diretamente no cabeçalho de dados existente na respectiva página, é justamente por isso que a propriedade Page_Verify utiliza alguns algoritmos de acordo com a opção escolhida nas configurações e propriedades de um banco de dados, como recurso para garantir em tempo real o menor número de ocorrências ou possíveis falhas que venham a ocasionar uma perda de dados.

Vamos agora conhecer as formas de verificação de páginas de dados e seus respectivos algoritmos.

Formas de Verificação: None, Torn_Page_Detection e CheckSum

Até a versão 2005 SP2 do Microsoft SQL Server tínhamos somente as formas de verificação de páginas de dados None e Torn_Page_Detection, mas este cenário muito e uma nova opção denominada CheckSum foi adicionada, sendo esta então valor padrão para propriedade Page_Verify para bancos de dados com nível de compatibilidade 90 ou superior.

None: Ao escolher esta opção, o Microsoft SQL Server recebe a orientação para que não seja realizado os procedimentos de verificação e correção das páginas lidas durante os atividades de armazenamento de dados.

Logicamente esta é uma opção que não deverá ser utilizada em ambientes que não podemos correr o menor risco possível de aceitar falhas ou perdas de dados, mesmo confiando nas tecnologias de Hardware, estratégias de armazenamento, contingência e retenção de dados, a partir do momento que esta opção for escolhida você estará assumindo o risco.

Torn_Page_Detection: Opção padrão existente na versão 2000 do Microsoft SQL Server. Ao escolher esta opção, estaremos definindo o uso do algoritmo que armazenará em tempo real no cabeçalho de cada página de dados bits que identificam a operação de gravação.

No momento em que esta mesma página é lida de um disco durante a operação de leitura, os bits do cabeçalho da página são comparados àqueles no corpo da página. Caso alguma discrepância venha a ser detectada, esta específica página de dados será em tempo real considerada quebrada (incompleta ou suspeita) e o problema é relatado para um usuário.

Vale destacar que este algoritmo no momento em que uma página de dados esta sendo verificada, realiza o procedimento de duplicação de pequenas porções de bits de dados contidos em seu cabeçalho, algo que não podemos necessariamente relatar como um consumo maior de espaço em disco, na verdade é esta tarefa de duplicação de dados bits de dados utilizada para garantir a consistência da página. Por outro lado, dependendo do tipo de falha que poderá ocorrer alguns erros acabam não sendo detectados, se justamente o bit quebrado é um daqueles que não foram duplicados no cabeçalho da página, o dano não é detectado.

CheckSum: Opção padrão desde o SQL Server 2005 SP3, a partir do momento que esta opção é selecionado, o Microsoft SQL Server estará fazendo uso do algoritmo responsável durante  operação de gravação, realizar uma soma de verificação (CheckSum) que calcula a partir da estrutura completa de uma página de dados um valor a ser armazenado diretamente em seu cabeçalho.

No momento em que a respectiva página de dados é lida a partir de um disco, CheckSum é calculado novamente e comparado com o valor no cabeçalho da página. A idéia é semelhante ao TORN_PAGE_DETECTION, podemos destacar que ambos algoritmos calculam um valor de verificação para uma página e armazenam o resultado no cabeçalho da página, mas CheckSum usa a página inteira para cálculo, ao contrário do TORN_PAGE_DETECTION que utiliza apenas um pequeno número de bits existente na página de dados.

Se compararmos a opção TORN_PAGE_DETECTION com a opção CheckSum, podemos afirmar que o CheckSum apresenta uma forma de análise e verificação de possíveis falhas e erros nas atividades de Input/Output de dados, mais confiável e inteligente, estabelecendo uma cobertura mais precisa que garante uma assertividade maior na identificação de possíveis páginas de dados incompletas, suspeitas ou quebradas.

Agora que conhecemos a propriedade Page_Verify e suas opções, vamos então conhecer de forma prática e entender o comportamento de cada uma delas, realizando assim a análise destacada no início deste post.

Chegou a hora de colocar a mão nos teclados, como de costume teremos um ambiente de testes a ser criado, o que será utilizado como cenário de estudos.

Criando o Ambiente

Em meu ambiente de estudos estou utilizando o Microsoft SQL Server 2017 Enterprise Edition – Cumulative Update 9 e Sistema Operacional Windows 10, fique a vontade para utilizar o melhor cenário possível dentro das suas necessidades.

Como já destacado anteriormente esta análise ou possível cenário de estudo não consiste em afirmar qual é a mais rápida ou melhor forma de verificação de páginas de dados, mas sim demonstrar o quanto uma determinada opção poderá impactar ou influenciar nos custos de processamento de dados nas atividades de leitura e escrita, nesta prática mais especificamente nas atividades de gravação de dados.

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: TesteDatabasePageVerify;
  • Tables: TabelaPageVerify; e PageVerifyTempoDecorrido.

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

— Acessando o Banco de Dados TesteDatabasePageVerify —
Use TesteDatabasePageVerify
Go

— Criando a Tabela TabelaPageVerify —
Create Table TabelaPageVerify
(Codigo Int Identity(1,1) Not Null Primary Key,
Texto VarChar(10) Not Null,
Quantidade SmallInt Not Null,
ValoresNumericos Numeric(18, 2) Not Null,
DataAtual Date Not Null)
Go

— Criando a Tabela PageVerifyTempoDecorrido —
Create Table PageVerifyTempoDecorrido
(NumeroDaAnalise SmallInt Identity(1,1) Not Null,
TipoDaAnaliseRealizada Varchar(22) Not Null,
HoraInicio Time Not Null,
HoraFim Time Not Null,
HoraDiferenca As (DateDiff(Second, HoraInicio, HoraFim)))
Go

A tabela TabelaPageVerify será utilizada como repositório dos dados que estaremos aleatoriamente gerando como fonte de análise, já a tabela PageVerifyTempoDecorrido terá um papel importante que consiste basicamente em armazenar os dados relacionada a análise realizada, dentre elas o Tipo da Análise, Horário de Início e Fim e a diferença em segundo entre os respectivos horários.

Avançando mais um pouco, vamos agora realizar propriamente a análise para cada uma das opções de verificação de páginas existentes, serão realizadas um total de 10 análises para cada opção e ao fim os dados armazenados na Tabela PageVerifyTempoDecorrido será apresentados como uma fonte de resultando da nossa análise.

Para realizar esta análise utilizaremos o Bloco de Código 2 apresentado abaixo:

— Bloco de Código 2 —
— Desativando a Contagem de Linhas —
Set NoCount On
Go

— Declarando as variáveis de controle —
Declare @Counter TinyInt = 0,
@Text Char(130),
@Position TinyInt,
@RowCount Int = 100000,
@HoraInicio Time = GetDate(),
@HoraFim Time

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

While @Counter <10 — Definindo a quantidade máxima de testes —
Begin

— Alterando a Propriedade Page_Verify para None —
Alter Database TesteDatabasePageVerify
Set Page_Verify None

— Inserindo a massa de dados na tabela TabelaPageVerify —
While (@RowCount >=1)
Begin

Set @Position=Rand()*130

Insert Into TabelaPageVerify (Texto, Quantidade, ValoresNumericos, DataAtual)
Values(Concat(SubString(@Text,@Position+2,2),SubString(@Text,@Position-4,4),SubString(@Text,@Position+2,4)),
Rand()*1000,
Rand()*100+5,
DATEADD(d, 1000*Rand() ,GetDate()))

Set @RowCount = @RowCount – 1
End

Set @HoraFim=GetDate()

Insert Into PageVerifyTempoDecorrido (TipoDaAnaliseRealizada , HoraInicio, HoraFim)
Values (‘None’, @HoraInicio, @HoraFim)

— Alterando a Propriedade Page_Verify para Torn_Page_Detection —
Alter Database TesteDatabasePageVerify
Set Page_Verify Torn_Page_Detection

— Inserindo a massa de dados na tabela TabelaPageVerify —
Set @RowCount = 100000
Set @HoraInicio = GetDate()

While (@RowCount >=1)
Begin

Set @Position=Rand()*130

Insert Into TabelaPageVerify (Texto, Quantidade, ValoresNumericos, DataAtual)
Values(Concat(SubString(@Text,@Position+2,2),SubString(@Text,@Position-4,4),SubString(@Text,@Position+2,4)),
Rand()*1000,
Rand()*100+5,
DATEADD(d, 1000*Rand() ,GetDate()))

Set @RowCount = @RowCount – 1
End

Set @HoraFim=GetDate()

Insert Into PageVerifyTempoDecorrido (TipoDaAnaliseRealizada , HoraInicio, HoraFim)
Values (‘Torn_Page_Detection’, @HoraInicio, @HoraFim)

— Alterando a Propriedade Page_Verify para CheckSum —
Alter Database TesteDatabasePageVerify
Set Page_Verify CheckSum

— Inserindo a massa de dados na tabela TabelaPageVerify —
Set @RowCount = 100000
Set @HoraInicio = GetDate()

While (@RowCount >=1)
Begin

Set @Position=Rand()*130

Insert Into TabelaPageVerify (Texto, Quantidade, ValoresNumericos, DataAtual)
Values(Concat(SubString(@Text,@Position+2,2),SubString(@Text,@Position-4,4),SubString(@Text,@Position+2,4)),
Rand()*1000,
Rand()*100+5,
DATEADD(d, 1000*Rand() ,GetDate()))

Set @RowCount = @RowCount – 1
End

Set @HoraFim=GetDate()

Insert Into PageVerifyTempoDecorrido (TipoDaAnaliseRealizada , HoraInicio, HoraFim)
Values (‘CheckSum’, @HoraInicio, @HoraFim)

Set @Counter = @Counter + 1
End
Go

Ótimo, após o processamento de nossa análise, gerou a hora de obter o resumo de tempo decorrido de processamento para cada opção, basta executar o Bloco de Código 3 divido em duas partes: Resumo Detalhado e Resumo Sumarizado, conforme declaro abaixo:

— Bloco de Código 3 —
— Parte 1 – Consultando o resumo detalhado —
Select NumeroDaAnalise,
TipoDaAnaliseRealizada,
HoraInicio,
HoraFim,
HoraDiferenca As ‘Segundos’
From PageVerifyTempoDecorrido
Go

A Tabela 1 apresentada a seguir, ilustra o detalhamento de dados coletados durante o processamento do Bloco de Código 2 realizado anteriormente:

Número da Análise Tipo da Análise Hora Início Hora Fim Segundos
1 None 10:45:59.1966667 10:46:51.0566667 52
2 Torn_Page_Detection 10:46:51.0566667 10:47:31.9633333 40
3 CheckSum 10:47:31.9800000 10:48:09.3566667 38
4 None 10:47:31.9800000 10:48:09.3566667 38
5 Torn_Page_Detection 10:48:09.3700000 10:48:38.6800000 29
6 CheckSum 10:48:38.6966667 10:49:13.6800000 35
7 None 10:48:38.6966667 10:49:13.6933333 35
8 Torn_Page_Detection 10:49:13.7133333 10:49:47.5100000 34
9 CheckSum 10:49:47.5100000 10:50:17.3433333 30
10 None 10:49:47.5100000 10:50:17.3600000 30
11 Torn_Page_Detection 10:50:17.3766667 10:50:49.7066667 32
12 CheckSum 10:50:49.7233333 10:51:23.3566667 34
13 None 10:50:49.7233333 10:51:23.3733333 34
14 Torn_Page_Detection 10:51:23.3733333 10:51:54.4200000 31
15 CheckSum 10:51:54.4200000 10:52:29.0466667 35
16 None 10:51:54.4200000 10:52:29.0500000 35
17 Torn_Page_Detection 10:52:29.0666667 10:53:00.8300000 31
18 CheckSum 10:53:00.8466667 10:53:32.1433333 32
19 None 10:53:00.8466667 10:53:32.1600000 32
20 Torn_Page_Detection 10:53:32.1766667 10:54:06.6466667 34
21 CheckSum 10:54:06.6633333 10:54:36.9400000 30
22 None 10:54:06.6633333 10:54:36.9400000 30
23 Torn_Page_Detection 10:54:36.9566667 10:55:09.7533333 33
24 CheckSum 10:55:09.7700000 10:55:41.8866667 32
25 None 10:55:09.7700000 10:55:41.8866667 32
26 Torn_Page_Detection 10:55:41.9033333 10:56:15.0166667 34
27 CheckSum 10:56:15.0166667 10:56:45.6966667 30
28 None 10:56:15.0166667 10:56:45.7133333 30
29 Torn_Page_Detection 10:56:45.7133333 10:57:21.7900000 36
30 CheckSum 10:57:21.7933333 10:57:54.8433333 33

Tabela 1 – Detalhamento de dados coletados após o processamento do Bloco de Código 2.

— Parte 2 – Consultando o resumo sumarizado —
Select TipoDaAnaliseRealizada,
Avg(HoraDiferenca) As ‘Média em segundos’
From PageVerifyTempoDecorrido
Group By TipoDaAnaliseRealizada
Order By ‘Média em segundos’ Desc
Go

A Tabela 2 apresentada a seguir, ilustra o dados coletados durante o processamento do Bloco de Código 2 realizado anteriormente de forma sumarizada com o cálculo da média de segundos gastos para o processamento de cada opção de verificação de páginas:

Tipo da Análise Média em segundos
None 34
Torn_Page_Detection 33
CheckSum 32

Tabela 2 – Dados sumarizados após o processamento do Bloco de Código 2.

Falta só um pouco, o último passo que iremos realizar, consiste na apresentação do Sumário de processamento em segundos demandado por cada algoritmo de verificação de páginas, através da execução do Bloco de Código 4, sendo que o mesmo apresentará os seguintes resultados:

  • Média de processamento em segundos;
  • Menor tempo de processamento em segundos;
  • Maior tempo de processamento em segundos; e
  • Somatória total do tempo de processamento.

— Bloco de Código 4 —
— Pivot —
Select ‘Média de processamento…..’ As ‘Sumário por segundos’, [None],[Torn_Page_Detection],[CheckSum]
From (Select TipoDaAnaliseRealizada,
HoraDiferenca
From PageVerifyTempoDecorrido
) As A
Pivot (Avg(HoraDiferenca) For TipoDaAnaliseRealizada In ([None],[Torn_Page_Detection],[CheckSum])) As Pvt
Union All
Select ‘Menor tempo de processamento…..’, [None],[Torn_Page_Detection],[CheckSum]
From (Select TipoDaAnaliseRealizada,
HoraDiferenca
From PageVerifyTempoDecorrido
) As A
Pivot (Min(HoraDiferenca) For TipoDaAnaliseRealizada In ([None],[Torn_Page_Detection],[CheckSum])) As Pvt
Union All
Select ‘Maior tempo de processamento…..’, [None],[Torn_Page_Detection],[CheckSum]
From (Select TipoDaAnaliseRealizada,
HoraDiferenca
From PageVerifyTempoDecorrido
) As A
Pivot (Max(HoraDiferenca) For TipoDaAnaliseRealizada In ([None],[Torn_Page_Detection],[CheckSum])) As Pvt
Union All
Select ‘Somatória do tempo de processamento…..’, [None],[Torn_Page_Detection],[CheckSum]
From (Select TipoDaAnaliseRealizada,
HoraDiferenca
From PageVerifyTempoDecorrido
) As A
Pivot (Sum(HoraDiferenca) For TipoDaAnaliseRealizada In ([None],[Torn_Page_Detection],[CheckSum])) As Pvt
Go

A Tabela 3 apresentada a seguir, ilustra o dados coletados durante o processamento do Bloco de Código 4, sumarizados e estruturados através do uso de Pivot:

Sumário por segundos None Torn_Page_Detection CheckSum
Média de processamento….. 34 33 32
Menor tempo de processamento….. 30 29 30
Maior tempo de processamento….. 52 40 38
Somatória do tempo de processamento….. 348 334 329

Tabela 3 – Dados sumarizados e apresentados em formato de Pivot após o processamento do Bloco de Código 4.

Agora sim, chegamos ao final. Ufa deu um pouco de trabalho este post, como de costume, mesmo assim sempre vale a pena poder compartilhar um pouco do conhecimento e experiências adquiridas ao longo dos anos de trabalho como DBA e Professor.

Espero que você tenha gostado, eu posso dizer que sim, mas sua opinião é muito importante.


Referências

https://docs.microsoft.com/en-us/sql/t-sql/statements/create-database-transact-sql?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/t-sql/statements/alter-database-transact-sql?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/relational-databases/policy-based-management/set-the-page-verify-database-option-to-checksum?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-properties-options-page?view=sql-server-2017

https://docs.microsoft.com/en-us/sql/relational-databases/backup-restore/manage-the-suspect-pages-table-sql-server?view=sql-server-2017

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/05/28/21-para-que-serve/

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/

Conclusão

Pensar na melhor forma para se armazenar um dado em uma respectiva tabela, vai muito além de escolher o tipo de dados mais indicado, temos também que procurar conhecer cada vez mais as propriedades de definem a estrutura e comportamento de um banco de dados, visando sempre garantir a melhor forma de armazenar, coletar e garantir que nossos servidores, aplicações e usuários possam fazer uso desta tão importante matéria prima utilizada pelas organizações, os dados que estão guardados em nossos bancos dados.

Neste post, você pode conhecer uma mais sobre a propriedade de banco de dados Page_Verify e suas opções: None, Torn_Page_Detection e CheckSum. Propriedade que desempenha um papel de extrema importância no que diz respeita a garantir que nossos dados estão armazenados de forma integra e confiável.

Realizamos uma simples análise para elucidar como estas opções podem influenciar no comportamento do Database Engine e também no Storage Engine, conhecemos também como cada opção desempenha o papel de verificar a estrutura física e lógica das páginas de dados que formam nossas tabelas, fazendo uso de algoritmos que gravam diretamente bits nos cabeçalhos destas mesma páginas, como fonte de identificação para tentar garantir que sua estrutura esta integra e confiável.

Mais uma vez destaco que este o estudo realizado no cenário apresentando neste post, não tem a finalidade de mostrar qual opção é mais rápida, mas sim demonstrar como em alguns momento a opção Torn_Page_Detection em comparação com a CheckSum pode ser mais vantajosa ou não, sabendo que a opção None não é recomendada para fiz corporativos.

Este é o fantástico Microsoft SQL Server, que desde suas primeiras versões nos apresenta inúmeras possibilidade de se aprender, possibilitando usar o passado como fonte de inspiração para construção de um futura melhor, por isso que a cada dia eu me apaixono ainda mais por este produto…

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 a ser publicado no mês novembro.

Um grande abraço e ótima semana.

Valeu.

Anúncios

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

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