¿Cuáles son las mejores prácticas para eliminar de forma segura y permanente una base de datos?

Tenemos un entorno "orgánico", lo que significa que las personas acumularon código en el código durante diez años con una supervisión o documentación mínima. El servidor que uso tiene varias bases de datos que creo que ya no se usan; Me encantaría eliminarlos y dejar solo los tres que realmente uso.

En el extremo temerario, podría deshabilitar estas bases de datos y esperar a que alguien grite; por el otro podría dejarlos corriendo para siempre "por si acaso". ¿Qué pasos ha encontrado valiosos para identificar si se está utilizando un servidor y cómo?

Además, ¿qué pasos recomendaría para garantizar que, a medida que uno avanza en los sistemas de desactivación, permanezcan convenientemente reversibles durante un período de tiempo (por ejemplo, cambiar el nombre de los objetos en lugar de eliminarlos por completo)?

¡Gracias!

También debe asegurarse de los sellos de fecha y hora de cada tabla. Busque cualquier metadato en el sistema para cada tabla, ordene dicha lista por fecha y hora actualizada por última vez, y muestre la salida en orden desc por fecha y hora. También puede verificar el tamaño de la tabla incluso para el ligero cambio de tamaño.

Por ejemplo, en MySQL 5.x, tiene information_schema.tables que se ve así:

mysql> desc information_schema.tables;
+-----------------+---------------------+------+-----+---------+-------+
| Field           | Type                | Null | Key | Default | Extra |
+-----------------+---------------------+------+-----+---------+-------+
| TABLE_CATALOG   | varchar(512)        | NO   |     |         |       |
| TABLE_SCHEMA    | varchar(64)         | NO   |     |         |       |
| TABLE_NAME      | varchar(64)         | NO   |     |         |       |
| TABLE_TYPE      | varchar(64)         | NO   |     |         |       |
| ENGINE          | varchar(64)         | YES  |     | NULL    |       |
| VERSION         | bigint(21) unsigned | YES  |     | NULL    |       |
| ROW_FORMAT      | varchar(10)         | YES  |     | NULL    |       |
| TABLE_ROWS      | bigint(21) unsigned | YES  |     | NULL    |       |
| AVG_ROW_LENGTH  | bigint(21) unsigned | YES  |     | NULL    |       |
| DATA_LENGTH     | bigint(21) unsigned | YES  |     | NULL    |       |
| MAX_DATA_LENGTH | bigint(21) unsigned | YES  |     | NULL    |       |
| INDEX_LENGTH    | bigint(21) unsigned | YES  |     | NULL    |       |
| DATA_FREE       | bigint(21) unsigned | YES  |     | NULL    |       |
| AUTO_INCREMENT  | bigint(21) unsigned | YES  |     | NULL    |       |
| CREATE_TIME     | datetime            | YES  |     | NULL    |       |
| UPDATE_TIME     | datetime            | YES  |     | NULL    |       |
| CHECK_TIME      | datetime            | YES  |     | NULL    |       |
| TABLE_COLLATION | varchar(32)         | YES  |     | NULL    |       |
| CHECKSUM        | bigint(21) unsigned | YES  |     | NULL    |       |
| CREATE_OPTIONS  | varchar(255)        | YES  |     | NULL    |       |
| TABLE_COMMENT   | varchar(2048)       | NO   |     |         |       |
+-----------------+---------------------+------+-----+---------+-------+
21 rows in set (0.01 sec)

La columna UPDATE_TIME registra la última vez que se aplicó por última vez cualquier INSERT, UPDATE o DELETE a la tabla. Puede ejecutar consultas como estas para saber cuándo se accedió por última vez a cada base de datos:

Última vez que se accedió a una tabla en cada base de datos:

SELECT table_schema,MAX(update_time) last_accessed
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema','mysql')
AND update_time IS NOT NULL
GROUP BY table_schema;

Última vez que se accedió a una tabla en cualquier base de datos:

SELECT MAX(update_time) last_accessed FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema','mysql');

Últimas 10 fechas en que se accedió a una tabla:

SELECT * FROM
(SELECT * FROM
(SELECT last_accessed,COUNT(1) access_count
FROM (SELECT DATE(update_time) last_accessed
FROM information_schema.tables
WHERE table_schema NOT IN ('information_schema','mysql')
AND update_time IS NOT NULL) A
GROUP BY last_accessed) AA
ORDER BY last_accessed DESC) AAA
LIMIT 10;

Estos son solo algunos ejemplos de cómo obtener dichos metadatos de MySQL. Estoy seguro de que Oracle y SQL Server tienen métodos similares o mejores.

Una vez que esté seguro de con qué frecuencia o pocas veces se accede a una base de datos (o esquema), debe volcar / exportar manualmente bases de datos antiguas junto con copias del esquema en sí, aparte de los datos. Por favor, disculpe que mi respuesta no es independiente de DB. Los DBA de SQLServer y Oracle también deberían expresar sus respuestas aquí, ya que el concepto de un esquema como una colección dentro de una instancia de base de datos está borroso en MySQL pero se sigue muy estrictamente en SQLServer y Oracle.

Podría intentar configurar un rastreo que solo capture conexiones y a qué base de datos se conectan. Dejaría esto en ejecución por un momento y luego me aseguraría de que nada se conecte a él.

Un problema con eso sería si tiene algún código que se abre en la base de datos maestra pero llama a otra base de datos dentro del código. No estoy seguro de qué tan malo es el código que apunta a sus bases de datos.

También consultaría todos sus trabajos y me aseguraría de que ninguno apunte a esa base de datos

También puede usar la auditoría SQL si tiene la versión correcta de SQL (2008 R2 Enterprise).

También puede usar disparadores de inicio de sesión para actualizar una tabla cuando alguien inicia sesión en esa base de datos. Esto le mostrará si algo se conecta a esa base de datos.

Además, ¿qué pasos recomendaría para garantizar que, a medida que uno avanza en los sistemas de desactivación, permanezcan convenientemente reversibles durante un período de tiempo?

En SQL Server, puede poner las bases de datos " fuera de línea ", lo que deja la base de datos presente, pero hace que no sea posible conectarse a ella a través del código. Si una base de datos está "fuera de línea", sigue estando disponible y es reversible en cuestión de minutos.

En mi último trabajo tuvimos algunos productos que estuvieron en funcionamiento durante varios meses al año, por lo que las personas que trabajan con ese producto no habrían notado el apagado o la desconexión de la base de datos durante meses. Como ejemplo, uno de los productos incluía formularios W-2, por lo que el 98% del negocio ocurre en enero y febrero (para la mayoría de las empresas, los datos no están disponibles hasta la primera semana de enero y la fecha límite regulatoria federal para presentar el la información es el último día hábil en enero). El servidor web generalmente estaba apagado desde mayo / junio hasta diciembre.

En esa compañía, teníamos una hoja de cálculo con el "propietario" de la base de datos: una sola persona responsable del producto. Mientras que otros podían hacer actualizaciones a la estructura de las tablas, el "propietario" era la persona a la que acudir cuando tenía que hacerse alguna pregunta. Si el dueño dejara la compañía (raro hasta el año pasado), alguien sería asignado para ser el nuevo dueño antes de irse.

En otras compañías, hemos desconectado las bases de datos durante un trimestre; si permanecen desconectadas sin que se rompa nada (como los informes mensuales / trimestrales), se las respaldará por última vez y se eliminarán. Esto permite que alguien regrese más tarde y restaure la base de datos (que toma unos minutos) para aquellas situaciones que tienen historias como "oh, eso fue para el proyecto de Jones que tuvimos que dejar de lado mientras terminamos el proyecto de Fred".