Isso está relacionado a um cenário de reversão de uma atualização de 2012 -> 2016.
O cenário é que o banco de dados SQL Server 2012 seja restaurado em 2016 e os arquivos de log sejam aplicados até que esteja atualizado. Em seguida, os sistemas de produção são cortados para 2016. O banco de dados é mantido no nível de compatibilidade para 2012. Subsequentemente, os logs incrementais da instância de 2016 são mantidos até a necessidade de reverter (digamos, 8 horas).
Os logs agora podem ser aplicados à instância do SQL Server 2012 para atualizá-la?
Não, não poderemos fazer isso. Isso ocorre porque a estrutura interna do arquivo é diferente.
Você pode usar ferramentas de terceiros como SQL Compare e SQL Data Compare para fazer "diffing" entre sua origem e destino, gerar scripts de atualização a partir dessas diferenças e, em seguida, executar esses scripts na plataforma de destino; isso funciona em diferentes versões do SQL Server.
Eu espero que isso ajude
Assim que você colocar o banco de dados online no SQL Server 2016, o banco de dados será atualizado para o formato 2016 e não será mais compatível com o SQL Server 2012. Essas alterações são operações totalmente registradas e estarão contidas em seus logs de transações.
O primeiro backup de log de transações feito no SQL Server 2016 conterá as etapas de atualização de script para trazer o banco de dados de 2012 (110) para 2016 (130). Se você tentar aplicar esse primeiro backup do log de transações à sua cópia do banco de dados no SQL Server 2012, ele falhará.
Não há como fazer backup/restauração (incluindo backups de log) para uma versão inferior.
Se você precisar reverter, precisará sincronizar dados "manualmente" - usando scripts personalizados ou uma ferramenta como o Red Gate SQL Data Compare.
Geralmente, minha preferência é não liberar o sistema para uso "público" até depois de fazer os testes básicos. Se surgirem problemas durante os testes de fumaça, você pode reverter sem precisar sincronizar os dados de volta para a versão inferior. Se os problemas surgirem mais tarde, depois que os testes de fumaça forem aprovados e depois que os usuários forem autorizados a voltar ao sistema - você se compromete a avançar e corrigir o problema, em vez de tentar reverter.
Infelizmente não. O SQL Server é como uma viagem no tempo: você não pode voltar atrás.