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


10

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!


11
Esta é uma pergunta muito astuta para as idades. +1 para essa pergunta. Espero que esta pergunta provoque uma resposta maior, já que os DBAs devem, mais cedo ou mais tarde, enfrentar essa situação em suas carreiras.
RolandoMySQLDBA

Uau, ótimos pontos ao redor! E o RolandoMySQLDBA já se ocupou de agradecer a todos por mim :) Deixarei isso em aberto por mais um tempo para ver se há mais sugestões. Depois, terei a difícil tarefa de escolher a resposta mais útil.
Jon de todos os negócios

Respostas:


4

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.


Uma dica muito boa. Vou montar um conjunto de consultas para ficar de olho nas atualizações. Para o benefício das gerações futuras, aqui está uma consulta no nível do esquema, para o 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

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.


Resposta muito boa, especialmente em relação aos gatilhos de login !!! O MySQL não tem nada disso, embora eu possa emular isso com a ativação do log geral e a verificação de endereços IP e bancos de dados especificados. O seu é um +1 !!!
RolandoMySQLDBA

4

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".


Bom mini estudo de caso, +1 !!!
RolandoMySQLDBA

@Tanguerna: Eu acho que usei esse recurso há muitos anos, mas é perfeito para esse tipo de papel, muito obrigado por me lembrar.
Jon of All Trades
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.