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

Question

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

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

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

Спасибо!

Answer 1

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

Например, в 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 записывает последний раз, когда любой вставка, обновление или удаление в последний раз применялись к таблице. Вы могли бы запустить подобные запросы, чтобы узнать, когда к каждой базе данных была получена в последний раз:

В прошлый раз в каждой базе данных доступ к таблице:

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 имеют аналогичные или лучшие методы.

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

Answer 2

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

Одна проблема с этим было бы, если у вас есть какой -то код, открываясь в Master DB, но вызов другой DB в коде. Я не уверен, насколько плохо код, который указывает на ваш DBS.

Я также запросил всю вашу работу и не указывает на этот БД

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

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

Answer 3

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

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

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

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

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