Short Scripts – Março 2022

Neste primeiro post de 2022 da sessão Short Scripts você vai encontrar scripts relacionados a utilização de arquivos de dados, arquivos de log e filegroups aplicados aos bancos de dados existente no Microsoft SQL Server.


Olá pessoal, bom dia…

Seja bem-vindo, em mais um post da sessão Short Scripts, o primeiro post desta sessão em 2022 e o de número 45 em seu total.

Estamos começando o outono de 2022, eu adoro este vento que fica o dia todo em conjunto com esta temperatura agradável, seja de passar calor.

Mantendo a tradição estou retornando com mais um conjunto dos “curtos ou pequenos” scripts catalogados e armazenados em minha biblioteca pessoal de códigos relacionados ao Microsoft SQL Server e sua fantástica linguagem de desenvolvimento Transact-SQL.

Como promessa é dívida e deve ser cumprida “ou melhor” compartilhada, vou pagar a minha mais uma vez hoje, feita no encerramento do post anterior publicado no mês de julho de 2021, se por acaso você ainda não acessou o mesmo, calma, fique tranquilo, tudo vai dar certo, no encerramento deste post você terá a sua disposição a relação das últimas cinco publicações relacionadas aos Short Scripts.

Vamos caminhar mais um pouco então……..

Continue Lendo “Short Scripts – Março 2022”

Short Scripts – Junho 2021

Neste segundo post de 2021 da sessão Short Scripts você vai encontrar scripts relacionados com a cláusula Values aplicada aos comandos Select e Insert.


Olá pessoal, bom dia…

Seja bem-vindo, em mais um post da sessão Short Scripts, o segundo post desta sessão em 2021 e o de número 44 em seu total.

Estamos terminando a primeira metade de 2021, o frio já esta chegando, nossa eu adoro o inverno.

Mantendo a tradição estou retornando com mais um conjunto dos “curtos ou pequenos” scripts catalogados e armazenados em minha biblioteca pessoal de códigos relacionados ao Microsoft SQL Server e sua fantástica linguagem de desenvolvimento Transact-SQL.

Como promessa é dívida e deve ser cumprida “ou melhor” compartilhada, vou pagar a minha mais uma vez hoje, feita no encerramento do post anterior publicado no mês de janeiro deste ano, se por acaso você ainda não acessou o mesmo, calma, fique tranquilo, tudo vai dar certo, no encerramento deste post você terá a sua disposição a relação das últimas cinco publicações relacionadas aos Short Scripts.

Vamos caminhar mais um pouco então……..

Continue Lendo “Short Scripts – Junho 2021”

Short Scripts – Janeiro 2021

Neste primeiro post de 2021 da sessão Short Scripts você vai encontrar uma super coleção de scripts compartilhados ao longo dos anos que apresentaram algo tipo de destaque.


Olá pessoal, bom dia…

Seja bem-vindo, em mais um post da sessão Short Scripts, o primeiro post desta sessão em 2021 e o de número 43 em seu total.

Estamos entrando na segunda semana de 2021, começando a esquentar bem lentamente nossos motores.

Mantendo a tradição estou retornando com mais um conjunto dos “curtos ou pequenos” scripts catalogados e armazenados em minha biblioteca pessoal de códigos relacionados ao Microsoft SQL Server e sua fantástica linguagem de desenvolvimento Transact-SQL.

Como promessa é dívida e deve ser cumprida “ou melhor” compartilhada, vou pagar a minha mais uma vez hoje, feita no encerramento do post anterior publicado no mês de setembro no ano de 2020, se por acaso você ainda não acessou o mesmo, calma, fique tranquilo, tudo vai dar certo, no encerramento deste post você terá a sua disposição a relação das últimas cinco publicações relacionadas aos Short Scripts.

Vamos caminhar mais um pouco então……..

Continue Lendo “Short Scripts – Janeiro 2021”

Short Scripts – Setembro 2020

Neste terceiro post de 2020 da sessão Short Scripts, você vai encontrar exemplos de códigos elaborados para criação e desenvolvimento de User Defined Functions – Funções Definidas pelo Usuário no Microsoft SQL Server.


Olá boa tarde, como vai?

Seja bem-vindo, em mais um post da sessão Short Scripts, o terceio post desta sessão em 2020 e o de número 42 em seu total.

Que bom poder te encontrar aqui neste feriado….. Espero que você e seus familiares se encontrem bem neste momento terrível que estamos vivendo em todo Mundo.

Mantendo a tradição estou retornando com mais um conjunto dos “curtos ou pequenos” scripts catalogados e armazenados em minha biblioteca pessoal de códigos relacionados ao Microsoft SQL Server e sua fantástica linguagem de desenvolvimento Transact-SQL.

Como promessa é dívida e deve ser cumprida “ou melhor” compartilhada, vou pagar a minha mais uma vez hoje, feita no encerramento do post anterior publicado no mês de Maio, se por acaso você ainda não acessou o mesmo, calma, fique tranquilo, tudo vai dar certo, no encerramento deste post você terá a sua disposição a relação das últimas cinco publicações relacionadas aos Short Scripts.

Vamos caminhar mais um pouco então……..

Continue Lendo “Short Scripts – Setembro 2020”

Dica do Mês – Identificando os números ausentes em uma sequência numérica


Olá pessoal, bom dia.

Tudo bem? Estamos no ultimo final de semana do mês de Setembro, a primavera chegou, já estamos vivendo a última estação do ano, 2019 voando, passando de forma extremamente rápida, o que muitas vezes não nos deixa perceber o quanto nossa vida é uma correria.

Mesmo com este correira, temos que tentar aproveitar todo tempo disponível dentro das 24 horas diárias para se dedicar também ao que gostamos de fazer, e por isso estou aqui novamente em mais um post do meu blog, que honra ter encontrar aqui neste sábado, sua presença é muito importante.

Ainda mais na sessão Dica do Mês, a qual foi criada á alguns anos com objetivo de compartilhar algo que possa ser considerada como uma dica ou melhores práticas para se trabalhar na área de banco de dados, mais especificamente com o Microsoft SQL Server.

A dica de hoje esta envolvida diretamente com os dados manipulados diariamente por empresas, instituições ou organizações públicas e privadas, me refiro a lançamento feitos através de um SIG – Sistema de Informação Gerencial ou ERP – Enterprise Resource Planning, que muitas vezes utilizamos para dar entrada em lançamento contábeis, movimentações fiscais e financeiras, ou “basicamente” cadastrar uma nota fiscal de recebimento de produto no almoxarifado da empresa.

Para facilitar o entendimento, e server como base de exemplo para nossa dica, dentre as mais diversas áreas, setores e departamentos que constituem uma empresa, selecione para esta dica, uma das mais tradicionais áreas conhecida por muitos como Controle de Estoque vinculado com os lançamentos contábeis.

Mais ainda não ficou claro o objetivo desta dica, não é mesmo? Tenho a certeza que não, mas tenha calma, você vai descobrir a seguir o que estou querendo te apresentar.

Continue Lendo “Dica do Mês – Identificando os números ausentes em uma sequência numérica”

#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

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.

#19 – Para que serve


Salve galera, boa tarde.

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

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

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

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


Introdução

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

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

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

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

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

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

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

Figura 1 – Estrutura dos componentes utilizados pelo comando select.

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

O Ciclo (Select)

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

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

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

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

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

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

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

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

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

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

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

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

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


Referências

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

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

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

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

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

Links

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

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

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

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

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

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

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

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

Conclusão

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

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

Agradecimentos

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

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

Valeu.

Microsoft disponibiliza o SQL Server 2017 CTP 2.1


A Microsoft anunciou nesta semana em seu blog a disponibilidade no TechNet Evaluation Center do SQL Server 2017 CTP 2.1, a versão de testes pública mais recente do novo SQL Server.

Performance inigualável
Faça consultas até 100 vezes mais rápido do que o disco com columnstore in-memory e transações até 30 vezes mais rápido com OLTP in-memory.

Menos vulnerável
Melhore a segurança com criptografia em repouso e em movimento. O SQL Server é o banco de dados menos vulnerável nos últimos sete anos no banco de dados de vulnerabilidades do NIST.

Inteligência em tempo real
Obtenha insights transformadores com até 1 milhão de previsões por segundo usando o Python interno e a integração da linguagem R e obtenha o BI móvel completo em qualquer plataforma.

Qualquer aplicativo, em qualquer lugar
Crie aplicativos modernos usando quaisquer dados e qualquer linguagem, na infraestrutura local e na nuvem.

Microsoft disponibiliza o SQL Server 2017 CTP 2.1

Faça o download do SQL Server 2017 CTP 2.1

O SQL Server 2017 CTP 2.0 para Windows (64 bits) está disponível para download aqui como uma imagem ISO e como um arquivo CAB nos seguintes idiomas: Inglês, alemão, espanhol, japonês, italiano, francês, russo, chinês simplificado, chinês tradicional, português (Brasil) e coreano.

A lista com as novidades no CTP 2.1 para Windows pode ser vista aqui. As versões para Linux, Docker, Azure e Mac OS estão disponíveis aqui.

Fontes e Direitos Autorais: Baboo.com – .

Atualização Cumulativa 3 para SQL Server 2016 SP1


A Microsoft disponibilizou para download nesta semana a Atualização Cumulativa 3 para SQL Server 2016 SP1.

O primeiro Service Pack do SQL Server 2016 foi lançado pela empresa em 17 de novembro de 2016 e está disponível para download aqui.

SQL Server 2016

O SQL Server 2016 traz recursos críticos inovadores com desempenho em memória e análise operacional integrada. Os recursos de segurança abrangentes, como a tecnologia de criptografia ininterrupta (Always Encrypted), ajudam a proteger seus dados fixos e em movimento, e uma solução avançada de alta disponibilidade e recuperação de desastres acrescenta novos aprimoramentos à tecnologia AlwaysOn.

As organizações terão visões mais aprofundadas de todos os seus dados com novos recursos que vão além da business intelligence, executando a análise avançada diretamente dentro de seus bancos de dados e apresentando visualizações avançadas para oferecer visões de negócios de qualquer dispositivo.

Atualização Cumulativa 3 para SQL Server 2016 SP1

Você também pode se beneficiar da nuvem em hiperescala, com novos cenários híbridos habilitados pela nova tecnologia de banco de dados elástico (Stretch Database), que permite expandir dinamicamente seus dados transacionais a quente e a frio até o Microsoft Azure de forma segura, para que seus dados estejam sempre à disposição para consultas, independentemente do tamanho.

O SQL Server 2016 também oferece uma plataforma de banco de dados completa para a nuvem híbrida, permitindo criar, implantar e gerenciar facilmente soluções que abrangem instalações locais e na nuvem.

Saiba mais sobre ele aqui.

Atualização Cumulativa 3 para SQL Server 2016 SP1

De acordo com o artigo KB4019916 publicado no site de suporte da Microsoft, a Atualização Cumulativa 3 para SQL Server 2016 SP1 contém correções para problemas encontrados depois do lançamento do SQL Server 2016 SP1. Essa atualização cumulativa também inclui todas as correções de todas as atualizações anteriores.

A lista de bugs corrigidos inclui um que causa um erro interno no SQL Server Analysis Service durante o processamento de um modelo Tabular, um que faz com que o consumo de memória aumente demais em certos cenários e um que faz com que o SQL Server 2016 pare de responder quando o evento estendido “Latch_Suspend_End” é iniciado incorretamente.

A Atualização Cumulativa 3 para SQL Server 2016 SP1 está disponível para download aqui. Já quem usa o SQL Server 2016 sem o SP1 pode fazer o download da Atualização Cumulativa 6 aqui.

Fontes e Direitos Autorais: Baboo.com –

Atualização Cumulativa 2 para SQL Server 2016 SP1


A Microsoft disponibilizou para download nesta segunda-feira a Atualização Cumulativa 2 para SQL Server 2016 SP1.

O primeiro Service Pack do SQL Server 2016 foi lançado pela empresa em 17 de novembro de 2016 e está disponível para download aqui.

SQL Server 2016

O SQL Server 2016 traz recursos críticos inovadores com desempenho em memória e análise operacional integrada. Os recursos de segurança abrangentes, como a tecnologia de criptografia ininterrupta (Always Encrypted), ajudam a proteger seus dados fixos e em movimento, e uma solução avançada de alta disponibilidade e recuperação de desastres acrescenta novos aprimoramentos à tecnologia AlwaysOn.

As organizações terão visões mais aprofundadas de todos os seus dados com novos recursos que vão além da business intelligence, executando a análise avançada diretamente dentro de seus bancos de dados e apresentando visualizações avançadas para oferecer visões de negócios de qualquer dispositivo.

Atualização Cumulativa 2 para SQL Server 2016 SP1

Você também pode se beneficiar da nuvem em hiperescala, com novos cenários híbridos habilitados pela nova tecnologia de banco de dados elástico (Stretch Database), que permite expandir dinamicamente seus dados transacionais a quente e a frio até o Microsoft Azure de forma segura, para que seus dados estejam sempre à disposição para consultas, independentemente do tamanho.

O SQL Server 2016 também oferece uma plataforma de banco de dados completa para a nuvem híbrida, permitindo criar, implantar e gerenciar facilmente soluções que abrangem instalações locais e na nuvem.

Saiba mais sobre ele aqui.

Atualização Cumulativa 2 para SQL Server 2016 SP1

De acordo com a Microsoft, a Atualização Cumulativa 2 para SQL Server 2016 SP1 contém correções para problemas encontrados depois do lançamento do SQL Server 2016 SP1.

Essa atualização cumulativa também inclui todas as correções de todas as atualizações cumulativas anteriores.

O artigo KB4013106 contendo mais informações sobre o que foi corrigido por esta atualização ainda não foi publicado pela Microsoft. Ele estará disponível em breve aqui.

A Atualização Cumulativa 2 para SQL Server 2016 SP1 está disponível para download aqui. Já quem usa o SQL Server 2016 sem o SP1 pode fazer o download da Atualização Cumulativa 5 aqui.

Fontes e Direitos Autorais: Baboo.com –

Dica do Mês – Restrições de Integridade para Banco de Dados


Fala galera, bom dia.

Tudo bem?

Estou um pouco ausente neste mês devido as correrias da minha vida profissional e acadêmica, mas sempre que possível compartilhando com vocês um pouco do meu conhecimento e experiência.

O post de hoje poderia ser diferente dos outros, na sessão Dica do Mês vou apresentar um pouco mais sobre os conceitos básicos de banco de dados voltados para área de modelagem, estou me referindo as chamadas Restrições de Integridade (RI), algo bastante útil e importante quando estamos realizando as definições da estrutura lógica para armazenamento de dados em qualquer banco de dados. Então vamos começar a falar um pouco mais sobre este conceito também criado na década dos anos 70 por Edgar Frank Codd.


Falando um pouco sobre integridade…

A integridade de dados é uma das características essenciais da segurança da informação, e garante que as informações não sofreram alterações que não foram autorizadas ou que são impróprias. Utilizada para assegurar que um documento não é alterado depois de ter sido assinado.

Quando vamos projetar um banco de dados, imaginamos as possíveis formas para que nossa aplicação grave os dados corretamente no banco de dados, mas as vezes, esquecemos de definir, a nível de banco, quais as validações que devem ser feitas para evitar inconsistências nos dados e que, futuramente, se tornariam dores de cabeça.

No contexto de bancos de dados relacional é comum falar de integridade referencial, que tem como objetivo conservar as relações existentes entre tabelas quando algumas linhas são inseridas ou eliminadas.

Restrições de Integridade….

As chamadas RIs possuem o objetivo de garantir a exatidão e a consistência dos dados em uma Banco de dados relacional. Ou seja, garantir que dados representem assertivamente a realidade modelada. A integridade dos dados é tratada nas bases de dados através do conceito de integridade relacional e é garantida pelo próprio SGDB.

Existem vários tipos de restrições de integridade. Codd, inicialmente definiu 2 tipos de restrições, mas na sua segunda versão do modelo relacional ele definiu 5 tipos de restrições de integridade.

Mas antes de conhecer este tipos, vamos entender um pouco o conceito de domínio dos atributos: O domínio indica os possíveis valores de um atributo. A integridade de domínio verifica se os dados são do tipo permitido (alfanumerico, numerico,etc), tamanho do campo, se ele pode ser nulo ou não. Por exemplo, é possível definir que um atributo “idade” de um funcionário é sempre um valor inteiro positivo.

Os cinco tipos de restrições…

Restrição de Chave: Impede que uma chave primária se repita. Um campo chave primária diferencia de forma única os registros (linhas) de uma relação (tabela).

Restrição de Domínio: Impede que uma chave primária receba como valor NULL (nulo).

Integridade de vazio: Verifica se um campo pode ou não receber valor NULL. Sub-item da integridade de domínio.

Integridade referencial: Uma chave estrangeira de uma relação tem que coincidir com uma chave primária da sua tabela “pai” a que a chave estrangeira se refere. Ou seja, não só deve existir o atributo (campo), como também, o valor referenciado.

Integridade definida pelo usuário: Permite definir regras comerciais que não se encaixam em outras categorias de integridade.

Elementos que formam as Restrições de Integridade…

Integridade Semântica: Garante que o dado inserido em uma linha da tabela seja um valor válido. Para esse valor ser válido deve ser do mesmo tipo de dados definido na especificação da coluna na tabela.

Imagine o atributo de uma determinada entidade definido como DATA, por padrão este atributo deverá conter somente dados relativos a DATA. É justamente esta definição que nos permite ter a certeza que no campo DATA_CONTRATACAO só terá datas válidas.

Caso um SGDB permita a inserção de um outro tipo de dado diferente do definido, a integridade semântica será violada. A integridade semântica em um SGDB é aplicada com a utilização de constraints.

Constraints: Pode ser definido resumidamente como uma regra que limita o valor que pode ser inserido, modificado ou eliminado em uma tabela. Na linguagem SQL temos os seguintes tipos de constraints:

  • Constraint de dados;
  • Constraint NOT NULL (não nulo);
  • Constraint única; e
  • Constraint de validação (check constraint).

Constraints de Dados: Esse tipo de constraint pode ser considerado o mais simples e por muitas vezes ignorado como um constraint. Ele é o que delimita o tipo de dado de cada coluna em uma tabela.

Os tipos de informações disponíveis na maioria dos SGDBs existentes pode ser dividia em:

  • Numérico;
  • Alfanumérico ou caracteres;
  • Data e tempo; e
  • Grandes objetos.

Constraints Not Null: O conceito de nulo é utilizado quando uma determinada coluna ou atributo de uma linha na tabela não possui valor ou este valor é desconhecido. Por outro lado, existem colunas / atributo que obrigatoriamente precisam de valor informado.

Por exemplo, em uma tabela chamada FUNCIONARIO, onde estão dados de funcionários, o atributo NUMERO_FUNCIONARIO é obrigatório. Nesse caso é possível utilizar a constraint NOT NULL para garantir que haverá informação nessa coluna.

Importante frisar que NULO é diferente de brancos e zeros. Temos que lembrar também que tanto branco quanto zero são valores válidos e que são levados em conta em funções de coluna, tais como média, somatório, máximo, mínimo. Sendo que o NULO é desconsiderado nessas funções.

Constraints Única (Unique): Reconhecida e tratata como uma regra única que garante e não permite a existência de valores duplicados da mesma coluna ou em um conjunto de colunas na mesma tabela.

Usando o mesmo exemplo da tabela FUNCIONARIO, podemos utilizar uma constraint única na coluna NUMERO_FUNCIONARIO para garantir que dois ou mais funcionários possuam o mesmo número de identificação.

Podemos considerar que a chave primaria (primary key), que será explicada mais adiante, é um tipo de constraint única. Lembrando que uma tabela pode ter apenas uma chave primária, porém diversas constraint únicas.

Constraints de Validação (Check): Esta constraint determina um conjunto de valores permitidos para uma determinada coluna na tabela. Através deste tipo de constraints podemos definir de forma explícita através da linguagem DDL (Data Definition Language) de uma tabela com expressões Booleanas similares a clausula WHERE da linguagem Transact-SQL.

Uma constraint de validação é forçada em qualquer inserção ou atualização da coluna. Caso a inserção ou atualização da coluna não esteja de acordo com a definição da constraint, a mesma não será executada.

Por exemplo, vamos supor que a tabela FUNCIONARIO possua uma coluna SALARIO e que o valor do salário de cada funcionário não possa ser maior que 50.000,00, é possível criar uma constraint para erra regra:

CREATE TABLE FUNCIONARIO

(NUMERO_FUNCIONARIO SMALLINT NOT NULL,

SALARIO DECIMAL (9,2) NOT NULL CHECK SALARIO >= 50.000);

Observações: Uma constraint de validação pode ser muito útil para garantir regras de negócio, pois ela não pode ser sobreposta. Uma vez definida é dada a garantia que a regra será respeitada.

Utilizar esse tipo de integridade torna as suas aplicações mais robustas, consistentes e simples, pois não é necessário controlar as regras dentro do próprio código de programação ou utilizando uma subrotina. Dessa maneira é isolada em apenas um lugar a regra de negócio; e

Havendo a necessidade de mudar alguma regra de negócio, basta apenas alterar a constraint de validação na tabela ao invés de sair alterando códigos e mais códigos de programação uma vez que a mesma regra pode estar replicada em diversos pontos da sua aplicação.

Realizando uma prática…

Após conhecermos um pouco sobre o conceito e elementos que formam as restrições de integridade, vamos então colocar “a mão na massa” ou melhor como eu sempre digo no teclado e construir um simples exemplo de como podemos fazer uso de forma mais coerente e organizada do uso da restrição de integridade em nossas tabelas. Para tal utilizaremos o Bloco de Código 1 apresentado abaixo:

— Bloco de Código 1 — Aplicando o conceito de restrições de integridade —

— Criando o Banco de Dados —
Create Database RI
Go
— Acessando o Banco de Dados —
Use RI
Go
— Criando a Tabela Funcionarios utilizando Constrainst – Not Null, Null, Check, Default e Unique —
Create Table Funcionarios
(Codigo Int Primary Key Identity(1,1),
Nome Varchar(80) Not Null,
Sexo Char(1) Check (Sexo = ‘F’ or Sexo = ‘M’),
RG Int Not Null Unique NonClustered,
CPF Int Not Null Unique NonClustered,
DataNascimento Date Check (DataNascimento >= ‘1950-01-01’),
DataCadastro DateTime Default GetDate(),
Email Varchar(100) Null)
Go
— Criando a Tabela Clientes utilizando Constrainst – Not Null, Null, Check, Default e Unique —
Create Table Clientes
(Codigo Int Identity(1,1),
Nome Varchar(80) Not Null,
Sexo Char(1),
RG Int Not Null,
CPF Int Not Null,
DataNascimento Date,
 DataCadastro DateTime Constraint DF_Clientes_DataCadastro Default GetDate(),
Email Varchar(100) Null
  Constraint PK_Clientes_Codigo Primary Key (Codigo),
  Constraint CK_Clientes_Sexo Check (Sexo = ‘F’ or Sexo = ‘M’),
  Constraint UQ_Clientes_RG Unique NonClustered (RG),
  Constraint UQ_Clientes_CPF Unique NonClustered (CPF),
  Constraint CK_Clientes_DataNascimento Check (DataNascimento >= ‘1950-01-01’))
Go
— Adicionando uma nova Constraint —
Alter Table Clientes
Add Constraint DF_Clientes_Sexo Default ‘M’ for Sexo
Go
— Removendo uma Constraint já existente —
Alter Table Clientes
Drop Constraint CK_Clientes_DataNascimento
Go
— Adicionando uma nova Constraint do tipo Check —
Alter Table Clientes
Add Constraint CK_Clientes_DataNascimento
Check(DataNascimento >=’1900-01-01′)
Go

Perfeito, após executarmos este bloco de código temos nosso ambiente totalmente criado seguindo as definições de restrições de integridade que aplicamos no script.

Você pode estar se perguntando mas o que existe de diferença entre criar uma tabela sem definir o nome dados constraints em comparação com uma tabela que possui o nome das constraints definidas. A resposta para esta sua dúvida será respondida através da Figura 1 apresentada abaixo:

constraints
Figura 1 – Restrições de integridade criadas em cada tabela.

Analisando a Figura 1 podemos notar claramente a diferença, quando definimos um nome para nossas constrainst o Microsoft SQL Server atribui exatamente o nome de definimos no momento da crição da tabela, com isso, teremos mais facilidade para realizar uma manutenção nestes objetos, bem como, toda documentação e apresentação da estrutura do nosso banco de dados será mais limpa e organizada.


 

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

O conhecimento técnico é muito importante para qualquer profissional, mas não podemos deixar de lado o conhecimento acadêmico adquirido ao longo dos anos dentro das instituições de ensino.

Este é um ponto fundamental, valorizar e conhecer a diferença entre um bom profissional e o profissional reconhecido e respeitado no mercado de trabalho, está justamente ligado na capacidade do mesmo em saber aliar o conhecimento teórico com o conhecimento prático, 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.

Microsoft SQL Server 2016 e String_Split(), agora ficou fácil dividir uma string.


Fala galera, boa tarde, segunda – feira, eita dia complicado, começo de semana é tenso, pois saber que mais um final de semana passou voando é triste. Vamos em frente e pensar que mais um final de semana está chegando, é bem melhor.

Seguindo a onda de informações, anúncios, posts, entre outras formas de divulgação sobre o Microsoft SQL Server 2016, hoje vou destacar mais um pouco no meu blog sobre esta nova versão e destacar mais uma das suas novidades, estou me referindo a nova Table Value Function String_Split(). Algo que realmente era muito pedido pelos desenvolvedores e que a Microsoft demorou um pouco para reconhecer a sua importância, mas na versão 2016 ela está presente e será muito útil.

 

A String_Split()

Pode-se dizer que é uma daquelas funções desejadas por todos os profissionais que trabalham com desenvolvimento e necessitam em algum momento realizar o chamado split de uma string. Se você não sabe ou conhece este termo, split pode ser entendido como fatiar, dividir, cortar, quebrar em pedaços.

Fazendo uma analogia, a string_split() vai fazer exatamente isso com uma string, transformando a mesma em pequenas outras strings (substrings ou partes de uma string).

Funcionalidade ou capacidade considerado por muitos como algo realmente complexo se der feito por um SGBD – Sistema Gerenciador de Banco de Dados, ainda mais para o SQL Server se pensarmos que até a versão 2014 tínhamos a necessidade de customizar este tipo de necessidade.

Mas que para nossa alegria a Microsoft introduziu este recurso na versão RC0 sinal que provavelmente e o que tudo indica a mesma vai fazer parte da versão final do SQL Server 2016.

 

Compatibilidade

Por se tratar de uma nova funcionalidade, até o presente momento a documentação oficial da Microsoft indica que esta função é compatível com a versões:

  • Microsoft SQL Server 2016; e
  • Azure Database.

As versões Azure SQL Data Warehouse e Parallel Data Warehouse até o momento não estão na lista de produtos compatíveis com a esta nova função.

Observação: Um detalhe muito importante é a necessidade do nível de compatibilidade do banco de dados estar definido na versão 130, sendo este o nível do SQL Server 2016.

 

Sua importância. O porquê ela pode ajudar

A String_Split() vem para preencher uma lacuna muito grande deixada pelo tipo de desenvolvimento e engenheiros da Microsoft desde a versão 2008 e 2012, onde novas funções para se trabalhar com string foram adicionadas no produto.

Sua importância vai muito além da capacidade técnica de permitir que uma string seja dividida em pequenas partes e posteriormente armazenada em uma tabela, variável ou função, ela vai com certeza flexibilidade e facilitar em muito a maneira com que os dados podem ser tratados e reconhecidos pelo SQL Server o que poderá permitir a criação de novos padrões de reconhecimento de caracteres.

Uma das grandes vantagens de se utilizar a String_Split() está relacionada com a uma simples sintaxe, onde requer basicamente dois parâmetros.

 

Como utilizar a String_Split()

Criada para ser utilizada de maneira rápida e simples, a String_split é composta pode dois parâmetros string compatíveis com os tipos de dados: (nvarcharvarcharnchar ou char) para a string que desejamos supostamente dividir em conjunto com o caractere reconhecido como “divisor” ou “separador”, que também deve ser informado em um tipo de string compatível com os tipos de dados: nvarchar(1)varchar(1)nchar(1) ou char(1)).

Outra característica muito interessante desta função é a maneira que os dados são apresentados e retornados para usuário, onde podemos ter o retorno do split da string em uma coluna com diversas linhas representando os fragmentos “pedaços” ou “partes” da string, como também um valor caractere no tipo de dados nchar ou nvarchar de acordo com o tipo de dado utilizado, respeitando o tamanho do dado identificado no momento da fragmentação da string. Caso não seja reconhecido o tipo de dados original da string, o resultado da sua fragmentação será retornado com o tipo de dados varchar.

Exemplos

A seguir você vai poder encontrar alguns exemplos de como podemos fazer uso da função String_Split(). Vale ressaltar que esta função se encontra disponível a partir da versão RC0, requerendo a configuração o nível de compatibilidade para o número 130.

Alguns dos exemplos apresentados aqui foram elaborados e executados no banco de dados de exemplo AdventureWorks2016 CTP3, caso venha tenha interesse em realizar o download desta sample database, utilize o link: https://www.microsoft.com/en-us/download/details.aspx?id=49502

Outro detalhe importante a ser destacado é o resultado apresentado para cada exemplo ilustrado a seguir, por padrão o SQL Server gera uma coluna chamada value contendo a lista de valores fragmentados após o processo de split da string.

 

 

— Exemplo 1 – Separando de forma simples uma string –

SELECT *

FROM STRING_SPLIT(‘Junior,Galvão,MVP,SQL Server’,’,’)

Go

 

Resultado

value
Junior
Galvão
MVP
SQL Server

 

— Exemplo 2 – Fazendo uso de variáveis como parâmetros de entrada de valores –

DECLARE @string VARCHAR(100) = ‘Microsoft,SQL Server,2016,RC0′,

@separador CHAR(1) =’,’

 

SELECT *

FROM STRING_SPLIT(@string,@separador)

Go

 

Resultado

value
Microsoft
SQL Server
2016
RC0

 

— Exemplo 3 – Armazenando o resultado da divisão de uma string em uma nova tabela –

DECLARE @string VARCHAR(100) = ‘Microsoft,SQL Server,2016,RC0′,

@separador CHAR(1) =’,’

 

SELECT * INTO #SplitTable

FROM STRING_SPLIT(@string,@separador)

GO

 

— Visualizando a estrutura da tabela —

sp_Columns #SplitTable

Go

 

— Consultando os dados da tabela —

Select * from #SplitTable

Go

 

Após executar a system stored procedure sp_columns podemos notar que o tamanho e tipo de dados da coluna value criada através do select…into foi definido como Varchar() sendo este o tipo de dados padrão utilizado pela String_Split() para garantir compatibilidade no armazenamento e apresentação de dados oriundos de uma outra tabela.

 

— Exemplo 4 – Apresentando a mensagem quando o separador de string for definido com mais de um caracter —

DECLARE @string VARCHAR(100) = ‘pedrogalvaojunior#@gmail#@com’,

@separador CHAR(2) =’#@’

 

SELECT * FROM STRING_SPLIT(@string,@separador)

Go

 

Como pode ser observado o Microsoft SQL Server 2016 vai lançar e apresentar uma mensagem de erro com o código 214 informando que a quantidade de caracteres ou melhor dizendo que o tamanho utilizado para o parâmetro separador foi definido acima de um caractere, sendo que, este parâmetro só identifica e reconhece um único caractere.

Resultado

Msg 214, Level 16, State 11, Line 3

Procedure expects parameter ‘separator’ of type ‘nchar(1)/nvarchar(1)’.

 

— Exemplo 5 – Apresentando o comportamento da String_Split() quando um parâmetro apresenta valor nulo –

SELECT * FROM STRING_SPLIT(‘pedrogalvaojunior,wordpress,com’,NULL)

Go

 

Para este exemplo 5 o comportamento do SQL Server 2016 é exatamente o mesmo do exemplo 4, onde será apresentanda uma mensagem de erro informando que o tamanho informado no parâmetro separado, foi definido acima de um caractere.

Resultado

Msg 214, Level 16, State 11, Line 3

Procedure expects parameter ‘separator’ of type ‘nchar(1)/nvarchar(1)’.

 

— Exemplo 6 – Realizando o split de uma string com base na junção de uma tabela com a função String_Split() –

— Criando a tabela Split —

Create Table Split

( SplitId INT IDENTITY (1,1) NOT NULL,

SplitValue1 NVARCHAR(50),

SplitValue2 NVARCHAR(50))

GO

 

— Inserindo linhas de registro —

INSERT INTO Split (SplitValue1, SplitValue2)

VALUES (‘Pedro’,’Galvão’),

(‘Junior’,’Galvão’),

(‘Antonio’,’Silva’),

(‘Chico’,’Bento’)

Go

 

— Realizando a Junção da Tabela Split com a função Split_String() —

Select SplitId, SplitValue1, SplitValue2, Value

From Split S Inner Join String_Split(‘Pedro,Antonio’,’,’) STS

On S.SplitValue1 = STS.Value

Go

 

Observe que o SQL Server realizou o split dos dados com base na junção e valores informados para a função e mesmo assim apresentou os dados dados de cada coluna que compõem a estrutura da tabela Split.

 

Resultado

SplitID SplitValue1 SplitValue2 Value
1 Pedro Galvão Pedro
3 Antonio Silva Antonio

 

— Exemplo 7 – Apresentando o resultado quando ambos os parâmetros vazios –

Select * from String_Split(‘ ‘,’,’)

Go

 

Após executa o select acima o SQL Server identificou que ambos os parâmetros encontra-se vazios, sem nenhum tipo de dado que permita fazer a identificação da string e do separador, sendo assim o resultado retornado será uma única linha de registro vazia.

 

Resultado

Value

 

— Exemplo 8 – Apresentando o comportamento da String_Split() quando o caracter do final da string é o mesmo utilizado como separador –

SELECT * FROM STRING_SPLIT(‘Conhecendo,SQL Server,2016,’,’,’)

Go

 

Este é um cenário bem interessante e pode ocorrer a qualquer momento, nesta situação o SQL Server 2016 vai trabalhar da mesma forma que os outros exemplos, analisando e identificando a string e posteriormente fazendo a fragmentação com base no caractere separador, mesmo que este seja um caractere utilizado no final da string.

Note que que criada 4 linhas de registro sendo que a última não apresentará valores por será reconhecida e tratada como uma linha nula ou em branco.

Resultado

value
Conhecendo
SQL Server
2016

 

Legal, legal, acredito que agora ficou ainda mais fácil de entender e compreender como a String_Split() é fácil de ser utilizado e principalmente a maneira que os dados são apresentando e retornado para usuário. Desta forma, vou encerrar mais este artigo por aqui, quero também aproveitar para disponibilizar abaixo uma relação de links sobre os principais posts referentes ao SQL Server 2016 que estou desde 2015 publicando.

 


 

 

Links

Caso você não tenha acessado os posts anteriores dedicados ao Microsoft SQL Server 2016, não perca tempo e a oportunidade de conhecer mais sobre esta nova versão acessando os links abaixo:

https://pedrogalvaojunior.wordpress.com/2015/12/28/microsoft-sql-server-2016-e-json-uma-combinacao-bem-interessante-final/

https://pedrogalvaojunior.wordpress.com/2015/11/09/microsoft-sql-server-2016-e-json-uma-combinacao-bem-interessante-parte-i/

https://pedrogalvaojunior.wordpress.com/2015/10/02/conhecendo-o-live-query-statistics-no-microsoft-sql-server-2016/

https://pedrogalvaojunior.wordpress.com/2015/07/10/microsoft-sql-server-2016-lista-de-novidades-parte-i/

https://pedrogalvaojunior.wordpress.com/2015/07/16/microsoft-sql-server-2016-lista-de-novidades-parte-ii/

https://pedrogalvaojunior.wordpress.com/2015/07/30/microsoft-sql-server-2016-lista-de-novidades-final

 

Conheça o SQL Server 2016 RC0: Faça download da versão RC0 disponibilizada a poucos dias acessando: https://www.microsoft.com/en-us/evalcenter/evaluate-sql-server-2016. Acesse também da documentação oficial Microsoft sobre a String_Split(): https://msdn.microsoft.com/en-us/library/mt684588.aspx

 


 

Conclusão

Como você pode observar uma das mais esperadas funcionalidades foi adicionada ao SQL Server, a capacidade de fragmentar, dividir, fatiar uma string em pequenas partes ou substrings. Recurso mais que necessário e importante para qualquer desenvolver ou profissional de banco de dados que necessita analisar um texto “string” e através de um caractere denominado separador delimitar como pode ser gerada fragmentos deste texto.

A cada novo build liberado pela Microsoft podemos observar e notar o grande trabalho e esforço que esta sendo feito para transformar o Microsoft SQL Server 2016 na maior e principal versão do produto desde o grande salto dado em 2005 com o lançamento naquele momento da versão 2005.

Funções similares ao String_Split() estão sendo cada vez mais disponibilidades e adicionadas ao produto como forma de fazer com que o SQL Server se torne uma plataforma única de desenvolvimento, administração, armazenamento e gestão de banco de dados, isso representa uma grande evolução e atenção das equipes de desenvolvimento e engenheiros do produto em atender e satisfazer a comunidade técnica que se dedica a estudar e conhecer cada vez mais o SQL Server.

Acredito que os exemplos apresentados aqui conseguir mostrar a simplicidade de se trabalhar com esta nova funcionalidade, ilustrando sua simplicidade no uso e forma de obter os resultados.

Mais uma vez agradeço a sua atenção, seu interesse em visitar o meu blog, espero encontra-lo em outras oportunidades. Deixe seus comentários, críticas e sugestões.

Até a próxima.

Utilizando Backup de Filegroup no SQL Server 2008 – Parte IV

Dica – Utilizando Backup de Filegroup no SQL Server 2008 – Parte IV


Bom dia comunidade,

Estou de volta com mais uma parte da minha série de artigos relacionados a Backup de Filegroup. Neste nossa parte, vou começar a demonstrar como podemos aplicar os backups de filegroup em nosso ambiente. Agradeço a sua visita, tenha uma boa leitura.

Aplicando o Backup de Filegroup

A partir de agora vamos começar a demonstrar como podemos trabalhar com Backup de Filegroups, com base em nosso Banco de Dados SQL. O primeiro passo será a realização de um Backup Database, conforme apresenta a Listagem 7, e ilustrado
através da Figura 8. Este backup full será a base para que nosso ambiente possa ser recuperado em caso de falha e consiste no recurso principal necessário para os processos de restauração de dados, através de um restore de  database, log ou filegroup.

Figura 8. Backup Database SQLMagazine.

Com o backup full realizado, estamos seguros e protegidos contra qualquer eventualidade de falha ou erro em nosso ambiente. Sendo assim, o próximo passo será a realização do tão esperado Backup de Filegroup, onde iremos executar este procedimento para ambos os filegroups, conforme apresenta a Listagem 8.  

Listagem 8. Backup Filegroup – Primary e Secondary

— Bloco 1 —

Backup Database SQL

File = ‘SQL_Dados’,

Filegroup = ‘Primary’

To Disk = ‘C:\SQL\Backup-Primary-SQL.bak’

With Init, NoFormat, Description =’Backup Filegroup Primary’

Go

— Bloco 2 —

Backup Database SQL

File = ‘SQL_Secondary_Dados’,

Filegroup = ‘Secondary’

To Disk = ‘C:\SQL\Backup-Secondary-SQL.bak’

With Init, NoFormat,

Description =’Backup Filegroup Secundário’

Go

Como podemos observar utilizamos o comando Backup Database para realizar o backup do nosso banco de dados e seus respectivos filegroups, para ajudar na entendimento do comando Backup, vou descrever brevemente as opções utilizadas neste
procedimento:
Database: Especifica um backup completo do banco de dados;

File: Especifica o nome do arquivo de dados utilizado no processo de backup;

Filegroup: Especifica o nome do filegroup utilizado no processo de backup;

To Disk: Especifica o caminho fisico em disco rígido, pra o qual o arquivo de backup será armazenado;

Init: Especifica que todos os conjuntos de backup devem ser substituídos, mas preserva o cabeçalho de mídia. Se INIT estiver especificado, qualquer conjunto de backup existente naquele dispositivo será substituído, se as condições permitirem;

NoFormat: Especifica que a operação de backup preserva o cabeçalho da mídia e os conjuntos de backup existentes nos
volumes de mídia usados para esta operação de backup. Esse é o comportamento padrão;

Description: Especifica uma breve descrição para o arquivo de backup, com no máximo 255 caracteres.

O processo de Backup Filegroup é muito simples e prático, ainda mais dependendo do tamanho banco de dados realizado em questão de segundos, como foi o nosso caso. Agora vamos simular uma manipulação desastrosa de objetos, onde nossa principal tabela Produtos, será excluída do nosso ambiente, e através do restauração do Filegroup Primary, iremos recuperar este objeto e todos os seus respectivos dados, conforme apresenta a Listagem 9.

Listagem 9. Recuperando a tabela Produtos através da restauração de Filegroup

— Bloco 1 —

Use Master

Go

Backup Log SQL

To Disk = ‘C:\SQL\Backup-Log-SQL.bak’

With Init, Stats=10,

Description=’Backup Log Database SQL’

Go

Como estamos utilizando o Modelo de Recuperação Completo (Recovery Model Full), torna-se necessário realizar um Backup Log. Este backup tem como finalidade informar ao SQL Server o ponto de liberação para acesso e gravação de dados contidos nos filegroups que compõem nosso banco de dados. Caso este backup não seja restaurado nossos filegroups serão definidos como somente leitura.

— Bloco 2 –

Drop Table Produtos

Agora nossa tabela Produtos foi excluída de nosso ambiente, conforme apresenta a Figura 9. 

Figura 9. Tabela Produtos excluída.

Mas poderemos realizar sua recuperação através do comando Restore, recuperando inicialmente o filegroup Primary e posteriormente liberando os demais filegroups para gravação através do comando Restore Log.

 — Bloco 3 —

Use Master

Go

Restore Database SQL Filegroup = ‘Primary’ From Disk = ‘C:\SQL\Backup-Primary-SQL.bak’

With Partial,  NoRecovery,  Replace

Go

Como iremos realizar a restauração do filegroup Primary e nosso banco de dados possui dois filegroups, será
necessário utilizar a opção Partial, para informar ao SQL Server que a restauração será realizada de forma partial, com base no primeiro filegroup.

A opção NoRecovery, será utilizada para impedir a liberação do banco de dados após seu processo de Restauração. Já a opção Replace, tem como finalidade substituir o conteúdo existem atualmente no banco de dados, pelo conteúdo que esta sendo
restaurado através do Restore.

— Bloco 4 —

Use Mmaster

Go

Restore Log SQL From Disk = ‘C:\SQL\Backup-Log-SQLMagazine.bak’

With Recovery, Replace

Go

Neste outro Restore realizado, informamos o SQL Server para liberar o banco de dados para uso através da opção Recovery, realizando a substituição do conteúdo através da opção Replace.

Pronto nosso filegroup Primary, foi restaurado e nossa tabela Produtos também esta novamente disponível em nosso banco de dados, conforme apresenta a Figura 10.

Figura 10. Tabela Produtos restaurada após restauração do filegroup Primary.

Para verificar se tudo esta certo, podemos realizar uma consulta aos dados armazenados em nossa tabela Produtos, conforme
apresenta a Figura 11.

Figura 11. Consulta aos dados armazenados na tabela Produtos.

Bom mas nem tudo pode ser considerado fácil, aparentemente nosso ambiente esta integro e funcional, mas não é bem assim. Se tentarmos inserir ou consultar dados em uma das tabelas armazenada no filegroup Secondary, recebemos uma mensagem de erro informando que este filegroup encontra-se em offline, conforme apresenta a Figura 12.

Galera, vou encerrar mais esta parte, estamos finalizando este arquivo, nos encontramos nas próximas séries.

Mais uma vez agradeço a sua visita.

Até mais.

%d blogueiros gostam disto: