Alterações de esquema do SQL Server 2014 no ambiente multiusuário 24/7

Temos o SQL Server 2014 Enterprise instalado para executar um banco de dados que deve estar disponível 24/7. Nosso banco de dados é grande o suficiente (200gb +). Também temos muitos serviços que acessam nosso banco de dados a cada minuto para ler, atualizar ou inserir novos dados. Queremos fornecer um recurso de reimplementação "quente" para nossos clientes e tornar nossas atualizações diárias (atualizações de .net e esquema) transparentes para os clientes. Encontramos uma solução baseada em cluster com balanceador de carga para atualizar os binários de nosso aplicativo, mas ainda temos alguns equívocos sobre o processo de implantação de atualizações de banco de dados e quais são as melhores práticas para resolver esse problema.

Para alterações de esquema, reduza um servidor, aplique alterações de esquema, traga-o de volta e aplique as mesmas alterações na segunda instância. Isso pode ser feito com as ferramentas do SQL Server e essa é uma abordagem comum? Como sincronizar dados após o backup do servidor? Ou estou pensando completamente na direção errada e existem soluções melhores?

Nossas alterações de esquema comuns: adicionar / soltar coluna, adicionar / excluir procedimento armazenado

Abaixo, será necessário um pouco mais de planejamento e teste.

Conceito azul esverdeado:

A essência do Blue-Green Concept é dividir sua produção em 2 ambientes e eles são idênticos o tempo todo (sincronização de dados) em que

1. O azul (atual) terá a versão atual do esquema / build ou produto e será o seu ambiente "LIVE".

2. Ao mesmo tempo, Green será o seu ambiente de teste / teste, no qual você atualizará seu esquema / build ou produto para a próxima versão, fará um teste de regressão completo e será assinado pelos usuários de negócios. Quando estiver satisfeito, durante um período de interrupção, você promoverá o Green para ser o seu ambiente "LIVE" e rebaixará o Blue para ser uma pré-produção / preparação ou teste para o próximo lançamento.

Dessa forma, você tem muito menos tempo de inatividade e o risco de falha de implantação em um sistema ativo (que está na janela de manutenção, desde que você está fazendo a atualização) será altamente minimizado. Além disso, seguindo a abordagem azul esverdeado, você estará oscilando entre as versões LIVE e PREVIOUS, que serão preparadas para a próxima versão.

Novamente, isso exigirá mais hardware / licenciamento, além de planejamento e teste.

A maioria das etapas pode ser automatizada usando DACPACs e PowerShell. Além disso, se você estiver instalando várias instâncias em um servidor, certifique-se de reequilibrar as configurações de memória ao alternar entre azul e verde. O ambiente LIVE obtém mais memória que o ambiente passivo.

No meu ambiente atual, implementamos o Modelo Azul / Verde para Implantação Ágil de Código, que nos permite promover o código a cada 2 semanas, com bastante tempo para testes e aprovação comercial. Além disso, é muito fácil reverter caso algo dê terrivelmente errado. Automatizamos a maioria das coisas de implantação usando Dacpacs e PowerShell.

(Fonte da imagem)

Consulte também o artigo de Grant Fritchey sobre solução de problemas de reversão e recuperação; Desafios e Estratégias

Se seu banco de dados não for replicado, adicione e solte colunas serão executadas muito rapidamente. Como adicionar coluna é apenas uma posição vazia que o SQL cria. A coluna Soltar apaga a referência.

Caso contrário, se houver alguma restrição ou índice, tenha cuidado.

ADD/DELETEprocedimentos só terão efeito na própria execução. A recomendação é antes de qualquer alteração executar a recompilação

sp_recompile 'myproc'