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
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 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.
Curtir isso:
Curtir Carregando...
Figura 1 – Introdução ao Microsoft SQL Server 2019.
Figura 3 – Posição atual de dados armazenados na tabela TemporalTableTemperatura.
Figura 4 – Todas as manipulações realizadas na tabela TemporalTableTemperatura armazenadas de forma espealhada na tabela histórico TemporalTableTemperaturaHistorico.
Figura 5 – Resultados obtidos após a execução de cada comando select declarado no Bloco de Código 5.
Figura 2 – Resultado apresentado pelo comando DBCC ShowFileStats.
Figura 1 – Código Transact-SQL apresentado no Script Challenge 14.
Figura 2 – Informações relacionadas a estimativa de tamanho do arquivo de backup e espaço livre em disco em megabytes.
Figura 1 – Novo ícone utilizado pelo Microsoft SQL Server Management Studio a partir da versão 17.