Bases de datos
En tablas donde hay cambios constantemente como un mantenimiento más de la BD, hay que reconstruir los índices B-TREE de forma periódica, por ejemplo (la sintaxis es más compleja):
ALTER INDEX SCOTT.PK_EMP REBUILD;Un B-TREE ideal tiene todas las ramas perfectamete equilibradas, un B-TREE degradado puede ofrecer tiempos de búsqueda lineales en lugar de logarítmicos debido a un fuerte desequilibrio.
Para determinar si un índice debe ser reconstruido:
Cada nueva versión del optimizador cada vez es más dependiente de las estadísticas, la calidad de ellas puede ser suficiente para una versión anterior pero para la actual no.
Como regla general se ha de analizar una tabla (en casacada, es decir incluyendo índices) cuando se realizan modificaciones importantes sobre ella. Por ejemplo:
Las estadísticas se pueden obtener de muchas maneras, algunas más rápidas que otras (estimaciones parciales, completas, etc…) y con más o menos generación de redologs.
Por ejemplo si usamos el paquete DBMS_STATS (https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_stats.htm#ARPLS059) concretamente el subprograma GATHER_TABLE_STATS (https://docs.oracle.com/cd/E11882_01/appdev.112/e40758/d_stats.htm#ARPLS68582), la sintaxis es muy similar para los subprogramas:
No es una cosa que me guste especialmente, pero es posible que nos encontremos con personas que digan que si el rendimiento de la BD mejora mucho con los redolog en raw, frente a un sistema de ficheros (ext4 por ejemplo).
Para salir de dudas podemos trabajar con los redologs en modo RAW de forma muy sencilla. Vamos a poner un ejemplo hecho en Red Hat 4, con una BDD de pruebas con 3 redologs de 51 MB cada uno:
[oracle@clu01 DBU]$ ls -l
total 1502076
-rw-r----- 1 oracle oinstall 9748480 Jun 25 20:38 control01.ctl
-rw-r----- 1 oracle oinstall 9748480 Jun 25 20:38 control02.ctl
-rw-r----- 1 oracle oinstall 7061504 Jun 12 11:36 control03.ctl
-rw-r----- 1 oracle oinstall 52429312 Jun 25 11:06 redo01.log
-rw-r----- 1 oracle oinstall 52429312 Jun 25 10:39 redo02.log
-rw-r----- 1 oracle oinstall 52429312 Jun 25 10:39 redo03.log
-rw-r----- 1 oracle oinstall 545267712 Jun 25 20:38 sysaux01.dbf
-rw-r----- 1 oracle oinstall 744497152 Jun 25 20:38 system01.dbf
-rw-r----- 1 oracle oinstall 20979712 Jun 23 21:22 temp01.dbf
-rw-r----- 1 oracle oinstall 36708352 Jun 25 20:38 undotbs01.dbf
-rw-r----- 1 oracle oinstall 5251072 Jun 25 20:38 users01.dbfEsta vez vamos a ver la forma de realizar una tarea programada dentro de MySQL (salvando las distancias, un job de Oracle).
Primero tenemos que asegurarnos de que tenemos el scheduler arrancado esto lo vemos con un:
mysql> SHOW processlist;
+----+------+-----------------+------------+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------------+------------+---------+------+-------+------------------+
| 6 | root | localhost:49987 | assets_pru | Sleep | 299 | | NULL |
| 8 | root | localhost | assets_pru | Query | 0 | NULL | SHOW processlist |
+----+------+-----------------+------------+---------+------+-------+------------------+
2 rows IN SET (0.00 sec)No está arrancado, para esto tenemos que modificar un parámetro de my.cnf en la seccion mysqld:
Continuando con el tuning MySQL ahora vamos a tocar de forma específica el motor INNODB.
Esta entrada está relacianada con la «MySQL, tuning de parámetros para cualquier motor«, vamos a trabajar a partir de estados y según el resultado ver que variables podemos modificar para mejorar los resultados.
En la entrada «Variables y estados en MySQL» ya se trató el tema de las variables y estados del servidor.
La documentación de todos las variables la podemos encontrar en:
http://dev.mysql.com/doc/refman/5.5/en/dynamic-system-variables.html
En las versiones 10g y 11g de Oracle Database, se ha simplificado la configuración de las estructuras de memoria tanto para el SGA como el PGA de forma notable.
A partir de la versión 10g se introducen 2 nuevos parámetros de gestión de memoria que simplifican enormente esta tarea.
SGA_TARGET, simplemente se fija un valor y redimensiona a demanda los valores (siempre y cuando sean=0):
Muchas gente realiza instalaciones MySQL y no se preocupan de la parametrización. La parametrización es importantísima, una BD puede funcionar bien (de momento) con los parámetros por defecto, los problemas aparecen cuando la BD crece o aumenta su carga de trabajo.
En esta entrada trataremos los parámetros que pueden afectar al rendimiento de cualquier motor (los más usados son INNODB y MyISAM).
Las variables son usadas por el servidor para dimensionar estructuras de memoria cruciales para el buen rendimiento del motor de BD, los estados del servidor nos indicarán si las variables que hemos definido realmente están causando algún efecto positivo o por el contrario no sirven para absolutamente nada.
En algunas ocasiones es necesario realizar operaciones sobre una BD cuando está abierta, por ejemplo mover datafiles o poner tablespaces en read only.
Estas operaciones generalmente se pueden realizar con la BD en producción, pero el problema surge cuando tenemos una actividad alta y tenemos que realizar cambios en masa. En estos casos lo mejor es restringir el acceso a los usuarios, permitiendo solo accesos DBA (sys o system si no hemos creado ningún otro).
Podemos poner la BD en modo quiesce (quieto o inactivo), solo sys y system pueden crear nueva sesiones, el resto siguen existiendo hasta que terminan la transacción.
Para ver el estado de la BD:
Las tablas con objetos BLOB en tablespaces diferentes del resto de la tabla, tienen un tratamiento algo diferente.
Vamos a preparar un entorno de pruebas:
Creamos 2 tablespaces con:
CREATE SMALLFILE TABLESPACE "TS_PFIRMA_DATOS" LOGGING DATAFILE '/u01/app/oracle/oradata/PRUEBA/TS_PFIRMA_DATOS.dbf' SIZE 10M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;
CREATE SMALLFILE TABLESPACE "TS_PFIRMA_BLOB" LOGGING DATAFILE '/u01/app/oracle/oradata/PRUEBA/TS_PFIRMA_BLOB.dbf' SIZE 10M EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;Analizando el log del listener, por defecto «listener.log» en posible que veamos mensajes como:
23-FEB-2012 08:17:56 * service_update * BD01 * 0
23-FEB-2012 08:19:08 * service_update * BD02 * 0
23-FEB-2012 08:27:56 * service_update * BD01 * 0
23-FEB-2012 08:29:08 * service_update * BD02 * 0
23-FEB-2012 08:37:56 * service_update * BD01 * 0
23-FEB-2012 08:39:08 * service_update * BD02 * 0
23-FEB-2012 08:47:56 * service_update * BD01 * 0
23-FEB-2012 08:49:08 * service_update * BD02 * 0
23-FEB-2012 08:57:59 * service_update * BD01 * 0
23-FEB-2012 08:58:08 * service_update * BD02 * 0
23-FEB-2012 09:03:59 * service_update * BD01 * 0
23-FEB-2012 09:05:08 * service_update * BD02 * 0
23-FEB-2012 09:12:59 * service_update * BD01 * 0
23-FEB-2012 09:14:23 * service_update * BD02 * 0