Pelo que entendi, o SQL Server gera arquivos de desfazer ao aplicar uma restauração em um banco de dados usando o RESTORE WITH STANDBY.
Da documentação do MSDN (ênfase minha):
O arquivo de espera é usado para manter uma pré-imagem "copy-on-write" para páginas modificadas durante a passagem de desfazerde um RESTAURAR COM STANDBY. O arquivo de espera permite que um banco de dados seja ativado para acesso somente leitura entre restaurações de log de transações e pode ser usado com situações de servidor de espera passiva ou situações de recuperação especiais nas quais é útil inspecionar o banco de dados entre restaurações de log. Após uma operação RESTORE WITH STANDBY, o arquivo de desfazer é excluído automaticamente pela próxima operação RESTORE. Se esse arquivo de espera for excluído manualmente antes da próxima operação RESTORE, todo o banco de dados deverá ser restaurado novamente. Enquanto o banco de dados estiver no estado STANDBY, você deve tratar esse arquivo de espera com o mesmo cuidado que qualquer outro arquivo de banco de dados. Ao contrário de outros arquivos de banco de dados, esse arquivo só é mantido aberto pelo Mecanismo de Banco de Dados durante operações de restauração ativas.
O standby_file_name especifica um arquivo de espera cuja localização é armazenada no log do banco de dados. Se um arquivo existente estiver usando o nome especificado, o arquivo será substituído; caso contrário, o Mecanismo de Banco de Dados criará o arquivo.
O requisito de tamanho de um determinado arquivo em espera depende do volume de ações de desfazer resultantes de transações não confirmadas durante a operação de restauração.
Qual é a passagem de desfazer referida no início?
Pelo que entendi, essas são as operações escritas no arquivo de log que não foram confirmadas. Se estiver correto, por que essas operações estão no arquivo de log se não foram confirmadas em primeiro lugar e por que a operação RESTORE WITH STANDBY precisa armazená-las em algum lugar para poder trazer o banco de dados para somente leitura acesso (em outras palavras, por que eles não podem simplesmente ser jogados fora)?
Todas as operações, confirmadas ou não confirmadas, são gravadas no log. Um commit garante que todas as entradas de log sejam duráveis (liberadas para o disco), mas nada impede que as entradas não confirmadas sejam liberadas antes disso (porque um bloco de log é preenchido ou porque outra transação é confirmada, forçando assim a liberação para cada transação). Um rollback deve analisar todas as entradas da transação e gerar ações de compensação (para cada inserção faça uma exclusão, para cada exclusão faça uma inserção, para cada atualização faça uma atualização que reverta os dados). Essas ações de compensação são, obviamente, registradas.
Quando um banco de dados é recuperado, ele deve reverter qualquer transação que não esteja confirmada no log. Ele deve, portanto, analisar o log, descobrir as transações não confirmadas e, em seguida, gerar ações de compensação para todas as ações pertencentes a transações não confirmadas. A recuperação online gravará as ações de compensação no próprio log. A recuperação em espera gravará as ações de compensação em um fluxo alternativo, permitindo assim que mais logs sejam aplicados a partir de uma fonte 'mestre' posteriormente (é assim que o acesso somente leitura em espera de envio de logs funciona).
Antes de fazer qualquer pergunta de esclarecimento, leia ARIES: Um método de recuperação de transação com suporte para bloqueio de granularidade fina e reversões parciais usando o log Write-Ahead .
A passagem de desfazer é necessária para reverter quaisquer páginas sujas de transações em andamento que foram liberadas para o disco por uma operação de ponto de verificação.
Um ponto de verificação grava TODAS as páginas sujas do cache do buffer no disco, independentemente de a transação que as gerou ter sido confirmada ou não. Os pontos de verificação e a parte ativa do log cobrem os detalhes sangrentos.
Restaurar WITH STANDBY permite colocar o banco de dados em um estado somente leitura entre restaurações (como sua citação menciona). Para que o banco de dados esteja em um estado transacionalmente consistente, a passagem de desfazer deve ser executada. Para continuar outras restaurações (que é o objetivo do standby), as páginas que foram modificadas pelo UNDO precisarão ser reaplicadas, daí a necessidade de armazená-las no arquivo standby.