Reflexiones sobre la Reorg

Caracteristicas deseables de la Reorg

Que no se pierdan.
A pesar de tener varias personas trabajando sobre una misma KB, no deberia perder ninguna reorganizacion.

Que avise si me salteo alguna
Si voy a correr una reorganizacion, que me avise si no corri la anterior.

Que pueda tener recuperacion ante caidas.
Es indudable que las reorganizaciones son programas complejos y muy propensos a tener errores porque utilizan muchos recursos (discos, cpu, software del DBMS, memoria, etc) y por lo tanto hay que tener una forma de recuperarse de las caidas que van a tener. Esto debe poder realizarse SIN TENER GENEXUS, pues cuando se corren las reorg, en varias oportunidades no se tiene Genexus

Que pueda correrse en forma parcial
En varias oportunidades hemos tenido que optar por no ejecutar parte de una reorganizacion, y hacerla en una forma diferente a la que plantea Genexus (por temas de performance, por temas de bloqueos que no eran posibles hacer en ese momento, etc).

Que sea predecible el tiempo que va a demorar
Deberia ser predecible el tiempo que va demorar una corrida de la reorg.

Verificable
Deberia ser verificable que la reorganizacion hizo todo lo que tenia que hacer, comprobandose la estructura de la base de datos despues de correr la reorganizacion, contra la estructura esperada.

Rapida
La reorganizacion deberia generar codigo eficiente, de forma de hacer optima la ejecucion.

Tipos de reorganizaciones

Prototipacion
Generalmente se trabaja con bases de datos pequeñas y raramente dan problemas. Estas estan bien resueltas hoy y no necesitan personal especializado para ejecutarlas.
No es critica la perdida de datos y el downtime es tolerable. El factor mas critico es la demora en el bloqueo del modelo de diseño, que imposibilita hacer otras tareas de programacion.

Pre-Produccion.
Estas reorganizaciones se corren para probar y optimizar las reorganizaciones de produccion. En ellas se realizan los ajustes necesarios para anticiparse a los problemas de la base de produccion y minimizar los riesgos de cancelaciones o demoras.
Algunas veces es critica la perdida de datos.

Produccion.
Es fundamental minimizar el downtime o el perjuicio de performance y lockeos en estas reorganizaciones. Es corrida por personal que conoce de base de datos y no necesita conocer de GeneXus. Es fundamental darle una herramienta que permita saber que es lo que se ejecuta, en que orden se ejecuta, hasta donde se ejecuta y que es lo que falta ejecutar.
La perdida de datos es inaceptable.
La ejecucion de este tipo de reorganizacion en la base de datos, es planificada con semanas de antelacion.
Generalmente una reorganiacion de produccion, implica la ejecucion de varias reorganizaciones de los tipos anteriores.


armin 01/09/09 02:21 PM Muchas de estas funcionalidades fueron implementadas en GeneXus X: ver Reorganization y Features of Reorganizations