MariaDB / El area de diagnosticos

Bienvenidos sean a este post, hoy veremos que es el area de diagnosticos.

En el post anterior vimos como es la depuracion de una forma introductoria y mencionamos que todo se maneja en un lugar llamado area de diagnosticos, en el post de hoy nos centraremos en ella, para comenzar mencionaremos que esta dividida en dos partes: La informacion de instrucion y la informacion de condicion; la primera a su vez se compone de dos valores:

• NUMBER, este indica el numero de condiciones almacenadas en el area de condicion
• ROW_COUNT, son la cantidad de filas afectadas por la ejecucion, es el mismo valor devuelto por la funcion ROW_COUNT() y la funciion mysql_affected_rows() de la API

Esta area se completa y vacia sigiendo siempre las mismas reglas, si uno las conoce perfectamente sabra evitar inconvenientes y podra hacer una perfecta depuracion de los programas almacenados.

Cuando una ejecucion genera al menos una condicion (nota, aviso o error) el area de diagnostico se completa con tales condiciones, haciendo que cualquier condicion anterior en el area sea eliminada, aunque tenemos una excepcion: si la nueva ejecucion es RESIGNAL o GET CONDITIONS las condiciones viejas no son eliminadas; esto es muy util para los desarrolladores, estas ejecuciones estan pensadas para manejar los errores inclusive cuando no son exitosas, el usuario necesita aun necesita leer las viejas condiciones, sin embargo una mala ejecucion de estos comandos puede generar que se vacie el area.

Federico Razzoli

Sin embargo si ninguna ejecucion produce algun error o accede a alguna tabla el area no es vaciada preservando todas las viejas condiciones, pero si accedemos a una tabla automaticamente se elimina el contenido sin importar si genero una condicion o no, por otro lado el sistema posee una variable llamada max_error_count la cual usa para saber cual es la cantidad maxima de condiciones que puede almacenar, para entender este concepto vamos a pasar a un par de ejemplos, primero ejecutemos esta linea:

MariaDB [(none)]> set sql_mode='x';

Al ejecutarla nos devolvera el siguiente error:

MariaDB [(none)]> set sql_mode='x';
ERROR 1231 (42000): Variable 'sql_mode' can't be set to the value of 'x'
MariaDB [(none)]>

Si ejecutamos a SHOW WARNINGS veremos lo siguiente:

MariaDB [(none)]> show warnings\G
*************************** 1. row ***************************
  Level: Error
   Code: 1231
Message: Variable 'sql_mode' can't be set to the value of 'x'
1 row in set (0.000 sec)

MariaDB [(none)]>

Como podemos ver tenemos la notificacion del error ocurrido anteriormente, pasemos a ejecutar lo siguiente:

MariaDB [(none)]> set sql_mode = 'STRICT_ALL_TABLES';

Esto no nos devolvera ningun error porque si podemos establecer ese valor a sql_mode pero que sucedera si ejecutamos nuevamente a SHOW WARNINGS? veamos:

MariaDB [(none)]> show warnings\G
*************************** 1. row ***************************
  Level: Error
   Code: 1231
Message: Variable 'sql_mode' can't be set to the value of 'x'
1 row in set (0.001 sec)

MariaDB [(none)]>

En este caso al no haber ocurrido ningun error o haber trabajado sobre alguna tabla el area no fue afectada y siguio manteniendo la ultima condicion almacenada, ejecutemos lo siguiente:

MariaDB [(none)]> drop table information_schema.columns;

Esto nos devolvera un error y si lo vemos con SHOW WARNINGS veremos lo siguiente:

MariaDB [(none)]> show warnings\G
*************************** 1. row ***************************
  Level: Error
   Code: 1044
Message: Access denied for user 'tinchicus'@'localhost' to database 'information_schema'
1 row in set (0.000 sec)

MariaDB [(none)]>

Como podemos ver al no permitirnos eliminarlo lo almaceno como un error y por ende elimino el anterior y lo reemplazo con este, prueben de ejecutar unicamente a RESIGNAL y luego llamemos nuevamente a SHOW WARNINGS para ver su salida:

MariaDB [(none)]> resignal;
ERROR 1645 (0K000): RESIGNAL when handler not active
MariaDB [(none)]> show warnings\G
*************************** 1. row ***************************
  Level: Error
   Code: 1044
Message: Access denied for user 'tinchicus'@'localhost' to database 'information_schema'
*************************** 2. row ***************************
  Level: Error
   Code: 1645
Message: RESIGNAL when handler not active
2 rows in set (0.000 sec)

MariaDB [(none)]>

Esto lo que hablamos un poco anteriormente si tenemos un error y pasamos otra ejecucion que se interpreta correctamente pero no tiene ninguna falla de sintaxis o involucre a una tabla esta se agrega a la anterior, esta al momento de verificar nos devolvera todas las existentes pero que sucederia si nosotros ejecutamos una consulta correctamente que involucre a una tabla? veamos:

MariaDB [(none)]> select count(*) from mysql.user\G
*************************** 1. row ***************************
count(*): 2
1 row in set (0.001 sec)

MariaDB [(none)]> show warnings\G
Empty set (0.000 sec)

MariaDB [(none)]>

Esto es lo mencionado al comienzo, cada vez que consultemos una tabla ya sea modificandola o simplemente leyendo nuestra area de diagnostico se limpiara automaticamente aunque no haya ninguna condicion en dicha ejecucion, tengan esto en cuenta a la hora de hacer la depuracion, si se lo estan preguntando max_error_count tiene un valor predeterminado de 64, su valor minimo es 0 y el maximo es 65535.

En resumen, hoy hemos visto como trabaja el area de diagnostico, como trabaja, en que nos ayuda, como es su conducta, algunas conductas extras, por ultimo hemos visto por medio de ejemplos como se comporta, espero les haya sido de utilidad sigueme en tumblr, Twitter o Facebook para recibir una notificacion cada vez que subo un nuevo post en este blog, nos vemos en el proximo post.