Quais são as práticas recomendadas para excluir permanentemente um banco de dados com segurança?

Temos um ambiente "orgânico", o que significa que as pessoas empilharam código em código por dez anos com supervisão ou documentação mínimas. O servidor que eu uso possui vários bancos de dados que, acredito, não estão mais sendo usados; Adoraria excluí-los e deixar apenas os três que realmente uso.

No extremo imprudente, eu poderia desativar esses bancos de dados e esperar alguém gritar; no outro, eu poderia deixá-los funcionando para sempre "apenas por precaução". Quais etapas você considerou valiosas para identificar se um servidor está sendo usado e como?

Além disso, quais etapas você recomendaria para garantir que, à medida que avançamos nos sistemas desabilitados, eles permaneçam convenientemente reversíveis por um período de tempo (por exemplo, renomeie objetos em vez de excluí-los completamente)?

Obrigado!

Você também deseja certificar-se dos carimbos de data e hora de todas as tabelas. Pesquise qualquer metadado no sistema para todas as tabelas, ordene essa lista por data e hora atualizadas pela última vez e exiba a saída em ordem descendente por data e hora. Você também pode verificar o tamanho da tabela até mesmo para uma ligeira alteração no tamanho.

Por exemplo, no MySQL 5.x, você tem information_schema.tables que se parece com isso:

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)

A coluna UPDATE_TIME registra a última vez que qualquer INSERT, UPDATE ou DELETE foi aplicado pela última vez à tabela. Você pode executar consultas como estas para descobrir quando cada banco de dados foi acessado pela última vez:

A última vez que uma tabela foi acessada em cada banco de dados:

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;

A última vez que uma tabela foi acessada em qualquer banco de dados:

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

Últimas 10 datas em que uma tabela foi acessada:

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;

Estes são apenas alguns exemplos de como obter esses metadados do MySQL. Tenho certeza de que o Oracle e o SQL Server têm métodos semelhantes ou melhores.

Depois de ter certeza de quantas vezes ou raramente um banco de dados (ou esquema) é acessado, você deve despejar / exportar manualmente os bancos de dados antigos, juntamente com cópias do próprio esquema, além dos dados. Por favor, desculpe que minha resposta não seja DB independente. Os DBAs SQLServer e Oracle também devem expressar suas respostas aqui, já que o conceito de um esquema como sendo uma coleção dentro de uma instância de banco de dados é obscurecido no MySQL, mas seguido rigorosamente no SQLServer e Oracle.

Você pode tentar configurar um rastreamento que captura apenas as conexões e com qual banco de dados elas se conectam. Eu deixaria isso funcionando por um tempo e depois garantiria que nada estivesse se conectando a ele.

Um problema com isso seria se você tivesse algum código abrindo no banco de dados mestre, mas chamando outro banco de dados no código. Não tenho certeza de quão ruim é o código que está apontando para seus bancos de dados.

Também consultaria todos os seus trabalhos e garantiria que nenhum deles apontasse para esse banco de dados

Você também pode usar a auditoria SQL se tiver a versão correta do SQL (2008 R2 enterprise).

Você também pode usar gatilhos de logon para atualizar uma tabela quando alguém fizer logon no banco de dados. Isso mostraria se algo estava se conectando a esse banco de dados.

Além disso, quais etapas você recomendaria para garantir que, à medida que avançamos nos sistemas incapacitantes, eles permaneçam convenientemente reversíveis por um período de tempo

No SQL Server, você pode colocar os bancos de dados " offline ", o que deixa o banco de dados presente, mas impossibilita a conexão a ele via código. Se um banco de dados estiver "offline", ele permanecerá disponível e é reversível em questão de minutos.

No meu último trabalho, tínhamos alguns produtos que estavam em operação por vários meses por ano, portanto, desligando ou desativando o banco de dados por meses seguidos não seria percebido pelas pessoas que trabalhavam com esse produto. Como exemplo, um dos produtos envolvia os formulários W-2, 98% dos negócios acontecem em janeiro e fevereiro (para a maioria das empresas, os dados não estão disponíveis até a primeira semana de janeiro e o prazo regulamentar federal para o preenchimento do informações é o último dia útil de janeiro). O servidor da web geralmente estava desativado de maio / junho até dezembro.

Nessa empresa, tínhamos uma planilha com o "proprietário" do banco de dados - uma única pessoa responsável pelo produto. Enquanto outros poderiam fazer atualizações na estrutura das tabelas, o "proprietário" era o responsável por todas as perguntas. Se o proprietário deixasse a empresa (raro até o ano passado), alguém seria designado para ser o novo proprietário antes de sair.

Em outras empresas, colocamos os bancos de dados offline por um quarto. Se eles permanecerem offline sem nada quebrar (como relatórios mensais / trimestrais), eles serão copiados pela última vez e excluídos. Isso permite que alguém volte mais tarde e restaure o banco de dados (o que leva alguns minutos) para situações com histórias como "ah, isso foi para o projeto jones que tivemos que deixar de lado enquanto terminávamos o projeto fred".