Quelles sont les meilleures pratiques pour supprimer définitivement et en toute sécurité une base de données?

Nous avons un environnement «organique», ce qui signifie que les gens ont empilé du code sur du code pendant dix ans avec un minimum de surveillance ou de documentation. Le serveur que j'utilise possède plusieurs bases de données qui, je crois, ne sont plus utilisées; J'adorerais les supprimer et ne laisser que les trois que j'utilise réellement.

À l'extrême téméraire, je pouvais désactiver ces bases de données et attendre que quelqu'un crie; de l'autre, je pouvais les laisser courir pour toujours "juste au cas où". Quelles étapes avez-vous trouvées utiles pour déterminer si un serveur est utilisé et comment?

De plus, quelles étapes recommanderiez-vous pour garantir que, à mesure que l'on progresse dans la désactivation des systèmes, ils restent commodément réversibles pendant un certain temps (par exemple, renommer des objets plutôt que de les supprimer purement et simplement)?

Merci!

Vous voulez également vous assurer des tampons datetime de chaque table. Recherchez toutes les métadonnées du système pour chaque table, triez une telle liste par date et heure de dernière mise à jour et affichez la sortie dans l'ordre décroissant par date et heure. Vous pouvez également vérifier la taille du tableau, même pour le léger changement de taille.

Par exemple, dans MySQL 5.x, vous avez information_schema.tables qui ressemble à ceci:

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 colonne UPDATE_TIME enregistre la dernière fois où INSERT, UPDATE ou DELETE a été appliqué pour la dernière fois à la table. Vous pouvez exécuter des requêtes comme celles-ci pour savoir quand chaque base de données a été accédée pour la dernière fois:

Dernière fois qu'une table a été consultée dans chaque base de données:

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;

Dernière fois où une table a été consultée dans une base de données:

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

10 dernières dates auxquelles un tableau a été consulté:

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;

Ce ne sont que quelques exemples de la façon d'obtenir de telles métadonnées à partir de MySQL. Je suis sûr qu'Oracle et SQL Server ont des méthodes similaires ou meilleures.

Une fois que vous êtes sûr de la fréquence ou de l'accès rare à une base de données (ou schéma), vous devez vider / exporter manuellement les bases de données anciennes avec des copies du schéma lui-même en dehors des données. Veuillez excuser que ma réponse ne soit pas indépendante de la base de données. Les DBA SQLServer et Oracle devraient également exprimer leurs réponses, car le concept d'un schéma étant une collection au sein d'une instance de base de données est flou dans MySQL mais très strictement suivi dans SQLServer et Oracle.

Vous pouvez essayer de configurer une trace qui capture uniquement les connexions et à quelle base de données ils se connectent. Je laisserais cela fonctionner un peu et je m'assurerais ensuite que rien ne s'y connecte.

Un problème avec cela serait si vous avez du code s'ouvrant sur la base de données principale mais appelant une autre base de données dans le code. Je ne sais pas à quel point le code pointe vers vos bases de données.

Je voudrais également interroger tous vos travaux et m'assurer qu'aucun ne pointe vers cette base de données

Vous pouvez également utiliser l'audit SQL si vous disposez de la bonne version de SQL (2008 R2 Enterprise).

Vous pouvez également utiliser des déclencheurs de connexion pour mettre à jour une table lorsque quelqu'un s'est connecté à cette base de données. Cela vous montrerait si quelque chose se connectait à cette base de données.

De plus, quelles étapes recommanderiez-vous pour vous assurer que, à mesure que l'on progresse dans la désactivation des systèmes, ils restent commodément réversibles pendant un certain temps

Dans SQL Server, vous pouvez mettre des bases de données " hors ligne ", ce qui laisse la base de données présente, mais rend la connexion via le code impossible. Si une base de données est "hors ligne", elle reste disponible et est réversible en quelques minutes.

Lors de mon dernier emploi, nous avions certains produits qui fonctionnaient plusieurs mois par an.Par conséquent, la désactivation ou la mise hors ligne de la base de données pendant des mois n'aurait pas été remarquée par les personnes travaillant avec ce produit. À titre d'exemple, l'un des produits impliquait des formulaires W-2, donc 98% de l'activité se déroule en janvier et février (pour la plupart des entreprises, les données ne sont disponibles que la première semaine de janvier et la date limite réglementaire fédérale pour déposer le l'information est le dernier jour ouvrable de janvier). Le serveur Web était généralement éteint de mai / juin à décembre.

Dans cette entreprise, nous avions un tableur avec le «propriétaire» de la base de données - une seule personne responsable du produit. Alors que d'autres pouvaient apporter des mises à jour à la structure des tables, le "propriétaire" était la personne de référence lorsque des questions devaient être posées. Si le propriétaire quittait l'entreprise (rare jusqu'à l'année dernière), quelqu'un serait désigné comme nouveau propriétaire avant son départ.

Dans d'autres sociétés, nous avons mis les bases de données hors ligne pendant un trimestre, si elles restent hors ligne sans rien casser (comme les rapports mensuels / trimestriels), elles sont sauvegardées une dernière fois et supprimées. Cela permet à quelqu'un de revenir plus tard et de restaurer la base de données (ce qui prend quelques minutes) pour les situations qui ont des histoires comme "oh, c'était pour le projet jones que nous avons dû mettre de côté pendant que nous avions terminé le projet fred."