Was sind Best Practices zum sicheren dauerhaften Löschen einer Datenbank?

Wir haben eine "organische" Umgebung, dh die Leute haben zehn Jahre lang Code auf Code gestapelt, mit minimaler Kontrolle oder Dokumentation. Der von mir verwendete Server verfügt über mehrere Datenbanken, von denen ich glaube, dass sie nicht mehr verwendet werden. Ich würde sie gerne löschen und nur die drei belassen, die ich tatsächlich benutze.

Im rücksichtslosen Extrem könnte ich diese Datenbanken deaktivieren und darauf warten, dass jemand schreit; auf der anderen Seite könnte ich sie für immer laufen lassen "nur für den Fall". Welche Schritte haben Sie als wertvoll erachtet, um festzustellen, ob und wie ein Server verwendet wird?

Welche Schritte würden Sie empfehlen, um sicherzustellen, dass die Systeme bei der Deaktivierung für einen bestimmten Zeitraum bequem umkehrbar bleiben (z. B. Objekte umbenennen, anstatt sie sofort zu löschen)?

Vielen Dank!

Sie möchten auch die Datums- / Uhrzeitstempel jeder Tabelle sicherstellen. Suchen Sie nach Metadaten im System für jede Tabelle, ordnen Sie eine solche Liste nach Datum / Uhrzeit der letzten Aktualisierung und zeigen Sie die Ausgabe in absteigender Reihenfolge nach Datum / Uhrzeit an. Sie können die Tabellengröße auch auf geringfügige Größenänderungen überprüfen.

In MySQL 5.x haben Sie beispielsweise information_schema.tables, die folgendermaßen aussehen:

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)

In der Spalte UPDATE_TIME wird aufgezeichnet, wann INSERT, UPDATE oder DELETE zuletzt auf die Tabelle angewendet wurden. Sie können Abfragen wie diese ausführen, um herauszufinden, wann zuletzt auf jede Datenbank zugegriffen wurde:

Das letzte Mal, als in jeder Datenbank auf eine Tabelle zugegriffen wurde:

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;

Das letzte Mal, als in einer Datenbank auf eine Tabelle zugegriffen wurde:

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

In den letzten 10 Daten wurde auf eine Tabelle zugegriffen:

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;

Dies sind nur einige Beispiele, wie Sie solche Metadaten von MySQL erhalten. Ich bin sicher, dass Oracle und SQL Server ähnliche oder bessere Methoden haben.

Wenn Sie sicher sind, wie oft oder selten auf eine Datenbank (oder ein Schema) zugegriffen wird, sollten Sie veraltete Datenbanken zusammen mit Kopien des Schemas selbst, abgesehen von den Daten, manuell sichern / exportieren. Bitte entschuldigen Sie, dass meine Antwort nicht DB-Agnostiker ist. SQLServer- und Oracle-Datenbankadministratoren sollten auch hier ihre Antworten aussprechen, da das Konzept eines Schemas als Sammlung innerhalb einer Datenbankinstanz in MySQL unscharf ist, in SQLServer und Oracle jedoch sehr streng befolgt wird.

Sie können versuchen, eine Ablaufverfolgung einzurichten, die nur Verbindungen und die Datenbank erfasst, zu der sie eine Verbindung herstellen. Ich würde dies für eine Weile laufen lassen und dann sicherstellen, dass nichts damit verbunden ist.

Ein Problem dabei wäre, wenn sich auf der Master-Datenbank Code öffnet, aber eine andere Datenbank innerhalb des Codes aufruft. Ich bin nicht sicher, wie schlecht der Code ist, der auf Ihre DBs zeigt.

Ich würde auch alle Ihre Jobs abfragen und sicherstellen, dass keiner auf diese Datenbank verweist

Sie können auch die SQL-Prüfung verwenden, wenn Sie über die richtige Version von SQL (2008 R2 Enterprise) verfügen.

Sie können auch Anmeldetrigger verwenden, um eine Tabelle zu aktualisieren, wenn sich jemand bei dieser Datenbank angemeldet hat. Dies würde Ihnen zeigen, ob eine Verbindung zu dieser Datenbank hergestellt wurde.

Welche Schritte würden Sie empfehlen, um sicherzustellen, dass die Systeme bei der Deaktivierung für einen bestimmten Zeitraum bequem umkehrbar bleiben?

In SQL Server können Sie Datenbanken " offline " schalten, wodurch die Datenbank vorhanden bleibt, eine Verbindung über Code jedoch nicht möglich ist. Wenn eine Datenbank "offline" ist, bleibt sie weiterhin verfügbar und ist innerhalb von Minuten umkehrbar.

Bei meinem letzten Job hatten wir einige Produkte, die mehrere Monate pro Jahr in Betrieb waren, so dass das monatelange Ausschalten oder Offline-Schalten der Datenbank von den Mitarbeitern dieses Produkts nicht bemerkt worden wäre. Zum Beispiel handelt es sich bei einem der Produkte um W-2-Formulare, sodass 98% des Geschäfts im Januar und Februar stattfinden (für die meisten Unternehmen sind die Daten erst in der ersten Januarwoche verfügbar und die bundesstaatliche Regulierungsfrist für die Einreichung des Formulars Informationen sind der letzte Geschäftstag im Januar. Der Webserver war normalerweise von Mai / Juni bis Dezember ausgeschaltet.

In diesem Unternehmen hatten wir eine Tabelle mit dem "Eigentümer" der Datenbank - einer einzigen Person, die für das Produkt verantwortlich ist. Während andere die Struktur der Tabellen aktualisieren konnten, war der "Eigentümer" der Ansprechpartner, wenn Fragen gestellt werden mussten. Wenn der Eigentümer das Unternehmen verlässt (selten bis letztes Jahr), wird jemand als neuer Eigentümer zugewiesen, bevor er das Unternehmen verlässt.

Bei anderen Unternehmen haben wir Datenbanken ein Viertel lang offline geschaltet. Wenn sie offline bleiben und nichts kaputt geht (z. B. monatliche / vierteljährliche Berichte), werden sie ein letztes Mal gesichert und gelöscht. Auf diese Weise kann jemand später zurückkehren und die Datenbank wiederherstellen (was einige Minuten dauert), wenn Situationen wie "Oh, das war für das Jones-Projekt, das wir beiseite legen mussten, während wir das Fred-Projekt abgeschlossen haben".