Not orange anymore (almost)

9 octubre \09\UTC 2018

Teradata cambia de imagen, de logo y de color corporativo:

Teradata new logo

Después de tantos años siendo naranja, sólo queda el punto… (sign of the times?)

Saludos.

Carlos.

Anuncios

Cloudera+Hortonworks=Cloudworks? Hortondera?

4 octubre \04\UTC 2018

Cloudera y Hortoworks anuncian su fusión después de años compitiendo.

Unas pocas reflexiones:

·No hay sitio en el Hadoop para dos: el negocio no da para tanto.

·Mala suerte para los que han abrazado cualquiera de las dos tecnologías (y aun peor para los que migraron de una a otra): habrá que hacer migraciones al nuevo “producto final” tras la fusión tarde o temprano (¿Qué pasa con las inversiones hechas?).

·¿Y qué pasa con los productos análogos de cada compañía que antes competían entre sí? ¿Cuál prevalecerá? ¿Cuál será discontinuado?

Ah, el Big Data, el Hadoop, el…

Saludos.

Carlos.

 

 


Remedy

27 septiembre \27\UTC 2018

Creo que el diablo tiene un sitio reservado en el infierno para el tío que inventó el Remedy .

Saludos.

Carlos.


DBQLObjTbl: ¿Acceso a vistas sin acceso a tablas?

21 septiembre \21\UTC 2018

(Based on a true story)

El cliente para el que estamos trabajando viene y nos pide que verifiquemos si se está accediendo a dos tablas que quiere eliminar (las llamaremos DBTablas.Tabla1 y DBTablas.Tabla2).

Chupado: vamos a DBQLObjTbl y vemos que, aunque hay algunos INSERTs y DELETEs (los de los procesos de carga), nadie ha hecho ningún SELECT sobre ellas desde hace semanas. Así se lo decimos.

Pero al rato vuelve y nos dice “pues hay algo que no me cuadra, porque a mí sí me salen SELECTs”.

Tras un par de miradas incrédulas, le decimos “muéstranoslo”.

Entonces va él y hace una “query” a DBQLSQLTbl con un “LIKE” con el nombre de la tabla en cuestión y obtiene múltiples resultados recientes de “queries” de tipo:

SELECT * FROM DBVistas."Tabla1"

Es decir, “queries” a una capa de acceso de vistas construídas sobre las tablas que estamos mirando.

Nuestra primera respuesta es: “OK. Eso es porque esas “queries” se han hecho con un usuario que no tiene activada la opcion OBJECTS en su QUERY LOGGING, por eso no las vimos cuando investigamos”.

Pero miramos el DBQLObjTbl para una de estas “queries” (por su QueryId) y vemos que la opción de QUERY LOGGING sí está activa para el usuario, pero que sólo hay registrados accesos a la base de datos de las vistas y a la vista:

QueryID ObjectDatabaseName ObjectTableName ObjectType
------- ------------------ --------------- ----------
nn...nn DBVistas           (null)          DB
nn...nn DBVistas           Tabla1          Viw

WTF???

¿Cómo es posible? ¿Cómo va a haber accesos a una vista sin accesos a su tabla subyacente? ¡Eso es imposible!

Miramos entonces DBQLStepTbl y vemos que no hay “steps” reales, sólo aparece el “step” virtual “RESP”.

Vamos a DBQLExplainTbl y vemos que el “query plan” existe y es correcto:

Explain:
  1) First, we lock DBTablas.Tabla1 in view DBVistas.Tabla1 for access
     With NoWait option. 
  2) Next, we do an all-AMPs RETRIEVE step from DBTablas.Tabla1 in view
     DBVistas.Tabla1 by way of an all-rows scan with no residual
     conditions into Spool 1 (group_amps), which is built locally on
     the AMPs. The size of Spool 1 is estimated with high confidence
     to be 666,458,833 rows (316,567,945,675 bytes). The estimated
     time for this step is 18.06 seconds. 
  -> The contents of Spool 1 are sent back to the user as the result of
     statement 1. The total estimated time is 18.06 seconds.

Más WTF!!!

Así que volvemos a mirar DBQLogTbl.

Y ahora nos damos cuenta de varias cosas:

No hay I/O, no hay AMPCPUTime, el NumSteps=0, y sólo hay un pequeño intervalo de “Parsing” (ParserCPUTime=0,02).

Pero lo más importante viene luego:

TxnMode=ANSI y RequestMode=Prep. Además, AppId=SAS.

Aquí es donde empezamos a ver la luz: resulta que esas “queries” ‘SELECT * FROM DBVistas.”Tabla1″‘ no están siendo ejecutadas, sino que sólo se realiza el “Parsing” (RequestMode=Prep), ya que SAS las envía como “PreparedStatement”. Seguramente se hace como algún mecanismo de comprobación rápida de existencia de objetos en la base de datos. Esto hace que sólo se verifiquen los objetos necesarios para la resolución de la “query”: la base de datos de vistas y la vista, que son los que efectivamente aparecen en DBQLObjTbl.

Para corroborar el argumento, ejecutamos la misma “query” y observamos como esta vez en DBQLObjTbl aparecen, además de los accesos a la base de datos de las vistas y la vista, accesos a la base de datos de las tablas, la tabla y sus columnas (es decir: lo normal y esperado).

Así que si eres, como yo, un buceador del “DBQL”, ten en cuenta que los “PreparedStatements” sólo accederán a los objetos primarios de la “query” para satisfacer la resolución de la misma, pero no a los objetos subyacentes. Al menos hasta que ésta no se ejecute realmente (con un executeQuery(), por ejemplo).

Saludos.

Carlos.


Big Data: el rey está desnudo.

18 septiembre \18\UTC 2018

Big Data, Big Data, Big Data, Big Data,Big Data…

Todo es Big data. Si no tienes Big Data, no eres nadie.

Pues resulta que sólo el 15% de los proyectos de Big Data llegan a Producción. Y la fuente original del dato no soy yo, es Gartner.

Eso quiere decir que la cantidad de tiempo, dinero, recursos que se va a la basura con esto del Big Data es inimaginable…

“¡El rey está desnudo!”

Saludos.

Carlos.

 


Convertir filas a cadenas en Teradata (III)

10 septiembre \10\UTC 2018

Bueno, pues otra forma más de convertir (concatenar) filas a cadenas (además de lo dicho ya antes aquí y aquí ): utilizar una udf “secreta” e indocumentada llamada udfConcat:

SELECT TDSTATS.udfConcat(TheCol)
FROM ( SELECT 'Uno' TheCol FROM (SELECT DATE a) A
        UNION ALL
       SELECT 'Dos' TheCol FROM (SELECT DATE a) A
) pre;


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

udfConcat(TheCol)
---------------------------------------------------------
"Uno","Dos"

 BTEQ -- Enter your SQL request or BTEQ command:

Cosas a tener en cuenta:

Es una función “de conveniencia” para la gestión de estadísticas y reside en la base de datos TDSTATS.

En principio, los usuarios no tienen privilegios de ejecución (EXECUTE FUNCTION) sobre ella.

Recibe un único parámetro de entrada VARCHAR(128) (el valor máximo que debería tener un nombre de columna).

Su tipo de retorno es VARCHAR(10000) CHARACTER SET UNICODE.

Saludos.

Carlos.


Dropbox, XFS, ext4

21 agosto \21\UTC 2018

Desde hace unos días, cada vez que arranco mi openSuSE Leap 42.3 me aparece un mensaje:

“Move Dropbox location. Dropbox will stop syncing in November”

Así, sin más explicaciones.

Después de investigar un poco, me entero de que:

“The Dropbox folder will need to be on an ext4-formatted hard drive or partition”

Y, claro, resulta que yo tengo Dropbox sincronizado en un directorio ubicado en una partición con XFS (que es donde reside el “mountpoint” /home ).

¿Qué hacer? Pues ni de coña voy a cambiar toda la partición /home de XFS a ext4.

Así que creo que me va a tocar recortar un poco la partición XFS donde está /home con gparted y crear una partición nueva con filesystem ext4 en el espacio sobrante. Luego, mover allí el directorio de sincronización de Dropbox…

Gracias por nada, Dropbox.

Saludos.

Carlos.