Was sind Best Practices, um eine Datenbank sicher dauerhaft zu löschen?

Question

Wir haben eine "organische" Umgebung, was bedeutet, dass Personen zehn Jahre lang mit minimaler Aufsicht oder Dokumentation Code auf Code stapeln. 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 lassen, die ich tatsächlich benutze.

Im rücksichtslosen Extrem konnte ich diese Datenbanken deaktivieren und darauf warten, dass jemand schreibt; Bei der anderen konnte ich sie für immer "für den Fall" laufen lassen. Welche Schritte haben Sie als nützlich festgestellt, ob ein Server verwendet wird und wie?

Welche Schritte würden Sie auch empfehlen, um sicherzustellen, dass sie, wenn man sich in Deaktivierungssystemen voranschreitet, für einen bestimmten Zeitraum bequem reversibel bleibt (z. B. umbenennen Objekte, anstatt sie direkt zu löschen)?

Vielen Dank!

Answer 1

Sie möchten auch die DateTime -Briefmarken jeder Tabelle sicherstellen. Suchen Sie nach Metadaten im System für jede Tabelle, bestellen Sie eine solche Liste nach datetime zuletzt aktualisiert und zeigen Sie die Ausgabe in der Auftrag nach DateTime an. Sie können auch die Tabellengröße für die geringfügige Größe ändern.

In MySQL 5.x haben Sie beispielsweise Information_Schema.tables, die so 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)

Die Spalte Update_Time zeichnet das letzte Mal auf, dass ein Einfügen, Update oder Löschen zuletzt auf die Tabelle angewendet wurde. Sie können solche Abfragen ausführen, um herauszufinden, wann auf jede Datenbank zuletzt zugegriffen wurde:

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

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 wurde auf eine Tabelle in jeder Datenbank zugegriffen:

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

Die letzten 10 Daten wurden 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 man solche Metadaten von MySQL bekommt. Ich bin sicher, Oracle und SQL Server haben ähnliche oder bessere Methoden.

Sobald Sie sicher sind, wie oft oder selten auf eine Datenbank (oder ein Schema) zugegriffen werden, sollten Sie gealterte Datenbanken manuell zusammen mit Kopien des Schemas selbst abheben/exportieren. Bitte entschuldigen Sie, dass meine Antwort nicht db agnostisch ist. SQLServer und Oracle DBAs sollten auch hier ihre Antworten äußern, da das Konzept eines Schemas eine Sammlung innerhalb einer Datenbankinstanz in MySQL ist, aber in SQLServer und Oracle sehr streng befolgt wird.

Answer 2

Sie könnten versuchen, eine Spur einzurichten, die nur Verbindungen erfasst und zu welcher Datenbank sie herstellen. Ich würde das für ein bisschen laufen lassen und dann sicherstellen, dass sich nichts damit verbindet.

Ein Problem damit wäre, wenn Sie einen Code haben, der auf dem Master -DB geöffnet wird, aber ein weiteres DB im Code anruft. Ich bin mir nicht sicher, wie schlimm der Code ist, der auf Ihre DBS zeigt.

Ich würde auch alle Ihre Jobs befragen und sicherstellen, dass keiner auf diese DB zeigt

Sie können auch SQL Audit verwenden, wenn Sie die richtige Version von SQL (2008 R2 Enterprise) haben.

Sie können auch Logon -Trigger verwenden, um eine Tabelle zu aktualisieren, wenn sich jemand bei dieser DB angemeldet hat. Dies würde Ihnen zeigen, wenn sich etwas mit dieser DB verbindet.

Answer 3

Welche Schritte würden Sie empfehlen, um sicherzustellen, dass sie bei Deaktivierungssystemen vorwärts gehen, die sie für einen bestimmten Zeitraum bequem reversibel bleiben

In SQL Server können Sie Datenbanken einnehmen. "offline"Was die Datenbank vorliegt, aber die Verbindung zum Code nicht möglich ist. Wenn eine Datenbank" offline "ist, bleibt sie weiterhin verfügbar und ist innerhalb von Minuten reversibel.

Bei meinem letzten Job hatten wir einige Produkte, die mehrere Monate pro Jahr in Betrieb waren. Daher hätte die Datenbank für Monate nicht ausgeschaltet oder offline durchgeführt worden, dass die Leute, die mit diesem Produkt arbeiten, nicht bemerkt worden wäre. Als Beispiel eines der Produkte mit W-2-Formularen erfolgen 98% des Geschäfts im Januar und Februar (für die meisten Unternehmen sind die Daten erst in der ersten Januarwoche und der Federal Regulatory Frist für die Einreichung des Informationen sind der letzte Geschäftstag im Januar). Der Webserver wurde normalerweise von Mai/Juni bis Dezember ausgeschaltet.

In dieser Firma 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" die Anlaufstelle, wenn Fragen gestellt werden mussten. Wenn der Eigentümer das Unternehmen verließ (selten bis letztes Jahr), wird jemand als neuer Eigentümer zugewiesen, bevor er ging.

Bei anderen Unternehmen haben wir Datenbanken ein Viertel offline gestellt, wenn sie offline bleiben, wenn nichts bricht (z. B. Monat/vierteljährliche Berichterstattung), werden sie ein letztes Mal unterstützt und gelöscht. Auf diese Weise kann jemand später zurückkommen und die Datenbank (die ein paar Minuten dauert) für die Situationen mit Geschichten wie "Oh, das für das Jones -Projekt, das wir beiseite legen mussten, während wir das Fred -Projekt beendet haben, aufnehmen."