MCDBA Brasil


  • Home
  • Sobre
  • Contato

Livros





Links Rápidos

SQL Server Builds (All Versions/Editions)


Download SQL Server 2017 (trial)


SQL Server 2017 Feature Pack


SQL Server 2016 Feature Pack


Cumulative Update SQL Server 2017 builds


Cumulative Update SQL Server 2016 builds


Cumulative Update SQL Server 2014 builds


Cumulative Update SQL Server 2012 builds


SQL Server 2005/2008 Samples Databases


Documentando o Servidor SQL Server


Analisando a Performance do Servidor-CheckList


Virtual PASS PT


Faça parte do maior virtual chapter do PASS com conteúdos técnicos em Português sobre SQL Server.

Todos os meses um evento Online para você! Acompanhe aqui os WebCasts já agendados

Sindicalize seu blog ou site ao VirtualPASSPT

SQL Server Blogs

SQL Server Query Processing Team


SQL Programmability & API Development Team


SQL Server Manageability Team


Latin America Support Team


Database + Disk + Performance


Microsoft SQL Server Support


SQL CLR Team


SQL Query Optimization Team


SQL 2005 Code Samples


SQL Server Express Team


SQL SMO Samples


SQL Storage Engine Team


SQL CAT Team


SQL Protocols Team


PSS SQL Server Engineers


Slava Oks on SQLOS


Ken Henderson’s blog


LUTI@Microsoft Blog


kimberly L. Trip’s blog


Fernando Garcia Blog

Artigos

Utilizando Database Snapshots no SQL Server 2005

por Nilton Pinheiro fevereiro 21, 2012 Nenhum comentário

Bem, para utilizarmos o Database Snapshot primeiro precisamos entender como ele funciona. O database snapshot provê uma “visão” apenas de leitura do database que o originou, retirando apenas as transações que não foram confirmadas (commited). Pense no database snapshot como sendo uma fotografia do banco de dados no instante em que ela foi batida.

Os database snapshot por ser o que eu costumo chamar de “fortemente acoplados” ou dependente do database que lhe deu origem, ele não pode ser criado em outra instância do SQL Server, bem como, caso aconteça qualquer problema no database que o originou, este também fica indisponível.

O database snapshot foi criado tendo como principal objetivo ser utilizado para recursos de relatórios, uma vez que este fica disponível como um banco de dados readonly, no entando, também podemos utilizá-lo para retornar o status de um “registro” ao momento que o snapshot foi gerado. Isso pode ser feito de duas maneiras: acessando a tabela afetada no banco snapshot e transferindo os registros afetados para a tabela no banco de produção ou ainda voltando um restore do banco snashot sobre o banco de produção. Neste último caso, o banco de produção voltará ao estado que estava no momento em que o snapshot foi criado, ou seja, tudo que foi feito após a criação do snapshot será literalmente perdido.


Databases Snapshots trabalham no nível de “data page”, ou seja, antes da página ser modificada esta é copiada para o snapshot. Este processo é chamado de “copy-on-write operation”. Sendo assim preservamos uma versão da “data page”, antes dessa ser alterada. Com isso, caso tenhamos problemas, podemos retornar o registro ao status anterior ao ser alterado no database que originou o snapshot.


O processo de “copy-on write” utiliza sparse files que pode ser um ou mais, este arquivo definimos no momento que criamos o database snapshot. Sparse Files é uma feature do NTFS, inicialmente ele não possui dados e o espaço em disco para os dados não é alocado.


Nota: Databases Snapshots não podem ser definidos para Log Files, apenas para Data Files.


A figura acima ilustra como funciona o processo de “copy-on-write”. Observe que no momento em que a página é atualizada, sua versão original é copiada para o sparse file. Com isto o sparse file tende a ficar com um tamanho pequeno, pois armazena apenas as páginas que foram alteradas. Entretanto, caso o database tenha diversas alterações o sparse file tende a ficar maior.


Como explanamos acima, o database snapshot trabalha no nível de “data page”, com isto não é possível realizarmos alterações neste, pois sempre acessamos as “data pages” originais, porém quando essas “data pages” são alteradas acessamos a versão salva no database snapshot ou seja no sparse file.


Dica: Para melhorar a performance do database snapshot, podemos alocá-lo em outro conjunto de discos, separando assim as operações de I/O do database original.


Exemplo:


Para um melhor entendimento, vamos a um exemplo prático. Neste exemplo demonstro como criar e utilizar o Database Snapshot criado sobre o banco de dados de exemplo do SQL Server 2005, o AdventureWorks. O script abaixo cria o snapshot de nome AdventureWorks_TestDBSnapshot. Observe que a sintaxe é semelhante à da criação de um banco de dados, porém utilizamos a opção AS SNAPSHOT OF.


USE AdventureWorks;
CREATE DATABASE AdventureWorks_TestDBSnapshot
ON (NAME=’AdventureWorks_TestData’, FILENAME=’D:ArtigosLabsAdventureWorks_TestData.MDF’)
AS SNAPSHOT OF AdventureWorks;


Após executarmos o comando acima, podemos visualizar o snapshot em Management Studio -> Databases -> Database Snapshots.


Nota: Um database pode possuir um ou mais database snapshots, porém cada um deste reflete o momento em que foi criado.


Antes:


Agora vamos realizar um teste de leitura dos dados antes e após alterarmos um registro. Quando executamos um SELECT no database snapshot que acabamos de criar, este fará a leitura das mesmas “data pages” da origem. Isso porque como as páginas que contém estes dados ainda não foram alteradas, o SQL Server acaba indo buscar os dados no database de origem.



Depois:


Agora vamos atualizar esse mesmo registro no database de origem AdventureWorks e em seguida comparar os resultados em ambos. O exemplo altera a cidade do AddressID 1 para “Rio de Janeiro”.


Veja na figura acima que no database de origem AdventureWorks o registro foi alterado com êxito. Ao executar o mesmo SELECT no database Snapshot AdventureWorks_TestDBSnapshot, notará que este mantém os dados originais.




Na figura acima podemos constatar que o registro não foi alterado no snapshot ou seja para este registro passamos a acessar a “data page” que foi copiada para o sparse file.


Limitações


O database snapshot tem algumas limitações, aqui descrevo algumas dessas:
– Database Snapshot é suportado apenas na versão Enterprise Edition do SQL Server 2005;
– Database Snapshots não podem ser criados em partições diferentes de NTFS;
– Não é possível criarmos DB Snapshot dos databases de sistema;
– A performance relativa a I/O do banco de origem é reduzida.


Database mirroring com Database Snapshot


Database mirroring trata-se de uma nova feature do SQL Server 2005, que consiste em fazer um mirror do database em outro servidor.


Algumas da vantagens do mirroring são:
– Fail over rápido em torno de 3 segundos dependendo da sua configuração;
– É configurado por database e não uma instância toda como no Cluster.


Para mais informações sobre Database Mirroring veja o artigo Configurando Database Mirroring no SQL Server 2005

Podemos utilizar database snapshot com database mirroring ou seja no mirror podemos criar um database snapshot para tornarmos disponível o database que compões o mirror.


Exemplo:


CREATE DATABASE AdventureWorks_TestDBSnapshot
ON (NAME=’AdventureWorks_Data’,
 FILENAME=’D:ArtigosLabsAdventureWorks_TestDBSnapshot.MDF’)
AS SNAPSHOT OF AdventureWorks


Verifique que mesmo quando não conseguimos acessar o mirror, através do database snapshot temos acesso de leitura nos dados. Mantendo o funcionamento do mirroring, bem como as mesmas premissas do database snapshot.


Bibliografia


Algumas figuras utilizadas neste artigo foram retiradas do Books Online do SQL Server 2005.
Para maiores informações consulte no BOL:
– How Database Snapshots Work
– Understanding Sparse Files in Database Snapshots
– Limitations on Database Snapshots


Abraços e até a próxima!
Rodrigo Fernandes (RFernandes)

Avaliação:
Compartilhe:
  • Anterior SQL Server 2012 Active/Active Cluster in Hyper-V9 anos atrás
  • Próximo Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster9 anos atrás

Deixe uma resposta Cancelar resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

MVP Reconnect Award

Categorias

  • Artigos (359)
  • Dica da Semana (95)
  • Documentação (54)
  • Downloads (113)
  • MSDE 2000 (3)
  • Sem categoria (1)
  • Tutoriais (9)

Posts recentes

  • #FechouBrasil #PartiuPortugal
  • Brigando com o erro “The cached MSI file is missing”
  • MCDBABRASIL está de volta
  • Documentando o Servidor SQL Server
  • Brigando com os Erros 17182, 17826 e 17120

SQL Server AlwaysOn Video Series

Video1: Introdução ao SQLServer2012 AlwaysOn


Video2: Introdução ao SQLServer2012 AlwaysOn Availability Group


Video3: Introdução ao SQLServer2012 AlwaysOn AVG-Demo


Video4: Introdução ao SQLServer2012 AlwaysOn Listener


Video5: Introdução ao SQLServer2012 AlwaysOn Readable Secondaries


Video6: Introdução ao SQLServer2012 AlwaysOn Readable Secondaries-Demo


Video7: Introdução ao SQLServer2012 AlwaysOn Failover Clustering


Serie SQL Server Failover Clustering End-to-End

Parte 1: Configuração da Rede e Ambiente


Parte 2: Configurando o Windows 2008 R2 Domain Controler e DNS


Parte 3: Preparando os nós para o Failover Cluster


Parte 4: Configurando um Failover Cluster de 2 nós


Parte 5: Configurando as LUNs no iSCSI Software Target (Parte 1)


Parte 6: Configurando as LUNs no iSCSI Software Target (Parte 2)


Parte 7: Apresentando as LUNs para os nós do Failover Cluster


Parte 8: Configurando os discos no Failover Cluster


Parte 9: Instalando a primeira instância virtual do SQL Server 2008


Parte 10: Instalando a segunda instância virtual do SQL Server 2008


Parte 11: Instalando e Configurando o MSDTC no Failover Cluster


Parte 12: Configurando Mount Points no Cluster e SQL Server 2008


Vídeo Extra: Removendo uma Instância do SQL Server 2008 R2 em Cluster


Alta Disponibilidade no SQL Server 2008 R2: Failover Clustering Overview


Alta Disponibilidade no SQL Server 2008 R2: Failover Clustering na Prática

Menu

  • Home
  • Sobre
  • Contato

Mais

  • RSS Feeds
2021 MCDBA Brasil.