Por que preciso fazer backup de um log de transações duas vezes para que ele seja reduzido?

Esta pergunta foi tentada duas vezes na troca de especialistas sem resposta real.

Eu sei que não devo reduzir o arquivo de log - essa não é a questão.

Se você sentir vontade de responder que não se deve fazê-lo - isso foi confirmado muitas vezes sim e não é o objetivo desta pergunta.

Definir como backup simples também não é uma opção.

Isso tem me incomodado há anos - o fato de que agora sei por que deveria ser feito backup duas vezes.

Recentemente, vi o primeiro arquivo de log que foi capaz de encolher todas as vezes na primeira tentativa - era inacreditável. Perguntei ao cara sobre isso e tudo o que consegui entender foi "reorganizar antes de liberar" - não sei a que ele estava se referindo. Não estou conseguindo entrar em contato com ele novamente.

Eu sei disso pelas postagens existentes no EE: "A redução remove partes inativas do log. Para ficar inativo, o log deve ser truncado, o que ocorre como parte do backup do log.

No entanto, o log de transações é composto de muitos arquivos de log virtuais que são usados ​​de forma round robin. Somente os logs virtuais no final do arquivo podem ser removidos, portanto, se o SQL Server estiver usando o último log virtual, nada poderá ser removido. A correção antiga no sql 7 era executar um script que executasse transações fictícias suficientes para preencher o log e envolver o ponteiro no primeiro log virtual (você ainda pode usar esse método, se preferir).
http://support.microsoft.com/kb/256650/EN-US

DBCC agora faz isso para você, mas ainda requer a etapa extra de truncar o log novamente para que o espaço inativo possa ser excluído"

De outro usuário: "Tudo o que eu precisava fazer era descontinuar a otimização automatizada e as verificações de integridade que o último administrador deixou nos planos de manutenção do banco de dados".