安全永久删除数据库的最佳实践是什么？

我们有一个“有机”的环境，这意味着人们在最少的监督或文档的情况下将代码堆积在代码上已有十年。我使用的服务器有几个我认为不再使用的数据库。我很想删除它们，只留下我实际使用的三个。

在极端鲁extreme的极端情况下，我可以禁用这些数据库并等待有人尖叫。在其他情况下，我可以让它们永远运行以防万一。您发现哪些步骤对确定服务器是否正在使用有价值，以及如何使用？

此外，您建议采取什么步骤来确保在禁用系统中不断发展，并在一段时间内保持可逆性（例如，重命名对象而不是直接删除它们）？

谢谢！

您还需要确保每个表的日期时间戳。在系统中为每个表搜索任何元数据，按上次更新的日期时间排序这样的列表，并按日期时间按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中却严格遵循。

您可以尝试建立一个仅捕获连接及其连接的数据库的跟踪。我会稍等一下，然后确保没有任何连接。

一个问题是如果您在主数据库上打开了一些代码，但是在代码内调用了另一个数据库。我不确定指向您的数据库的代码有多糟糕。

我还要查询您的所有作业，并确保没有作业指向该数据库

如果您具有正确版本的SQL（2008 R2企业版），则也可以使用SQL审核。

当有人登录该数据库时，您也可以使用登录触发器来更新表。这将显示是否有任何内容正在连接到该数据库。

另外，您建议采取哪些步骤来确保在禁用系统中不断发展，并在一段时间内保持可逆性

在SQL Server中，您可以使数据库“ 脱机 ”，从而使数据库不存在，但无法通过代码连接到数据库。如果数据库处于“脱机”状态，则该数据库仍将保持可用状态，并且在数分钟内可逆。

在我的上一份工作中，我们每年都会使用某些产品运行几个月，因此，使用该产品的人们不会注意到一次关闭或脱机几个月的数据库。例如，其中一种产品涉及W-2表格，因此98％的业务发生在1月和2月（对于大多数公司而言，该数据要到1月的第一周才可用，而联邦监管部门必须在1月的第一个星期之前提交该数据）。信息是一月份的最后一个工作日）。Web服务器通常在5月/ 6月至12月关闭。

在那家公司，我们有一个带有数据库“所有者”的电子表格-一个人负责产品。当其他人可以更新表的结构时，当必须提出任何问题时，“所有者”是首选人。如果所有者离开公司（直到去年才稀有），那么在离开之前，将指派一个人作为新所有者。

在其他公司，我们已经使数据库脱机了四分之一，如果它们保持脱机状态且没有任何中断（例如，月/季度报告），那么它们将最后一次备份并删除。这样一来，在某些情况下，诸如“哦，那是为完成fred项目而不得不搁置的jones项目”这样的情况，某人以后可以返回并恢复数据库（这需要几分钟）。