Início / dba / Perguntas / 138724
Accepted
Tim Schmelter
Asked: 2016-05-18 00:14:41 +0800 CST

Como ocultar/desativar tabelas sem soltá-las para verificar a redundância?

  • 772

Eu tenho que manter e estender um sistema legado antigo que contém métodos de webservice e tabelas de banco de dados que não são mais usados. Como não tenho certeza absoluta de que as tabelas são realmente redundantes, tenho medo de abandoná-las.

Existe alguma outra maneira de obter o mesmo efeito (as tabelas não podem mais ser usadas) sem soltá-las? Minha ideia era transferi-los para um esquema diferente (por exemplo, Deleted) do padrão atual, dbo.

IF NOT EXISTS (SELECT * FROM sys.schemas WHERE name = 'Deleted')
BEGIN
   EXEC('CREATE SCHEMA Deleted')
END

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

Existe alguma outra opção ou há alguma desvantagem na abordagem do esquema?

sql-server database-design

5 respostas

  1. Algumas outras opções são apenas renomear as tabelas ou, se tiverem índices clusterizados, você pode desabilitar o índice clusterizado.

    • 12
  2. Best Answer

    Existe alguma outra maneira de conseguir o mesmo (as tabelas não podem mais ser usadas) sem descartá-las?

    Uma mudança de esquema é uma operação muito rápida - apenas a mudança de metadados é necessária. A ideia original que tive foi do blog de Aaron Bertrand - Schema Switch-A-Roo .

    Você pode seguir os passos da minha resposta aqui

    Obviamente, existem outros métodos como sp_rename N'old table', N'new table' ou apenas negar permissões para a tabela.

    • 7

  3. Remova as permissões na tabela da(s) Função(ões)/Grupo(s)/Conta(s) que [podem] estar usando.

    Se alguma coisa explodir, coloque-a de volta [rapidamente].

    Dica: Usar um script para fazer essas alterações seria uma ideia muito, muito boa.

    • 6

  4. Remova as permissões como Phil W. sugere.

    Remova também as permissões de quaisquer procedimentos armazenados que usam as tabelas. No SQL Server, (não sei sobre outros) as permissões são encadeadas de um objeto de chamada (por exemplo, o procedimento armazenado) para o objeto chamado (por exemplo, uma tabela).

    • 3

  5. A remoção de permissões geralmente não funciona porque você não pode ter CERTEZA de que alguém não tem permissões. Possivelmente através de um grupo, função ou mesmo porque são administradores de sistema (embora esperemos que não).

    Para tabelas, você pode desativá-los. E esse é um processo rápido. No entanto, para ativá-los , é necessário reconstruí-los e para uma tabela grande, o que pode levar um bom tempo.

    Sua melhor aposta será mover o objeto para um novo esquema (como você sugeriu) ou renomear o objeto. Ambas as operações são rápidas e fáceis de fazer e desfazer. As permissões também permanecerão em vigor em ambas as direções.

    Uma etapa adicional que você pode executar é adicionar uma "nota TBD" nas propriedades estendidas do objeto. Você pode anotar quando fez a alteração e/ou quaisquer anotações que possa ter sobre o motivo pelo qual acha que é seguro se livrar.

    Dito isso, eu executaria uma sessão de eventos estendida (ou rastreamento do criador de perfil) por alguns dias para ter certeza de que você tem todos os objetos sendo usados. Você pode limitar fortemente a sessão apenas ao nome do objeto e quando foi tocado para reduzir a sobrecarga. Além disso, certifique-se de executar esta sessão por alguns dias em ambos os lados do final do mês e possivelmente até no final do trimestre para ter certeza de que você tem tudo.

    • 3

relate perguntas