Início / dba / Perguntas / 14279
Accepted
Chris Aldrich
Asked: 2012-03-03 07:23:48 +0800 CST

Práticas recomendadas para gerenciamento de mudanças com índices

  • 772

Nossa loja de TI está começando a construir um grupo de DBA's. Todos nós (inclusive eu) viemos do mundo do desenvolvimento de aplicativos/arquitetura, então o mundo DBA ainda é relativamente novo para nós.

Juntamente com a construção de um grupo de DBA, estamos procurando criar procedimentos e processos de gerenciamento de mudanças (esperançosamente baseados nas melhores práticas) para quando precisarmos mover mudanças.

Encontrei a postagem a seguir que é útil principalmente para alterações de gatilho, procedimento armazenado e/ou DDL. Mas não aborda necessariamente índices ou bancos de dados de fornecedores.

Temos uma mistura de bancos de dados próprios e de fornecedores. Em nosso caso, alguns dos fornecedores (embora não todos) estão trabalhando com nossa empresa para construir o(s) banco(s) de dados e aplicativos. Estamos no processo de teste de desempenho de nossos aplicativos agora, antes que eles "entrem no ar". Assim, estamos analisando os índices (ou a falta deles) bastante.

À medida que nos deparamos com índices que achamos que deveriam ser feitos, como lidamos melhor com o gerenciamento de mudanças em relação a eles, tanto para nossos próprios bancos de dados quanto para quaisquer fornecedores?

O que você faz na sua loja? Estou menos preocupado com as ferramentas do que com o processo.

EDIT: Até agora, estou apreciando o feedback, comentários e respostas para esta pergunta. Percebi que algumas das respostas são um pouco específicas da ferramenta. Estou procurando práticas mais "agnósticas", se possível.

No entanto, se o agnóstico não for possível, para conjuntos de ferramentas, usamos principalmente o IBM DB2 LUW (e, na verdade, no AIX). Temos algum DB2 no Windows e DB2 para i (IBM's i5/OS), mas somos principalmente AIX DB2. Nós usamos o controle de origem, especificamente o Subversion.

Novamente, procurando as melhores práticas gerais, mas acima está o que usamos que seria específico do fornecedor.

EDIT: Decisão atual: Pretendemos acompanhar nosso raciocínio, bem como nossas mudanças. Então, vamos abrir um problema em nosso software de rastreamento de problemas (que no nosso caso é o JIRA). Agora podemos adicionar documentação sobre a prioridade da mudança, dados que respaldam qual deve ser a mudança, a mudança e os resultados da mudança de outro ambiente onde a mudança foi testada.

Também pretendemos acompanhar nossas alterações nos scripts no SVN (como foi sugerido abaixo). Dessa forma, podemos rastrear qual versão do que existe onde. Isso pode ser registrado em nosso problema do JIRA (e em qualquer outro software de auditoria que usamos, ou seja, links colados). Podemos saber com mais certeza que mudança ocorreu em qual ambiente e por quê. Também podemos rastrear se o índice foi algo que adicionamos além da implementação dos fornecedores ou antes de sua implementação, etc.)

best-practices index

3 respostas

  1. Best Answer

    Eu recomendo fortemente que você trate seu banco de dados basicamente da mesma maneira que você trata o código de seu aplicativo. Você pode fazer o script de seu banco de dados para suas partes componentes e verificá-las no controle de origem e, em seguida, usar os mesmos rótulos e versões que você usa para seus aplicativos.

    Para obter os objetos no controle de origem, há várias ferramentas que você pode usar. A Microsoft tem uma ferramenta que é apelidada de Data Dude. Funciona com o Visual Studio. Eles também estão se preparando para lançar uma nova ferramenta chamada SQL Server Database Tools (SSDT), novamente trabalhando com o Visual Studio. Minha empresa, Red Gate Software, faz uma ferramenta que funciona com SSMS chamada SQL Source Control.

    Em termos de processo, escrevi vários capítulos para o livro Red Gate Guide to Team Development . Está disponível para download gratuito (ou se você quiser matar uma árvore, pode comprá-la na Amazon). Eu entro em muito mais detalhes sobre como trabalhar com bancos de dados em equipes de desenvolvimento lá.

    • 11

    1. Mantemos scripts de banco de dados como parte de nossa base de código de aplicativo, que é mantida sob controle de versão. No entanto, usamos "processos" diferentes para código de desenvolvimento e produção

    2. Desenvolvimento mantemos os seguintes scripts:

      • base.sql - cria as tabelas de esquema e os dados de amostra
      • stagingchanges.sql - faz alterações no base.sql para ambiente de teste, principalmente endereços de e-mail, caminhos e outros ativos que podem mudar
      • prodchanges.sql - faz alterações no base.sql para uma implantação de produção. Para novos projetos, geralmente os testamos em ambientes de produção reais

    3. Manutenção

      • base.sql - uma versão limpa do banco de dados de produção
      • stagingchanges.sql e prodchanges.sql - como acima
      • changerequest.sql (geralmente tem o id da solicitação de alteração) que aplica quaisquer alterações de esquema para a solicitação de alteração atual em que estamos trabalhando
      • changerequest-rollback.sql - reverte as alterações feitas para a solicitação de alteração e redefine o banco de dados de volta à produção
      • arquivar (pasta) para scripts de solicitação de alteração anteriores

    Portanto, no modo de manutenção, tudo o que precisamos fazer é aplicar o script changerequest.sql durante a implantação na produção

    • 3

  3. Estando no espaço de controle de versão de banco de dados por 5 anos (como diretor de gerenciamento de produtos na DBmaestro ) e tendo trabalhado como DBA por mais de duas décadas, posso te dizer o simples fato de que você não pode tratar os objetos de banco de dados como você trata seu Java, C# ou outros arquivos.

    Os motivos são muitos e vou citar alguns:

    • Os arquivos são armazenados localmente no PC do desenvolvedor e as alterações feitas por ele
      não afetam outros desenvolvedores. Da mesma forma, o desenvolvedor não é afetado pelas alterações feitas por seu colega. No banco de dados, este
      não é (geralmente) o caso e os desenvolvedores compartilham o mesmo
      ambiente de banco de dados, portanto, qualquer alteração que tenha sido confirmada no banco de dados afetará outras pessoas.
    • A publicação de alterações de código é feita usando Check-In / Enviar alterações / etc. (dependendo de qual ferramenta de controle de código-fonte você usa). Nesse ponto, o código do diretório local do desenvolvedor é inserido
      no repositório de controle do código-fonte. O desenvolvedor que deseja obter o
      código mais recente precisa solicitá-lo na ferramenta de controle de origem. No
      banco de dados, a alteração já existe e afeta outros dados, mesmo que não tenha sido registrado no repositório.
    • Durante o check-in do arquivo, a ferramenta de controle de origem executa uma verificação de conflito para ver se o mesmo arquivo foi modificado e verificado por outro desenvolvedor durante o tempo em que você modificou sua cópia local. Novamente, não há verificação para isso no banco de dados. Se você alterar um procedimento do seu PC local e, ao mesmo tempo, eu modificar o mesmo procedimento com o código do meu PC local, substituiremos as alterações um do outro.
    • O processo de compilação do código é feito obtendo o rótulo / versão mais recente do código em um diretório vazio e, em seguida, executando uma compilação – compilação. A saída são binários nos quais copiamos e substituímos os existentes. Não nos importamos com o que era antes. No banco de dados, não podemos recriar o banco de dados, pois precisamos manter os dados! Além disso, a implantação executa scripts SQL que foram gerados no processo de construção.
    • Ao executar os scripts SQL (com os comandos DDL, DCL, DML (para conteúdo estático)), você assume que a estrutura atual do ambiente corresponde à estrutura ao criar os scripts. Caso contrário, seus scripts podem falhar porque você está tentando adicionar uma nova coluna que já existe.
    • Tratar scripts SQL como código e gerá-los manualmente causará erros de sintaxe, erros de dependências de banco de dados, scripts não reutilizáveis ​​que complicam a tarefa de desenvolver, manter e testar esses scripts. Além disso, esses scripts podem ser executados em um ambiente diferente daquele em que você pensou que eles seriam executados.
    • Às vezes, o script no repositório de controle de versão não corresponde à estrutura do objeto que foi testado e, portanto, ocorrerão erros na produção!

    Há muitos mais, mas acho que você entendeu.

    O que descobri que funciona é o seguinte:

    1. Use um sistema de controle de versão imposto que imponha operações de check-out/check-in nos objetos do banco de dados. Isso garantirá que o repositório de controle de versão corresponda ao código que foi verificado, pois ele lê os metadados do objeto na operação de check-in e não como uma etapa separada feita manualmente
    2. Use uma análise de impacto que utilize linhas de base como parte da comparação para identificar conflitos e identificar se uma alteração (ao comparar a estrutura do objeto entre o repositório de controle de origem e o banco de dados) é uma alteração real que teve origem no desenvolvimento ou uma alteração que teve origem em um caminho diferente e, em seguida, deve ser ignorado, como um ramal diferente ou uma correção de emergência.

    Um artigo que escrevi sobre isso foi publicado aqui , você está convidado a lê-lo.

    • 1

relate perguntas