Quali sono le migliori pratiche per l'eliminazione permanente sicura di un database?

Abbiamo un ambiente "organico", il che significa che le persone hanno accumulato codice su codice per dieci anni con una supervisione o documentazione minima. Il server che uso ha diversi database che credo non vengano più utilizzati; Mi piacerebbe eliminarli e lasciare solo i tre che uso effettivamente.

All'estremo spericolato, potrei disabilitare questi database e aspettare che qualcuno urli; dall'altro potrei lasciarli correre per sempre "per ogni evenienza". Quali passaggi hai trovato prezioso per identificare se un server viene utilizzato e come?

Inoltre, quali passi consiglieresti di assicurare che, man mano che avanzi nei sistemi di disabilitazione, rimangano convenientemente reversibili per un certo periodo di tempo (ad esempio, rinominare gli oggetti anziché eliminarli del tutto)?

Grazie!

Vuoi anche assicurarti dei timbri datetime di ogni tabella. Cerca eventuali metadati nel sistema per ogni tabella, ordina tale elenco in base all'ultimo aggiornamento di datetime e visualizza l'output in ordine decrescente per datetime. Puoi anche controllare le dimensioni della tabella anche per un leggero cambiamento nelle dimensioni.

Ad esempio, in MySQL 5.x, hai information_schema.tables che assomiglia a questo:

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 colonna UPDATE_TIME registra l'ultima volta che INSERT, UPDATE o DELETE sono stati applicati l'ultima volta alla tabella. È possibile eseguire query come queste per scoprire quando è stato effettuato l'ultimo accesso a ciascun database:

L'ultima volta è stato effettuato l'accesso a una tabella in ciascun database:

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;

L'ultima volta è stato effettuato l'accesso a una tabella in qualsiasi database:

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

Ultime 10 date di accesso a una tabella:

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;

Questi sono solo alcuni esempi di come ottenere tali metadati da MySQL. Sono sicuro che Oracle e SQL Server hanno metodi simili o migliori.

Una volta che si è sicuri della frequenza o raramente dell'accesso a un database (o schema), è necessario eseguire il dump / esportazione manuale di database obsoleti insieme alle copie dello schema stesso a parte i dati. Scusa, la mia risposta non è agnostica per DB. Anche i DBA di SQL Server e Oracle dovrebbero dare le loro risposte qui, poiché il concetto di uno schema che è una raccolta all'interno di un'istanza di database è offuscato in MySQL ma seguito molto rigorosamente in SQL Server e Oracle.

È possibile provare a impostare una traccia che acquisisce solo le connessioni e il database a cui si connettono. Vorrei lasciarlo in esecuzione per un po 'e quindi assicurarmi che nulla si connetta ad esso.

Un problema potrebbe essere se si dispone di un codice che si apre sul db master ma che chiama un altro DB all'interno del codice. Non sono sicuro di quanto sia negativo il codice che punta ai tuoi DB.

Interrogerei anche tutti i tuoi lavori e mi assicurerei che nessuno indichi quel DB

È inoltre possibile utilizzare il controllo SQL se si dispone della versione corretta di SQL (2008 R2 enterprise).

È inoltre possibile utilizzare i trigger di accesso per aggiornare una tabella quando qualcuno accede a quel DB. Questo ti mostrerebbe se qualcosa si connetteva a quel DB.

Inoltre, quali passi consiglieresti di garantire che, man mano che si procede in avanti nella disattivazione dei sistemi, rimangano convenientemente reversibili per un periodo di tempo

In SQL Server, è possibile portare i database " offline " che lascia il database presente, ma rende impossibile la connessione tramite codice. Se un database è "offline" rimane comunque disponibile ed è reversibile in pochi minuti.

Nel mio ultimo lavoro avevamo alcuni prodotti che erano in funzione per diversi mesi all'anno, quindi la disattivazione o la disattivazione del database per mesi alla volta non sarebbe stata notata dalla gente che lavorava con quel prodotto. Ad esempio, uno dei prodotti riguardava i moduli W-2, quindi il 98% delle attività avviene a gennaio e febbraio (per la maggior parte delle aziende, i dati non sono disponibili fino alla prima settimana di gennaio e il termine regolamentare federale per la presentazione del l'informazione è l'ultimo giorno lavorativo di gennaio). Il web server era generalmente spento da maggio / giugno a dicembre.

In quella società, avevamo un foglio di calcolo con il "proprietario" del database, una sola persona responsabile del prodotto. Mentre altri potevano aggiornare la struttura delle tabelle, il "proprietario" era la persona di riferimento quando dovevano essere poste delle domande. Se il proprietario lasciasse l'azienda (raro fino allo scorso anno), a qualcuno verrebbe assegnato il ruolo di nuovo proprietario prima di partire.

In altre società, abbiamo portato i database offline per un quarto, se rimangono offline senza interruzioni (come i report mensili / trimestrali), vengono sottoposti a backup un'ultima volta e cancellati. Ciò consente a qualcuno di tornare in seguito e ripristinare il database (che richiede alcuni minuti) per quelle situazioni che hanno storie come "oh, era per il progetto jones che abbiamo dovuto mettere da parte mentre abbiamo finito il progetto fred".