miércoles, 28 de octubre de 2009

Cancelar un rollback

En un artículo anterior se explicaba como averiguar el porcentaje rollback realizado por un trabajo.

Pero en muy contadas excepciones nos puede interesar cancelar un rollback, cosa realmente peligrosa sino conocemos, pero que muy bien, lo que esta haciendo el trabajo en la base de datos.

Por norma un rollback NUNCA se debe cancelar, debemos esperar que termine.

No se os ocurra realizar un IPL para forzar la finalización de un rollback, ya que el sistema lo terminara durante el IPL, con lo os quedareis sin sistema durante un tiempo indeterminado.

Dicho lo anterior, unos ejemplos de casos en que nos puede interesar cancelar el rollback:

  • Supongamos que lanzamos un programa que crea una tabla temporal, abre un ciclo de commit y empieza a insertar registros en esta tabla, el programa se mete en un bucle y continua insertando registros, cuando lleva unos cuantos millones de insert nos damos cuenta y cancelamos el trabajo. Entonces empieza a realizar el rollback eliminando millones de registros insertados. En este caso si pudiéramos cancelar el rollback y eliminar la tabla temporal seguro que terminaría más rápido que esperar el final del rollback.
  • Un programa se mete en un bucle actualizando miles de veces el mismo registro, es importante verificarlo con las entradas del diario. Al cancelarlo el rollback empezara a realizar miles de update en sentido inverso hasta dejarlo en el valor original. También en este caso si supiéramos el valor del registro al inicio del bucle, podríamos cancelar el rollback y después realizar un update manual del registro a su valor inicial; con esto ahorraríamos seguramente mucho tiempo.
  • Un trabajo realiza cambios en una o mas tablas, utilizando un solo ciclo de commit, cuando lleva unos millones de cambios cancelamos el trabajo. Si tenemos la absoluta seguridad que tenemos una copia de las tablas antes de empezar el proceso y que ningún otro trabajo ha realizado cambios en las mismas, podríamos valorar la posibilidad de cancelar el rollback y restaurar las tablas.
A partir de la V5R3 existe un procedimiento para cancelar un rollback, es el siguiente:
  1. Definir la estrategia para reparar la base de datos: Asegurarse de que tenemos los datos necesarios, verificar que tenemos las copias de seguridad, son accesibles  y contienen las tablas implicadas (recordar los ejemplos).
  2. Conectarse con usuario con permisos *SECOFR.
  3. Lanzar el ENDJOB, con OPTION(*IMMED), del trabajo que empezara a realizar el rollback.
  4. Averiguar el ciclo de compromiso del rollback que vamos a cancelar:
  5. WRKCMTDFN JOB(012345/MYUSER/MYJOB)
  6. Pulsar F23 para ver más opciones y  aparecerá la opción 20=End rollback.
  7. Introducir la opción 20 en el ciclo de compromiso a cancelar y pulsar Intro.
  8. Nos aparecerá una pantalla (ver imagen) que nos advierte del peligro de cancelar el rollback, ya que dejaremos inconsistente la base de datos y eso podría afectar a otros trabajos.
  9. Si estamos seguros pulsaremos Intro. Sino podemos pulsar F12 para volver atras.
  10. A partir de ese momento el trabajo empezará a liberar los registros bloqueados por el commit, cancelando el rollback. Esto puede tardar algún tiempo dependiendo de la cantidad de registros.
  11. Una vez a finalizado el rollback y el trabajo, podremos reparar la base de datos, según la estrategia decidida en el primer paso. En los ejemplos: Eliminar la tabla temporal, Actualizar manualmente el registro implicado, Restaurar la/s tabla/s implicadas.


ADVERTENCIA FINAL: Es responsabilidad vuestra el utilizar, o no, este procedimiento. Como comprenderéis podéis causar un daño irreversible a la base de datos, si no estáis absolutamente seguros de lo que vais a hacer. En caso de la más mínima duda os recomiendo esperar al final del rollback.

Más información en el documento: Ending A Rollback - V530 and Later Releases

lunes, 19 de octubre de 2009

Cambio hora verano/invierno


La madrugada del ultimo domingo de Octubre los sistemas deben cambiar la hora al horario de invierno, o sea a las 3:00 se retrasara la hora a las 2:00 horas.
Actualmente, a partir de la V5R4, podemos configurar el sistema para que automáticamente realize el cambio de hora sin nuestra intervención, para ello debéis seguir las indicaciones del articulo:
Sincronizar la hora del AS400
Pero si tenemos un sistema con una versión anterior del OS400, podemos utilizar mi utilidad SUMWIN para realizar el cambio de hora automáticamente.

La estrategia para realizar el cambio de hora es añadir un trabajo automático al planificador de tareas el siguiente mandato (con usuario QSECOFR):
ADDJOBSCDE JOB(SUMWIN) CMD(CALL PGM(SUMWIN)) FRQ(*MONTHLY) SCDDATE(*NONE) SCDDAY(*SUN) SCDTIME(020000) RELDAYMON(*LAST) JOBQ(QSYSNOMAX) TEXT('Cambio automático a horario de verano-invierno')

Con esto conseguimos que cada ultimo domingo de mes se lance el trabajo y solo cambiara la hora cuando sea:
  • El ultimo domingo del mes de Marzo a las 02:00:00 sumara una hora o
  • El ultimo domingo del mes de Octubre esperara a las 03:01:00 y restara una hora,
  • En ambos casos envía un mensaje al operador.
  • El resto de meses no hará nada.

jueves, 15 de octubre de 2009

Cambios en variable de sistema QLMTDEVSSN (V6R1)

La nueva versión del i5/OS V6R1, incluye un muy esperado nuevo valor para la variable del sistema QLMTDEVSSN (Limit device session).

Hasta la versión V5R4 podíamos tener los siguientes valores:
0=Do not limit = El usuario puede abrir tantas sesiones interactivas como quiera.
1=Limit = El usuario solo puede abrir una sesion interactiva.

Con la V6R1 se modifican los valores de esta variable como sigue:
0=Do not limit = El usuario puede abrir tantas sesiones interactivas como quiera.
1-9=Maximum device sessions = Este valor nos indica cuantas sesiones podrá abrir como máximo un usuario 1,2,.. y hasta 9 sesiones interactivas concurrentes.

Para ver que valor tiene el sistema: 
DSPSYSVAL SYSVAL(QLMTDEVSSN)

Por defecto es preferible, sobretodo en los sistemas de Producción, que este valor de sistema este a 1, así todos los usuarios, que en el parámetro LMTDEVSSN de su perfil de usuario tengan el valor *SYSVAL, solo podrán abrir una sesión interactiva por defecto. A los Operadores y/o Administradores podemos darles más sesiones cambiando este valor en su perfil de usuario.

Pero puede ser interesante tener el valor de sistema a 2 o 3 en los sistemas de Desarrollo, para que al crear un nuevo programador, y sin tener que cambiar su perfil de usuario, ya pueda tener más de una sesión interactiva, cosa muy solicitada y recomendable para poder realizar pruebas, del código que están creando y probando, mas cómodamente.