Windows 10 is still Windows… as always.

15 septiembre \15\+02:00 2020

En uno de mis ordenadores con Windows 10 el audio ha dejado de funcionar después de una de esas actualizaciones que se instalan “porque sí”. Sin ningún motivo aparente, sin ninguna explicación.

Un día arrancas el sistema y te das cuenta de que no suena. Y ves que el altavoz de la barra de tareas aparece con una X roja. Al pasar el ratón por encima aparece el mensaje “No Audio Output Device is enabled.”

A partir de ahí intentas todo tipo de soluciones. Desinstalar/instalar el “device”, actualizar el controlador, cambiar el controlador, usar el “troubleshooter”, editar el registry(!!)… Nada. Pero nada de nada.

El “device manager” dice que todo está OK: “This device is working properly.” Pero no. Ni “properly” ni mucho menos “working”. Ni un ruido. Muerto.

Buceando en la web me encuentro un artículo que habla de actualizaciones corruptas o incompletas. Así que me voy al “Windows Update” y me doy cuenta que ¡tampoco funciona! Las actualizaciones fallan con error 0x800f0900 una y otra vez:

También pruebo de todo según los artículos de la base de conocimiento de Microsoft, pero lo mismo: nada de nada.

Así que me estoy replanteando una reinstalación desde cero, con todo lo que ello supone… 😡😡😡

Y luego me llaman “raro” y “friki” porque uso Linux.

Windows 10 is still Windows…

Saludos.

Carlos.


Teradata 17.00

1 junio \01\+02:00 2020

Actualmente estoy probando Teradata 17.00 en SLES 12 SP3. (Es un pre-release).

 

TD 17.00 en SLES 12 SP3

 

Saludos.

Carlos.


Larry Higa’s Ratio, Product Join Indicator and Unnecessary I/O Indicator.

24 marzo \24\+02:00 2020

En Teradata (y en la mayoría de los RDBMS), el consumo de CPU y las actividades de I/O son métricas básicas cuando se trata de analizar el rendimiento de un sistema.
En todos los sistemas Teradata hay tareas que tienden a ser “CPU-bound” y otras tienden a ser “I/O-bound“. Es una buena idea determinar qué tareas encajan en cada categoría.
Las métricas de CPU e I/O se utilizan para hacerse una idea acerca de la eficiencia de las “queries” a la hora de consumir recursos de CPU e I/O. Estas métricas se pueden calcular fácilmente a partir de las tablas y vistas DBQL / PDCR utilizando las columnas AMPCpuTime y TotalIOCount.

Larry Higa’s Ratio (LHR).

Larry Higa era un especialista en temas de rendimiento de Teradata que encontró muy útil relacionar las métricas de CPU e I/O de una manera simple.
El Ratio de Larry Higa (Larry Higa’s Ratio – LHR) es un índice empírico que muestra la tasa de CPU frente a I/O.
La experiencia muestra que la mayoría de las solicitudes de SQL consumen alrededor de 1 segundo de CPU por cada 1000 operaciones de I/O. La desviación de esta constante indica predominio de CPU o I/O, lo que significa un consumo de recursos desequilibrado.

Product Join Indicator (PJI).

El “Product Join Indicator” es la aplicación del principio LHR desde el punto de vista del consumo de CPU:

PJI = CPU Seconds * 1000 dividido por I/O.

Esto se traduce a las columnas DBQLogTbl como: PJI = (1000 * AmpCPUTime) / NullIfZero (TotalIOCount)

Un PJI relativamente alto para una consulta significa que la consulta está usando mucho CPU para las operaciones de I/O dadas.
El valor umbral para considerar PJI “alto” es algo difuso. Algunos dicen 3, algunos dicen 6, algunos dicen 10 … Pero en general, cuanto mayor es PJI menor es la eficacia en el uso de los recursos de CPU (se consume demasiada CPU).

No obstante, podemos encontrar “falsos positivos” en los PJI.
Las “queries” pueden arrojar falsos positivos PJI (alto consumo de CPU por I/O) cuando hay en ellas:
· Agregaciones grandes o muchos grupos de agregación (GROUP BY).
· Numerosos SUBSTRINGS.
· Cláusulas CASE.
· Uso de INDEX / POSITION en cadenas de caracteres.
· Operaciones aritmeticas.
· Comprobaciones de filas duplicadas (INSERTAR filas con el mismo “rowhash” en tablas SET con NUPI).
· Tareas de compresión / descompresión de bloque de datos para actividades de compresión a nivel de bloque (BLC – “block level compression”).

Unnecessary I/O Indicator (UII).

El “Unnecessary I/O Indicator” es la aplicación del principio LHR desde el punto de vista de I/O:

UII (Unnecessary I/O Indicator) = I/O dividida por (CPU Seconds * 1000).

Esto se traduce a las columnas DBQLogTbl como: UII = TotalIOCount / (1000 * NullIfZero (AMPCpuTime))

Cuando una “query” presenta un UII alto generalmente significa que se leen muchos bloques de I/O, pero en realidad se procesa un número relativamente pequeño de filas. Un ejemplo podría ser un “full table scan” que devuelva un resultado de unas pocas filas. En este caso el uso de un índice (secondary, join index…) podría reducir el consumo de I/O. igual que con el PJI, el valor umbral para considerar un UII “alto” también es difuso pero, en general, cuanto mayor es el UII, mayor es la sobrecarga de I/O provocada por una “query”.

Algunas acciones pueden ayudar a reducir el UII:
· Agregar índices secundarios, join indexes, hash indexes, sparse indexes.
· Recopilación / actualización de estadísticas en todas las columnas de “JOIN” y de selección (WHERE).
· Elegir los tipos de datos (y los juegos de caracteres) correctos para limitar el almacenamiento necesario para las columnas y filas.
· Usar MVC (“multi value compression”) para reducir el tamaño de fila y obtener más filas por bloque.
· Usar PPI (y column-PPI).
· Aumentar el tamaño de los “datablocks”.
· Usar el modelo de datos en tercera forma normal (3NF) para obtener filas más pequeñas, más filas por bloque, menos I/O y desnormalizar después si es necesario.
· Aumentar la memoria del nodo, para ampliar el tamaño de la caché FSG.
· BLC también puede ayudar a reducir I/O y aumentar la utilización de FSG.

Saludos.

Carlos.


Teradata available for Google Cloud

5 noviembre \05\+02:00 2019

La oferta de Teradata “on cloud”  se amplía. Hace ya tiempo que Teradata Vantage está disponible para AWSMicrosoft Azure, y ahora lo va a estar también en Google Cloud.

Más información en la nota de prensa.

Saludos.

Carlos.


Teradata New Developer Site

4 noviembre \04\+02:00 2019

Teradata tiene un nuevo “Developer Site”.

TeradataDeveloperSite

Se accede por aquí: https://www.teradata.com/Developer o por aquí: https://developer.teradata.com/

… ¡y en “dark mode”!

Saludos.

Carlos.

 


Hewlett Packard compra MapR

6 agosto \06\+02:00 2019

Hewlett Packard acaba de comprar MapR.

Después de la fusión de Cloudera con HortonWorks parece que el mundo del Hadoop tal y como fue pensado (open-source, commodity hardware, community mantained…) ha tenido mejores épocas, si no es que ha pasado a mejor vida.

Saludos.

Carlos.


Zapas Nuevas

2 agosto \02\+02:00 2019

Adidas Solar Glide, son básicamente las mismas Supernova con las que he corrido este último año.

Saludos.

Carlos.


Time to die…

24 julio \24\+02:00 2019

“Todos esos momentos se perderán en el tiempo, como lágrimas en la lluvia. Es hora de morir” 😪😪😪

https://www.fotogramas.es/noticias-cine/a28496491/rutger-hauer-muere-blade-runner/

Saludos.

Carlos.


Cloudera kaputt?

11 junio \11\+02:00 2019

Pues parece que muy bien no está…

… y MapR tampoco parece estar mucho mejor…

Y esto del hadoop era lo que iba a borrarnos del mapa a nosotros los dinosaurios de los Datawarehouses. En fin…

Saludos.

Carlos.


openSuSE Leap 15.0

13 mayo \13\+02:00 2019

He reciclado un viejo portátil y le he puesto openSuSE 15.0 con KDE.

 

 

Veremos a ver qué tal (de momento, problemas con el adaptador WiFi).

Saludos.

Carlos.