Temos um cenário em que queremos alterar o agrupamento de nosso banco de dados de produção (incluindo colunas) de SQL_Scandinavian_Pref_CP850_CI_AS para Finnish_Swedish_CI_AS. Desenvolvemos scripts para isso. Mas executar esse script em um banco de dados grande com mais de 100 GB levará um tempo considerável e não podemos nos dar ao luxo de ficar muito tempo inativo. Então decidimos reduzir esse tempo de inatividade usando a estratégia abaixo:
- Vamos configurar a Replicação Transacional e inicializar o assinante usando o método de backup do banco de dados.
- O banco de dados do editor estará ativo com o aplicativo e suas transações serão entregues ao banco de dados do assinante por meio da Replicação Transacional.
- Executaremos o Collation Change Script no lado do assinante e ele nos permite executar esse script quando o SQL Server for o mesmo para bancos de dados do editor e do assinante. Recentemente, encontramos isso no SQL Server 2019.
- Agora, o problema é que não está replicando corretamente os dados da coluna varchar, char quando ela contém caracteres especiais como 'åÅäÄöÖ'. Do lado do assinante, estamos recebendo personagens estranhos como '†„Ž”™'
Você pode sugerir como podemos resolver esse bug ou qualquer arquitetura alternativa para minimizar o tempo de inatividade na produção ao alterar o agrupamento do banco de dados (incluindo colunas)?
Além disso, meu script de alteração de agrupamento está realizando as seguintes tarefas no banco de dados do assinante para alterar seu agrupamento:
- Descartar restrições de chave estrangeira
- Índices de descarte, incluindo chave primária
- Verificação de descarte e restrições padrão
- Eliminar estatísticas do usuário
- Solte visualizações, colunas computadas, SPs para resolver bugs vinculados a objetos
- Após a execução das etapas acima, as Tabelas estão prontas para alteração de agrupamento. Portanto, o script alterará os agrupamentos das colunas de cada tabela, um por um.
- Recrie as restrições listadas acima após a execução bem-sucedida da etapa 6.
Acabei de tentar isso e funcionou na replicação transacional:
A configuração acima forneceu dados corretos do banco de dados do lado do editor para o banco de dados do lado do assinante. Seu agrupamento em nível de coluna é alterado, o que leva tempo e depende de quantos dados a tabela contém. A alteração de agrupamento no nível do banco de dados pode ser gerenciada no tempo de inatividade simplesmente descartando as dependências primeiro e recriando-as. Portanto, é o agrupamento no nível do banco de dados que estava causando esse problema de dados, quando era diferente, não o agrupamento no nível da coluna.