5.1 Respaldo y Recuperación
Es posible generar periódicamente copias de respaldo y
conservar una serie de versiones anteriores. Cada copia de respaldo estará
identificada por tiempo y fecha y por la última transacción incluida. Una copia
de respaldo debe generarse mientras la base de datos esta en reposo, ya que las
actualizaciones durante el copiado pueden provocar que la copia se
inconsistente.
Recuperación.
A continuación se presentaran una serie de pasos que podrán seguirse cuando se presente una falla en el sistema y se desee recuperar la información:
Detección del error.- el proceso de recuperación se inicia
al detectarla existencia de un error. Es posible distinguir una variedad de
puntos de entrada en le proceso de recuperación. Se considerarán fallas de sistemas detectadas por falta de acción del sistema o por verificaciones
irrecuperables de redundancia y salida incorrecta observada por un usuario.
Determinación de la fuente del error.- para decidir cual es
la mejor acción correctora es necesario determinar la extensión del daño. Desde
luego este esfuerzo es muy relacionado con la determinación del tiempo y la
causa del error. Después de una caida o cuando el procesamiento sea
interrumpido debido a una señal de error, es necesario determinar tantos
aquellas áreas del archivo de datos que sean sospechosas como cuál fue la
transacción que no se concluyo.
Ubicación de errores secundarios.- cuando se ha detectado un
error que provocó una modificación inadecuada a un archivo un rastreo a traves
de las listas de actividad encontrara aquellas transacciones que emplearon el
bloque correcto. Entonces es posible volver a introducir automáticamente el
bloque correcto de lñas transacciones afectadas y producir resultados
correctos. Si se actualizaron bloques mediante transacciones que leyeron
bloques incorrectos antes de existir es necesario restaurar a un más el
archivo.
Aplicación de correcciones. Si la extensión del daño es
limitada, puede utilizarse un proceso de volver a enrollar. Las porciones
dañadas del archivo se restauran aplicando primero aquellasimágenes anteriores
a los bloques en error reemplazando después de las transacciones incompletas.
La salida proveniente de estas trasacciones se suprime de ser posible, para
evitar duplicar resusltados que previamente se hayan enviado a los usuarios.
Mirroring SQL Server
El Mirroring (Base de Datos Espejo) proporciona una solución
de alta disponibilidad de bases de datos, aumenta la seguridad y la
disponibilidad, mediante la duplicidad de la base de datos.
Esta tecnología esta disponible a partir de la versión de
SQL Server 2005 (es la evolución del log shipping presente en versiones
anteriores)
En el Mirroring tenemos un servidor principal/primario que
mantiene la copia activa de la base de datos (bbdd accesible). Otro servidor de
espejo quemantiene una copia de la base de datos principal y aplica todas las
transacciones enviadas por el Servidor Principal (en el que no se podrá acceder
a la bbdd). Y un servidor testigo/arbitro que permite recuperaciones automáticas
ante fallos, monitoriza el servidor principal y el de espejo para en caso de
caída cambiar los roles (servidor opcional, no es obligatorio).
Existen varios tipos de mirroring:
Alta
disponibilidad: Garantiza la consistencia transaccional entre el servidor
principal y el servidor de espejo y ofrece Automatic Failover mediante
unservidor testigo.
Alta Protección:
Garantiza la consistencia transaccional entre el servidor principal y el
espejo.
Alto Rendimiento:
Aplica las transacciones en el Servidor Espejo de maneraasíncrona ocasionando
mejoras significativas en el rendimiento del servidor principal pero no
garantiza que dichas transacciones se hallan realizado de manera exitosa en el
espejo.
5.1.1 Espejeo (mirroring).
Espejeo de Datos en un DBMS.
1.-Base de Datos Espejo (Database Mirroring).
Donde actúan dos servidores
o más para mantener copias de la
base de datos y archivo de registro de transacciones.
El servidor primario como el servidor espejo mantienen una
copia de la base de datos y el registro de transacciones, mientras que el
tercer servidor, llamado el servidor árbitro, es usado cuando es necesario
determinar cuál de los otros dos servidores puede tomar la propiedad de la base
de datos. El árbitro no mantiene una copia de la base de datos. La
configuración de los tres servidores de base de datos (el primario, el espejo y
el árbitro) es llamado Sistema Espejo (Mirroring System), y el servidor primarioy
espejo juntos son llamados Servidores Operacionales (Operational Servers) o
Compañeros (Partners).
5.1.1.1 Beneficios del espejeo de Datos en un DBMS.
Esta característica tiene 3 modalidades que son Alto
rendimiento, Alta Seguridad, y Alta Disponibilidad, este caso estamos hablando
de las 2 primeras, las cuales el levantamiento es manual.
La creación de reflejo de la base de datos es una estrategia
sencilla que ofrece las siguientes ventajas:
- Incrementa la disponibilidad de una base de datos.
- Si se produce un desastre en el modo de alta seguridad con conmutación automática por error, la conmutación por error pone en línea rápidamente la copia en espera de la base de datos, sin pérdida de datos. En los demás modos operativos, el administrador de bases de datos tiene la alternativa del servicio forzado (con una posible pérdida de datos) para la copia en espera de la base de datos.
- Aumenta la protección de los datos.
La creación de reflejo de la base de datos proporciona una
redundancia completa o casi completa de los datos, en función de si el modo de
funcionamiento es el de alta seguridad o el de alto rendimiento. Para obtener
más información, vea Modos de funcionamiento, más adelante en este tema.
Un asociado de creación de reflejo de la base de datos que
se ejecute en SQL Server 2008 Enterprise o en versiones posteriores intentará
resolver automáticamente cierto tipo de errores que impiden la lectura de una
página de datos. El socio que no puede leer una página, solicita una copia
nueva al otro socio. Si la solicitud se realiza correctamente, la copia
sustituirá a la página que no se puede leer, de forma que se resuelve el error
en la mayoría de los casos.
Mejora la disponibilidad de la base de datos de producción
durante las actualizaciones.
Para minimizar el tiempo de inactividad para una base de
datos reflejada, puede actualizar secuencialmente las instancias de SQL Server
que hospedan los asociados de creación de reflejo de la base de datos. Esto
incurrirá en el tiempo de inactividad de solo una conmutación por error única.
Esta forma de actualización se denomina actualización gradual. Para obtener más
información, vea Instalar un Service Pack en un sistema con un tiempo de
inactividad mínimo para bases de datos reflejadas.
5.1.1.2 Activación de espejeo en un DBMS.
1. Asegúrese de que
las versiones de MySQL instalado en el maestro y en el esclavo son compatibles,
debe usar la versión más reciente de MySQL en maestro y servidor.
Por favor no reporte bugs hasta que ha verificado que el
problema está presente en la última versión de MySQL.
2. Prepare una
cuenta en el maestro que pueda usar el esclavo para conectar. Este cuenta debe
tener el privilegioREPLICATION SLAVE . Si la cuenta se usa sólo para
replicación (lo que se recomienda), no necesita dar ningún privilegio
adicional. (Para información sobre preparar cuentas de usuarios y privilegios.
Suponga que su dominio es mydomain.com y que quiere crear
una cuenta con un nombre de usuario de replque puedan usar los esclavos para
acceder al maestro desde cualquier equipo en su dominio usando una contraseña
de slavepass. Para crear la cuenta, use el comando GRANT:
mysql>gt; GRANT REPLICATION SLAVE ON *.*
->gt; TO 'repl'@'%.mydomain.com' IDENTIFIED BY
'slavepass';
Si quiere usar los comandos LOAD TABLE FROM MASTER o LOAD
DATA FROM MASTER desde el servidor esclavo, necesita dar a esta cuenta privilegios
adicionales:
- De a la cuenta el privilegio global SUPER y RELOAD .
- De el privilegio SELECT para todas las tablas que quiere cargar. Cualquier tabla maestra desde la que la cuenta no puede hacer un SELECT se ignoran por LOAD DATA FROM MASTER.
Si usa sólo tablas MyISAM , vuelque todas las tablas y
bloquee los comandos de escritura ejecutando un comandoFLUSH TABLES WITH READ
LOCK :
mysql>gt;
FLUSH TABLES WITH READ LOCK;
Deje el cliente en ejecución desde el que lanza el comando
FLUSH TABLES para que pueda leer los efectos del bloqueo. (Si sale del cliente,
el bloqueo se libera.) Luego tome una muestra de los datos de su servidor
maestro.
La forma más fácil de crear una muestra es usar un programa
de archivo para crear una copia de seguidad binaria de las bases de datos en su
directorio de datos del maestro. Por ejemplo. use tar en Unix, oPowerArchiver,
WinRAR, WinZip, o cualquier software similar en Windos. Para usar tar para
crear un archivo que incluya todas las bases de datos, cambie la localización
en el directorio de datos del maestro, luego ejecute el comando:
shell>
tar -cvf /tmp/mysql-snapshot.tar .
Si quiere que el archivo sólo incluya una base de datos
llamada this_db, use este comando:
shell>
tar -cvf /tmp/mysql-snapshot.tar ./this_db
Luego copie el archivo en el directorio /tmp del servidor
esclavo. En esa máquina, cambie la localización al directorio de datos del
esclavo, y desempaquete el fichero usando este comando:
shell>
tar -xvf /tmp/mysql-snapshot.tar
Puede no querer replicar la base de datos mysql si el
servidor esclavo tiene un conjunto distinto de cuentas de usuario a la
existente en el maestro. En tal caso, debe excluírla del archivo. Tampoco
necesita incluir ningún fichero de log en el archivo, o los ficheros
master.info o relay-log.info files.
Mientras el bloqueo de FLUSH TABLES WITH READ LOCK está en
efecto, lee el valor del nombre y el desplazamiento del log binario actual en
el maestro:
mysql >
SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB |
Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
|
mysql-bin.003 | 73 | test | manual,mysql |
+---------------+----------+--------------+------------------+
La columna File muestra el nombre del log, mientras que
Position muestra el desplazamiento. En este ejemplo, el valor del log binario
es mysql-bin.003 y el desplazamiento es 73. Guarde los valores. Los necesitará
más tarde cuando inicialice el servidor. Estos representan las coordenadas de
la replicación en que el esclavo debe comenzar a procesar nuevas
actualizaciones del maestro.
Una vez que tiene los datos y ha guardado el nombre y
desplazamiento del log, puede reanudar la actividad de escritura en el maestro:
mysql>gt; UNLOCK TABLES;
Si está usando tablas InnoDB , debería usar la herramienta
InnoDB Hot Backup. Realiza una copia consistente sin bloquear el servidor
maestro, y guarda el nombre y desplazamiento del log que se corresponden a la
copia para usarlo posteriormente en el esclavo. InnoDB Hot Backup es una
herramienta no libre (comercial) que no está incluída en la distribución de
MySQL estándar.
Sin la herramienta Hot Backup , la forma más rápida de hacer
una copia binaria de los datos de las tablasInnoDB es parar el maestro y copiar
los ficheros de datos InnoDB, ficheros de log, y ficheros de definición de
tablas (ficheros .frm). Para guardar los nombres de ficheros actual y
desplazamientos, debe ejecutar el siguiente comando antes de parar el servidor:
mysql>gt;
FLUSH TABLES WITH READ LOCK;
mysql>gt; SHOW MASTER STATUS;
Luego guarde el nombre del log y el desplazamiento desde la
salida de SHOW MASTER STATUS como se mostró antes. Tras guardar el nombre del
log y el desplazamiento, pare el servidor sin bloquear las tablas para
asegurarse que el servidor para con el conjunto de datos correspondiente al
fichero de log correspondiente y desplazamiento:
shell>gt; mysqladmin -u root shutdown
Una alternativa que funciona para tablas MyISAM y InnoDB es
realizar un volcado SQL del maestro en lugar de una copia binaria como se
describe en la discusión precedente. Para ello, puede usar mysqldump
--master-data en su maestro y cargar posteriormente el fichero de volcado SQL
en el esclavo. Sin embargo, esto es más lento que hacer una copia binaria.
Si el maestro se ha ejecutado previamente sin habilitar
--log-bin , el nombre del log y las posiciones mostradas por SHOW MASTER STATUS
o mysqldump --master-data están vacíos. En ese caso, los valores que necesita
usar posteriormente cuando especifica el fichero de log del esclavo y la
posición son una cadena vacía ('') y 4.
Asegúrese que
la sección [mysqld] del fichero my.cnf en el maestro incluye una opción log-bin
. Esta sección debe también tener la opción server-id=master_id , donde
master_id debe ser un entero positivo de 1 a 2^32 - 1. Por ejemplo:
[mysqld]
log-bin=mysql-bin
server-id=1
Si estas opciones no están presentes, añádalas y reinicie el
servidor. Pare el
servidor que se vaya a usar como esclavo y añada lo siguiente a su fichero
my.cnf :
[mysqld]
server-id=slave_id
El valor slave_id , como el valor master_id , debe ser un
entero positivo de 1 a 2^32 - 1. Además, es muy importante que el ID del
esclavo sea diferente del ID del maestro. Por ejemplo:
[mysqld]
server-id=2
Si está preparando varios esclavos, cada uno debe tener un
valor de server-id único que difiera del maestro y de cada uno de los otros
esclavos. Piense en los valores de server-id como algo similar a las
direcciones IP: estos IDs identifican unívocamente cada instancia de servidor
en la comunidad de replicación.
Si no especifica un server-id, se usa 1 si no ha definido un
master-host, de otro modo se usa 2. Tenga en cuenta que en caso de omisión de
server-id, un maestro rechaza conexiones de todos los esclavos, y un esclavo
rechaza conectar a un maestro. Por lo tanto, omitir el server-id es bueno sólo
para copias de seguridad con un log binario.
Si ha hecho
una copia de seguridad binara de los datos del maestro, cópielo en el
directorio de datos del esclavo antes de arrancar el esclavo. Asegúrese que los
privilegios en los ficheros y directorios son correctos. El usuario que ejecuta
el servidor MySQL debe ser capaz de leer y escribir los ficheros, como en el
maestro.
Si hizo una copia de seguridad usando mysqldump, arranque
primero el esclavo (consulte el siguiente paso).
Arranque el
esclavo. Si ha estado replicando préviamente, arranque el esclavo con la opción
--skip-slave-start para que no intente conectar inmediatamente al maestro. También
puede arrancar el esclavo con la opción --log-warnings (activada por defecto en
MySQL 5.0), para obtener más mensajes en el log de errores acerca de problemas
(por ejemplo, problemas de red o conexiones). En MySQL 5.0, las conexiones
abortadas no se loguean en el log de errores a no ser que el valor sea mayor
que 1.
Si hace una
copia de seguridad de los datos del maestro usando mysqldump, cargue el fichero
de volcado en el esclavo:
shell>gt;
mysql -u root -p
Ejecute los siguientes comandos
en el esclavo, reemplazando los valores de opciones con los valores relevantes
para su sistema:
mysql>gt; CHANGE MASTER TO
->gt; MASTER_HOST='master_host_name',
->gt; MASTER_USER='replication_user_name',
->gt; MASTER_PASSWORD='replication_password',
->gt; MASTER_LOG_FILE='recorded_log_file_name',
->gt;
MASTER_LOG_POS=recorded_log_position;
La siguiente tabla muestra la longitud máxima para las
opciones de cadenas de caracteres:
Arranque el flujo esclavo:
mysql>gt; START SLAVE;
Una vez realizado este procedimiento, el esclavo debe
conectar con el maestro y atapar cualquier actualización que haya ocurrido
desde que se obtuvieron los datos.
Si ha olvidado asignar un valor para server-id en el
maestro, los esclavos no son capaces de conectar.
5.1.1.3 Creación de espacios de disco con espejo.
- Necesitaras el programa R-Drive Image
- Ejecuta el programa R-Drive Image desde la ubicación en la que esté instalado.
- Haz clic en el botón "Crear imagen", que se localiza en la sección superior de la ventana principal del programa.
- Selecciona la unidad que quieres configurar como espejo de la lista de unidades disponibles y presiona el botón "Siguiente".
- Selecciona un destino para el espejo nuevo en la ventaja de navegación y haz clic en el botón "Siguiente". Éste puede colocarse en cualquier medio, como un CD, DVD u otro disco duro, dependiendo del tamaño que elijas para hacerlo.
- Presiona nuevamente el botón "Siguiente" de la página "Modo de imagen" y deja marcadas las opciones por defecto. Estas opciones son para usuarios avanzados que quieren crear espejos especializados en arreglos RAID o servidores NAS.
- Si lo deseas, introduce una contraseña para el espejo nuevo y haz clic en el botón "Siguiente".
- Presiona el botón "Iniciar" para comenzar a crear el espejo del disco duro. Este proceso tomará desde minutos a varias horas dependiendo de la velocidad y cantidad de información del disco duro que se esté configurando. Una ventana de diálogo aparecerá para informarte cuando el proceso haya sido completado exitosamente.
Una vez preparados los discos, para crear el RAID, y si
hemos seguido la misma estructura de mi ejemplo, usaremos las siguientes
órdenes, suponiendo que los discos nos los ha identificado como sda, sdb, sdc y
sdd:
mdadm
--create --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1
mdadm
--create --level=raid5 --raid-devices=4 /dev/sda3 /dev/sdb3 /dev/sdc3 /dev/sdd3
La primera orden nos creará un RAID de tipo RAID1 con sólo 2
componentes activos, empleando para ello la primera partición de cada disco.
Como le indicamos menos dispositivos de raid (2) que dispositivos físicos, lo
que hace es poner los otros dos como spares.
La segunda orden nos creará un RAID5 con la tercera
partición de todos los discos indicados. En este caso, el parámetro
--raid-devices=4 es superfluo y se podría omitir, ya que si no decimos nada
sobreentiende que queremos usar todos los discos.
Recomendaciones:
- Use una copia de seguridad completa muy reciente o una copia de seguridad diferencial reciente de la base de datos principal.
- Si se programa un trabajo de copia de seguridad de registros para que se ejecute muy a menudo en la base de datos principal, puede que sea necesario deshabilitar el trabajo de copia de seguridad hasta que se haya iniciado la creación de reflejo.
- Si es posible, la ruta de acceso (incluida la letra de unidad) de la base de datos reflejada debería ser idéntica a la de la base de datos principal.
- Si las rutas de acceso de archivo deben ser diferentes (por ejemplo, si la base de datos principal se encuentra en la unidad 'F:' pero el sistema reflejado no tiene unidad F:), se debe incluir la opción MOVE en RESTORE STATEMENT.
5.1.2.1 Beneficios de la réplica de Datos en un DBMS.
Ø El componente
encargado de lograr la atomicidad de una transacción se conoce como
administrador de transacciones.
Ø Las operaciones
COMMIT (comprometer o confirmar) y ROOLBACK (retroceder) son la clave de su
funcionamiento.
Ø La operación COMMIT
indica el término exitoso de una transacción.
Ø La operación ROLLBACK,
en cambio, nos indica el término no exitoso de una transacción.
Fallo en la transacción
- Error lógico (violación de restricciones, tipos incompatibles, etc.).
- Error del sistema (interbloqueos, espacio insuficiente, etc.).
- Fallo del sistema
- Error en la memoria volátil.
- Error en el funcionamiento del DBMS o del SO.
- Fallo de disco
- Errores de I/O
VOLÁTIL
- Memoria principal / caché (ej. RAM)
- Acceso rápido
- No sobrevive a las caídas
ESTABLE
- Se implementa a través de soluciones como los sistemas RAID o los Sistemas de Copia de Seguridad Remota.
- La información “nunca” se pierde.
5.1.3 Métodos de respaldo de un DBMS
Archivo de log:
- Identificador de la transacción
- Hora de modificación
- Identificador del registro afectado
- Tipo de acción
- Valor anterior del registro
- Nuevo valor del registro
- Información adicional
Checkpoint:
- Técnicas basadas en el registro histórico
- Paginación en la sombra o páginas en espejo
- Técnica de Recuperación Aries
5.1.3.1 Elementos y frecuencia de respaldo.
Secuencia de registros que mantiene un rastro de las
actualizaciones realizadas a la BD. Registros de inicio de Tx, Registros de compromiso de una
Tx, Registros de aborto de una Tx, Registros de actualización de una Tx:
Debe estar guardado en almacenamiento estable.
Se clasifican en:
Ø _ Técnica de
actualización diferida
Ø _ Técnica de
actualización inmediata
Retarda la actualización en la BD hasta que la transacción
se compromete (commit) parcialmente.
La base de datos se divide en un número determinado de
bloques de tamaño fijo (páginas).
En memoria volátil se mantiene la tabla actual y en memoria
estable una tabla doble (sombra).
La idea principal es mantener dos tablas de páginas durante
la vida de una transacción.
5.1.3.2 Comandos para respaldo de datos
Para hacer una copia de respaldo de una base de datos se
recomienda crear un dump.
Para hacer un dump
de todas las bases de datos es necesario ejecutar el comando:
mysqldump --user=****** --password=****** -A >
/Ruta/Hacia/archivo_dump.SQL
Para hacer un dump
de sólo algunas bases de datos es necesario ejecutar el comando:
Para hacer un dump
de todas las tablas de una base de datos es necesario ejecutar el comando:
mysqldump --user=****** --password=****** db >
/Ruta/Hacia/archivo_dump.SQL
Para hacer un dump
de sólo ciertas tablas de una base de datos es necesario ejecutar el comando:
mysqldump --user=****** --password=****** db --tablas tab1
tab2 > /Ruta/Hacia/archivo_dump.SQL
Para cada uno de estos comando es necesario indicar un
usuario (user) y la contraseña (password) con derechos de administrador en la
base de datos.
Restauración
Para restaurar un dump tan sólo hay que ejecutar el comando:
mysql --user=****** --password=****** db_nom <
/Ruta/Hacia/archivo_dump.SQL
5.1.3.3 Métodos de recuperación de un DBMS
Técnica de recuperación de aires
Representa a los métodos actuales de recuperación.
Ø Usa números de
secuencia del registro histórico (NSR) para implementar varias optimizaciones
que reducen el tiempo de recuperación.
Ø Estrategia robar/no
forzar para la escritura en disco:
Ø Escritura
anticipada en el log.
Ø Repetición de la
historia.
Ø Anotación en el log
de las modificaciones durante el deshacer
La recuperación consiste en tres pasos principales:
Ø Análisis:
Identifica las páginas sucias y el conjunto de transacciones activas en el
momento de la caída y el punto del logapropiado para empezar la operación
REHACER
Ø Rehacer: se
replican las operaciones del log.
Ø Deshacer: Se
recorre el log hacia atrás y se deshacen las transacciones activas en el
momento de la caída, o iniciadas después, de las que no se ha encontrado
confirmación.
5.1.4 Comandos para recuperación
Mantenimiento y monitoreo de la base
Respaldos
La manera usual de hacer un respaldo es usando el comando
mysqldump, que posee muchas opciones que permiten duplicar todas las base, una
base en particular, una tabla, solo los datos, solo la estructura, etc.
Para obtener un respaldo completo de una base
[digital@pcproal digital]$ mysqldump --opt -u carlos -p prueba >
prueba.bak
Para restaurar un respaldo completo de una base
[digital@pcproal digital]$ mysql -u carlos -p prueba < prueba.bak
Otra manera de hacer respaldos es através del comando
"select into" y restaurar los datos con "mysqlimport" o
"load data infile".
Redo Log Files: dos o más archivos donde se registra
cualquier modificación transacción al de una memoria intermedia de la BD.
Archivos de control:
metadatos necesarios para operar en la Base de Datos, incluyendo información
sobre copias de seguridad. Guían la recuperación.
Segmento Rollback:
guarda las últimas sentencias realizadas sobre la BD y sabe cuándo se ha
confirmado o no una transacción.
5.1.4.1 Ventajas y Desventajas de cada método
Procedimiento de Escritura:
1. Cuando se inicia una transacción ambas tablasson iguales.
2. Cuando se actualiza una página, se escribe la página
actualizada en una página no usada, y se actualiza la tabla actual para apuntar
a ésta (dejando la “sombra” sin modificar).
3. Cuando se confirma la transacción, la tabla depáginas
actual pasa a almacenamiento no volátil (se cambian las direcciones de las
tablas).
4. Si se produce un fallo, la tabla “sombra” se copia en la
“actual”.
5. No es necesario ni rehacer ni deshacer.
5.1.4.2 Aplicación de cada método
Ejemplo de
recuperación de aires
En la fase REHACER, empezando desde el mínimo NSD en la
tabla de páginas sucias(min(NSD)=1)) se rehacen las actualizaciones del log (en
este caso
NSD=1, 2, 6).
En la fase DESHACER, se deshacen las actualizaciones del log
de las transacciones no confirmadas (T3) (i.e.NSD=6).
Recuperación postgresql
Ø Recuperación
basada en WAL (Write – AheadLogging) con fases de Rehacer y Deshacer similares
a Aries.
Ø El directorio pg_xlog contiene los diarios de
escritura adelantada (WAL).
Ø Un archivo pg_clog
registra el estado actual de cada transacción.
5.2 Migración de la Base de Datos
Los conceptos esenciales de la migración describen cambios
realizados en el soporte para el desarrollo de aplicaciones, cambios el soporte
de nuevas funciones, funciones no soportadas y funciones en desuso que pueden
afectar a las aplicaciones de base de datos, scripts y herramientas.
Migración de aplicaciones de BD dentro de DB2
Cambios en el soporte de los sistemas operativos
Cambios en los controladores de las aplicaciones
Cambios en el soporte del software de desarrollo
Cambios en las API de DB2 y en los mandatos de DB2
Cambios en la sintaxis de las sentencias de SQL
Cambios en las vistas y rutinas administrativas de SQL y en
las vistas de catálogo
Paquetes de base de datos
Cambios en el soporte de 32 bits y 64 bits
Cambios en el comportamiento del servidor DB2
Soporte de conectividad de clientes DB2
5.3 Monitoreo y Auditoría de la Base de Datos
La auditoría y la protección de bases de datos (DAP)
representa un avance evolutivo importante con respecto a anteriores
herramientas de monitoreo de actividad en bases de datos (DAM). Los gerentes de
seguridad, los administradores de bases de datos (DBAs) y otros interesados,
que estén preocupados con proteger datos sensibles en las bases de datos, deben
evaluar estas herramientas.
5.3.1 Monitoreo
El término Monitoreo es un término no incluido en el
diccionario de la Real Academia Española (RAE). Su origen se encuentra en
monitor, que es un aparato que toma imágenes de instalaciones filmadoras o
sensores y que permite visualizar algo en una pantalla. El monitor, por lo
tanto, ayuda a controlar o supervisar una situación.
Esto nos permite inferir que monitoreo es la acción y efecto
de monitorear, el verbo que se utiliza para nombrar a la supervisión o el
control a través de un monitor. Por extensión, el monitoreo es cualquier acción
de este tipo, más allá de la utilización de un monitor.
5.3.1.1 Monitoreo general de un DBMS
DAP— un término que Gartner desarrolló para remplazar el
anterior concepto de DAM —se refiere a las suites de herramientas que se
utilizan para apoyar la identificación y reportar comportamiento inapropiado,
ilegal o de otra forma indeseable en las RDBMSs, con mínimo impacto en las
operaciones y la productividad del usuario. Estas suites han evolucionado de
herramientas DAM — que ofrecían análisis de la actividad del usuario en las
RDBMSs y alrededor de ellas— para abarcar un conjunto más integral de
capacidades, que incluyen:
Ø Descubrimiento y
clasificación.
Ø Gestión de
vulnerabilidades.
Ø Análisis al nivel
de aplicación.
Ø Prevención de
intrusión.
Ø Soporte de
seguridad de datos no estructurados.
Ø Integración de
gestión de identidad y acceso.
Ø Soporte de gestión
de riesgos.
5.3.1.2 Monitoreo de espacio en disco
El espacio en disco.
El abaratamiento de los discos ha reducido considerablemente
la incidencia del espacio ocupado por los usuarios. No obstante, los discos
requieren administración: hay que instalarlos, darles formato, montarlos en
otras máquinas, respaldarlos, monitorearlos. Aunque el espacio en disco sea
suficiente, es preciso insistir ante los usuarios para hacer un uso racional
del recurso.
Comandos para el monitoreo del espacio en disco
quot
du
El comando
du
da un resumen del uso de disco en una rama de directorios.
du -s /export/home/*
Muestra el total para cada rama de subdirectorio bajo
/export/home;
Esto no es efectivo para ver el consumo total de cada
usuario si los usuarios tienen archivos en otras partes del sistema.
df
El comando
df
Da un resumen del uso del espacio a nivel de todo el
sistema:
df
Muestra el espacio utilizado en cada sistema de archivos,
incluso a veces en los que están montados vía NFS. Si se indica uno en
particular, da el espacio utilizado en ese sistema de archivos: df /dev/hda2.
El comando
quot
Informa sobre el espacio en disco consumido por los usuarios
en cada sistema de archivos:
quot -f /dev/hda2
quot -f /dev/hda2
Proporciona una lista de la cantidad de bloques y archivos a
nombre de cada usuario.
5.3.1.3 Monitoreo de logs
Monitorear el log de transacciones es una de las actividades
más importantes para los administradores de bases de datos, ya que en caso de
que este llegara a llenarse, no podrían llevarse a cabo más transacciones sobre
esta base de datos quedando fuera de servicio.
Monitoreando el log de transacciones(SQL SERVER)
Monitorear el log regularmente puede ayudarnos a resolver
varios problemas dentro de nuestros sistemas, ya que este puede indicarnos si
existen demasiadas transacciones realizadas por una sola aplicación, que podría
resultar en un mal diseño o simplemente la necesidad de planear mejor los
recursos de log en nuestro servidor de base de datos.
Monitoreo de Logs
Una de ellas es mediante un comando desde el analizador de
consultas:
Desde el analizador de consultas ejecutar el comando DBCC
SQLPERF(LOGSPACE).
Monitoreo de Logs
La otra utilizando los contadores de SQL Server desde el
sistema operativo.
Monitoreo de Log transacciones
5.3.1.4 Monitoreo de Memoria compartida
SGA de Oracle (Sistema de Área Global)
Es un conjunto de áreas de memoria compartida
"instancia" (un ejemplo es los programas de bases de datos y la
memoria RAM).
Sirve para facilitar la transferencia de información entre
usuarios y también almacena la información estructural de la BD más frecuentemente
requerida.
La SGA se divide en varias partes:
Buffers de BD, Database Buffer Cache
Es el caché que almacena los bloques de datos leídos de los
segmentos de datos de la BD, tales como tablas, índices y clusters. Los bloques
modificados se llamas bloques sucios. El tamaño de buffer caché se fija por el
parámetro DB_BLOCK_BUFFERS del fichero init.ora.
Buffer Redo Log
Los registros Redo describen los cambios realizados en la BD
y son escritos en los ficheros redo log para que puedan ser utilizados en las
operaciones de recuperación hacia adelante, roll-forward, durante las
recuperaciones de la BD. Pero antes de guardar cambios en los ficheros redo
log, son escritos en un caché de la SGA llamado redo log buffer.
Área de SQL Compartido, Shared SQL Pool
En esta zona se encuentran las sentencias SQL que han sido
analizadas. El análisis sintáctico de las sentencias SQL lleva su tiempo y
Oracle mantiene las estructuras asociadas a cada sentencia SQL analizada
durante el tiempo que pueda para ver si puede reutilizarlas. Antes de analizar
una sentencia SQL, Oracle mira a ver si encuentra otra sentencia exactamente
igual en la zona de SQL compartido. Si es así, no la analiza y pasa
directamente a ejecutar la que mantiene en memoria. De esta manera se premia la
uniformidad en la programación de las aplicaciones.
5.3.1.5 Monitoreo de Base de Datos
Procedimiento Monitoreo de la Base de Datos Oracle10g
Se establece que se debe realizar una revisión periódica
mensual de la base de datos institucional (Oracle10g), con la finalidad de
identificar oportunamente cualquier anomalía que pueda afectar el rendimiento
de la misma. El encargado de realizar este proceso es el Administrador de la
Base de Datos, en la Unidad de Informática del CATIE.
Revisión de las Tablas del Esquema APLIC
A. Verificar que el tablespace este asignado correctamente a
uno válido para el Esquema.
B. Que no se encuentre particionada.
D. Que el número de registros no exceda el tamaño según la
funcionalidad de cada tabla.
Revisión de los Índices del Esquema APLIC
A. Verificar que el tablespace este asignado correctamente a
uno válido para el Esquema
B. Que no se encuentre particionado
C. Que el estado sea válido.
Revisión de los Procedimientos del Esquema APLIC
A. Verificar que el estado sea válido
Revisión de los Tablespaces en Almacenamiento
A. Verificar el estado sea ONLINE
B. Que el espacio usado no sobre pase el 85%, si no debe
asignársele más espacio en disco.
Revisión de los Archivos de Datos en Almacenamiento
A. Verificar el estado sea ONLINE
B. Si el espacio usado no sobre pase el 85%, debe
asignársele más espacio en disco, creando un nuevo archivo de datos.
Revisión de los Segmentos de RollBack en Almacenamiento
A. Verificar el estado sea ONLINE
5.3.1.6 Monitoreo de modos de operación
MONITOREO DE BASE DE DATOS
Revisión del espacio físico desde el S.O. del servidor
ADMIN. (root)
A. Ejecutar el comando:
$ df -k | grep dsk
5.3.1.6 Monitoreo de modos de operación.
Varios Consejos técnicos y libros se han escrito en los
últimos años sobre la modalidad de operaciones continua para garantizar copias
de seguridad adecuadas en la Base de Datos.
Sin embargo, poco se ha dicho acerca de la supervisión en
este modo de operacion,por ello se ha escrito este consejo tecnico para saber
como hacer copias de seguridad mas fluidas.
¿Cuál es el modo de funcionamiento continuo?
*Es un modo especial en las bases de datos especializadas.
*Permite realizar copias de seguridad instantanea en su
entorno.
*Se puede realizar en cualquier momento del dia.
*Escribe un archivo fisico independiente llamado
"archivo delta"
*Se obtiene una copia de seguridad que incluye el estado de
la base de datos
en un solo momnto en el tiempo.
5.3.1.7 Monitoreo de espacios espejeados
Una de las tareas de un DBA es monitorear el espacio de la
base de datos, debido a que esto consume mucho tiempo cuando se tienen varias
DB’s es bueno automatizar tareas repetitivas y tediosas. Una manera de realizar
la automatización del monitoreo de DB’s en UNIX es por medio del crontab, el
siguiente es un ejemplo de como usar el crontab para monitorear los
tablespaces.
Los siguientes
scripts permiten obtener el espacio utilizado y libre de los tablespaces, uno
lo obtiene en base el porcentaje libre de espacio y el otro obtiene el espacio
en base a los MB libres. Estos scripts reciben dos parametros: &1 .- es el
directorio y archivo donde se va a crear el reporte(spool) y &2 que es el
limite ya sea porcentaje (99) o Mb(99999).
tablespace_size_pct.sql
Con el siguiente
script podemos
ejecutarhttps://cdncache-a.akamaihd.net/items/it/img/arrow-10x10.png los SQL
scripts anteriores dependiendo los parametros que le enviemos. La forma de
ejecutar el script es la siguiente:
Para reportar
en base al espacio, despues del parametro -d debe seguir el nombre de la
instancia (SID), despues del parametro -s sigue la cantidad minima que puede
tener libre un tablespace:
tbs_monitor.ksh -d DEVELOPMENT -s 500
§ Connected.
§ Instance:
DEVELOPMENT
§ Tablespaces with
usage < 500 MB.
§
§ Tablespace Allocated Used Free
% % File
§ Name in MB in MB
in MB used free
Count
§
------------------------------ ---------- ---------- ---------- ------
------ ----------
§ SYSTEM 600 403.13
196.88 67.19 32.81
1
IDX1 11741 11363 378
96.78 3.22 3
Para reportar en
base al porcentaje, en lugar de utilizar el parametro -s se utiliza el
parametro -p seguido del porcentaje maximo que puede tener un tablespace:
tbs_monitor.ksh -d DEVELOPMENT -p 80
o Connected.
o Instance:
DEVELOPMENT
o Tablespaces with
usage >= 80%.
o
o Tablespace Allocated Used Free
% % File
o Name in MB in MB
in MB used free
Count
o ------------------------------
---------- ---------- ---------- ------ ------ ----------
o IDX1 11741 11363 378
96.78 3.22 3
o IDX2 3201 2696 505
84.22 15.78 2
o IDX5 18385 17394 991
94.61 5.39 3
o DATA02 13312 11520.13
1791.88 86.54 13.46
2
o DATA03 33797 31709.13
2087.88 93.82 6.18
4
o DATA01 56629 46606.38
10022.63 82.30 17.70
7
tbs_monitor.ksh
#!/bin/ksh
#######################################################################
#
# SCRIPT :
tbs_monitor.ksh
#
# DESCRIPTION : This
script will monitor usage in tablespaces of a database.
# If
the usage is >= 90% it will send an email to the DBA group.
#
# INPUT FILES :
[oracle_sid] only one database is processed
#
# OUTPUT FILES : NONE
#
# CALLED OBJECT: $SCRIPTS/switchdb.ksh
# ASSUMPTIONS : NONE
#
# SETUP INSTRUCTIONS : NONE
#
# COMMAND LINE EXECUTION: tbs_monitor.ksh -d [oracle_sid]
[-s sizeinMB] [-p pct]
#
# EXAMPLE: tbs_monitor.ksh -d DEV -s 300
# EXAMPLE: tbs_monitor.ksh -d DEV -p 85
#
# RESTART INSTRUCTIONS: rerun script
# SPECIAL CONSIDERATIONS: NONE
#######################################################################
# Modification Log:
# Version Date
Name Description
#######################################################################
# 1.0 04-Jul-2006
Delfino Nunez Initial Creation
#######################################################################
########################################################################
# FUNCTION :
showHelp
# DESCRIPTION: Print the help for using the script
########################################################################
function showHelp {
echo " Argument
Description"
echo "
------------
----------------------------------------------"
echo " -d [sid]
Oracle sid to check."
echo " -p xx
Report on percentage usage(pct > xx)."
echo " -s xxxxxx
Report on MB size usage(sizeMB < xxxxxx)."
echo " -h
This help."
echo " \n\n
EXAMPLE: "
echo " Report tablespaces that have more
than 95% space used"
echo " tbs_monitor.ksh -s EDS2TSDE -p
95"
echo " Report tablespaces that have less
than 300Mb space"
echo " tbs_monitor.ksh -s EDS2TSDE -s
300"
}
########################################################################
# Main Program start here
########################################################################
# Verify input paramtter and set environment variables
#parm_list=$@
. $DBA_BASE/init
#set -- $parm_list
#check parameters
if [ "$1" != "" ]
then
while [ "$#" != "0" ]
do
case $1 in
-s)
shift
if [
"$1" != "" ]; then
export
RPTTYPE="SIZE"
export
PSIZE=$1
shift
fi
;;
-d)
shift
if [
"$1" != "" ]; then
export
ORACLE_SID=$1
shift
fi
;;
-p)
shift
if [
"$1" != "" ]; then
export
RPTTYPE="PCT"
export
PSIZE=$1
shift
fi
;;
-h)
showHelp
exit 0;
;;
*)
echo "Bad
argument: $1"
showHelp
exit 1;
;;
esac
done
else
showHelp
exit 1
fi
. $SCRIPTS/switchdb.ksh $ORACLE_SID
BOXNAME=`uname -n`
MAILIDS=`cat $DBA_BASE/.forward`
# point to where the rpt file will go
export RPTFILE=$TMP/${ORACLE_SID}_tablespace_rpt.txt
export EMAILMSG=$TMP/tbs_email.txt
export dbpass=`cat $PWDFILE`
# should not need to be changed
export DATE=$(date +%y-%m-%d.%H:%M:%S)
#remove any previous file
if [ -a $RPTFILE ]
then
rm
$RPTFILE
fi
if [ -a $EMAILMSG ]
then
rm
$EMAILMSG
fi
#Run the status report.
case "$RPTTYPE" in
"PCT")
MESSAGE="Tablespaces with usage >= $PSIZE%."
sqlplus -s /nolog <
connect $dbpass
prompt Instance: $ORACLE_SID
prompt Tablespaces with usage >= $PSIZE%.
@$SQL/tablespace_size_pct.sql $RPTFILE $PSIZE
EOF
;;
"SIZE")
MESSAGE="Tablespaces with usage <= $PSIZE Mb."
sqlplus -s /nolog <
connect $dbpass
prompt Instance: $ORACLE_SID
prompt Tablespaces with usage < $PSIZE MB.
@$SQL/tablespace_size_spc.sql $RPTFILE $PSIZE
EOF
;;
esac
#tablespace with problems
if [[ -s $RPTFILE ]]; then
echo
"The following database have problems with the size of their
tablespaces:\n" >> $EMAILMSG
echo
"Instance: $ORACLE_SID" >> $EMAILMSG
echo
$MESSAGE >> $EMAILMSG
cat
$RPTFILE >> $EMAILMSG
mailx -s
"ALERT!!! Tablespace Usage Problems - $BOXNAME:$ORACLE_SID $DATE"
$MAILIDS < $EMAILMSG
fi
Y el ultimo script
nos permite obtener el reporte para todas las bases que se encuentran en el
servidor. Este script lee el archivo ORATAB y saca todas las bases de datos
registradas en el servidor. Este script se puede poner en el crontab de la
siguiente manera:
00 00-01,06-23 * *
* /home/oracle/dba/scripts/all.tbs_monitor -p >/dev/null 2>&1
Aqui le estamos
diciendo al crontab que ejecute el script cada hora excepto de 2am-5am, esto
por cuestiones de respaldos.
Si no se quiere
procesar todas las bases de datos y solo se quiere verificar algunas entonces
es necesario de calendarizar el script tbs_monitor.ksh por cada una de las
bases de datos.
all.tbs_monitor
#!/bin/ksh
#######################################################################
#
# SCRIPT :
all.tbs_monitor
#
# DESCRIPTION : This
script will call tbs_monitor script for all databases
#
# INPUT FILES :
$DBA_BASE/init - configuration file
# -a
all databases are processed
# -p
production (*PD) databases are processed
#
# OUTPUT FILES : NONE
#
# CALLED OBJECT: tbs_monitor
# ASSUMPTIONS : NONE
#
# SETUP INSTRUCTIONS : Need to switchdb first to a
default.
#
# COMMAND LINE EXECUTION:
#
# EXAMPLE:
#
# RESTART INSTRUCTIONS: rerun script
# SPECIAL CONSIDERATIONS: NONE
#######################################################################
# Modification Log:
# Version Date
Name Description
#######################################################################
# 1.0 04-Jul-2006
Delfino Nunez Initial Creation
#######################################################################
############################################################################
# MAIN PROGRAM STARTS HERE
############################################################################
. $HOME/dba/init
priority=1
########################################################################
# FUNCTION :
showHelp
# DESCRIPTION: Print the help for using the script
########################################################################
function showHelp {
echo " Argument
Description"
echo "
------------
----------------------------------------------"
echo " -p Only production databases."
echo "
-a All databases."
echo "
-h This help."
echo " \n\n
EXAMPLE: all.tbs_monitor -a"
echo " all.tbs_monitor -p"
}
########################################################################
# Main Program start here
########################################################################
if [ -f /var/opt/oracle/oratab ]
then
export
ORATAB='/var/opt/oracle/oratab'
elif [ -f /etc/oratab ]
then
export
ORATAB='/etc/oratab'
else
# following code from Steve Larson
FOUND_ORATAB=$(
find / -name oratab 2>/dev/null | head -1 )
if [
"$FOUND_ORATAB" ] && [ -f "$FOUND_ORATAB" ]
then
ORATAB="$FOUND_ORATAB"
else
exit 1
fi
fi
#check parameter
if [ "$1" != "" ]
then
while [ "$#" != "0" ]
do
case $1 in
-p)
export
INSTANCES=`awk -F: '$1 !~ /\#/ && $1 !~ /\*/ {print $1}' $ORATAB|grep
"PD"`
shift
;;
-a)
export
INSTANCES=`awk -F: '$1 !~ /\#/ && $1 !~ /\*/ {print $1}' $ORATAB`
shift
;;
-h)
showHelp
exit 0;
;;
*)
echo "Bad
argument: $1"
echo
""
showHelp
exit 1;
;;
esac
done
else
showHelp
exit 1
fi
if [ "$#" != "0" ]
then
ORACLE_SID=$1
shift
export ORACLE_SID
else
for ORACLE_SID in
$INSTANCES
do
swdb
$ORACLE_SID
tbs_monitor.ksh -d $ORACLE_SID -s 300
done
fi
Los scripts utilizan otros scripts o archivos que no estan
incluidos aqui y que voy a ir publicando, pero estos scripts pueden usarse como
base para crear unos personalizados.
5.3.2 Auditoría
Es la actividad consistente en la emisión de una opinión
profesional sobre si el objeto sometido a análisis presenta adecuadamente la
realidad que pretende reflejar y/o cumple con las condiciones que le han sido
prescritas.
5.3.2.1 Habilitación y deshabilitar el modo de auditoría
Funcionamiento comando audit (Oracle):
El comando audit permite iniciar los tipos de auditoría que
a continuación se detallan. Este comando puede funcionar aunque no esté
activada la auditoría de la base de datos, pero no dejará constancia, para que
funcione correctamente es necesario que la auditoría esté activada.
Sintaxis:
AUDIT
{ sql_statement_clause | schema_object_clause | NETWORK }
[ BY { SESSION | ACCESS } ]
[ WHENEVER [ NOT ] SUCCESSFUL ] ;
•
sql_statement_clause
: activa la auditoría para una sentencia SQL concreta.
•
schema_object_clause
: activa la auditoría para un objeto concreto de la base de
datos.
•
WHENEVER SUCCESSFUL
: activa la auditoría sólo para operaciones e instrucciones
SQL en objetos de esquema que se completen con éxito.
•
WHENEVER NOT SUCCESSFUL
: activa la auditoría sólo para operaciones e instrucciones
SQL en objetos de esquema que originen error.
Funcionamiento comando noaudit:
La instrucción noaudit se utiliza para detener la actividad
de auditoría que se había activado previamente con la instrucción audit. Esta
instrucción no influye en el parámetro audit_trail.
Sintaxis:
NOAUDIT
{ sql_statement_clause | schema_object_clause | NETWORK}
[WHENEVER [NOT] SUCCESSFUL];
•
sql_statement_clause
: detiene la auditoria de una sentencia SQL concreta.
•
schema_object_clause
: detiene la auditoría para un objeto concreto de la base de
datos.
•
WHENEVER SUCCESSFUL
: detiene la auditoría sólo para operaciones e instrucciones
SQL en objetos de esquema que se completen con éxito.
•
WHENEVER NOT SUCCESSFUL
: detiene la auditoría sólo para operaciones e instrucciones
SQL en objetos de esquema que originen error.
5.3.2.2 Consultas de las tablas vistas con información de la
auditoría
Dependiendo del tipo de auditoría que queramos consultar
utilizaremos una u otra consulta SQL.
Para el caso de la auditoría de inicio de sesión
utilizaremos la siguiente consulta SQL:
selectOS_UsernameUsuario_SO,
UsernameUsuario_Oracle, Terminal ID_Terminal,
DECODE (Returncode, '0', 'Conectado', '1005', 'Fallo -
Null',
1017, 'Fallo', Returncode) Tipo_Suceso,
TO_CHAR(Timestamp, 'DD-MM-YY HH24:MI:SS')
Hora_Inicio_Sesion,
TO_CHAR(Logoff_Time, 'DD-MM-YY HH24:MI:SS') Hora_Fin_Sesion
from DBA_AUDIT_SESSION;
Para el caso de la auditoría de acción utilizaremos la
siguiente consulta SQL:
selectOS_UsernameUsuario_SO,
UsernameUsuario_Oracle, Terminal ID_Terminal,
OwnerPropietario_Objeto,
Obj_NameNombre_Objeto,
Action_NameAccion,
DECODE (Returncode, '0', 'Realizado', 'Returncode')
Tipo_Suceso,
TO_CHAR (Timestamp, 'DD-MM-YY HH24:MI:SS') Hora
from DBA_AUDIT_OBJECT;
5.4 Herramientas de software y hardware para monitoreo y
administración automática
Herramientas de Microsoft SQL Server
Estas herramientas son el Profiler y el Performance monitor.
*Permiten ver los procesos en ejecucion del servidor
*Ayudan a ver como esta el rendimiento del sistema
PROFILER
-Permite crear trace para dar seguimiento a las ejecuciones
y consultas que se ejecutan en el servidor
-Podemos tener acceso en la dirección Start>Program Files
> Microsoft SQL Server >Profiler.
-Se pueden filtar traces especificando el nombre de la aplicacion
a la que se le quiere dar seguimiento.
PERFORMANCE MONITOR
-Con esta herramienta se visualiza como se esta comportando
el disco duro
-A demas de como la base de datos utiliza la memoria y el
procesador del servidor los cuales deberían mantenerse por debajo de un 20%
Herramientas de MySql
MySQL-Proxy
Es una herramienta para monitorear y optimizar consultas y
búsquedas.
1.- Hacer un Log de todas las consultas que recibe el
Servidor
2.- Denegar consultas peligrosas que puedan dañar nuestra
base de datos
3.- Generar Alias de comandos comunes por ejemplo SLE se
podría convertir en SELECT
4.- Balancear la carga entre varios servidores de MySQL en
un esquema de Master/Slave
5.- Dar prioridad a ciertas consultas para acelerar la
respuesta del servidor