Sparse File
Os sparse_files é um recurso do NTFS, inicialmente não contem dados. Quando o arquivo é criado, o NTFS gradativamente aloca espaço, sendo assim o arquivo poderá crescer gradualmente dependendo das requisições que forem feitas para o mesmo. Se por acaso o banco de dados estiver sem espaço em disco, e assim for marcado como suspect, então possivelmente excluindo o database snapshot o mesmo possa voltar ao normal. O crescimento do arquivo se da de 64 KB á 64 KB, o último crescimento do arquivo poderá ter de 1 a 8 KB de espaço disponível, dependendo de quantas páginas terão que ser copiadas para o arquivo. O tamanho do arquivo não poderá ultrapassar o tamanho do arquivo .mdf do banco de dados.
Funcionamento
Quando há uma inserção no banco de dados fonte, a página que foi modificada é copiada pelo sistema de copy-on-write (COW) para o database snapshot específico, fazendo assim com que o sparse file comece a crescer.
Quando há alguma operação de leitura que foi requisitada a partir do Database Snapshot, a realização da leitura do dado se dá pelo acesso no banco de dados fonte para as páginas que ainda não foram copiadas para a “Foto” ou seja para as páginas que ainda não foram copiadas para o Snapshot, há nele um ponteiro para a página no banco de dados fonte, por isso que podemos também ter alguns problemas de IO, isso ocorre porque a base terá diversos ponteiros para saber aonde se encontra a página que foi requisitada, sendo assim a requisição poderá ficar prejudicada.
Então quando temos a página que foi solicitada para leitura dentro do Snapshot, não é necessário que a Engine vá ao banco de dados fonte, porque a página está alocada no sparse file do Database Snapshot.
Depois de diversas inserções no database snapshot o sparse file do Database Snapshot ficará muito grande fazendo com que o mesmo tenha aproximadamente o tamanho do banco de dados original
Internamente
Quando há a criação de um database snapshot, é guardado na memória um mapa de bit que indica em nível página, se a página foi alterada ou não, se esse bit estiver marcado então a página original é copiada para o sparse file.
Pensando como a engine do SQL Server, o database snapshot é um novo banco, sendo assim cada banco de dados tem um cache no buffer pool, sendo assim quando a consulta é realizada é necessário que seja feita uma leitura física no disco para que a informação seja retornada
A cópia da página para a “Foto”tem um grande custo de IO, isso se torna um cenário de grande perda de performance.
A rotina de alocação de uma nova página se dá pelo fato de criar e formatar uma página. A primeira ação para alocar uma nova página, é verificar se o banco de dados contem um Database Snapshot, se houver a página anterior será copiada para o sparse file antes de ser inserida uma nova página formatada no banco de dados.
A quantidade de número de páginas lidas de cada banco de dados do buffer pool é informada através da sys.dm_buffer_descriptors, agora como as páginas já estão em cache, então não temos nenhuma leitura física.
Armazenamento do Snapshot em discos diferentes pode aumentar a performance na hora da escrita dentro do arquivo.
Quando há um truncate na tabela ou uma desalocação de página, isso não afeta o armazenamento físico da mesma. A mudança ocorre na GAM, SGAM, IAM…
Ocorrendo um truncate na tabela e fazendo uma pesquisa pelo Snapshot, o mesmo irá buscar o dado do banco de dados fonte, isso ocorre porque a mudança física da página não é realizada, os registros são marcados como alterados porém visualizando pelo snapshot essas páginas não são copiadas, isso evita ter que copiar uma tabela inteira quando ocorre uma operação desse tipo.
Quando não há muitas operações de leitura ocorrendo no servidor, a criação e manutenção dos Snapshots são bastante eficientes, porém se no banco de dados fonte, porém, havendo inúmeras operações de escrita o tempo de criação aumenta. Quanto mais páginas sejam modificadas no banco de dados fonte, maior é o tempo de criação, isso ocorre porque todas as páginas antes de serem modificadas teram que ser movidas para o snapshot.
O impacto de IO ocorre durante a criação de um novo snapshot, porque se houver bastante páginas modificadas no banco de dados fonte o recovery do banco de dado será demorado, porque essa operação contempla undo, redo, analysis e start do banco, antes da operação ser concluída.
As operações de Update e Delete no banco de dados fonte, causam intensivas operações de IO no banco de dados, isso ocorre porque para cada página que é modificada pela primeira vez na fonte, todos os Databases snapshots criados para o banco de dados fonte são tocados.
Fernando L. Veltem edited Original. Comment: adicionado TOC