Informix 'alter table' Performance

Conoce los algoritmos usados por Informix para procesar un 'alter table'

Visitas: 172

Informix usa uno de los siguientes algoritmos para procesar un alter table, son los siguientes:

  • Slow alter
  • In-place alter
  • Fast alter

Informix decide el algoritmo a emplear en función del tipo de alter table que hayamos indicado. No podemos influir sobre este comportamiento aunque si es recomendable conocerlo desde el punto de vista del “Performance”.

Veamos ahora las particularidades de cada método y las acciones que realiza el gestor de base de datos en cada uno de ellos.

Slow alter

La tabla queda inaccesible mientras se realiza el proceso de alter. El tiempo vendrá determinado por el tamaño de la tabla y de los índices que contenga (si alteramos un campo involucrado en un índice).

La tabla podría quedar inaccesible para los usuarios por los siguientes motivos:

  • Se coloca un bloqueo exclusivo en la tabla.
  • Se hace una copia de la tabla para realizar la conversión.
  • Convierte la información de cada fila.
  • Puede causar un long transaction y abortarse el proceso.

Dado que hace una copia para realizar la conversión, necesitamos el doble del espacio de la tabla y espacio adicional para el log.

Informix usa este algoritmo cuando el alter table hace cambios en columnas y no puede aplicar el algoritmo “in-place alter”.

In-place alter

Este algoritmo provee numerosas ventajas en mejora de prestaciones sobre el slow alter. Veamos.

El algoritmo In-place alter:

Incrementa la disponibilidad de la tabla, aspecto muy importante en sistemas que requieren una disponibilidad de 24*7. Los usuarios pueden acceder a la tabla tan pronto como el alter table usa el algoritmo In-place alter. La tabla se bloquea solo el tiempo necesario para alterar la definición de la tabla y reconstruir índices que contienen columnas alteradas.

  • No se hace copia de la tabla para convertir los datos.
  • No convierte las filas durante el proceso de alter table.
  • Altera las columnas físicamente cuando posteriormente insertamos o actualizamos filas, en ese momento se convierten todas las filas que residen en cada página que actualizamos o donde insertemos.

No se almacena en los log los cambios de las filas puesto que el cambio no se aplica en ese momento. Por tanto:

  • Ahorramos espacio en los logs
  • No se producen long transactions.

Fast alter

Informix usa este algoritmo cuando la sentencia alter table cambia atributos de la tabla pero el cambio no afecta a los datos.

Se usa este mecanismo cuando:

  • Cambiamos next extent size
  • Añadimos o borramos una constraint
  • Cambiamos el lock mode de la tabla (row, page)

Informix bloquea la tabla por un periodo casi imperceptible por el usuario.

Consideraciones para la mejora de prestaciones

Cada vez que Informix aplica el algoritmo “In-place alter” sobre una tabla, crea una versión de la estructura de la tabla.

  • Informix guarda pistas de todas las versiones de definición de las tablas.
  • “resetea” esta información cuando todas las páginas son convertidas o se hace un slow alter.

Cuando informix detecta páginas en diferente versión durante operaciones de insert, update, delete y select, realiza las siguientes acciones:

  • UPDATE, se convierte la página de datos que contiene la fila a la versión final de alter.
  • INSERT, convierte la fila insertada al formato final e inserta la fila en la página que mejor se ajusta y se convierten las filas de dicha página.
  • DELETE, no se realiza ninguna conversión de la página en donde estaba ubicada la fila.
  • SELECT, no se realiza físicamente la conversión de la página al formato final. Cuando una query accede a una fila de una página no convertida, se produce una degradación en el rendimiento de la query porque Informix reformatea cada fila antes de retornarla al usuario.

En resumen, cuando Informix escoge el algoritmo “In-place alter” en vez del “slow alter”, se obtienen muchas ventajas en el momento del alter (como hemos explicado al describir cada método), pero por otra parte empeora el rendimiento cuando accedemos a páginas de datos no convertidas.

Una forma de conocer el nivel de versionado de una tabla es ejecutando la siguiente sentencia desde la línea de comandos:

oncheck –pT basedatos:tabla

Esta sentencia nos mostrará información (entre otra) como la siguiente:

Home Data Page Version Summary
                 Version                                Count
                      12 (oldest)                           0
                      13                               147180
                      14 (current)                      46390

Esto indica que hay 147.180 páginas sin convertir en la versión 13 y 46.390 convertidas en la versión actual 14. Cuando hagamos un update de una fila contenida en una página de la versión 13, Informix realizará la conversión de todas las filas de dicha página. Esta operación influirá en el rendimiento. Y lo mismo cuando hagamos el resto de operaciones indicadas con anterioridad: INSERT, SELECT, aplicando el mecanismo que hemos descrito para cada una de ellas.

Nota: Para la ejecución de oncheck -pT Informix coloca un bloqueo y puede que no esté disponible en ese momento dando un error similar a este: “ERROR:  Could not obtain lock for basedatos:propietario.tabla”.

Gracias a la base de datos de administración sysadmin, existe una forma de conocer todas las tablas con diferente versionado, es la siguiente:

  • Primero localizaremos el id de la tarea mediante la query siguiente:
database sysadmin;
select tk_id,tk_name from ph_task
  • Localizaremos el id de la tarea check_for_ipa (puede variar de una instalación a otra):
     tk_id tk_name
     ...
     27 check_for_ipa
     ...
  • Activamos la tarea:
dbaccess sysadmin;
update ph_task set tk_enable = “t”
where tk_id = 27;

La tarea será ejecutada por el planificador, de manera casi inmediata podemos ejecutar la query siguiente para obtener las tablas:

dbaccess sysadmin;
select alert_object_name from ph_alert
where alert_message matches "*alter*"      
and alert_action_dbs = "basededatos"
order by 1

Luego podemos desactivar la alerta:

dbaccess sysadmin;
update ph_task set tk_enable = “f”
where tk_id = 27;

Una vez que hemos localizado una tabla con diferente versionado podemos usar la siguiente utilidad para realizar la conversión de las páginas a la última versión:

dbaccess sysadmin;
execute function task (“table update_ipa parallel”,”tabla”,”basedatos”)

Nota: Hay que manejar esta utilidad con precaución cuando la tabla tiene millones de filas o es de uso frecuente. Se genera mucha actividad en los logs y puede afectar al rendimiento durante su ejecución.

Veamos un ejemplo sobre una tabla comparando la situación antes y después de la ejecución de table_update_ipa:

Se genera información en el fichero de mensajes online.log. Luego se observa cómo todas las páginas están en la última versión, y por último vemos que el número de páginas de datos ha aumentado en 7 tras la conversión. El aumento de páginas es debido a las características del alter table realizado en su momento

04/17/18 15:10:17  SCHAPI Update IPA for basedatos:informix.tabla started
04/17/18 15:10:18  SCHAPI Update IPA of table
'basedatos:informix.tabla partnum 5003eb succeeded; 1821 rows updated.
04/17/18 15:10:18  SCHAPI table  basedatos:informix.tabla succeeded

Antes:

Home Data Page Version Summary
                 Version                                Count
                       0 (oldest)                        1394
                       1                                    0
                       2 (current)                        238

Despues:

Home Data Page Version Summary
                 Version                                Count
                       0 (oldest)                           0
                       1                                    0
                       2 (current)                       1639

Fuente:

Autor

Imagen de Business Platform

Equipo

CAPTCHA
Esta pregunta es para comprobar si usted es un visitante humano y prevenir envíos de spam automatizado.