Які найкращі практики для безпечного постійного видалення бази даних?


10

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

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

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

Дякую!


1
Це дуже проникливе питання для віків. +1 для такого питання. Я сподіваюся, що це питання викликає більшу відповідь, оскільки спеціалісти з питань фізичної та юридичної особи повинні пізніше зіткнутися з цією ситуацією в своїй кар'єрі.
RolandoMySQLDBA

Ух, чудові бали навколо! І RolandoMySQLDBA вже подбав про те, щоб подякувати всім за мене :) Я залишу це відкриття трохи довше, щоб побачити, чи є ще пропозиції, тоді я буду складним завданням вибрати найбільш корисну відповідь.
Джон з усіх торгів

Відповіді:


4

Ви також хочете переконатися в марках дати кожної таблиці. Шукайте будь-які метадані в системі для кожної таблиці, упорядкуйте такий список за останнім часом оновленим датою та виведіть вихід у порядку desc до дати. Ви також можете перевірити розмір столу на предмет навіть незначної зміни розміру.

Наприклад, у 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 DBA повинні також озвучувати свої відповіді, оскільки концепція схеми, що є колекцією в екземплярі бази даних, розмита в MySQL, але дуже суворо дотримується в SQLServer та Oracle.


Дуже хороша порада. Я зберу набір запитів, щоб слідкувати за оновленнями. Для користі майбутніх поколінь, ось такий запит на рівні схеми, для MS SQL:SELECT S.name, MAX(T.modify_date) AS MostRecentDataModification FROM sys.schemas AS S INNER JOIN sys.tables AS T ON S.schema_id = T.schema_id GROUP BY S.name
Jon of All Trades

6

Ви можете спробувати встановити трасування, яке фіксує лише з'єднання та базу даних, до якої вони підключаються. Я хотів би залишити це на деякий час, а потім переконатися, що до нього нічого не підключається.

Проблема з цим полягала б у тому, що у вас є який-небудь код, що відкривається на головний db, але викликає інший БД в коді. Я не впевнений, наскільки поганий код, який вказує на ваші БД.

Я також запитую всі ваші завдання та переконайтесь, що жодна не вказує на цю БД

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

Ви також можете використовувати тригери входу для оновлення таблиці, коли хтось увійшов у цю БД. Це покаже вам, чи щось підключалося до цієї БД.


Дуже хороша відповідь, особливо що стосується тригерів входу !!! MySQL не має нічого подібного, хоча я міг би наслідувати його за допомогою активації загального журналу та перевірки вказаних IP-адрес та баз даних. Твій - +1 !!!
RolandoMySQLDBA

4

Крім того, які кроки ви б рекомендували, щоб у міру того, як ви рухаєтесь вперед в системах відключення, вони залишалися зручними оборотними протягом певного періоду часу

У SQL Server ви можете приймати бази даних " офлайн ", що залишає базу даних присутньою, але робить підключення до неї за допомогою коду неможливим. Якщо база даних не працює в режимі офлайн, вона все ще залишається доступною і повертається протягом декількох хвилин.

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

У цій компанії у нас була електронна таблиця з "власником" бази даних - однією єдиною особою, відповідальною за продукт. Хоча інші могли оновлювати структуру таблиць, "власник" був людиною, яка переходила до людини, коли потрібно було задавати будь-які питання. Якщо власник покинув компанію (рідко до минулого року), хтось був призначений новим власником до того, як вони пішли.

В інших компаніях ми брали бази даних в автономному режимі протягом чверті, якщо вони залишаються в режимі офлайн, нічого не порушує (наприклад, звітність за місяць / квартал), вони отримують резервну копію в останній раз та видаляються. Це дозволяє комусь пізніше повернутися і відновити базу даних (що займає кілька хвилин) для тих ситуацій, в яких є історії на кшталт "о, це було для проекту Джонса, який нам довелося відкласти, поки ми закінчили проект fred".


Хороший міні-кейс, +1 !!!
RolandoMySQLDBA

@Tanguerna: Я думаю, що я користувався цією функцією багато років тому, але вона ідеально підходить для такої ролі, тому дуже дякую, що нагадали.
Йон з усіх торгів
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.