viernes, 1 de febrero de 2013

Uso del mandato RGZPFM



El mandato Reorganizar miembro de archivo físico (RGZPFM) tiene dos funciones principales:

  • Comprimir (remover registros eliminados) de un miembro de un archivo físico (PF), para reducir el tamaño del objeto.
  • Ordenar los registros de la tabla con una clave, por lo general la clave principal usando el valor KEYFILE(*FILE), aunque hay que tener en cuenta que si el código de la aplicación es necesito leer los registros con la secuencia de llegada, hemos de utilizar el valor *NONE, para dicho parámetro.
Mientras se ejecuta el proceso de compresión, el mandato RGZPFM bloquea en exclusividad el objeto, por lo que, dependiendo del número de registros, el tamaño de la tabla, y la reconstrucción de los indices de la tabla, la ejecución podría durar mucho tiempo y habla que tenerlo en cuenta para buscar una ventana donde se pueda ejecutar. También está recomendado, yo diría prohibido, cancelar la ejecución del RGZPFM (* ver nota al final), ya que podría dañar el objeto; por ello es recomendable, antes de ejecutarlo, realizar una copia de seguridad del archivo, sus índices y tablas asociadas (restricciones) y detener las aplicaciones que están utilizando la tabla.




Básicamente, la estrategia para descubrir cuántos archivos tienen registros suprimidos, y son candidatos a un RGZPFM, es obtener los registros eliminados, de los tablas, a un archivo de trabajo y lanzar una consulta sobre esta tabla, para, en el ejemplo, obtener que tablas tienen mas de un registro eliminado, esto lo podemos hacer con este mandato, podéis someterlo si la biblioteca contienen muchos archivos:
DSPFD FILE(MYLIB/*ALL) TYPE(*MBRLIST) 
OUTPUT(*OUTFILE) FILEATR(*PF) OUTFILE(MYTEMP_LIB/LIST_FILES)

Con SQL obtenemos facilmente la lista de tablas con uno o más registros eliminados:
SELECT * FROM MYTEMP_LIB/LIST_FILES DONDE MLNDTR> 0

Ahora debemos decidir que archivos/miembros necesitan ser reorganizados. Es una buena idea calcular una proporción de registros borrados de una tabla, y sólo ejecutar el RGZPFM para las tablas con cierto porcentaje: 
SELECT ((MLNDTR * 100) / MLNRCD) AS RATIO, MLLIB, MLFILE, MLSIZE, MLMTXT 
FROM YOUR_MYTEMP_LIB/LIST_FILES
WHERE MLNDTR > 0
ORDER BY DESC RATIO



También habrá que considerar que beneficio obtenemos con:
  • La reducción de tamaño, ya que se relaciona directamente con la longitud de registro y el número de registros eliminados.
  • Relación tamaño/tiempo necesario para comprimir.
  • Numero y tiempo necesarios para reconstruir los indices de la tabla.
  • Mejora del rendimiento en las aplicaciones que leen la tabla por la clave principal. 
Otra forma de detectar tablas con registros eliminados es cambiar el parámetro DLTPCT, en el archivo físico: 
CHGPF FILE(MY_LIB/MY_PHYFILE) DLTPCT (30)


Este parámetro, de los atributos del archivo, envía automáticamente, cuando una aplicación hace un close de la tabla, el mensaje CPF4653 a la cola de mensajes QSYSOPR y al Histórico del Sistema (QHST): 

                     Additional Message Information 
Message ID . . . . . . : CPF4653 
Date sent . . . . . . : 31/01/13 Time sent . . . . . . : 12:50:08 
Message . . . . : DLTPCT parameter value for member MY_MEMBER exceeded. 
Cause . . . . . : The ratio of deleted records to data records has exceeded the limit specified in DLTPCT parameter value of the create file command for member MY_MEMBER file MY_PHYFILE in library MY_LIB. 
Recovery . . . : If necessary use the RGZPFM command to reorganize and remove deleted records from the file. Then try your request again. 



Se puede recoger este mensaje con una herramienta de monitorización o con el mandato DSPLOG MSGID (CPF4653) y, cuando lo planifiquemos, ejecutarlo en batch (recomendado):
SBMJOB CMD(RGZPFM FILE(MY_KLIB/MY_PHYFILE) MBR(MY_MEMBER) KEYFILE(*FILE))  JOB(RGZFMYFILE)

* El mandato RGZPFM tiene (a partir de V5R4) el parámetro ALWCANCEL, que esta oculto por omisión. En teoría esto permite el poder cancelar la reorganización de un archivo, pero a costa de necesitar mas tiempo y recursos del sistema para llevarla a cabo; además tiene un punto de no retorno en el que ya no se puede cancelar. El nuevo parámetro LOCK, relacionado con el anterior, permite el acceso a la tabla durante la reorganización, pero hemos de haber analizado previamente el impacto en nuestras aplicaciones.

Publicar un comentario