DIRTY READS

 

Teradata funciona en ISOLATION LEVEL SERIALIZABLE por defecto. Esto significa que para garantizar la integridad de los datos se implementan bloqueos que impiden modificaciones de los mismos por otras transacciones mientras estos están siendo leídos. Esta política de bloqueos es bastante restrictiva en sí (READERS BLOCK WRITERS) aunque es la más segura a la hora de garantizar integridad. Hay que tener en cuenta que en Datawarehouses lo normal es leer mucho y modificar poco (READERS DON’T BLOCK READERS). Otras bases de datos más orientadas a OLTP funcionan de otras formas (READ COMMITED en Oracle, por ejemplo. READERS DON’T BLOCK WRITERS)

Teradata nos permite relajar los bloqueos de lectura de forma que no interfiramos la actividad de actualización de tablas sobre las que únicamente queremos leer para que otras transacciones puedan desarrollar dichas actividades de actualización. La forma más habitual de hacerlo es con el modificador LOCKING … FOR ACCESS. Con este modificador podremos leer los datos sin bloquearlos, permitiendo actividades de actualización por parte de otras transacciones. Pero a un coste: estaremos permitiendo los llamados ‘dirty reads’: lectura de datos modificados por otras transacciones pero sobre los que no se ha hecho COMMIT (ISOLATION LEVEL READ UNCOMMITED). Esto puede tener consecuencias no deseadas.

Lo podemos ver con un ejemplo ‘de la vida real’. Uso la siguiente ‘query‘ para monitorizar la actividad sobre una tabla por parte de un agente externo que realiza constantes borrados e inserciones sobre ella:

 BTEQ -- Enter your SQL request or BTEQ command:
LOCKING TABLE THE_DATABASE.THE_TABLE FOR ACCESS
SELECT CURRENT_TIMESTAMP (FORMAT 'YYYY-MM-DDbhh:mi:ss') FECHA,
       ZEROIFNULL(SUM (CASE WHEN TS_PROCESADO IS NULL 
                            THEN 1 ELSE 0 END)) PENDIENTES,
       ZEROIFNULL(SUM (CASE WHEN TS_PROCESADO IS NOT NULL 
                            THEN 1 ELSE 0 END)) PROCESADOS,
       PENDIENTES + PROCESADOS TOTAL,
       MAX(TS_TIMESTAMP) ULTIMO_INSERTADO
  FROM THE_DATABASE.THE_TABLE
;


 *** Query completed. One row found. 6 columns returned.
 *** Total elapsed time was 1 second.

              FECHA PENDIENTES PROCESADOS TOTAL    ULTIMO_INSERTADO
------------------- ---------- ---------- ----- -------------------
2015-02-11 09:36:00          5         15    20 2015-02-11 09:36:00

 BTEQ -- Enter your SQL request or BTEQ command:
=1


 *** Query completed. One row found. 6 columns returned.
 *** Total elapsed time was 1 second.

              FECHA PENDIENTES PROCESADOS TOTAL    ULTIMO_INSERTADO
------------------- ---------- ---------- ----- -------------------
2015-02-11 09:36:02          0         20    20 2015-02-10 12:32:17

Aquí se ve como en la primera ejecución de la query estábamos leyendo datos modificados por una transacción del agente (había borrado cinco filas y las había vuelto a insertar como ‘pendientes’) pero sobre los que aun aun no había efectuado un COMMIT. Por algún problema en la transacción -o por una orden explícita- ésta es abortada con el consiguiente ROLLBACK, de tal forma que las segunda ejecución de nuestra SELECT (apenas dos segundos después) muestra los datos tal y como estaban al comienzo de la transacción abortada.

Hay que hacer notar que, al no existir un COMMIT, hemos leído datos que nunca han existido “realmente” en la base de datos.

Como siempre: no se trata de que esto sea algo malo o bueno, se trata de saber las necesidades y asumir los posibles efectos de aplicar las diferentes técnicas.

Nota: mis compañeros A. y N. lo vieron ‘in situ‘ y me animaron a escribir esto.

Saludos.

Carlos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: