Каковы рекомендации для безопасного безвозвратного удаления базы данных?

У нас «органическая» среда, то есть люди накапливали код в течение десяти лет с минимальным контролем или документацией. Сервер, который я использую, имеет несколько баз данных, которые, я считаю, больше не используются; Я хотел бы удалить их и оставить только три, которые я на самом деле использую.

В безрассудной крайности я мог отключить эти базы данных и ждать, пока кто-нибудь закричит; с другой стороны, я могу оставить их работать вечно "на всякий случай". Какие шаги вы нашли ценными при определении того, используется ли сервер и как?

Кроме того, какие шаги вы бы порекомендовали для обеспечения того, чтобы по мере продвижения вперед в отключении систем они оставались удобно обратимыми в течение определенного периода времени (например, переименовывали объекты, а не удаляли их сразу)?

Спасибо!

Вы также хотите удостовериться в отметках даты и времени каждой таблицы. Выполните поиск любых метаданных в системе для каждой таблицы, упорядочите такой список по дате и времени последнего обновления и отобразите выходные данные в порядке убывания по дате и времени. Вы также можете проверить размер таблицы даже для небольшого изменения размера.

Например, в MySQL 5.x у вас есть information_schema.tables, которая выглядит так:

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)

Столбец UPDATE_TIME записывает, когда в последний раз любые INSERT, UPDATE или DELETE последний раз применялись к таблице. Вы можете выполнить такие запросы, чтобы узнать, когда к каждой базе данных обращались в последний раз:

Последний раз к таблице обращались в каждой базе данных:

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;

Последний раз к таблице обращались в любой базе данных:

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

Последние 10 дат обращения к таблице:

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;

Это всего лишь несколько примеров того, как получить такие метаданные из MySQL. Я уверен, что Oracle и SQL Server имеют похожие или лучшие методы.

Если вы уверены, как часто или редко обращаетесь к базе данных (или схеме), вам следует вручную вывести / экспортировать устаревшие базы данных вместе с копиями самой схемы, кроме данных. Пожалуйста, извините, что мой ответ не является независимым от БД. Администраторы SQLServer и Oracle также должны здесь озвучить свои ответы, поскольку концепция схемы, являющейся коллекцией в экземпляре базы данных, в MySQL размыта, но в SQLServer и Oracle очень строго соблюдается.

Вы можете попытаться настроить трассировку, которая фиксирует только соединения и к какой базе данных они подключаются. Я бы оставил это включенным на некоторое время, а затем убедился, что к нему ничего не подключено.

Одна проблема с этим будет, если у вас есть код, открывающийся на главной базе данных, но вызывающий другую БД внутри кода. Я не уверен, насколько плох код, который указывает на ваши базы данных.

Я также запросил бы все ваши работы и удостоверился, что никто не указывает на ту DB

Вы также можете использовать аудит SQL, если у вас есть правильная версия SQL (2008 R2 Enterprise).

Вы также можете использовать триггеры входа в систему для обновления таблицы, когда кто-то вошел в эту БД. Это покажет вам, если что-то подключается к этой БД.

Кроме того, какие шаги вы бы порекомендовали, чтобы по мере продвижения вперед в отключении систем они оставались удобно обратимыми в течение некоторого периода времени?

В SQL Server вы можете переводить базы данных в автономный режим, что оставляет базу данных присутствующей, но делает невозможным подключение к ней через код. Если база данных находится в автономном режиме, она все еще остается доступной и обратимой в течение нескольких минут.

На моей последней работе у нас было несколько продуктов, которые работали в течение нескольких месяцев в году, поэтому люди, работающие с этим продуктом, не заметили бы отключение или отключение базы данных на несколько месяцев подряд. В качестве одного примера, один из продуктов включал формы W-2, поэтому 98% бизнеса происходит в январе и феврале (для большинства компаний данные недоступны до первой недели января и федерального нормативного срока подачи заявок). информация последний рабочий день января). Веб-сервер обычно отключался с мая / июня до декабря.

В этой компании у нас была электронная таблица с «владельцем» базы данных - одним человеком, ответственным за продукт. В то время как другие могли вносить изменения в структуру таблиц, «владелец» был ответственным лицом, когда нужно было задать какие-либо вопросы. Если владелец покинул компанию (редко до прошлого года), кто-то будет назначен новым владельцем до своего ухода.

В других компаниях мы отключаем базы данных на четверть, если они остаются в автономном режиме, не нарушая ничего (например, отчет за месяц / квартал), их резервируют в последний раз и удаляют. Это позволяет кому-то позже вернуться и восстановить базу данных (что занимает несколько минут) для тех ситуаций, в которых есть истории типа «о, это было для проекта Джонса, который нам пришлось отложить, пока мы заканчивали проект fred».