2011-11-29 8 views
6

Me gustaría tener una compilación de CI (por ejemplo, Hudson) configurada y derribar un esquema de Oracle 11g como parte de un ciclo de compilación/prueba nocturno para una versión bastante vainilla Aplicación JSF/JPA.Configurar/desmontar el esquema de Oracle para construir CI sin fragmentar el catálogo

La forma más obvia de hacerlo es soltar y volver a crear todas las tablas. Si bien esto se siente bastante estándar (al menos, eso es lo que las herramientas de Hibernate/JPA harían automáticamente), he tenido que los DBA de Oracle me advierten que el catálogo de Oracle se fragmentará después de repetidos ciclos de creación/caída de objetos. Eventualmente, esto causará problemas de rendimiento porque el espacio de tabla SYSTEM no se puede desfragmentar/fusionar.

Mis preguntas son:

  • es la fragmentación de una preocupación genuina, o no es algo que tiene que preocuparse de en un entorno típico de desarrollo de aplicación web?
  • si la fragmentación realmente es una preocupación, ¿hay alguna manera mejor de derribar y recrear un esquema en Oracle que DROP TABLE/CREATE TABLE?

Gracias!

Respuesta

7

No crea que esos administradores de bases

Al menos con 10g y por encima cuando se utiliza tablespaces gestionados localmente (LMT) esto no debería ser un problema.

E incluso si eso causó alguna fragmentación, dudo mucho que pueda medir su impacto, especialmente en una base de datos que se usa para CI.

+1

Los LMT por sí solos deben eliminar cualquier preocupación que alguien tenga con la fragmentación, suponiendo que el espacio de tabla 'SYSTEM' se gestiona localmente. No es obvio para mí que ASM agrega algo. Y ASM tiende a ser una tecnología políticamente mucho más polémica ya que se trata de dejar que los DBA manejen más tareas de administración de almacenamiento, lo que significa quitar esa responsabilidad de los grupos que lo hacen hoy. Los LMT, por otro lado, son un sustituto cerebralmente obvio, obviamente superior a los espacios de tabla administrados por el diccionario (DMT). –

+0

@JustinCave: gracias por la pista. Eliminé el comentario sobre ASM (de todos modos, no estaba tan seguro) –

2

Estoy en el proceso de poner en marcha un proceso de construcción de CI para mi 2do proyecto de Oracle. No creo que dejar caer y volver a crear todo sea dañino (como a_horse_with_no_name indicado anteriormente). Me alegra saber que está pensando en extender el CI a los objetos de la base de datos, demasiados equipos no.

Un enfoque diferente podría ser restaurar la base de datos de una copia de seguridad reciente cada noche (o usar la base de datos de flashback) y migrar su aplicación de 'copia de seguridad de producción' al estado actual de desarrollo en cada ejecución de CI. De esta forma, el código que eventualmente se aplicará a la producción se probará todas las noches contra algo que es en gran parte idéntico a la producción. Es un cambio en el pensamiento, pero no demasiado cambio si ya estás pensando en CI.

Si te apetece probar el enfoque de migración, tengo una herramienta en la que he estado trabajando que puede ayudar - http://dbgeni.com Todavía está en desarrollo, pero lo diseñé con CI y gestioné los cambios de la base de datos con migraciones en mente.

Cuestiones relacionadas