Um instantâneo de banco de dados fornece uma exibição somente leitura de um banco de dados SQL Server que é transacionalmente consistente com o estado do banco de dados de origem no momento em que o instantâneo de banco de dados foi criado. Existem vários motivos para usar instantâneos de banco de dados, por exemplo, relatórios em um banco de dados espelhado, e o DBCC CHECKDB também usa instantâneos de banco de dados internos do SQL Server 2005 em diante.
Os instantâneos de banco de dados também fornecem a capacidade de reverter todas as alterações que ocorreram em um banco de dados desde que o instantâneo do banco de dados foi criado, mas com um efeito colateral desagradável no log de transações do banco de dados sobre o qual Paul postou aqui.
Uma das coisas que geralmente não é considerada ou mostrada em instantâneos de banco de dados é o impacto no desempenho que o instantâneo tem para a carga de trabalho de gravação do banco de dados. A equipe do SQLCAT publicou um whitepaper para o SQL Server 2005, Considerações de desempenho de instantâneos de banco de dados sob cargas de trabalho intensivas de E/S, que investigou os impactos de desempenho de instantâneos de banco de dados e, depois de trabalhar com um cliente recentemente em que instantâneos de banco de dados resultaram em problemas de desempenho, eu queria teste o SQL Server 2012 e determine se houve alguma alteração na sobrecarga dos instantâneos de banco de dados sete anos e três versões do SQL Server posteriores.
Configuração de teste
Para realizar o teste do efeito de instantâneos de banco de dados no desempenho da carga de trabalho de gravação, usei nosso Dell R720 realizando uma inserção de 1.000.000 de linhas em uma nova tabela em uma versão ampliada do banco de dados AdventureWorks2012. O banco de dados AdventureWorks2012 foi criado com 8 arquivos de dados distribuídos em dois SSDs Fusion-io ioDrive Duo de 640 GB que foram configurados como dois discos individuais de 320 GB no Windows, apresentando um total de 4 discos. Para simplificar a explicação da configuração, o layout de armazenamento usado para esses testes é mostrado na tabela abaixo:
| Disco | Configuração | Uso |
|---|---|---|
| K | 15K RAID 5 – 6 discos | Instantâneo |
| L | Fusion-io Card2 – Lado B | Arquivo de registro |
| M | Fusion-io Card2 – Lado A | 4 arquivos de dados |
| N | Fusion-io Card1 – Lado A | 4 arquivos de dados |
| P | Fusion-io Card1 – Lado B | Tempdb |
| R | LSI Nytro BLP4-1600 | Instantâneo |
Tabela 1 – Layout e uso do disco do servidor
O armazenamento para o instantâneo do banco de dados era uma matriz RAID-5 de seis unidades SAS de 15k RPM conectadas por meio de iSCSI ou uma placa PCI-E LSI Nytro BLP4-1600.
A carga de trabalho de teste usou a seguinte instrução SELECT INTO para gerar uma tabela de 1.000.000 linhas que foi descartada entre cada um dos testes.
SELECT TOP 1000000 * INTO tmp_SalesOrderHeader FROM Sales.SalesOrderHeaderEnlarged;
Os testes foram cronometrados para medir a duração sem um instantâneo de banco de dados e, em seguida, a duração com um instantâneo de banco de dados criado em cada um dos dispositivos de armazenamento para medir a degradação de desempenho causada pela gravação de alterações de página no arquivo esparso de instantâneo de banco de dados. Os testes também foram executados usando dois instantâneos de banco de dados no mesmo dispositivo de armazenamento para verificar qual poderia ser a sobrecarga de ter instantâneos de banco de dados adicionais para as operações de gravação duplicadas que potencialmente precisam ser executadas.
Resultados
Cada configuração de teste foi executada dez vezes e a duração média, convertida de milissegundos para segundos para facilitar a visualização, é mostrada na Figura 1, para 0, 1 ou 2 snapshots de banco de dados.
Figura 1 – Duração do instantâneo
Os testes de linha de base sem instantâneos de banco de dados executados em média em 1,8 segundos e, mesmo quando o armazenamento para os arquivos de instantâneos de banco de dados era equivalente em desempenho, a existência de um único instantâneo de banco de dados impunha sobrecarga ao desempenho de gravação do banco de dados. A sobrecarga do segundo instantâneo de banco de dados é menor do que ter o primeiro instantâneo de banco de dados em cada um dos testes, embora os discos de 15.000 RPM tenham tido muito mais dificuldade em acompanhar a carga de trabalho de gravação adicionada do segundo instantâneo de banco de dados para o banco de dados.
O desempenho da placa LSI Nytro inicialmente me surpreendeu, pois também era um SSD PCI-X. No entanto, depois de discutir os resultados com Glenn, ele mencionou que a compactação do controlador Sandforce e o desempenho de gravação mais lento para dados aleatórios e de baixa compactação de seus testes anteriores na unidade. No entanto, ainda superou facilmente a mídia giratória.
Antes de executar os testes, eu estava interessado em saber quais tipos de espera ocorreriam durante os testes, então, como parte da configuração do teste, limpei sys.dm_os_wait_stats com DBCC SQLPERF e capturei a saída do DMV para cada teste executado em uma tabela. As principais esperas para as configurações de instantâneo único foram PREEMPTIVE_OS_WRITEFILE e WRITE_COMPLETION, conforme mostrado na Figura 2, para 1 ou 2 instantâneos de banco de dados.
Figura 2 – Principais esperas do instantâneo
Um dos itens interessantes foi a adição de esperas FCB_REPLICA_WRITE quando um segundo snapshot foi criado. Depois de revisar os resultados de espera de instantâneo de banco de dados único e executar novamente algumas rodadas de testes, essa espera nunca ocorre para um único instantâneo e ocorre apenas quando existe mais de um instantâneo e está associado à cópia das páginas nos arquivos de instantâneo de banco de dados. Os tempos de espera para as esperas PREEMPTIVE_OS_WRITEFILE tendem a se aproximar dos aumentos na duração da execução para cada uma das configurações.
Com esses resultados em mente, ao revisar um sistema usando a metodologia Waits and Queues, ver esse tipo de espera com valores mais altos pode valer a pena investigar se existem ou não instantâneos de banco de dados para qualquer um dos bancos de dados no servidor.
Conclusão
Ao usar instantâneos de banco de dados, mesmo no SQL Server 2012, há uma sobrecarga associada às gravações adicionais necessárias para copiar páginas de dados para os arquivos esparsos dos instantâneos. Se o uso de instantâneos de banco de dados fizer parte de sua configuração geral, eu realmente teria cuidado ao planejar o subsistema de E/S para atender aos requisitos de carga de trabalho para atividade de E/S simultânea para os arquivos esparsos de instantâneo de banco de dados.
A partir dos resultados desses testes, eu consideraria colocar instantâneos de banco de dados em SSDs à frente do tempdb para o desempenho de gravação e também para menor impacto no desempenho da manutenção do instantâneo.
Como sempre, sua milhagem pode variar e você certamente desejará testar o desempenho de qualquer configuração antes de colocá-la em uso em produção.
