Opção de restauração de estratégia em espera para arquivo de envio de log por hora

Eu restauro cada arquivo de log transacional como "standby" o tempo todo e apenas os deixo no modo "standby"?

Qualquer um funcionará, mas é mais rápido aplicar todos os logs, exceto o último, usando NORECOVERY. A última aplicada utiliza STANDBY, disponibilizando o banco de dados para acesso somente leitura. O SQL Server precisa fazer um trabalho extra para disponibilizar o banco de dados para leitura em um estado transacionalmente consistente. Em seguida, ele precisa desfazer esse trabalho (usando o arquivo em espera) quando você solicita que ele aplique o próximo backup de log. Resumindo, especificar STANDBYdesnecessariamente pode realmente atrasar as coisas porque você acaba fazendo e desfazendo parte do processo de recuperação (veja o link de Paul Randal abaixo).

No seu caso, isso significaria aplicar 23 backups de log de transações com NORECOVERY, depois o 24º com STANDBY. No dia seguinte, você faz a mesma coisa.

Observe que você precisará garantir que nada esteja conectado ao banco de dados no modo de espera quando for iniciar a próxima sequência de restauração. Isso não deve ser um problema no seu caso, já que você controla todo o acesso ao banco de dados. Se você precisar desconectar outros usuários à força:

ALTER DATABASE DbName 
SET SINGLE_USER 
WITH ROLLBACK IMMEDIATE;

Não se esqueça de disponibilizar o banco de dados para outros usuários novamente mais tarde com:

ALTER DATABASE DbName 
SET MULTI_USER;

Se eu acidentalmente executar um script para restaurar esse banco de dados como modo "NoRecovery or Recovery", existe uma maneira de alterar o modo de volta para "Standby"

Você pode mudar de NORECOVERYpara STANDBYe vice-versa, por exemplo:

-- From norecovery to standby
RESTORE DATABASE DbName
WITH STANDBY = N'C:\StandbyFiles\DbName.sby';

-- From standby to norecovery
RESTORE DATABASE DbName
WITH NORECOVERY;

Você não precisa alterar de STANDBYpara NORECOVERYpara aplicar o próximo conjunto de backups de log.

Uma vez que o banco de dados é recuperado ( WITH RECOVERY), você não pode voltar e deve iniciar toda a sequência de restauração novamente. Você nunca faria isso no seu cenário.

O arquivo em espera será automaticamente excluído (ou reutilizado) na próxima etapa de restauração, mas o SQL Server não bloqueará o arquivo enquanto ele não estiver sendo usado ativamente por um comando de restauração. Trate o arquivo com o mesmo cuidado que você faria com qualquer outro arquivo de banco de dados - se for perdido, o banco de dados também o será.

Recomendo a leitura:

• Relatório de um Log Shipping Secundário no modo STANDBY por Kendra Little.
• Problemas de desempenho de envio de logs por Paul Randal