From Kenzie to Kovacs…

22 febrero \22\UTC 2015

El título de esta entrada es un guiño a la fabulosa From Hank to Hendricks, de Neil Young y sirve para describir cómo he pasado de leerme de un tirón los seis libros de Kenzie & Gennaro a devorarme la trilogía de Takeshi Kovacs, de Richard K. Morgan.

Comencé con “Carbono Alterado” (“Altered Carbon“) por recomendación de mi amigo T. Y me gustó tanto que me leí las otras dos (“Broken Angels” y “Woken Furies”) sin parar y en inglés, ya que todavía no las han traducido al castellano.

“You’re never going to get away with this, Kovacs. They’ve got. They’ve got you looking for you, man.”

Altamente recomendables.

Saludos.

Carlos.


DIRTY READS

13 febrero \13\UTC 2015

 

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.


SQL is not dead yet…

10 febrero \10\UTC 2015

Por mucho que los jóvenes cachorros del “big data” lo vayan diciendo por ahí, el “good old” SQL no está muerto

Saludos.

Carlos.


Teradata Unity implementation workshop

10 enero \10\UTC 2015

Esta semana la he pasado haciendo el Teradata Unity implementation workshop. Un ‘hands on workshop‘ que te da la oportunidad de conocer, utilizar y experimentar con los diferentes productos del ecosystem de Teradata Unity y las interacciones entre ellos.

El curso ha sido interesantísimo y el monitor, además de saber un montón, ha resultado ser un tipo encantador.

Teradata Unity implementation workshop

Teradata Unity implementation workshop

Una semana muy bien aprovechada…

Saludos.

Carlos.


С Новым Годом

31 diciembre \31\UTC 2014

Feliz Año Nuevo.

Happy New Year.

Y a ver si el 2015 es un poquito mejor que el puto 2014, hostia.

Saludos.

Carlos.


Feliz Navidad

24 diciembre \24\UTC 2014

Feliz Navidad a todos los seguidores, habituales u ocasionales.

Hay muchos villancicos para elegir, pero me quedo con el “River” de Joni Mitchell. A disfrutarlo.

Feliz Navidad, Merry Christmas.

Saludos.

Carlos.


Now listening to…

12 diciembre \12\UTC 2014

Heidi Andresen & Band: “No Name“. Blues-Rock noruego (de Oslo) con una de esas voces de chica que me gustan tanto, y esas guitarras…

Saludos.

Carlos.


Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 54 seguidores