Arquivo da tag: Armazenamento

#23 – Para que serve

Olá, bom dia, tudo bem? E ai preparado para festividades de final de Ano?

Seja bem-vindo a mais um post da sessão Para que Serve, sendo este o de número 23, mais um dia de muito começando, repleto de atividades e compromissos, ainda mais hoje sexta – feira e muito próximo ao Natal.

Mesmo no ritmo de fim de ano, tenho mantido a minha rotina, acordar bem cedo, 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, vou compartilhar com você que esta acessando meu blog, uma nova opção adicionada diretamente aos bancos de dados que criamos a partir do Microsoft SQL Server 2016 que nos permite que seja utilizada de forma exclusiva no nível de banco de dados ao invés de aplicar diretamente no nível de instância.

Talvez você já possa ter utilizada esta nova opção, mas tenho a certeza que muitos dos profissionais que ainda não migraram seus ambientes para versões mais novas talvez não a conheçam, estou me referindo a opção AUTOGROW_ALL_FILES, que basicamente define no nível de banco de dados (Database Level) ao contrário do que acontecia nas versões anteriores que tínhamos a necessidade de ativar a Trace Flag T1117 que aplicava esta alteração de comportamento padrão no nível de instância (Server Level).

No decorrer deste post será realizado um pequeno comparativo entre as opções AUTOGROW_ALL_FILES e AUTOGROW_SINGLE_FILE, analisando seus comportamentos padrões, tendo como base um simples bloco de código inserindo 500.000 (Quinhentas mil linhas de registros lógicos) com dados fixos.

Adianto 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 que o uso destas opções podem influenciar na maneira que o Microsoft SQL Server utiliza um ou mais arquivos de dados de forma proporcional ou simultânea.

Sendo assim, chegou a hora de conhecer um pouco mais sobre o post de número 23 da sessão Para que serve. Mas uma vez, bem vindo ao #23 – Para que serve – Opções de Bancos de Dados – AUTOGROW_ALL_FILES versus AUTOGROW_SINGLE_FILE.

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

Introdução

Todo o banco de dados SQL Server tem, no mínimo, dois arquivos de sistema operacional: um arquivo de dados e um arquivo de log. Os arquivos de dados contêm dados e objetos como tabelas, índices, procedimentos armazenados e exibições.

Os arquivos de log contêm as informações necessárias para recuperar todas as transações no banco de dados, ao contrário dos arquivos de dados que podem ser agrupados em grupos de arquivos para propósitos de alocação e administração.

Os bancos de dados SQL Server possuem três tipos de arquivos, como mostrado na Tabela 1 a seguir:

Arquivo	Descrição
Primário	O arquivo de dados primário contém as informações de inicialização do banco de dados e aponta para os outros arquivos no banco de dados.
Primário	Dados do usuário e objetos podem ser armazenados neste arquivo ou em arquivos de dados secundários. Todo banco de dados possui um arquivo de dados primário. A extensão de nome de arquivo indicada para arquivos de dados primários é .mdf.
Secundário	Os arquivos de dados secundários são opcionais, definidos pelo usuário, e armazenam dados do usuário.
	Arquivos secundários podem ser usados para distribuir os dados entre os diversos discos, colocando cada arquivo em uma unidade de disco diferente. Além disso, caso um banco de dados exceda o tamanho máximo em um único arquivo Windows, será possível usar arquivos de dados secundários, assim, o banco de dados continuará a crescer.
	A extensão de nome de arquivo indicada para arquivos de dados secundários é .ndf.
Log de transações	Os arquivos de log de transações armazenam as informações de log usadas para recuperar o banco de dados. Deve haver, no mínimo, um arquivo de log para cada banco de dados.
Log de transações	A extensão de nome de arquivo indicada para arquivos de transação é .ldf.

Tabela 1 – Tipos de Arquivos que formam um banco de dados criado no Microsoft SQL Server.

Agora que já conhecemos os tipos de arquivos que podem compor um banco de dados, vamos conhecer um pouco sobre um outro importante recurso que esta diretamente relacionado a este post, os denominados Filegroups.

Filegroups

Quando objetos são criados no banco de dados sem especificar a qual grupo de arquivos eles pertencem, os objetos são atribuídos ao grupo de arquivos padrão. A qualquer hora, um grupo de arquivos é designado como o grupo de arquivos padrão.

Os arquivos no grupo de arquivos padrão devem ser grandes o suficientes para armazenar qualquer objeto novo alocado a outros grupos de arquivo.

O grupo de arquivos PRIMÁRIO é o grupo de arquivos padrão, a menos que seja alterado usando a instrução ALTER DATABASE. A alocação para os objetos de sistema e de tabelas permanece no grupo de arquivos PRIMÁRIO, e não no novo grupo de arquivos padrão. O SQL Server mapeia um banco de dados de um conjunto de arquivos do sistema operacional.

As informações de log e dados nunca ficam misturadas no mesmo arquivo, e os arquivos individuais são usados apenas por um banco de dados, os grupos de arquivos são conhecidos como coleções de arquivos e são usados para simplificar o posicionamento de dados e em tarefas administrativas, como operações de backup e restauração.

Crescimento de Arquivos de Dados

Ao criar um banco de dados, estamos estabelecendo o uso de uma ou mais áreas em disco rígido para alocar nossos arquivos de dados. Dentre as diversas opções e propriedades que podemos configurar no momento da criação de um novo banco de dados ou em sua alteração, nos deparamos com a propriedade FileGrowth, sendo esta responsável em estabelecer a forma ou método de crescimento que toda estrutura de arquivos de dados que formam nossos bancos deverá aplicar, escolhendo a método de rodízio (Round-Robin) na qual os arquivos vão sendo preenchidos de forma aleatória de acordo com a necessidade ou através do método Preenchimento Proporcional (Proportional Fill).

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, a partir da versão 2016 do Microsoft SQL Server.

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

Databases: TesteDatabaseAUTOGROWSINGLEFILE; e TesteDatabaseAUTOGROWALLFILES;
Tables: TabelaGrowSingleFile; e TabelaGrowAllFile.

Importante: Destaco que os caminhos informados para criação dos referidos bancos e seus arquivos, estão apresentados de acordo com a configuração do meu ambiente, fique a vontade para alterar de acordo com suas necessidades e configurações.

— Bloco de Código 1 —
— Criando os respectivos bancos de dados —

— Criando o Banco de Dados TesteDatabaseAUTOGROWSINGLEFILE —
Create Database TesteDatabaseAUTOGROWSINGLEFILE
On Primary
(Name= ‘TesteDatabaseAUTOGROWSINGLEFILE_Data’,
FileName= ‘S:\MSSQL-2017\Data\TesteDatabaseAUTOGROWSINGLEFILE_Data.mdf’,
Size=10 MB,
MaxSize=4096 MB,
FileGrowth=100 MB),
(Name= ‘TesteDatabaseAUTOGROWSINGLEFILE_Data1’,
FileName= ‘S:\MSSQL-2017\Data\TesteDatabaseAUTOGROWSINGLEFILE_Data1.ndf’,
Size=10 MB,
MaxSize=4096 MB,
FileGrowth=100 MB),
(Name= ‘TesteDatabaseAUTOGROWSINGLEFILE_Data2’,
FileName= ‘S:\MSSQL-2017\Data\TesteDatabaseAUTOGROWSINGLEFILE_Data2.ndf’,
Size=10 MB,
MaxSize=4096 MB,
FileGrowth=100 MB)
Log On
(Name= ‘TesteDatabaseAUTOGROWSINGLEFILE_Log’,
FileName= ‘S:\MSSQL-2017\Log\TesteDatabaseAUTOGROWSINGLEFILE_Log.Ldf’,
Size=20 MB,
MaxSize=8192 MB,
FileGrowth=200 MB)
Go

— Criando o Banco de Dados TesteDatabaseAUTOGROWALLFILES —
Create Database TesteDatabaseAUTOGROWALLFILES
On Primary
(Name= ‘TesteDatabaseAUTOGROWALLFILES_Data’,
FileName= ‘S:\MSSQL-2017\Data\TesteDatabaseAUTOGROWALLFILES_Data.mdf’,
Size=10 MB,
MaxSize=4096 MB,
FileGrowth=100 MB),
(Name= ‘TesteDatabaseAUTOGROWALLFILES_Data1’,
FileName= ‘S:\MSSQL-2017\Data\TesteDatabaseAUTOGROWALLFILES_Data1.ndf’,
Size=10 MB,
MaxSize=4096 MB,
FileGrowth=100 MB),
(Name= ‘TesteDatabaseAUTOGROWALLFILES_Data2’,
FileName= ‘S:\MSSQL-2017\Data\TesteDatabaseAUTOGROWALLFILES_Data2.ndf’,
Size=10 MB,
MaxSize=4096 MB,
FileGrowth=100 MB)
Log On
(Name= ‘TesteDatabaseAUTOGROWALLFILES_Log’,
FileName= ‘S:\MSSQL-2017\Log\TesteDatabaseAUTOGROWALLFILE_Log.Ldf’,
Size=20 MB,
MaxSize=8192 MB,
FileGrowth=200 MB)
Go

Nota: Vale ressaltar que ambos os bancos de dados estão estruturados com a mesma quantidade de arquivos de dados e log, respectivamente 3(três) arquivos de dados e somente um único arquivo de log.

Muito bem, neste momento nossos bancos de dados estão criados e ambos contendo a mesma configuração para as propriedades: Size, MaxSize e FileGrowth, como também, configurados para que o crescimento ocorra de forma aleatória para os arquivos de dados.

Vamos validar nossa estrutura através do Bloco de Código 2 apresentado abaixo, o qual vai nos permitir identificar justamente as configurações que aplicamos no momento da criação dos referidos bancos de dados:

— Bloco de Código 2 —
Select DB_NAME() AS [DatabaseName], Name, file_id, physical_name,
(size * 8.0/1024) as Size,
((size * 8.0/1024) – (FILEPROPERTY(name, ‘SpaceUsed’) * 8.0/1024)) As FreeSpace
From sys.database_files
Go

Após executar o Bloco de Código 2, o Management Studio deverá apresentar o resultado similar a ilustrado na Figura 1 para ambos os bancos de dados:
Figura 1 – Informações sobre os bancos de dados seus arquivos, tamanhos e espaço livre ocupado.

Nosso próximo passo será forçar o crescimento dos nossos arquivos para o Banco de Dados TesteDatabaseAUTOGROWSINGLEFILE, observando o comportamento que o SQL Server vai utilizar, ressalto que estaremos fazendo a criação da tabela que utilizaremos como base para inserir os dados, para tal cenário vamos utilizar o Bloco de Código 3 apresentado a seguir:

— Bloco de Código 3 —
Use TesteDatabaseAUTOGROWSINGLEFILE
Go

— Criando a Tabela TabelaGrowSingleFile —
Create Table TabelaGrowSingleFile
(Codigo Int Identity(1,1) Not Null Primary Key,
Texto VarChar(100) Default ‘Grow Single File’,
Quantidade SmallInt Default 2018,
ValoresNumericos Numeric(8,2) Default ‘2018.12’,
DataAtual Date Default GetDate()+Rand()*30)
Go

— Inserindo a massa de dados —
Insert Into TabelaGrowSingleFile Default Values
Go 500000

A partir do momento que o Bloco de Código 3 é executado, o Microsoft SQL Server em conjunto com o SQL OS, Database Engine e Storage Engine, começam a fazer uso dos arquivos de dados, distribuindo em tempo real as páginas de dados conforme o método ou técnica escolhida para preenchimento dos arquivos de dados.

Para confirmarmos a alocação e distribuição destas páginas, vamos executar o Bloco de Código 4 apresentado abaixo em uma Nova Query e observar o resultado apresentado:

— Bloco de Código 4 —
Use TesteDatabaseAUTOGROWSINGLEFILE
Go

DBCC ShowFileStats — Comando que vai apresentar a distribuição de páginas de dados entre os arquivos
Go

Observação: Execute o comando DBCC ShowFileStats durante a execução do Bloco de Código 3, para que você possa obter um resultado similar ao apresentado na Figura 2 abaixo:

Figura 2 – Resultado apresentado pelo comando DBCC ShowFileStats.

No decorrer do processamento do Bloco de Código 3, podemos novamente o Bloco de Código 2 para identificar que neste momento o Microsoft SQL Server esta fazendo uso método de preenchimento dos arquivos de dados Round-Robin, no qual ele identifica qual seria o melhor arquivo para alocar a página, para confirmar este cenário a Figura 3 ilustra o resultado obtido de mais uma execução do Bloco de Código 2:
Figura 3 – Alocação dos arquivos de dados.

Observe a mudança de valores nas colunas Size e FreeSpace, como também, suas diferenças de valores em relação ao File_ID=1 para com os File_ID = 2 e 3, são justamente estas diferenças que nos orientam a entender que o Round-Robin esta sendo utilizado.

Estamos indo bem, falta um pouco para chegarmos ao final….

Nosso próximo passo se destina a alterar a forma de preenchimento e utilização dos arquivos de dados definidos para o Banco de Dados TesteDatabaseAUTOGROWALLFILES, e em seguida forçar o uso de cada arquivos e a distribuição de páginas. Vamos então executar o Bloco de Código 5 e sua sequência de passos:

— Bloco de Código 5 —
— Alterando a definição de crescimento dos arquivos de Dados para o FileGroup Primary —
Use Master
Go

Alter Database TesteDatabaseAUTOGROWALLFILES
Modify FileGroup [Primary] AUTOGROW_ALL_FILES — Definindo o crescimento proporcional para todos os arquivos de dados —
Go

— Acessando o Banco de Dados —
Use TesteDatabaseAUTOGROWALLFILES
Go

— Criando a Tabela TabelaGrowSingleFile —
Create Table TabelaGrowAllFile
(Codigo Int Identity(1,1) Not Null Primary Key,
Texto VarChar(100) Default ‘Grow All File’,
Quantidade SmallInt Default 2018,
ValoresNumericos Numeric(8,2) Default ‘2018.12’,
DataAtual Date Default GetDate()+Rand()*30)
Go

— Inserindo a massa de dados —
Insert Into TabelaGrowAllFile Default Values
Go 500000

Neste momento temos o banco de dados TesteDatabaseAUTOGROWALLFILES sendo utilizando, no qual sua estrutura de arquivos esta definida para ser utilizada de forma conjunto e proporcional, ou seja, conforme a necessidade de crescimento dos arquivos de dados, ao invés de um único arquivo ser invocado e ter seu valor de crescimento definido, todos os arquivos serão envolvidos e afetados, conforme a Figura 4 a seguir ilustra:
Figura 4 – Preenchimento de todos os arquivos de dados sendo realizado com base no uso da opção Grow_All_Files.

Estamos quase lá, para finalizar nosso estudos, vamos executar o Bloco de Código 6, o qual tem a finalidade de repetir a inserção das 500.000 mil linhas de registros em cada banco de dados e posteriormente forçar um crescimento para os arquivos de dados:

— Bloco de Código 6 —
— Acessando o Banco de Dados —
Use TesteDatabaseAUTOGROWSINGLEFILE
Go

— Inserindo a massa de dados —
Insert Into TabelaGrowSingleFile Default Values
Go 500000

— Acessando o Banco de Dados —
Use TesteDatabaseAUTOGROWALLFILES
Go

— Inserindo a massa de dados —
Insert Into TabelaGrowAllFile Default Values
Go 500000

Note que para o Banco de Dados TesteDatabaseAUTOGROWSINGLEFILE o crescimento vai ocorrer no primeiro arquivo de dados e para no Banco de Dados TesteDatabaseAUTOGROWALLFILES este crescimento será aplicado a todos os arquivos, conforme apresenta a Figura 5 abaixo:
Figura 5 – Espaço ocupado pelos arquivos de dados após o crescimento ser ocorrido.

Para finalizar, compartilho a Figura 6 que apresenta a utilização dos arquivos de dados por parte do Storage Engine de acordo com o método de alocação e preenchimento dos arquivos de dados, respeitando a configuração dos bancos de dados aqui utilizados:

Figura 6 – Comparativo entre AutoGrowSingleFile versus AutoGrowAllFiles.

Importante: Observe que todos os arquivos de dados definidos para uso no banco de Dados TesteDatabaseAutoGrowAllFiles apresentam os mesmos valores para colunas Size e FreeSpace, cenário totalmente diferente para o banco de dados TesteDatabaseAutoGrowSingleFile, que ilustra a utilização de forma diferente dos arquivos de dados, no qual os arquivos File_ID=2 e 3 estão neste momento sem espaço livre, o que indica que o crescimento foi aplicado ao primeiro arquivo de dados.

Com isso, e sem mais delongas, 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://pedrogalvaojunior.wordpress.com/2017/01/23/12-para-que-serve/

https://docs.microsoft.com/en-us/sql/t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql

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

https://blogs.msdn.microsoft.com/psssql/2016/03/15/sql-2016-it-just-runs-faster-t1117-and-t1118-changes-for-tempdb-and-user-databases/

https://www.brentozar.com/archive/2014/06/trace-flags-1117-1118-tempdb-configuration/

https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-files-and-filegroups?view=sql-server-2017

https://www.sqlshack.com/understanding-sql-server-proportional-fill-algorithm/

http://www.sqlservercentral.com/scripts/Maintenance+and+Management/30218/

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/08/22/22-para-que-serve/

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/

Conclusão

Conhecer a cada nova versão as mudanças e novidades aplicadas ao Microsoft SQL Server não é uma tarefa fácil, mas deixar de fazer uso delas pode em algum momento parecer falta de interesse ou até mesmo desconhecimento do potencial existente no produto.

Neste post, podemos conhecer esta nova opção Auto_Grow_All_Files, que nos permite aplicar uma nova maneira de orientar o SQL Server no uso, alocação e principalmente crescimento de nossos arquivos de dados, o que pode ou não impactar de forma direta na performance, contenção ou distribuição de recursos relacionados a disco rígido.

Em momento algum, o cenário aqui utilizado, muito menos a análise feita, teve o objetivo de comprovar qual forma de alocação e uso dos arquivos de dados é melhor, isso deve ser analisado para cada necessidade e ambiente.

Espero que o conteúdo aqui apresentado possa lhe ajudar a conhecer um pouco sobre como os arquivos de dados são importantes e úteis para nossos bancos, além disso, a importância de se utilizar mais de um arquivo de dados ou filegroups.

Este é o fantástico Microsoft SQL Server, que desde suas primeiras versões nos apresenta inúmeras possibilidades de se aprender, possibilitando usar o passado como fonte de inspiração para construção de um futuro 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 fevereiro de 2019.

Um grande abraço e ótima semana.

Valeu.

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

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

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

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

Microsoft SQL Server 2017 Cumulative Update 9 disponível

A Microsoft informou ontem dia 19/07 no blog SQL Server Release Services a disponibilidade da Atualização Cumulativa(Cumulative Update) 9 para o Microsoft SQL Server 2017.

Atualizações Cumulativas disponíveis para o Microsoft SQL Server 2017:

O artigo KB4341265 publicado no site de suporte da Microsoft, esta nova atualização do SQL Server 2017 traz todas as correções disponibilizadas desde o lançamento do novo SQL Server, incluindo também correções para problemas encontrados após o lançamento das atualizações cumulativas anteriores.

Hotfixes que estão incluídos neste pacote de atualização cumulativa:

Número do bug VSTS	Número do artigo KB	Descrição	Área fixa	Plataforma
12144190	4340069	CORREÇÃO: SQL Server 2017 no Linux é desligado inesperadamente durante a recuperação de um banco de dados OLTP de memória	OLTP in-memory	Linux
12041154	4340134	CORREÇÃO: Erro quando uma função é definida com uma coluna restrita é usada para executar uma consulta drill-through no SSAS	Analysis Services	Windows
12128861	4340747	CORRIGIR: SQLDUMPER. Despejos EXE iniciada podem levar muito tempo para concluir o processo de geração de despejo para 2017 do SQL Server no Linux	Mecanismo SQL	Linux
12168709	4010460	CORREÇÃO: Um erro do.NET Framework ocorreu quando você atualiza a tabela de referência de uma transformação Fuzzy Lookup no SSIS	Integration Services	Windows
12138685	4339613	CORREÇÃO: “Unclosed aspas após a sequência de caracteres” erro ocorre no explorer MDS quando você tentar adicionar um novo membro para uma entidade no SQL Server	Data Quality Services (DQS)	Windows
12107546	4338890	CORREÇÃO: Uma instância do SQL Server pode parecer não responder e em seguida, pode ocorrer um erro de “não respondendo no Agendador” no SQL Server 2016	Mecanismo SQL	Windows
11922902	4316858	CORREÇÃO: “índice corrompido” mensagem e servidor desconexão quando uma consulta de estatísticas de atualização usa hash agregação no SQL Server	Desempenho do SQL	Todas
12149855	4341219	CORREÇÃO: Um cenário de cérebro divisão ocorre após um failover ao usar grupos de disponibilidade do AlwaysOn com a tecnologia de cluster externo no SQL Server 2017	Alta disponibilidade	Todas
12111717	4340837	CORREÇÃO: Erro 3906 quando for aplicado um hotfix em um SQL Server que possui um banco de dados em um banco de dados de inscrição de recepção de instantâneo	Mecanismo SQL	Windows
11983925	4133164	CORREÇÃO: Erro quando um trabalho do SQL Server Agent executa um comando PowerShell enumere permissões do banco de dados	Ferramentas de gerenciamento	Windows
12121216	4339664	CORREÇÃO: O erro de exceção ocorre quando você tenta atualizar dados de uma tabela dinâmica no Excel no SSAS 2017	Analysis Services	Windows
12123248	4340742	CORREÇÃO: Acesso ao SSAS usando HTTP falha no SQL Server	Analysis Services	Windows
12162067	4341264	Aperfeiçoamento: Permitir trabalhos do SQL Server Agent iniciar sem esperar que todos os bancos de dados obter recuperado no SQL Server 2017 no Linux	Mecanismo SQL	Linux
12186129	4101502	CORREÇÃO: Backup de banco de dados TDE habilitada com compactação causa corrupção de banco de dados no SQL Server	Mecanismo SQL	Todas
12129434	4134601	CORREÇÃO: “não foi possível carregar arquivo ou assembly ‘ Microsoft.AnalysisServices.AdomdClientUI” erro quando uma operação de “Processo total” é executada no SQL Server	Analysis Services	Windows
12162425	4341221	CORREÇÃO: Backup VSS Falha na réplica secundária de grupos básicos de disponibilidade no SQL Server 2016 e 2017	Mecanismo SQL	Windows
12108225	4339858	CORREÇÃO: Redo paralelo não funciona após você desativar 3459 de sinalizador de rastreamento em uma instância do SQL Server	Alta disponibilidade	Todas
12061383	4341253	CORREÇÃO: Sys.dm_db_log_info e sys.dm_db_log_stats DMVs podem retornar valores incorretos para o último banco de dados da instância do SQL Server 2016	Mecanismo SQL	Windows

Dentre os erros e falhas corrigidas neste cumulative update, as informações apresentadas no KB4341265 destacam uma correção relacionada comportamento apresentado por uma instância do SQL Server 2017 que aparentemente encontra-se travada e exibindo o erro “Non-yielding Scheduler“.

Outra correção destacada no artigo, se relaciona ao erro “Could not load file or assembly ‘Microsoft.AnalysisServices.AdomdClientUI”.

Vale ressaltar que além de correções relacionadas a erros apresentados por comportamentos apresentadas pelas instância SQL Server 2017, a CU9 também possui correções para os bugs relacionados as DMVs sys.dm_db_log_stats e sys.dm_db_log_info may retornem valores incorretos em determinados momentos de consulta de dados relacionados aos arquivos de log existentes em bancos de dados.

Vale ressaltar que após a atualização desta nova atualização cumulativa, o número do build utilizado pelo Microsoft SQL Server 2017 RTM será alterado para compilação: 14.0.3030.27.

Para realizar o download clique na imagem abaixo:

Fontes e Direitos Autorais: SQL Server Release Services – 19/07/2018.

Novidades no cliente do OneDrive para Windows anunciadas pela Microsoft

A Microsoft divulgou nesta semana no OneDrive Blog algumas novidades no cliente do OneDrive para Windows que estarão disponíveis ainda em julho. O OneDrive é o serviço de armazenamento e sincronização de arquivos na nuvem da Microsoft e sucessor do SkyDrive. Ele foi lançado oficialmente no dia 19 de fevereiro de 2014.

Uma das novidades no cliente do OneDrive para Windows é útil para usuários de portáteis e permite a pausa da sincronização de arquivos quando o modo de economia de energia estiver ativo.

Assim que o cliente do OneDrive detectar que o modo de economia de energia foi ativado, a sincronização será interrompida automaticamente e uma notificação como essa abaixo será exibida:

Microsoft anuncia novidades no cliente do OneDrive para Windows

Os usuários também poderão enviar facilmente feedback para a Microsoft acessando a opção abaixo no menu do cliente do OneDrive:

Onedrive Julho 04

A Central de Atividades do OneDrive será atualizada para tornar seu uso mais fácil. A Central de Atividades permite que o usuário visualize o status do cliente do OneDrive para Windows e acesse suas configurações:

Sincronização em andamento:

Onedrive Julho 03 Sincronização concluída:

Onedrive Julho 02 Fontes e Direitos Autorais: Microsoft OneDrive Blog – Julho/2018.

Azure for Students anunciada pela Microsoft

A Microsoft anunciou no último dia 05/03 o Azure for Students. Desenvolvido para o uso da nuvem, com os estudantes em mente, ele oferece aos alunos verificados acesso total a mais de 25 produtos Azure gratuitos, além de crédito de US$ 100 para uso em produtos pagos, sem exigência de cartão de crédito.

O Azure for Students faz parte do crescente compromisso da Microsoft com a Educação, tanto na nuvem quanto na sala de aula STEM (“Science, Technology, Engineering and Mathematics”, ou Ciência, Tecnologia, Engenharia e Matemática, em português).

Microsoft anuncia o Azure for Students

Você pode começar a construir com qualquer um dos serviços gratuitos e usar o seu crédito Azure para gastar agora:

– Descubra a flexibilidade do Azure por meio da biblioteca de serviços de código aberto.

– Implemente máquinas virtuais Azure, incluindo equipadas com GPUs poderosas, com suporte para Linux, Windows Server, SQL Server, Oracle, IBM e SAP. O Azure oferece aos usuários a flexibilidade de virtualização para uma ampla gama de soluções de computação.

– Crie aplicativos Web e Móveis rapidamente usando .NET, .NET Core, Java, Ruby, Node.js, PHP e Python. Integre o Azure App Service em modelos existentes e obtenha uma produtividade de desenvolvedor incomparável com recursos de ponta, como integração contínua, depuração no site ao vivo e o líder do setor, Microsoft Visual Studio IDE – Integrated Development Environment.

– Inteligência Artificial e Aprendizado de Máquinas conectam aplicativos, sites e robôs com algoritmos inteligentes para ver, ouvir, falar, entender e interpretar as necessidades de um usuário por meio de métodos naturais de comunicação. Habilitando computadores para aprender com dados e experiências e para agir sem ser programado.

– Aproveite o Big Data analisando todos os dados em um único lugar sem restrições artificiais com o Azure Data Lake Store. O Data Lake Store pode armazenar trilhões de arquivos, e um único arquivo pode ser maior do que um petabyte em tamanho – 200 vezes maior do que outras opções da loja na nuvem.

Para maiores informações, acesse: https://azure.microsoft.com/pt-br/free/students/

Fontes e Direitos Autorais: Microsoft News Center Brasil.

Microsoft Virtual Academy – Novo treinamento sobre noções básicas do Windows Server 2016

Nos últimos dias a Microsoft adicionou a sua biblioteca de cursos on-line disponibilizados no Microsoft Virtual Academy, um novo curso dedicado exclusivamente ao Windows Server 2016, trata-se do curso de Noções Básicas, focado em profissionais, estudantes e entusiastas que querem conhecer um pouco mais sobre o sistema operacional da Microsoft utilizado em servidores.

A Microsoft Virtual Academy (ou MVA) oferece treinamento online da Microsoft realizado por especialistas para ajudar os tecnólogos a aprender constantemente, com centenas de cursos em múltiplos idiomas. A MVA é gratuita e o serviço inteiro é hospedado no Microsoft Azure. Além dos treinamentos, ela também oferece para download diversos ebooks gratuitos.

O treinamento é dividido em seis módulos que apresentam a versão 2016 do Windows Server, que foi lançada em setembro de 2016 durante a conferência Ignite e disponibilizada oficialmente em outubro do mesmo ano.

O Treinamento

O primeiro módulo centra-se na instalação do novo sistema operacional e na comparação da funcionalidade de diferentes versões.

No segundo módulo, são apresentadas as novas funções na área de identidade. O terceiro módulo apresenta os novos recursos da rede.

O módulo 4 fornece uma visão geral dos novos recursos e melhorias na memória. No quinto módulo, são apresentadas as novas funções no campo da virtualização. Após uma pequena introdução ao Hyper-V, também é mostrado como criar e configurar máquinas virtuais.

No último módulo, a Microsoft aborda os contêineres que fornecem uma extensão da virtualização.

Módulos do treinamento gratuito Noções básicas sobre o Windows Server 2016:

01 | Introdução ao Windows Server 2016
O primeiro módulo se concentra na instalação do novo sistema operacional e na comparação da funcionalidade de diferentes versões.

02 | Serviços de diretório do Windows Server 2016
No segundo módulo, são apresentadas as novas funções no campo da identidade.

03 | Serviços de rede no Windows Server 2016
No terceiro módulo você receberá uma introdução às novas funções na rede.

04 | Soluções de armazenamento do Windows Server 2016
Este módulo fornece uma visão geral dos novos recursos e melhorias de memória.

05 | Virtualização do Windows Server 2016
No quinto módulo são apresentadas as novas funções no campo da virtualização.

06 | Windows Server 2016 Container Basics
O último módulo tem como foco os contêineres.

Para maiores informações e acesso ao treinamento clique aqui.

Fontes e Direitos Autorais: Microsoft.com – 05/02/2018.

Suporte para Cosmos DB no Azure Storage Explorer já está disponível como Preview

A Microsoft anunciou na semana passada que o suporte para Cosmos DB no Azure Storage Explorer já está disponível como Preview.

Cosmos DB no Azure Storage Explorer

Com o suporte os bancos de dados Cosmos DB podem ser explorados e gerenciados com a mesma experiência de uso que torna o Azure Storage Explorer uma poderosa ferramenta para desenvolvedores que precisam gerenciar armazenamento no Azure.

Para quem não sabe, o Storage Explorer é um aplicativo autônomo que permite que você trabalhe facilmente com dados do Azure Storage no Windows, macOS e Linux.

O aplicativo fornece várias maneiras de se conectar às contas de armazenamento. Isso inclui se conectar a contas de armazenamento associadas às suas assinaturas do Azure, conectar-se às contas de contas de armazenamento e serviços compartilhados por outras assinaturas do Azure e até mesmo se conectar e gerenciar o armazenamento local usando o Emulador de Armazenamento do Azure.

Suporte para Cosmos DB no Azure Storage Explorer já está disponível como Preview — Azure Storage Explorer

O suporte para o Cosmos DB no Azure Storage Explorer permite que você gerencie entidades, manipule dados, crie e atualize ‘stored procedures’ e muito mais.

Para começar, faça o Azure Storage Explorer aqui para Windows, aqui para macOS ou aqui para Linux, confira aqui um artigo para saber mais sobre o Storage Explorer e utilize o manual para ver como gerenciar Cosmos DB no Azure Storage Explorer.

Uma demonstração do Cosmos DB no Storage Explorer está disponível aqui.

Fontes e Direitos Autorais: azure.microsoft.com – 09/11/2017.

Dica do Mês – Você sabe o que é Normalização de Banco de Dados?

Olá galera, bom dia, bom dia comunidade!!!

Estou de volta com mais um post da sessão Dica do Mês, nossa como o tempo esta passando, este é o sexto post desta nova sessão criada este ano no meu blog e que lentamente começa a apresentar alguns resultados. Como você já deve estar acostumado quando visita o meu blog, todo final de mês é dedicado a post exclusivos das sessões Dica do Mês e Para que Serve.

No último post publicado no mês de Maio, apresentei um conteúdo mais focado para área acadêmica e hoje não será diferente, vou falar sobre um dos conceitos mais importantes quando falamos sobre banco de dados, estou me referindo a Normalização de Dados ou para muitos Normalização.

Acredito que você já deve ter ouvir falar sobre este conceito, para muitos algo bastante complexo, mas na verdade não é bem assim, por isso eu decidi compartilhar com vocês um pouco do meu conhecimento nesta área.

Então, seja bem vindo a mais uma dica do mês, começa aqui a Dica do Mês – Você sabe o que é Normalização de Banco de Dados?

Introdução

Conhecida como técnicas de racionalização das estruturas de dados de um sistema, eliminando redundâncias, problemas de manipulação e armazenamento, basicamente a normalização é um processo através do qual esquemas de relação, que não sejam satisfatórios às características do modelo relacional, são decompostos em esquemas menores que satisfaçam as propriedades desejáveis.

Inicialmente proposta como uma ferramenta de auxílio no projeto físico para a definição de relações, porém na prática tornou-se uma ferramenta de verificação, pois serve para verificar se os esquemas do projeto físico satisfazem algumas características básicas. Estas características são conhecidas como medidas de qualidade que devem obrigatóriamente estar alinhadas as necessidades do projeto de banco de dados e seu modelagem conceitual.

Medidas de Qualidade

Na normalização, são analisadas algumas medidas de qualidade para o projeto de um esquema de relação. Estas medidas de qualidade visam, por exemplo, evitar um mau uso da memória. As medidas são as seguintes:

1 – Correta representação semântica – os dados devem ser projetados de forma a terem seus significados bem definidos e coerentes com o que realmente querem representar;

2 – Redução de valores redundantes – sempre que possível deve-se reduzir ao máximo os valores redundantes desnecessários, ou seja, valores que muitas vezes aparecem repetidos quando isto não seria preciso;

3 – Redução de valores nulos – sempre que possível deve-se reduzir o número de atributos que por alguma razão receberão muitos valores nulos;

4 – Não geração de tuplas espúrias (sem sentido) – durante o processo de normalização deve-se atentar para evitar que sejam geradas tuplas que não façam sentido diante da realidade, isto pode ocorrer devido a alguma decomposição.

Estas medidas de qualidade nos ajudam a estabelecer uma estrutura organizacional para nosso modelo de banco de dados, onde podemos tentar afirmar que estamos criando um cenário para armazenar com coerência.

Outro elemento muito importante quando estamos trabalhando com Normalização é a chamada dependência funcional, conhecida como propriedade da semântica ou do significado dos atributos. Você pode estar se perguntando poxa vida o que seria isso, calma vou tentar se ajudar neste respostas.

Dependência Funcional

As decomposições da normalização ocorrem seguindo os conceitos de dependências funcionais. A seguir estes conceitos serão apresentados, juntamente com as três principais e mais utilizadas formas normais.

Uma dependência funcional (DF) é uma propriedade da semântica ou do significado dos atributos. Formalmente, uma dependência funcional entre dois conjuntos de atributos, x e y, que são subconjuntos de um esquema de relação R, denotada por x® y é uma restrição que estabelece que para quaisquer tuplas t1 e t2 de uma instância r de R, tal que, se temos t1[x] = t2[x], então também devemos ter que t1[y] = t2[y].

Em outras palavras, os valores do componente y em uma tupla de r dependem de (ou são determinados por) valores do componente x.

Por exemplo: Seja x = {Matrícula} e y = {Nome, Endereço, Telefone, CodCurso}, então {Matrícula} {Nome, Endereço, Telefone, CodCurso}, ou seja, a depender do valor da Matrícula, serão determinados os valores do Nome, Endereço, Telefone, e CodCurso.

Quando se define uma dependência funcional, esta regra deve valer para todas as instâncias da relação, é como se fosse uma restrição de integridade, onde em muitos casos não se pode deduzir a existência de uma dependência, conforme a Figura 1 apresentada abaixo demonstra:

Figura 1 – Exemplo de como podemos identificar a existência ou não de dependência funcional.

Seguindo em frente, agora que conhecemos um pouco sobre a normalização, suas medidas de qualidade e seu principal elemento de decomposição chamado dependência funcional, o próximo passo é justamente conhecer e entender um pouco mais sobre esta técnica de decomposição de estrutura, para tal será necessário se aprofundar um pouco mais, vamos então começar a desmistificar as tão temidas Formas Normais (kkkkkk), tenho a certeza que você vai gostar.

Formas Normais Baseadas em Chaves Primárias

O processo de normalização é realizado gradativamente através de formas normais, definidas a partir do conceito de DF. As três principais formas normais são a Primeira Forma Normal (1FN), a Segunda Forma Normal (2FN) e a Terceira Forma Normal (3FN).

1FN 2FN 3FN……

Este processo de normalização é composto por algumas propriedades:

Junções sem perda – uma vez definida uma decomposição, caso esta seja recomposta através de uma operação de junção, no resultado gerado não pode haver perdas; e
Preservação de dependências – assegura que cada DF seja representada em algumas relações individuais resultantes após a decomposição.

A Figura 2 apresentada a seguir ilustra como as formas normais trabalham, sua forma de uso e finalidade:

Figura 2 – Resumo formas normais.

Primeira Forma Normal (1FN)

Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos e monovalorados, ou seja, não possuem valores que formam atributos compostos.

1 – Exemplo:
ESTUDANTES = {MATRÍCULA + NOME + ENDEREÇO + CODCURSO} e
ENDEREÇO é um atributo composto, ENDEREÇO = {RUA + NUMERO + BAIRRO + CIDADE + UF}.

Para colocar na 1FN faz:
ESTUDANTES={MATRÍCULA+NOME+RUA+NUMERO+BAIRRO+CIDADE+UF+CODCURSO}

Um esquema de relação R está na 1FN se todos os seus atributos forem atômicos e monovalorados, ou seja, não possuem valores que formam atributos compostos.

2 – Exemplo:

FUNCIONÁRIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATAFIM}}

Para colocar na 1FN faz:

– FUNCIONÁRIOS = {CODFUNC + NOME + CARGO}

– FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATAFIM}

Observação: todas as tabelas são relações na 1FN.

Segunda Forma Normal (2FN)

Dependência funcional total ou completa: Uma DF x® y é total, se não existir nenhum atributo A em x, tal que (x – {A})® y, para qualquer AÎ x, ou seja, se retirarmos este atributo A da relação x a DF deixa de existir. Caso contrário, x® y é parcial.

Definição da 2FN: Um esquema de relação está na 2FN se: estiver na 1FN e, além disso, todo atributo que não pertença a alguma de suas chaves for totalmente dependente da sua chave primária.

Em outras palavras, para que uma relação esteja na 2FN é preciso que esteja na 1FN e que, havendo uma chave primária composta, todos os dados que não são chaves dependem de toda a chave primária (a chave primária completa).

Seja o exemplo de uma relação que represente o estoque de um estabelecimento comercial, da seguinte forma:

ESTOQUE = {PRODUTO + ALMOX + END_ALMOX + UNID_EST + QTD + PRECO}

Não está na 2FN porque alguns dados não chave dependem somente de parte da chave, como END_ALMOX depende só de ALMOX, e UNID_EST depende só de PRODUTO.

Com a normalizando ficaria:
– Estoque = {PRODUTO + UNID_EST}
– Almoxarifado = {ALMOX + END_ALMOX}
– Produto= {PRODUTO + ALMOX + QTD + PRECO}

Terceira Forma Normal (3FN)

Dependência funcional transitiva: Uma DF x® y é transitiva em um esquema de relação R se existir um conjunto de atributos z, que não seja um subconjunto de alguma chave de R, e as DFs x® z e z® y forem válidas em R.

Um esquema de relação está na 3FN se: estiver na 2FN e, além disso, nenhum atributo que não pertença a alguma das suas chaves for transitivamente dependente da sua chave primária.

Em outras palavras, para que uma relação esteja na 3FN é preciso que esteja na 2FN e todo atributo, que não pertença a alguma chave for não dependente de algum outro atributo, que também não pertença a alguma chave.

Seja o exemplo de uma relação que represente os dados referentes às músicas, da seguinte forma:

Exemplo: MÚSICA = {CÓDIGO + TÍTULO + GÊNERO + PAÍS_ORIGEM}, supondo que neste exemplo, o PAÍS_ORIGEM refere-se ao GÊNERO musical e não a música, sendo assim, apesar de estar na 2FN, a relação não está na 3FN, pois existe dependência entre GÊNERO e PAÍS_ORIGEM.

Com a normalizando ficaria:
MÚS_1 = {CÓDIGO + TÍTULO + GÊNERO}
MÚS_2 = {GÊNERO + PAÍS_ORIGEM}

Acredito que você pode ter entendido como inicialmente a normalização de dados vai influenciar na estrutura da sua modelagem de dados, como a mesma vai ser elaborada, estruturada e elaborada.

Para tentar ajudar o seu entendimento e tentar praticar o que estamos vendo neste post, vou deixar algumas perguntas que podem ser de extrema importância para o esclarecimento de dúvidas, como também, um exercício prático de normalização.

Questionário

1.O que é uma dependência funcional?

2.Quem especifica as dependências funcionais que se mantêm (são válidas) entre os atributos de um esquema de relação?

3.A que se refere a expressão “relação desnormalizada”?

4.Defina primeira, segunda e terceira formas normais quando somente chaves primárias são consideradas. Como as definições da 2FN e 3FN, que consideram todas as chaves de uma relação, diferem daquelas que consideram somente chaves primárias?

Exercício

Sejam os seguintes dados de uma locadora de automóveis:

A locadora aluga automóveis de uma determinada marca apenas para clientes pessoa jurídica (empresas). Estes clientes credenciam motoristas para utilizarem os veículos, o preço diário de aluguel e a potência do carro dependem de seu modelo. Considerando que a locadora necessite, para seu controle, dos dados descritos na seguinte relação:

REGISTRO_ALUGUEL = {NumCNH + NomeMotorista + DataNasc + CGCCliente + NomeCliente + EndCliente + {PlacaCarro + Modelo + Cor + Potência + QTDDiárias + PreçoDiária}}

Sendo assim chegamos ao final de mais uma dica do mês.

O conhecimento técnico é muito importante para qualquer profissional, mas o conceito é algo que sempre devemos valorizar e conhecer, a diferença entre um bom profissional e um profissional reconhecido e respeitado no mercado de trabalho é saber aliar o conhecimento teórico com o conhecimento prática, como muitos costumam dizer aliar a téoria a prática, sendo este o objetivo deste post.

Espero que você tenha gostado, que as informações e exemplos publicadas possam de alguma maneira ajudar e colaborar com suas atividades diárias, profissionais e ou acadêmicas.

Desejo um forte abraço, agradeço mais uma vez a sua visita.

Até mais.

MAIS DETALHES SOBRE O OFFICE 16

A Microsoft está atualmente trabalhando no desenvolvimento da nova versão do Office, que é conhecida pelo codinome Office 16.

Agora a empresa começou a disponibilizar para um grupo restrito a versão de testes da nova versão da popular suíte de produtividade.

OFFICE 16

Por ser uma versão de testes ainda nos estágios iniciais de desenvolvimento, é possível que algumas coisas mencionadas aqui não estejam presentas na versão final.

De acordo com informações do site Winbeta.org, o build da versão de testes é 16.0.3030.1040.

Esta versão de testes do Office 16 inclui novidades como o recurso Tell Me. Ele é exibido na parte superior de aplicativos como o Word e também pode ser usado como uma ferramenta de busca:

office16_tellme
Basicamente o Tell Me oferece uma forma fácil e rápida de obter ajuda sem que seja necessário navegar pela documentação completa do Office. Fazer perguntas como “Como insiro imagens?” fará com que ele exiba informações relevantes e ajuda adicional.

Outra novidade interessante no Office 16 é o suporte para rotação automática de imagens. Neste caso os metadados das imagens são usados para posicioná-las corretamente nos documentos.

Quando uma imagem é inserida no documento, o Office fará a rotação da imagem automaticamente para ficar de acordo com a orientação da câmera. Se o usuário quiser, ainda será possível fazer a rotação manualmente.

A Microsoft também incluiu um novo tema escuro nesta versão Preview do novo Office. Este tema escuro não é o padrão, é apenas mais uma opção para os usuários:

Mais detalhes sobre o Office 16
A nova versão do Excel traz recursos com foco em Business Intelligence, enquanto que o Visio traz novidades como a seção Getting Started, melhorias na acessibilidade e suporte para proteção de arquivos via Information Rights Management (IRM).

O Microsoft Office 16 também inclui diversas melhorias no Outlook, como novas opções de sincronização de mensagens, assim ele pode fazer o download de apenas um dia de mensagens ou optar por 3, 4, 7 ou 14 dias, e armazenamento mais enxuto em dispositivos móveis.

Fontes e Diretois Autorais: Baboo.com – SID VICIOUS @ 20 OUT 2014 | 1:47 PM

Conhecendo o Microsoft SQL Server 2012 e 2014 – Utilizando o ColumnStored Index.

Salve, Salve Comunidade! Tudo bem?

Após um período de diversos eventos que participei e realizei desde Março deste ano, até a última semana, consegui um pouco de tempo para poder compartilhar com vocês, mais um pouquinho sobre o Fantástico Mundo que forma o Microsoft SQL Server, que neste momento se encontra em destaque com o lançamento da nova versão denonimada 2014.

Dentre as diversas inovações que normalmente uma nova versão apresenta, eu vou destacar hoje com você um recurso que foi criado e implementado na versão 2012 mas que apresentou um grande evolução neste nova versão. Estou me referindo ao ColumnStore Index, ou simplesmente, Índice armazenado em Coluna, numa tradução bem comum.

Como de costume foi fazer uma pequena introdução sobre este recursos e no decorrer deste artigo, destacarei:

Pontos Positivos e Negativos;

Considerações;

Restrições;

Cenários de Uso; e

Códigos de exemplo.

Então boa leitura e Lets Go!!!

Introdução ao ColumnStore Index

Implementado no Microsoft SQL Server 2012 desde as primeiras versões disponibilizadas para comunidade, o ColumnStore Index foi apresentado como um dos maiores recursos e inovações do SQL Server 2012, principalmente no quesito de performance para se trabalhar com grandes volumes de dados, algo muito desejado por todos aqueles que trabalham com SQL Server, mas que entendiam que era um ponto a ser investido e tratado pela Microsoft.

Através do ColumnStore Index a Microsoft, possibilitou ao mercado de Banco de Dados e Data Warehouse, o uso de tecnologia considerada inovadora na forma de tratar os dados que estão armazenados em tabelas em bases relacionais e tabelas fatos em ambientes de Data Warehouse.

O funcionamento do ColumnStore Index

Com base, no novo algoritmo de processamento de dados chamado de xVelocity, o Microsoft SQL Server a partir da versão 2012, permite que suas consultas sejam processadas com um ganho de desempenho para padrões de alto nível com grandes volumes de dados, este um recurso que permite aumentar a velocidade das consultas em até 100% dentro de tabelas fatos em um Data Warehouse.

Vindo da tecnologia VertiPaq o ColumnStore Index, recurso que esta vinculado ao xVelocity, permite a transformação das páginas de dados em colunas, onde cada página de dados é acessada independentemente, fazendo com que a compressão seja muito mais efetiva.

Outro fator importante consiste no novo modo interno de busca de dados chamado Batch Mode, que estabelece e permite uma busca de dados nas colunas de forma mais ágil, inteligente, sendo realizado em blocos de 1000 em 1000 registros, possibilitando uma maior velocidade na busca de dados.

Nas versões anteriores do Microsoft SQL Server, os dados eram armazenados em modo de linhas, como também em tabelas Heaps e Índice em estrutura de armazenamento no formato B-Tree. Com o ColumnStore Index, este cenário muda, estes mesmos dados podem ter um maior aproveitamento, onde os valores são armazenados em modo coluna, sendo as colunas que formam o respectivo índice, conforme apresenta a Figura 1.

Figura 1 – Forma de armazenamento de dados utilizados no ColumnStore Index em comparação a forma normal realizada por Tabelas e Índices.

Como qualquer outro recurso e tecnologia o ColumnStore Index, também possui algumas características e comportamentos, dentre os quais destaco:

Pontos Positivos

A seguir apresento os principais Pontos Positivos existentes para o ColumnStore Index:

Batch Mode = Blocos de 1.000 linhas que são retornados a consulta ao ínves de linha-a-linha;

Algoritmo de Redução de Custo de I/O, tornando a consulta assim mais eficiente; e

“Segment　 Elimination” de acordo com os filtros passados ao Query Optimizer, possibilitará trazer a consulta mais rápido, isso porque o mecanismo possibilita a quebra da partição em diversas partes selecionando assim os dados de uma forma mais eficiente.

Pontos Negativos

A seguir apresento alguns elementos considerados Pontos Negativos para em relalção ao ColumnStore Index:

Ao criar um ColumnStored Index no SQL Server 2012, a tabela se torna “Read-Only”, não podendo ser permitido operações de DML tais como: INSERT/UPDATE/DELETE e MERGE. Sendo assim só é possivel alterá-la se o ColumnsStore Index for desabilitada ou excluída no Microsoft SQL Server 2012. No Microsoft SQL Server 2014 esta limitação foi contornado, onde podemos criar ColumnStore Index no Clustered que permitem alteração e manipulação;

Algumas operações não são possíveis no novo modo “Batch Mode” como: Outer Joins, Join entre strings, NOT IN, IN, EXISTS e agregações escalares;

Se houver pressão na memória ou um grande uso de paralelismo, provavelmente o Query Optimizer utilizirá o modo linha-a-linha para a execução da consulta; e

Somente nas edições Enterprise, Standard e Developer é possível criar índices do tipo ColumnStore Index.

Considerações

A seguir apresento a relação de Considerações aplicadas ao ColumnStore Index:

Tabelas contendo milhões a bilhões de registros (Fact Tables) representam cenários mais indicados para se trabalhar com o ColumnStore Index;

O ColumnStore Indexes não suporta operações de Seek, somente Scan;

Operações de agregação como SUM(), AVG, joins e filtros utilizados na pesquisa;

Os índices podem ser criados em uma tabela temporária. Quando a tabela for removida ou a sessão encerrada, os índices serão removidos;

Os tipos de dados corporativos comuns podem ser incluídos em um índice columnstore, sendo eles:

char e varchar;

nchar e nvarchar (exceto varchar(max) e nvarchar(max));

decimal (e numeric) (exceto com precisão maior que 18 dígitos.);

int , bigint, smallint e tinyint;

float (e real);

Bit; e

money e smallmoney.

Observação: Todos os tipos de dados de data e hora (exceto datetimeoffset com escala maior que 2) podem ser utilizado.

Por outro lado, existem vários tipos de dados que não podem ser utilizados com ColumnStore Index, sendo eles:

binary e varbinary;

ntext , text e image;

varchar(max) e nvarchar(max);

Uniqueidentifier;

rowversion (e timestamp);

sql_variant ;

decimal (e numeric) com precisão maior que 18 dígitos;

datetimeoffset com escala maior que 2; e

Tipos CLR (hierarchyid e tipos espaciais).

Restrições

A seguir apresento a relação de Restrições existentes para o ColumnStore Index:

Não pode ter mais de 1024 colunas;

Apenas índices columnstore não clusterizados estão disponíveis, até a versão 2012. Na versão 2014 esta limitação foi removida, permitindo a utilização de ColumnStore Index, com base, em índices Clustered, permitindo a realizações de comandos de manipulação de Dados, sem necessitar que a tabela fique em “Read-Only”.

Não pode ser um índice exclusivo;

Não pode ser criado em uma exibição ou exibição indexada;

Não pode incluir uma coluna esparsa;

Não pode atuar como uma chave primária ou estrangeira;

Não pode ser alterado por meio da instrução ALTER INDEX. Em vez disso, remova e recrie o índice columnstore. Você pode usar ALTER INDEX para desabilitar e recriar um índice columnstore;

Não pode ser criado por meio da palavra-chave INCLUDE; e

Não pode incluir as palavras-chave ASC ou DESC para classificar o índice. Os índices columnstore são ordenados de acordo com os algoritmos de compactação. A classificação eliminará muitos dos benefícios de desempenho.

Índices ColumnStore não podem ser combinados com os recursos a seguir:

Compactação de página e de linha, e formato de armazenamento vardecimal (um índice columnstore já foi compactado em um formato diferente);

Replicação;

Controle de alterações;

Change Data Capture; e

Fluxo de arquivos.

Agora que já conhecemos mais sobre o ColumnStore Index, vamos começar a trabalhar com o mesmo, para isso utilizaremos os Bloco de Código apresentado abaixo, seguindo o passo a passo:

— Passo 1 — Criando o Banco de Registros ColumnStoreIndex —

CREATEDATABASEColumnStoreIndex

— Passo 1.1 — Acessando o Banco de Registros ColumnStoreIndex —

UseColumnStoreIndex

— Passo 2 — Criando uma nova Sequência de Valores —

CREATESEQUENCESeqAsINT— Tipo

STARTWITH 1 — Valor Inicial (1)

INCREMENTBY 1 — Avança de um em um

MINVALUE 1 — Valor mínimo 1

MAXVALUE 100000 — Valor máximo 100000

CACHE 1000 — Mantém 1000 posições em cache

NOCYCLE— Não irá reciclar

— Passo 3 — Criando a Tabela Registros com Primary Key —

CreateTableRegistros

(DescricaoVarChar(60)NotNull,

ValorFloatNull,

DateDateDefaultGetDate(),

TimeTimeDefaultGetDate())

AlterTableRegistros

AddConstraint[PK_Registros]PrimaryKeyClustered (Descricao)On[Primary]

— Passo 3.1 — Criando um Índice NonClustered para Tabela Registros —

CREATENONCLUSTEREDINDEX [IND_Registros_NonClustered]

ON Registros

(Descricao, Valor,Date,Time)

— Passo 4 — Listando a Relação de Índices da Tabela dbo.Registros —

Execsp_helpindex‘Registros’

— Passo 5 — Inserindo a Massa de Registros —

InsertIntoRegistros(Descricao,Valor)

Values (‘Ola…’+Convert(Varchar(100),Rand()),Rand())

Go 10000

No Passo 6, realizaremos a execução do primeiro Select para buscar dados na Tabela Registros em conjunto com o Plano de Execução, conforme apresentam a Figura 2 e Figura 3:

— Passo 6 — Executando o Select em conjunto com Sequence e Verificar o Plano de Execução —

SelectNextValueforSeqAsCodigo,Descricao,Valor,Date,TimefromRegistros

Figura 2 – Resultado do Plano de Execução apresentado após o Passo 6 ser executado.

Figura 3: Indicadores de execução utilizados pelo operadores Index Scan, na Tabela Registro, sendo que, este operador consumiu 98% do custo de processamento da query executado na Passo 6.

Galera, até aqui nada de novo tirando o objeto Sequence chamado Seq, que criamos no Passo 2, como um recurso para criar um seqüenciador(incremento) de valores utilizado como mecanismo de numeração dos registros que estão sendo inseridos em nossa Tabela. Vale ressaltar que este numerador esta sendo gerado durante o processamento do comando Select.

— Passo 7 — Limpando o Cache de Execução – Procedure e Buffer —

DBCCDROPCLEANBUFFERS

DBCCFREEPROCCACHE

Você pode estar se perguntando o porquê, estamos fazendo a Limpeza do Cache de Execução existente neste momento no SQL Server. Na verdade isso não é obrigatório, decidi fazer uso deste procedimento para garantir e demonstrar que não existe nada residente em memória e que o SQL Server deverá criar novos planos para as transações que estarão sendo processadas.

Observações

Use DBCC FREEPROCCACHE para limpar o cache do plano cuidadosamente.　Por exemplo, liberar o cache do plano faz com que um procedimento armazenado seja recompilado em vez de reutilizado no cache.Isso pode causar uma diminuição súbita e temporária no desempenho de consulta.

Para cada armazenamento em cache limpo no cache do plano, o log de erros do SQL Server conterá a seguinte mensagem informativa: “O SQL Server encontrou %d ocorrência(s) de liberação de armazenamento em cache ‘% s’ (parte do cache do plano) devido às operações ‘DBCC FREEPROCCACHE’ ou ‘DBCC FREESYSTEMCACHE'”. Essa mensagem é registrada a cada cinco minutos, desde que o cache seja liberado dentro desse intervalo de tempo.

O próximo passo será realizar a criação do ColumnStore Index, chamado ColumnStoreIndex_Registros, conforme apresenta a Figura 4:

— Passo 8 — Criando o ColumnStore Index —

CREATENONCLUSTEREDCOLUMNSTOREINDEXColumnStoreIndex_Registros

ONdbo.Registros

(

Descricao,

Valor,

Date,

Time

)

Figura 4: Relação de Índices existentes na Tabela Registros, incluindo o ColumnStore Index.

Pois bem, para ilustrar nosso cenário, vamos fazer a ativação das Estatíticas de Time e IO para utilizarmos como indicadores de comparação quando estivermos ou não fazendo uso do ColumnStore Index, para isso executaremos o Passo 9.

— Passo 9 — Ativando as Estatísticas de Time e IO —

SETSTATISTICSTIMEON

SETSTATISTICSIOON

Muito bem, estatísticas ativas, a partir de agora nossas transações terão o controle de tempo de I/O sendo apresentadas em tela como indicadores ou medidores de desempenho. Nosso próximo passo é executar o Passo 10 e Passo 11, observando as diferenças apresentada entre os Planos de Execução.

— Passo 10 — Executando novamente o Select com ColumnStore Index e Verificar o Plano de Execução —

SelectNextValueforSeqAsCodigo,Descricao,Valor,Date,TimefromRegistros

— Passo 11 — Executando novamente o Select ignorando o ColumnStore Index e Verificar o Plano de Execução —

SelectNextValueforSeqAsCodigo,Descricao,Valor,DatefromRegistros

OPTION (IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX);

Neste momento podemos realizar a execução do Passos 10 e 11, em seguida poderemos observar o resultado deste processamento, com base, nos operadores e custo de processamento de cada operador apresentado pelo Plano de Execução. Então vamos nessa, hora de executar os próximos passos e conferir o seu resultado apresentado abaixo na Figura 5.

Figura 5: Resultado apresentado pelo Plano de Execução, no momento do processamento dos Passos 10 e 11.

Podemos facilmente notar que o custo de Processamento do Passo 10, que faz uso do nosso ColumnStore Index foi de 27%, sendo que, o operador ColumnStore Index Scan, consumiu 98% de processamento. Em contra partida o Passo 11, consumiu 73% do custo de processamento, onde 99% deste processamento foi consumido pelo operador Index Scan.

Entendo que neste momento, você já pode ter entendido e observado como o ColumnStore Index pode fazer diferença, principalmente quando estamos fazendo uma consulta de dados, os demais passos vou deixar como complemento, na verdade com passos adicionais para representar outros cenários de comparação e uso do ColumnStore Index em relação a Tabelas e Índices.

— Passo 12 — Executando novamente o Select + Group By com ColumnStore Index e Verificar o Plano de Execução —

SelectNextValueforSeqAsCodigo,Descricao,Valor,Date,Count(Time)AsContagemfromRegistros

GroupByDescricao,Valor,Date

— Passo 13 — Executando novamente o Select + Group By ignorando o ColumnStore Index e Verificar o Plano de Execução —

SelectNextValueforSeqAsCodigo,Descricao,Valor,Date,Count(Time)AsContagemfromRegistros

GroupByDescricao,Valor,Date

OPTION (IGNORE_NONCLUSTERED_COLUMNSTORE_INDEX);

— Passo 14 — Desativando as Estatísticas de Time e IO —

SETSTATISTICSTIMEOFF

SETSTATISTICSIOOFF

Finish!!!

Conclusão

O ColumnStore Index, com certeza representa uma evolução nos recursos e tecnologias de bancos de dados relacional criada para se trabalhar com grandes volumes de dados, a maneira com que os dados são armazenados no ColumnStore Index nos permitem conseguir um ganho de performance de maneira perceptível e satisfatória.

As vantagens que este tipo de recurso pode apresentar são inúmeras, desde o processo de configuração até mesma a forma de uso, que possibilita ao SQL Server adaptar-se no momento da execução da transação que esta fazendo a consulta dos dados.

Espero que o material apresentado neste artigo possa ser útil e colabore com suas atividades, vou continuar testando novos recursos presentes no Microsoft SQL Server 2012 que foram melhorados na versão 2014.

Mais uma vez obrigado, nos encontramos em breve.

Até mais.

Junior Galvão – MVP – Data Platform

Select 'MVP | MCC | MSTC | MIE | MTAC' As Awards

Arquivo da tag: Armazenamento

#23 – Para que serve

Referências

Links

Agradecimentos

#22 – Para que serve

Referências

Links

Agradecimentos

Microsoft SQL Server 2017 Cumulative Update 9 disponível

Azure for Students anunciada pela Microsoft

Microsoft Virtual Academy – Novo treinamento sobre noções básicas do Windows Server 2016

O Treinamento

Suporte para Cosmos DB no Azure Storage Explorer já está disponível como Preview

Cosmos DB no Azure Storage Explorer

Dica do Mês – Você sabe o que é Normalização de Banco de Dados?

Introdução

Medidas de Qualidade

Dependência Funcional

Formas Normais Baseadas em Chaves Primárias

Questionário

Exercício

MAIS DETALHES SOBRE O OFFICE 16

OFFICE 16

Conhecendo o Microsoft SQL Server 2012 e 2014 – Utilizando o ColumnStored Index.

Referências

Links

Agradecimentos

Compartilhe isso:

Referências

Links

Agradecimentos

Compartilhe isso:

Compartilhe isso:

Compartilhe isso:

Compartilhe isso:

O Treinamento

Compartilhe isso:

Cosmos DB no Azure Storage Explorer

Compartilhe isso:

Introdução

Medidas de Qualidade

Dependência Funcional

Formas Normais Baseadas em Chaves Primárias

Questionário

Exercício

Compartilhe isso:

OFFICE 16

Compartilhe isso: