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)