Como você versiona as alterações do banco de dados Oracle?

Nos sites em que trabalhei, quaisquer alterações que precisem ser feitas na(s) instância(s) de produção devem ser roteirizadas como scripts de alteração que serão executados no SQL*Plus; além disso, os scripts necessários para recriar todos os objetos de esquema do zero devem ser mantidos atualizados. Todos esses scripts são verificados no controle de alterações e migrados de lá.

Você pode auditar alterações DDL ou usar gatilhos DDL para coletar alterações, ou até mesmo usar software diff para comparar duas instâncias, mas esses métodos são indiscriminados; muitas vezes um desenvolvedor fará e desfará uma série de alterações em um esquema (por exemplo, pequenas alterações de teste, criação de tabelas fictícias para testar conceitos, etc.) antes de descobrir o que exatamente precisa ser alterado.

Tenho pensado e lido muito sobre este assunto. Este é um tópico amplo de controle de configuração e estratégia de gerenciamento de mudanças. O CMMI tem um domínio neste tópico. Mesmo em empresas que possuem um credenciamento do CMMI 3-5, às vezes elas não controlam a versão de seus bancos de dados.

Esta pergunta deve ser respondida tendo em mente as restrições .

1. Você tem um guardião e cada DDL é executado por este guardião.
2. Outras pessoas têm a capacidade de executar instruções DDL.
3. Você só precisa registrar quais mudanças foram feitas, mas não precisa comparar grandes diferenças.
4. Seu design de banco de dados é feito por meio de uma ferramenta externa e depois publicado no banco de dados. Esta ferramenta externa pode ser scripts DDL no controle de origem mesmo. Mas o ponto-chave é que você controla a origem disso e depois publica no banco de dados.
5. Você não precisa conhecer as mudanças instantâneas, mas de tempos em tempos: ou seja, de hora em hora, diariamente.
6. Você tem uma estrutura de servidor definida: Desenvolvimento, Teste, Produção. E uma boa estratégia de teste.

resposta 1

• se 1 ,4,6 for true, você poderá usar um controle de origem externo. Por exemplo
  • A Embercadero possui uma ferramenta de gerenciamento de alterações de banco de dados ( http://www.embarcadero.com/products/db-change-manager-xe ). Que tem capacidade de fazer engenharia reversa de um banco de dados (Oracle) e colocá-lo em seu controle de origem. Então, qualquer número de desenvolvedor, dba, pode acessar esse esquema e fazer alterações nele.
  • O Oracle SQL Designer é semelhante a essa abordagem.
  • Colocando você cria scripts de tabela para controle de fonte (svn, mercurial etc) e mantendo-os também a mesma coisa.
  • http://www.liquibase.org é a abordagem automatizada acima.
  • Eu escrevi o gerador de código que gerou instruções DAL (Data Access Layer), DDL (Create Table). Nós os colocamos no controle de origem e mantivemos lá. Acho que uma solução dedicada como a liquibase pode funcionar melhor.

Essa abordagem funciona bem se tiver 6. Você coloca instruções DDL, que também é um código, no controle de origem e as mantém. Ninguém mudará os Servidores de Teste e Produção sem a devida consideração.

Desvantagens é se você fizer qualquer alteração nos servidores de produção ou teste por qualquer motivo, uma correção rápida de bug, alteração de chave primária etc. Você precisa rolar essas alterações para o servidor de desenvolvimento também. Uma vez que, na verdade, o servidor de desenvolvimento é sua VERDADE FUNDAMENTAL. Não de outra forma.

Esta é uma abordagem muito orientada para o desenvolvedor. Mas quando você desenvolve um novo módulo, ele funciona muito bem.

Resposta 2 - se 1 e 6 forem verdadeiras:

Uma abordagem semelhante à resposta 1 é manter um servidor de desenvolvimento. Todo mundo usa isso muda. Do que quando chega a hora de atualizar. Você usa uma ferramenta de comparação de banco de dados. Obtenha-os como scripts, coloque-os sob controle de origem.

- Red Gate Schema Compare supports Oracle
- Embercadero has similar tool
- https://github.com/carbonfive/db-migration
- http://www.sumsoftsolutions.com/svco/ (I have not used this product but I believe it belongs to this category.)
- Rails Active Migration (http://www.oracle.com/technetwork/articles/kern-rails-migrations-100756.html)

A diferença entre a resposta 1 e a resposta 2 é que na resposta 1 você coleta instruções DDL para todo o banco de dados e as armazena. Na resposta 2, você precisa armazenar todas as versões de alteração.

1. Começar
2. V1
3. V2
4. V3
5. ...

Se você colocar uma coluna em uma tabela e depois decidir removê-la. Seus scripts mostrarão isso na resposta2, enquanto na resposta1 você verá apenas a última versão. E você precisa comparar V2 e V1 para ver as diferenças. Pessoalmente, gosto mais da resposta 1, pois posso comparar facilmente Start e V3, V1 e V3. Na resposta2, preciso procurar todas as alterações. Também na resposta 2, o script no controle de origem tende a ser um script complexo e big bang. Difícil encontrar informações.

Resposta 3 Se 3 for verdadeiro. Note que nesta situação você não tem restrição 6 , ou seja : você não tem servidores de Desenvolvimento, Teste, Produto. Apenas servidor de produção. Você pode usar gatilhos DDL para registrar quais alterações foram feitas. Isso é usado principalmente para desencorajar as pessoas de abusar de seus subsídios DDL. Se ocorrer algum problema, você pode encontrar o responsável. Para que isso funcione, cada pessoa deve se conectar com sua conta de usuário e a conta do aplicativo não deve ter nenhuma concessão DDL. Já que todo desenvolvedor conhece a conta do aplicativo e pode usá-la.

Resposta 4 Se você tem 3 e 5. Observe que nesta situação você não tem restrição 6 , ou seja: você não tem servidores de Desenvolvimento, Teste, Produto. Apenas servidor de produção. Em vez de acionar para armazenar as alterações. Você usa uma ferramenta externa para localizar alterações e armazenar scripts DDL no controle de origem.

Se essas ferramentas tiverem a capacidade de registrar quem fez alterações, seria útil. Observe que nesta solução você perde DDL extra que é feito em intervalos.

Acabei de encontrar um tutorial interessante sobre como usar o Liquibase para versão do Oracle.

Em alguns de nossos bancos de dados, estamos usando gatilhos DDL para capturar alterações e salvá-las em uma tabela. Em seguida, temos uma interface da Web para acessar essas versões anteriores. Tem graves desvantagens, e é por isso que estou procurando alternativas, mas é fácil e é melhor do que nenhum controle de versão.

Usamos o Schema Version Control para nossos bancos de dados 11g, mas tivemos alguns problemas com o software em 11.2. Se não fossem esses problemas que ainda estamos trabalhando, seria um ótimo produto.

Costumávamos trabalhar com o Oracle SQL Designer, que (eu acho) foi substituído pelo SQL Developer Data Modeler agora. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

Isso foi muito bom, esp. a capacidade de definir DOMAINs para colunas e economizar muito tempo criando colunas comuns (mtime, ctime etc).

Usamos o conjunto de ferramentas oracle-ddl2svn (do qual sou o autor) para automatizar o armazenamento do esquema DDL oracle em SVN.

Eu nunca usei, mas http://blog.gitora.com/ é outra opção.

Dê uma olhada no DBmaestro TeamWork, que sua abordagem de gerenciamento de mudanças imposta pelo banco de dados .

_{divulgação: eu trabalho para dbMaestro}