Las herramientas de cada gestor

Un gestor de base de datos es un servicio del sistema y se puede manejar de dos maneras: con las órdenes propias del producto o con el gestor de servicios del sistema operativo. Las dos hacen lo mismo por debajo y conviene conocer las dos, porque en un incidente no siempre está disponible la que uno prefiere.

La comprobación de si el servicio está vivo tiene también sus dos caminos. Desde el producto se pregunta al propio motor, lo que además confirma que responde; desde el sistema se mira el estado del servicio o directamente la lista de procesos. Que el proceso exista no garantiza que la base esté abierta, así que la comprobación buena es la que interroga al gestor.

mysqladmin -u root -p ping
systemctl status mysqld
ps aux | grep mysqld

pg_ctl status

Que el proceso esté levantado no significa que la base esté abierta. La comprobación fiable es la que le pregunta al gestor, no la que mira la lista de procesos.

Oracle no tiene un solo modo de parar ni un solo modo de arrancar, y cuál se elige tiene consecuencias directas sobre las sesiones abiertas y sobre lo que hará el gestor la próxima vez que se levante. Es materia de examen porque las cuatro opciones de parada se parecen mucho.

El arranque también es escalonado, y refleja exactamente la distinción entre instancia y base de datos de «El oficio del DBA»: NOMOUNT levanta la instancia sin abrir nada, MOUNT lee los ficheros de control pero no deja entrar a los usuarios, y OPEN es el estado normal de servicio. RESTRICT abre solo para las cuentas con privilegio de sesión restringida, que es lo que se usa para hacer mantenimiento con la base arriba y sin usuarios dentro.

SHUTDOWN IMMEDIATE;

STARTUP NOMOUNT;
STARTUP MOUNT;
STARTUP OPEN;
STARTUP RESTRICT;

Dos avisos de escritura, porque los apuntes suelen traerlos mal: el mandato de arranque es STARTUP, no START, y la opción rápida de parada es IMMEDIATE, con dos emes y sin ene delante.

MySQL reparte la administración en varios programas de línea de mandatos, cada uno con un cometido. Saber cuál hace qué es de las preguntas más agradecidas del examen, porque los nombres se parecen y basta con fijar el verbo de cada uno.

La pareja que más se confunde es mysqlcheck y myisamchk. La regla práctica es la del servidor: mysqlcheck habla con el servidor y por tanto funciona con la base arriba y con cualquier motor; myisamchk toca los ficheros por debajo, solo entiende MyISAM y hay que usarlo con la tabla fuera de servicio para no corromperla más.

mysqldump copia, mysql restaura, mysqladmin administra, mysqlcheck repara con el servidor en marcha y myisamchk repara ficheros MyISAM por debajo.

De mysqldump, las opciones que cambian el resultado de una copia y que conviene tener presentes son las que deciden el alcance, qué se incluye y qué pasa al restaurar sobre una base que ya existe.

mysqldump -u root -p llegando > respaldo.sql
mysqldump -u root -p --databases llegando alumnos > respaldo.sql
mysqldump -u root -p --all-databases > respaldo.sql

# --routines      incluye también procedimientos y funciones
# --add-drop-database  antepone el borrado de la base a su creación
# --no-data       solo la estructura, sin filas

De mysqladmin, las subórdenes se leen solas y son las que aparecen en las preguntas: ping para saber si el servidor está vivo, shutdown para pararlo, version para la versión y el estado, processlist para ver qué se está ejecutando en ese momento, kill para matar un proceso concreto, create para crear una base, reload para recargar las tablas de privilegios y stop-slave para detener la replicación en un servidor esclavo. Con la opción de servidor remoto, todo eso se hace contra otra máquina.

mysqladmin -u root -p processlist
mysqladmin -u root -p kill 4711
mysqladmin -u root -p -h 10.0.0.15 status

Para el mantenimiento de tablas hay además equivalentes en SQL puro, que es lo que ejecuta mysqlcheck por debajo: OPTIMIZE TABLE, ANALYZE TABLE, CHECK TABLE y REPAIR TABLE. Conviene saber que existen, porque en un servidor donde no se tiene acceso al intérprete de mandatos son la única vía.

PostgreSQL sigue la misma filosofía: un programa pequeño por tarea, todos ellos envoltorios sobre sentencias SQL que se podrían escribir a mano. La ventaja para el administrador es que se automatizan bien desde un guion.

Vacuumdb merece una explicación aparte porque no tiene equivalente en los otros gestores. PostgreSQL no borra ni sobrescribe una fila cuando se actualiza: escribe una versión nueva y deja la antigua marcada, porque puede haber transacciones que todavía la estén viendo. Esas versiones antiguas son las filas muertas, y si nadie las limpia el fichero de la tabla no para de crecer aunque el número de filas útiles sea el mismo. Eso es lo que hace VACUUM, y de paso recalcula las estadísticas con las que el optimizador decide sus planes.

En PostgreSQL, un fichero que crece sin que crezca el número de filas casi siempre significa que falta mantenimiento de VACUUM.

Los parámetros de conexión son comunes a casi todos los mandatos, así que se aprenden una vez: servidor, base de datos, usuario y petición de contraseña.

psql -h servidor -d llegando -U panel_web -W

pg_ctl start
pg_ctl stop
pg_ctl restart
pg_ctl status

En la copia y la restauración lo que hay que fijar es la correspondencia entre formatos, que es donde se falla. Si la copia sale en formato de guion SQL, se restaura con el cliente redirigiendo el fichero a la entrada o pasándolo como fichero de órdenes. Si sale en el formato propio del producto, hace falta el restaurador específico.

# Copia y restauración en formato guion SQL
pg_dump llegando > respaldo.sql
psql llegando < respaldo.sql
psql -d llegando -f respaldo.sql

# Copia y restauración en formato propio
pg_dump -Fc llegando > respaldo.dump
pg_restore -d llegando respaldo.dump

# Todas las bases del servidor
pg_dumpall > respaldo_completo.sql

vacuumdb llegando
vacuumdb --analyze llegando
reindexdb llegando

La regla que resume todo: pg_restore solo sirve para las copias hechas en el formato propio; las que están en guion SQL se restauran con psql, porque no son más que un fichero de sentencias.

Localizar el fichero de configuración es lo primero que se necesita cuando hay que cambiar un puerto, subir un límite de conexiones o abrir el servicio a la red. Cada producto lo coloca en un sitio y lo trocea a su manera.

Cuidado con el nombre del fichero de MySQL: es my.cnf, con las consonantes en ese orden. Aparece mal escrito en muchísimos apuntes y en una pregunta con cuatro rutas parecidas es exactamente el detalle que se usa para distinguirlas.

Además de la línea de mandatos, cada producto tiene su consola gráfica. En SQL Server es SQL Server Management Studio, la aplicación con la que se gestionan y administran todos sus componentes, y es la que se pregunta por sus siglas. Oracle tiene sus consolas empresariales y su cliente SQL*Plus en texto, y en MySQL y PostgreSQL las consolas gráficas más usadas son de terceros.

Un parámetro que se pregunta y que no está en ninguno de esos ficheros es NLS_LANG de Oracle: se fija en el lado del cliente y declara el juego de caracteres con el que ese cliente trabaja, para que el gestor haga la conversión que corresponda. Si está mal, los datos no se corrompen en el servidor pero llegan con los acentos rotos a la aplicación.