Mark Sowul's questions

Imagine que você criou um login para um grupo local do Windows, por exemplomachine_name\group_name

Você reconstrói o servidor (nova máquina física) com o mesmo nome de máquina ( machine_name), anexa as unidades antigas a ele, incluindo o SQL server. O grupo também foi recriado.

Mas é uma nova instalação de SO. Como tal, o novo machine_name\group_nameterá um novo SID e não funcionará de fato.

Como podemos detectar que o SID do login não é mais válido para sabermos que precisamos recriá-lo?

SELECT SUSER_SID(machine_name\group_name)ainda está retornando o SID antigo (conforme armazenado em sys.server_principals). [sys].[sp_validatelogins]também não relata nada.

Parece que isso SUSER_SIDacontece à sys.server_principalsprimeira vista, então não sabemos como detectar isso.

Estou pensando em aplicar durabilidade atrasada em um sistema em que trabalho e quero ter certeza de que tenho o modelo mental correto para evitar perda de dados. Meu entendimento é que basicamente significa COMMITse transformar em uma espécie de "gato de Schrodinger" entre COMMITe ROLLBACK, certo? Em outras palavras, algumas transações que são confirmadas podem acabar sendo revertidas ("a confirmação é uma mentira").

Portanto, não devemos esperar ver nenhuma perda de dados em cenários como o seguinte:

1. Um procedimento de ativação do service broker que RECEIVEs mensagens, as processa dentro de uma transação e COMMITs. Se "a confirmação for uma mentira" e a transação não for realmente confirmada, será uma reversão e o service broker a executará automaticamente novamente.
2. Um trabalho periódico do tipo ETL que importa arquivos em massa para uma tabela de preparo (essa parte seria totalmente durável). Depois, dentro de uma transação, ele processa os dados encenados e marca os dados encenados como processados. Se "o commit for uma mentira" e a transação não for realmente confirmada, será um rollback e os dados testados não serão marcados como processados, então faremos isso novamente na próxima vez.

Nesses cenários, não esperaríamos perda real de dados porque as transações são executadas novamente automaticamente. Nesse caso, não é mais arriscado do que qualquer outra coisa que possa interromper uma transação (por exemplo, um deadlock ou um desligamento não planejado que interrompa o processo).

Por outro lado, um cenário como o seguinte não seria um bom candidato para durabilidade atrasada e arriscaria a perda de dados:

1. Um processo externo (por exemplo, SSIS), para cada arquivo em um diretório, inicia uma transação, importa em massa os dados do arquivo e confirma a transação. Depois que a transação é confirmada, ele exclui o arquivo. Agora, se "o commit for uma mentira" e a transação não for realmente confirmada, teremos perdido os dados do arquivo para sempre porque excluímos o arquivo, mas a importação foi revertida.

Portanto, em suma, a durabilidade atrasada pode perder dados apenas se alguma parte externa estiver confiando no COMMIT. Por exemplo, um checkout online insere uma venda e assume razoavelmente que, quando os dados foram confirmados, a venda foi concluída etc., e informa o usuário como tal. Mas se for algum processamento que já pode tolerar e retomar automaticamente a partir de interrupções/reversões, não deve haver risco aumentado.

Isso soa certo?