Estoy migrando en una base de prueba y cuando ejecuto el script_A_coleg_localid.sql se cualga el motor y se llenan los logical logs.
Debo ejecutar un backup de logical log y luego uno de nivel 0 para que se recupere el motor.
Les paso la salida del onstat -l actual, serán pocos logical logs? o tendré que dividir ese script en 2 partes?
Saludos. Ricardo.
logicallogs.txt (2.05 KB)
Ricardo:
Los logical logs parecen razonables, lo mismo que su tamaño si el sistema operativo es Windows.
Cuando corres ese script el motor no creo que se cuelgue realmente, sino que lo que pasa es que se llenan los logical logs y deja de trabajar, pero si en una ventana independiente ejecutas el ontape -a (backup de logical logs) el script sigue corriendo.
Para correr ese script es conveniente tener un backup continuo de logical logs ejecutandose en una ventana independiente (ontape -c), ya que se llenan con rapidez y quizás más de 1 vez, segun la cantidad y tamaño.
No entiendo porque después de ejecutar el backup de los logical logs tenes que ejecutar un backup de nivel 0. No tienen ninguna relación una cosa con otra, al menos en este caso. Y te repito, no es que el motor se cuelgue, sino que se llenan los logical logs. Si los backupeas desde la consola el script sigue su trabajo.
Saludos
Gustavo
Hola
Como dice Gustavo con un backup de los logs logicos (ontape -a) deberia alcanzar para que se destrabe y continue procesando el script. El backup nivel cero no es necesario hacerlo, sin embargo hacer backup de los logs logicos (con ontape -a u ontape -c), sin tener un nivel 0 inicial realizado con anticipacion (ontape -s) no tiene sentido.
Estoy armando un material de capacitacion en el uso de backup continuo, para impulsar un poco que se haga backup de esta forma, ya que tiene ventajas con respecto al simple dbexport o al ontape -s. Los que se entusiasmen, avisenme y vamos analizando alternativas para difundirlo.
saludos
Ignacio
Hoy volví a ejecutar esos scripts desde el servidor sobre esa base y no tuve inconvenientes en ninguno de los 3 scripts con inserciones.
Saludos. Ricardo.
Ignacio:
Está buena la idea de ese material. En algún momento, allá por el año 2002, había un instructivo de como poner el ontape -c como un servicio en Windows (NT / 2000). Yo lo usé un tiempo así, pero después se pudrió ese servidor y me volteaba el servidor cada vez que se arrancaba ese servicio.
Con el tiempo, opté por poner como tareas programadas los backups de nivel 0, 1 y 2. Y una vez por día ejecuto una tarea programada del ontape -a, renombrando el archivo de salida. De esa manera tengo todo automatizado, pero a pedal. Sé que hay maneras mucho mejores de hacerlo, pero nunca tuve tiempo de ponerme a estudiar.
Un amigo y colega que trabaja conmigo en varias instituciones (Freddy) una vez lo automatizó (en Windows 2003), pero ya ni se acuerda como lo hizo. Ahora está volviendo a estudiar el ISM, para ver de hacerlo funcionar.
Toda colaboración para aprender es bienvenida.
Saludos
Gustavo
El ISM (Informix Storage Manager) es un servicio adicional que viene con el informix y tiene la habilidad de recibir peticiones desatendidas, es decir que tanto el motor, como un comando manual como una tarea cronometrada puede ejecutar backups en forma desatendida. Hay un guìa de administraciòn de IBM con toda la informiaciòn
Saludos