Control del tamaño de registro para operaciones de SQL

La cantidad de registro cronológico realizado para aplicaciones depende de la cantidad de datos que se modifican.

Acerca de esta tarea

Ciertas sentencias de SQL son bastante potentes, y a veces una sola sentencia puede modificar una gran cantidad de datos. Dichas sentencias incluyen:

INSERT con fullselect
Se pueden insertar una gran cantidad de datos en una tabla o vista, en función del resultado de la consulta.
Supresiones masivas y actualizaciones masivas (excepto para suprimir todas las filas de una tabla en un espacio de tabla segmentado (no UTS) o espacio de tabla universal)

Para espacios de tabla no segmentados, cada una de estas sentencias hace que se registren cronológicamente todos los datos de la base de datos que cambian. Por ejemplo, si una tabla contiene 200 millones de filas de datos, esta información sobre datos y control se registra si todas las filas de una tabla se suprimen con la sentencia de SQL DELETE. No se toma ningún punto de confirmación intermedio durante esta operación.

Para espacios de tabla segmentados (no UTS) y espacios de tablas universales, una supresión masiva da como resultado el registro cronológico de los datos de los registros suprimidos cuando se cumple alguna de las condiciones siguientes:

  • La tabla es la tabla padre de una restricción referencias.
  • La tabla está definida como DATA CAPTURE(CHANGES), lo que hace que se registre información adicional para ciertas operaciones de SQL.
  • Hay un desencadenante de supresión definido en la tabla.
TRUNCATE TABLE
Básicamente una supresión masiva que no activa desencadenantes de supresión
Sentencias de definición de datos
Registro cronológico para el descriptor de la base de datos entera para la que se ha realizado el cambio. Para DBD muy grandes, esto puede significar una gran cantidad de registro cronológico.
Modificación de filas que contienen datos LOB o XML
Datos en tablas que contienen datos LOB o XML.

Procedimiento

Para controlar el uso de espacio de registro por parte de sentencias de SQL potentes:

  • Para operaciones de supresión masiva, considere la posibilidad de utilizar espacios de tabla segmentados (no UTS) o espacios de tablas universales. Si estos tipos de espacio de tabla no son una opción, y no existen desencadenantes en la tabla o la aplicación puede ignorar de forma segura los desencadenantes de la tabla, cree una tabla por cada espacio de tabla y utilice TRUNCATE.
  • Para insertar una gran cantidad de datos, en lugar de utilizar una sentencia de SQL INSERT utilice el programa de utilidad LOAD con LOG(NO) y realice una copia en línea.
  • Para actualizaciones, tenga en cuenta la carga de trabajo cuando defina las columnas de una tabla.
    La cantidad de datos que se registra para una actualización depende de si la fila contiene o no columnas de longitud fija. Para filas no comprimidas de longitud fija, los cambios se registran solo desde el principio de la primera columna actualizada hasta el final de la última columna actualizada. Por lo tanto, debe mantener las columnas actualizadas con frecuencia cercanas entre sí para reducir las cantidades de registro.

    Para las filas de longitud variable (las filas de longitud variable contienen una o varias columnas de longitud variable), los datos se registran desde el primer byte modificado hasta el final de la última columna actualizada si la longitud no ha cambiado. Sin embargo, en los casos en los que la longitud cambia, que son habituales, los datos se registran desde el primer byte modificado hasta el final de la fila.

    Para determinar si una carga de trabajo realiza mucha actividad de lectura o mucha actividad de escritura, compruebe la velocidad de datos de registro. Encontrará la velocidad en el campo LOG RATE FOR 1 LOG (MB/SEC) de las estadísticas de registro. Determine el tamaño medio de registro y divídalo por 60 para obtener el número de bytes de registro que se escriben por segundo.

    • Si registra a una velocidad menor a 2 MB por segundo, la carga de trabajo realiza mucha actividad de lectura.
    • Si registra a una velocidad mayor a 20 MB por segundo, la carga de trabajo realiza mucha actividad de actualización.
    • De 2 a 20 MB por segundo, la carga de trabajo no es intensiva en lectura ni en actualización.
  • Si tiene muchas sentencias de definición de datos (CREATE, ALTER, DROP) para una sola base de datos, emítalas dentro de una sola unidad de trabajo para evitar registrar cronológicamente DBD modificado para cada sentencia de definición de datos.
    Sin embargo, tenga en cuenta que el DBD se bloquea hasta que se emite COMMIT.
  • Utilice la opción NOT LOGGED para los datos LOB o XML que necesiten actualización frecuente y para los que sea aceptable la concesión de no recuperabilidad de datos LOB o XML del registro. (Puede seguir utilizando el programa de utilidad RECOVER sobre espacios de tabla LOB o XML para recuperar información de control que asegure la coherencia física del espacio de tabla LOB o XML).
    Dado que los espacios de tabla LOB y XML definidos como NOT LOGGED no se pueden recuperar del registro de registro de Db2 , debe hacer un plan de recuperación para esos datos. Por ejemplo, si ejecuta actualizaciones por lotes, asegúrese de tomar una copia de imagen una vez finalizadas las actualizaciones.
  • Para datos que se modifican con poca frecuencia, excepto durante ciertos periodos como el proceso de fin de año, cuando se producen cambios frecuentes o grandes durante un breve periodo de tiempo:
    1. Realice una copia de imagen de los datos.
    2. Cambie el espacio de tabla a NOT LOGGED.
    3. Realice cambios masivos.
    4. Detenga otras actividades que actualicen los datos.
    5. Realice una copia de imagen de los datos.
    6. Cambie el espacio de tabla por LOGGED.
  • Para realizar cambios en tablas, como tablas de consulta materializadas, que contengan datos propagados, utilice la opción NOT LOGGED porque los datos existen en cualquier lugar.
    Si los datos resultan dañados, puede renovar toda la tabla a partir de la fuente original.