¿Cómo versiona los cambios de su base de datos Oracle?

Estoy interesado en saber qué métodos están utilizando otras personas para realizar un seguimiento de los cambios realizados en la base de datos, incluidos los cambios de definición de tabla, nuevos objetos, cambios de paquetes, etc. ¿Utiliza archivos planos con un sistema de control de versiones externo? Disparadores? Otro software?

En los sitios en los que he trabajado, cualquier cambio que deba realizarse en la (s) instancia (s) de producción debe estar programado como script de cambio que se ejecutará en SQL * Plus; Además, los scripts necesarios para recrear todos los objetos de esquema desde cero deben mantenerse actualizados. Todos estos scripts se registran en el control de cambios y se migran desde allí.

Puede auditar los cambios DDL o usar los desencadenadores DDL para recoger los cambios, o incluso usar el software diff para comparar dos instancias, pero estos métodos son indiscriminados; a menudo, un desarrollador realizará y deshacerá una serie de cambios en un esquema (por ejemplo, pequeños cambios de prueba, creación de tablas ficticias para probar conceptos, etc.) antes de determinar qué es exactamente lo que se debe cambiar.

He pensado y leído mucho sobre este tema. Este es un tema amplio de control de configuración y estrategia de gestión de cambios. CMMI tiene un dominio en este tema. Incluso en empresas que tienen una acreditación de CMMI 3-5, a veces no controlan la versión de sus bases de datos.

Esta pregunta debe responderse teniendo en cuenta las siguientes limitaciones .

1. Tienes un guardián y cada DDL es ejecutado por este guardián.
2. Otras personas tienen la capacidad de ejecutar sentencias DDL.
3. Solo necesita registrar qué cambios se han realizado, pero no necesita comparar grandes diferencias.
4. El diseño de su base de datos se realiza mediante una herramienta externa y luego se publica en la base de datos. Esta herramienta externa puede ser scripts DDL incluso en control de código fuente. Pero el punto clave es que controle esto y luego publique en la base de datos.
5. No necesita conocer los cambios instantáneos, sino de vez en cuando: es decir, cada hora, todos los días.
6. Tiene una estructura de servidor definida: Desarrollo, Prueba, Producción. Y una buena estrategia de prueba.

respuesta 1

• si 1, 4,6 es verdadero, entonces puede usar un control de fuente externo. Por ejemplo
  • Embercadero tiene una herramienta de gestión de cambio de base de datos ( http://www.embarcadero.com/products/db-change-manager-xe ). Que tiene la capacidad de aplicar ingeniería inversa a una base de datos (Oracle) y ponerla en su control de origen. Luego, cualquier número de desarrolladores, dba puede alcanzar este esquema y realizar cambios en él.
  • Oracle SQL Designer es similar a este enfoque.
  • Poner las secuencias de comandos de la tabla para el control de origen (svn, mercurial, etc.) y mantenerlas también lo mismo.
  • http://www.liquibase.org es un enfoque automatizado de arriba.
  • Escribí el generador de código que generaba declaraciones DAL (Capa de acceso a datos), DDL (Crear tabla). Les pusimos control de fuente y lo mantuvimos allí. Creo que una solución dedicada como liquibase puede funcionar mejor.

Este enfoque funciona bien si tiene 6. Usted pone instrucciones DDL, que también es un código, en el control de origen y lo mantiene. Nadie cambiará los servidores de prueba y producción sin la debida consideración.

Las desventajas son si realiza algún cambio en los servidores de producción o de prueba por cualquier motivo, una corrección rápida de errores, cambio de clave principal, etc. También debe transferir esos cambios al servidor de desarrollo. Dado que en realidad el servidor de desarrollo es su VERDAD EN TIERRA. No al revés.

Este es un enfoque muy orientado al desarrollador. Pero cuando desarrolla un nuevo módulo por primera vez, funciona bastante bien.

Respuesta 2 : si 1 y 6 son verdaderos:

Un enfoque similar a la respuesta 1 es mantener un servidor de desarrollo. Todo el mundo lo usa, lo cambia. Que cuando llega el momento de actualizar. Utiliza una herramienta de comparación de bases de datos. Consíguelos como scripts, póngalos bajo control de origen.

- 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)

La diferencia entre la Respuesta 1 y la Respuesta 2 es que, en la respuesta 1, recopila declaraciones DDL para toda la base de datos y las almacena. En la respuesta 2, debe almacenar cada versión de cambio.

1. comienzo
2. V1
3. V2
4. V3
5. ...

Si coloca una columna en una tabla y luego decide eliminarla. Sus scripts mostrarán esto en la respuesta2 mientras que en la respuesta1 solo verá la última versión. Y necesitas comparar V2 y V1 para ver las diferencias. Personalmente, me gusta la respuesta 1 mejor, ya que puedo comparar fácilmente Start y V3, V1 y V3. En la respuesta2, necesito buscar todos los cambios. También en la respuesta 2, el script en el control de la fuente tiende a ser un script complejo y de gran explosión. Difícil de encontrar información.

Respuesta 3 Si 3 es verdadero. Tenga en cuenta que en esta situación no tiene la restricción 6, es decir: no tiene servidores de Desarrollo, Prueba, Producto. Solo servidor de producción. Puede usar los desencadenadores DDL para registrar qué cambios se han realizado. Esto se usa principalmente para disuadir a las personas de abusar de sus subvenciones DDL. Si se produce algún problema, puede encontrar responsable. Para que esto funcione, cada persona debe conectarse con su cuenta de usuario y la cuenta de la Aplicación no debe tener ninguna subvención DDL. Dado que cada desarrollador conoce la cuenta de la aplicación y puede usarla.

Respuesta 4 Si tiene 3 y 5. Tenga en cuenta que en esta situación no tiene la restricción 6, es decir: no tiene servidores de Desarrollo, Prueba, Producto. Solo servidor de producción. En lugar de disparador para almacenar cambios. Utiliza una herramienta externa para buscar cambios y almacenar scripts DDL en el control de origen.

Si esta herramienta tiene la capacidad de registrar quién ha realizado cambios, sería útil. Tenga en cuenta que en esta solución pierde DDL extra que se realizan a intervalos.

Acabo de encontrar un interesante tutorial sobre el uso de Liquibase para la versión de Oracle.

En algunas de nuestras bases de datos estamos utilizando disparadores DDL para detectar cambios y guardarlos en una tabla. Luego tenemos una interfaz web para abrir estas versiones anteriores. Tiene graves inconvenientes, por eso estoy buscando alternativas, pero es fácil y es mejor que no tener control de versiones.

Hemos utilizado Schema Version Control para nuestras bases de datos 11g, pero hemos tenido algunos problemas con el software en 11.2. Si no fuera por esos problemas en los que todavía estamos trabajando, sería un gran producto.

Solíamos trabajar con Oracle SQL Designer, que (supongo) ha sido reemplazado con SQL Developer Data Modeler ahora. http://www.oracle.com/technetwork/developer-tools/datamodeler/overview/index.html

Eso fue bastante agradable, especialmente. la capacidad de establecer DOMINIOS para columnas y ahorrar mucho tiempo creando columnas comunes (mtime, ctime, etc.).

Utilizamos el conjunto de herramientas oracle-ddl2svn (del cual soy autor) para el almacenamiento automático del esquema DDL de Oracle en SVN.

Eche un vistazo a DBmaestro TeamWork, que su base de datos impuso el enfoque de gestión de cambios .

_{divulgación: trabajo para dbMaestro}

Nunca lo he usado, pero http://blog.gitora.com/ es otra opción.