Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Aplica-se a:SQL Server
Banco de Dados SQL do Azure
Um checkpoint cria um ponto bom conhecido a partir do qual o Motor de Base de Dados SQL Server pode começar a aplicar alterações contidas no log durante a recuperação, após um desligamento ou crash inesperado.
Visão geral
Por razões de desempenho, o Motor de Base de Dados realiza modificações nas páginas da base de dados na memória, no buffer cache, e não escreve essas páginas no disco após cada alteração. Em vez disso, o Motor de Base de Dados emite periodicamente um checkpoint em cada base de dados. Um checkpoint escreve as páginas modificadas em memória atuais (conhecidas como dirty pages) e a informação do registo de transações da memória para o disco, e também regista a informação no registo de transações.
O Motor de Base de Dados suporta vários tipos de pontos de controlo: automáticos, indiretos, manuais e internos. A tabela seguinte resume os tipos de pontos de controlo.
| Nome | Transact-SQL interface | Description |
|---|---|---|
| Automático | EXEC sp_configure 'intervalo de recuperação', 'segundos' | Emitido automaticamente em segundo plano para cumprir o limite máximo de tempo sugerido pela opção de configuração intervalo de recuperação do servidor. Os pontos de controlo automáticos executam-se até serem concluídos. Os checkpoints automáticos são controlados com base no número de escritas pendentes e se o motor da base de dados deteta um aumento na latência de escrita acima de 50 milissegundos. Para mais informações, consulte Configurar a Opção de Intervalo de Recuperação da Configuração do Servidor. |
| Indireto | ALTER BASE DE DADOS ... DEFINIR TARGET_RECOVERY_TIME = target_recovery_time { SEGUNDOS | MINUTOS } | Emitido em segundo plano para cumprir um tempo de recuperação alvo especificado pelo utilizador para uma determinada base de dados. A partir do SQL Server 2016 (13.x), o valor padrão é 1 minuto. O padrão é 0 para versões mais antigas, o que indica que a base de dados usará checkpoints automáticos, cuja frequência depende da definição do intervalo de recuperação da instância do servidor. Para mais informações, consulte Alterar o Tempo de Recuperação Alvo de uma Base de Dados (SQL Server). |
| Manual | POSTO DE CONTROLO [ checkpoint_duration ] | Emitido quando executas um comando Transact-SQL CHECKPOINT. O checkpoint manual ocorre na base de dados associada à sua ligação. Por padrão, os checkpoints manuais executam-se até à conclusão. O throttling funciona da mesma forma que nos checkpoints automáticos. Opcionalmente, o parâmetro checkpoint_duration especifica um tempo solicitado, em segundos, para que o ponto de controlo seja concluído. Para obter mais informações, consulte CHECKPOINT (Transact-SQL). |
| Interno | Nenhum | Emitido por várias operações de servidor, como backup e criação de snapshots de bases de dados, para garantir que as imagens do disco correspondem ao estado atual do registo. |
A opção de instalação avançada do -k SQL Server permite que um administrador de banco de dados limite o comportamento de E/S do ponto de verificação com base na taxa de transferência do subsistema de E/S para alguns tipos de pontos de verificação. A -k opção de configuração aplica-se a postos de controlo automáticos e a quaisquer postos manuais e internos que não sejam limitados.
Para checkpoints automáticos, manuais e internos, apenas modificações feitas após o checkpoint mais recente são aplicadas durante a recuperação da base de dados. Isto reduz o tempo necessário para recuperar uma base de dados.
Importante
Transações de longa duração e não comprometidas aumentam o tempo de recuperação para todos os tipos de pontos de controlo.
Interação da TARGET_RECOVERY_TIME e das opções de 'intervalo de recuperação'
A tabela seguinte resume a interação entre a definição sp_configure 'recovery interval' abrangente do servidor e a definição ALTER DATABASE ... TARGET_RECOVERY_TIME específica da base de dados.
| TEMPO_RECUPERAÇÃO_ALVO | 'Intervalo de recuperação' | Tipo de posto de controlo utilizado |
|---|---|---|
| 0 | 0 | pontos de controlo automáticos cujo intervalo de recuperação do alvo é de 1 minuto. |
| 0 | > 0 | Checkpoints automáticos cujo intervalo alvo de recuperação é especificado pela definição configurada pelo utilizador da opção sp_configure 'recovery interval'. |
| > 0 | Não aplicável | Pontos de controlo indiretos cujo tempo alvo de recuperação é determinado pela definição TARGET_RECOVERY_TIME, expressa em segundos. |
Pontos de verificação automáticos
Um checkpoint automático ocorre cada vez que o número de registos de log atinge o número que o motor de base de dados estima que pode processar durante o tempo especificado na opção de configuração do servidor intervalo de recuperação. Para mais informações, consulte Opção de Configuração do Servidor para o intervalo de recuperação.
Em todas as bases de dados sem um tempo de recuperação alvo definido pelo usuário, o motor de bases de dados gera checkpoints automáticos. A frequência depende da opção de configuração avançada do servidor do intervalo de recuperação , que especifica o tempo máximo que uma dada instância de servidor deve usar para recuperar uma base de dados durante um reinício do sistema. O Motor de Base de Dados estima o número máximo de registos de log que pode processar no intervalo de recuperação. Quando uma base de dados que utiliza checkpoints automáticos atinge este número máximo de registos de log, o Mecanismo de Base de Dados realiza um checkpoint na base de dados.
O intervalo de tempo entre os pontos de controlo automáticos pode ser altamente variável. Uma base de dados com uma carga de trabalho substancial em transações terá pontos de verificação mais frequentes do que uma base de dados usada principalmente para operações de apenas leitura. No modelo simples de recuperação, um ponto de controlo automático também é colocado em fila se o registo estiver 70 por cento cheio.
No modelo de recuperação simples, a menos que algum fator atrase o truncamento do log, um checkpoint automático trunca a secção não utilizada do log de transações. Por outro lado, nos modelos de recuperação completo e em massa registado, uma vez estabelecida uma cadeia de backup de log, os checkpoints automáticos não causam truncagem do log. Para obter mais informações, consulte O log de transações (SQL Server).
Após uma falha do sistema, o tempo necessário para recuperar uma determinada base de dados depende em grande parte da quantidade de I/O aleatórias necessárias para refazer páginas que estavam sujas no momento da falha. Isto significa que a definição do intervalo de recuperação é pouco fiável. Não consegue determinar uma duração precisa da recuperação. Além disso, quando um checkpoint automático está em curso, a atividade geral de I/O para dados aumenta significativamente e de forma imprevisível.
Efeito do intervalo de recuperação no desempenho da recuperação
Para um sistema de processamento de transações online (OLTP) que utiliza transações curtas, o intervalo de recuperação é o principal fator que determina o tempo de recuperação. No entanto, a opção do intervalo de recuperação não afeta o tempo necessário para desfazer uma transação de longa duração. A recuperação de uma base de dados com uma transação de longa duração pode demorar muito mais do que o tempo especificado na definição do intervalo de recuperação .
Por exemplo, se uma transação de longa duração demorasse duas horas a ser atualizada antes de a instância do servidor ser desativada, a recuperação real demora consideravelmente mais tempo do que o valor do intervalo de recuperação para recuperar a transação longa. Para mais informações sobre o impacto de uma transação prolongada no tempo de recuperação, consulte O Registo de Transações (SQL Server). Para obter mais informações sobre o processo de recuperação, consulte Visão geral da restauração e recuperação (SQL Server).
Normalmente, os valores padrão proporcionam um desempenho ótimo de recuperação. No entanto, alterar o intervalo de recuperação pode melhorar o desempenho nas seguintes circunstâncias:
Se a recuperação demora rotineiramente significativamente mais do que 1 minuto quando as transações de longa duração não estão a ser revertidas.
Se reparar que pontos de controlo frequentes estão a prejudicar o desempenho numa base de dados.
Se decidir aumentar a definição do intervalo de recuperação , recomendamos aumentá-la gradualmente em pequenos incrementos e avaliar o efeito de cada aumento incremental no desempenho da recuperação. Esta abordagem é importante porque, à medida que a definição do intervalo de recuperação aumenta, a recuperação da base de dados demora tantas vezes mais tempo a ser concluída. Por exemplo, se alterar o intervalo de recuperação para 10 minutos, a recuperação demora aproximadamente 10 vezes mais a concluir do que quando o intervalo de recuperação está definido para 1 minuto.
Pontos de controlo indiretos
Os checkpoints indiretos, introduzidos no SQL Server 2012 (11.x), fornecem uma alternativa configurável ao nível da base de dados aos checkpoints automáticos. Isto pode ser configurado especificando a opção de configuração da base de dados de tempo de recuperação alvo . Para mais informações, consulte Alterar o Tempo de Recuperação Alvo de uma Base de Dados (SQL Server). Em caso de falha do sistema, os pontos de controlo indiretos proporcionam um tempo de recuperação potencialmente mais rápido e previsível do que os pontos automáticos.
Os pontos de controlo indiretos oferecem as seguintes vantagens:
Os checkpoints indiretos garantem que o número de páginas sujas está abaixo de um determinado limiar, para que a recuperação da base de dados seja concluída dentro do tempo de recuperação previsto.
A opção de configuração do intervalo de recuperação utiliza o número de transacções para determinar o tempo de recuperação, em oposição aos checkpoints indiretos que utilizam o número de páginas sujas. Quando os checkpoints indiretos são ativados numa base de dados que recebe um grande número de operações DML, o gravador em segundo plano pode começar a expulsar agressivamente os buffers sujos para o disco rígido para garantir que o tempo necessário para realizar a recuperação está dentro do tempo de recuperação definido para a base de dados. Isto pode causar atividade adicional de I/O em certos sistemas, o que pode contribuir para um gargalo de desempenho se o subsistema do disco estiver a operar acima ou perto do limiar de I/O.
Os checkpoints indiretos permitem-lhe controlar de forma fiável o tempo de recuperação da base de dados, tendo em conta o custo de I/O aleatória durante o REDO. Isto permite que instância de um servidor se mantenha dentro de um limite superior para os tempos de recuperação de uma base de dados específica (exceto quando uma transação prolongada causa tempos excessivos de reversão).
Os checkpoints indiretos reduzem picos de I/O relacionados com checkpoints ao escreverem continuamente páginas sujas no disco em segundo plano.
No entanto, uma carga de trabalho transacional online numa base de dados configurada para checkpoints indiretos pode sofrer degradação de desempenho. Isto deve-se ao facto de o escritor em segundo plano usado pelo checkpoint indireto por vezes aumentar a carga total de escrita de uma instância de servidor.
Importante
O checkpoint indireto é o comportamento padrão para novas bases de dados criadas no SQL Server 2016 (13.x), incluindo as bases de dados model e tempdb.
Bases de dados que foram atualizadas no local, ou restauradas a partir de uma versão anterior do SQL Server, usarão o comportamento automático de checkpoint anterior, a menos que sejam alteradas explicitamente para optar por checkpoint indireto.
Escalabilidade dos checkpoints indiretos melhorada
Antes do SQL Server 2019 (15.x), pode enfrentar erros de escalonador não responsivo quando há uma base de dados que gera um grande número de páginas sujas, como tempdb. O SQL Server 2019 (15.x) introduz uma escalabilidade melhorada para checkpoints indiretos, o que deverá ajudar a evitar estes erros em bases de dados com uma carga de trabalho pesada UPDATE/INSERT .
Pontos de controlo internos
Os Checkpoints internos são gerados por vários componentes do servidor para garantir que as imagens do disco correspondem ao estado atual do registo. Os pontos de controlo internos são gerados em resposta aos seguintes eventos:
Os ficheiros da base de dados foram adicionados ou removidos usando a ALTER DATABASE.
Um backup de banco de dados é feito.
Um snapshot da base de dados é criado, seja de forma explícita ou interna, para o DBCC CHECKDB.
Uma atividade que requer um desligamento do banco de dados é executada. Por exemplo, AUTO_CLOSE está LIGADO e a última ligação do utilizador à base de dados é encerrada, ou é feita uma alteração na opção da base de dados que exige o reinício da base de dados.
Uma instância de SQL Server é interrompida ao parar o serviço SQL Server (MSSQLSERVER). Esta ação provoca a criação de um checkpoint em cada base de dados na instância do SQL Server.
Colocar uma instância de cluster de failover do SQL Server (FCI) offline.
Próximos passos
- Configurar o intervalo de recuperação Opção de Configuração do Servidor
- Alterar o tempo de recuperação alvo de uma base de dados (SQL Server)
- PONTO DE VERIFICAÇÃO (Transact-SQL)