Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: 
SQL Server
Durante uma troca de funções, o tempo em que o espelhamento da base de dados estará fora de serviço depende do tipo de troca de função e da causa da troca de funções.
Para o failover automático, há dois fatores que contribuem para o tempo durante o qual o serviço fica interrompido: o tempo necessário para o servidor espelho reconhecer que a instância do servidor principal falhou, ou seja, a deteção da falha, mais o tempo necessário para efetuar o failover da base de dados, ou seja, o tempo de failover.
Para uma operação de serviço forçado, embora tenha ocorrido uma falha, a deteção e resposta à falha depende da resposta humana. No entanto, estimar a possível interrupção do serviço limita-se a estimar o tempo que o servidor espelho tem de mudar de função após a emissão do comando de serviço forçado.
Note
Para reduzir o tempo necessário para detetar condições específicas, como alguns tipos de erros, pode definir alertas para essas condições.
Para uma comutação pós-falha manual, apenas o tempo necessário para efetuar a comutação pós-falha da base de dados após a execução do comando de comutação pós-falha.
Deteção de erros
O tempo que o sistema detetaria um erro depende do tipo de erro; por exemplo, um erro de rede é detetado quase instantaneamente, enquanto a notação de um servidor que não responde demora 10 segundos (com o timeout padrão).
Para obter informações sobre erros que podem provocar uma falha durante uma sessão de espelhamento de base de dados e a deteção de tempo limite no modo de alta segurança com failover automático, consulte Possíveis Falhas Durante o Espelhamento da Base de Dados).
Tempo de failover
O tempo de failover consiste principalmente no tempo que o antigo servidor espelho necessita para avançar qualquer registo restante na sua fila de redo, mais um curto tempo adicional (para mais informações sobre como o servidor espelho processa registos de log, veja Espelhamento de Base de Dados (SQL Server)). Para obter informações sobre como estimar o tempo de failover, consulte Taxa de repetição de failover estimada, mais adiante neste tópico.
Importante
Se o failover ocorrer durante uma transação em que um índice ou tabela é criado e depois alterado, o failover pode demorar mais do que o habitual. Por exemplo, o failover durante a seguinte série de operações pode aumentar o tempo de failover: INICIAR TRANSAÇÃO, CREATE INDEX numa tabela, e SELECT INTO na tabela. A possibilidade de aumento do tempo de failover durante tal transação mantém-se até que seja concluída com uma instrução COMMIT TRANSACTION ou ROLLBACK TRANSACTION.
Fila de Refazer
Fazer avançar a base de dados implica aplicar quaisquer registos de log que estejam atualmente na fila de repetição no servidor em espelho. A fila de redo consiste nos registos de registo que foram escritos no disco no servidor espelho mas que ainda não foram encaminhados para a base de dados espelhada.
O tempo de failover da base de dados depende da rapidez com que o servidor espelho consegue avançar o registo na fila de redo, que, por sua vez, é determinada principalmente pelo hardware do sistema e pela carga de trabalho atual. Potencialmente, uma base de dados principal pode ficar tão ocupada que o servidor principal envia o log para o servidor espelho muito mais rapidamente do que consegue avançar o log. Nesta situação, o failover pode demorar um tempo significativo enquanto o servidor espelho avança o log na fila de redo. Para saber o tamanho atual da fila de redo, utilize o contador Redo Queue no objeto de desempenho espelhado da base de dados. Para mais informações, consulte SQL Server, Objeto de Espelhamento de Base de Dados.
Estimativa da Taxa de Reabilitação por Falha
Pode medir o tempo necessário para reaplicar os registos de log — a taxa de repetição — utilizando uma cópia de teste da base de dados de produção.
O método para estimar o tempo de roll forward durante o failover depende do número de threads que o servidor espelho utiliza durante a fase de refazer. O número de threads depende do seguinte:
Na edição SQL Server Standard, o servidor espelho usa sempre um único thread para avançar a base de dados.
Na edição SQL Server Enterprise, servidores espelho em computadores com menos de cinco CPUs também utilizam apenas um único thread. Com cinco ou mais CPUs, um servidor espelho distribui as suas operações de roll forward entre múltiplos threads durante um failover (isto é conhecido como redo paralelo). O redo paralelo está otimizado para usar um thread para cada quatro CPUs.
Estimando a taxa de reexecução numa única thread
Para refazer de thread única, o avanço da base de dados espelhada durante a ativação pós-falha demora aproximadamente o mesmo tempo que o restauro de uma cópia de segurança do registo demora a avançar a mesma quantidade de registo. Para estimar o tempo de failover, crie uma base de dados de teste no ambiente onde pretende executar o espelhamento. Depois faz uma cópia de segurança dos logs da base de dados de produção. Para medir a taxa de redo desse backup de registo, cronometre quanto tempo demora a restaurar o backup de registo WITH NORECOVERY na base de dados de teste.
Depois de conhecer a taxa de repetição do seu servidor espelho, pode estimar o tempo necessário para efetuar a ativação pós-falha da base de dados num determinado momento, dividindo a quantidade atual de registo de transações a repetir no espelho (conforme medido pelo contador de desempenho Redo Queue) pela taxa de repetição. Em condições normais, se o servidor espelho conseguir acompanhar a carga do principal, a Redo Queue é pequena ou próxima de zero, e um failover demora apenas alguns segundos.
Estimativa da Taxa de Repetição Paralela
Na edição Enterprise do SQL Server, o redo paralelo é otimizado para utilizar uma thread por cada quatro CPUs. Para estimar o tempo de roll forward para refazer em paralelo, é mais preciso aceder a um sistema de testes em execução do que a uma base de dados de teste. Ao monitorizar a fila de redo no servidor espelho, aumente a carga no servidor principal. Em condições normais de funcionamento, a fila de redo está próxima de zero. Aumentar a carga no servidor principal até que a fila de redo comece a crescer continuamente; o sistema atinge então a sua taxa máxima de redo, e o contador de desempenho Bytes de redo/segundo, neste ponto, representa a taxa máxima de redo. Para mais informações, consulte SQL Server, Objeto de Espelhamento de Base de Dados.
Estimativa da interrupção de serviço durante o failover automático
A figura seguinte ilustra como a deteção de erros e o tempo de failover contribuem para o tempo total necessário para que um failover automático seja concluído em Partner_B. O failover requer tempo para avançar a base de dados (a fase de refazida) mais um pequeno período de tempo para colocar a base de dados online. A fase de desfazer, que envolve reverter quaisquer transações não comprometidas, ocorre após a nova base de dados principal entrar online e continua após o failover. A base de dados está disponível durante a fase de undo.
