Comment masquer / désactiver des tables sans les supprimer pour vérifier la redondance?

12

Je dois maintenir et étendre un ancien système hérité qui contient des méthodes de service Web et des tables de base de données qui ne sont plus utilisées. Comme je ne suis pas entièrement sûr que les tables soient vraiment redondantes, j'ai peur de les supprimer.

Existe-t-il un autre moyen d'obtenir le même effet (les tableaux ne peuvent plus être utilisés) sans les supprimer? Mon idée était de les transférer à un schéma différent (par exemple Deleted) à partir de la valeur par défaut actuelle, dbo.

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

ALTER SCHEMA Deleted TRANSFER dbo.TableName;

Y a-t-il une autre option ou y a-t-il des inconvénients à l'approche de schéma?

— Tim Schmelter
source

7

Existe-t-il un autre moyen de réaliser la même chose (les tables ne peuvent plus être utilisées) sans les supprimer?

Un changement de schéma est une opération très rapide - il suffit d'un changement de métadonnées. L'idée originale que j'ai eue est venue du blog d' Aaron Bertrand - Schema Switch-A-Roo .

Vous pouvez suivre les étapes de ma réponse ici

De toute évidence, il existe d'autres méthodes telles que sp_rename N'old table ', N'new table' ou simplement refuser les autorisations sur la table.

— Kin Shah
source

Je n'étais pas sûr de la réponse que je devais accepter car tous sont utiles. Je ne connaissais pas l'article d'Aaron, donc je l'ai accepté car il contient plus d'informations (même si elles sont uniquement liées).

— Tim Schmelter

@TimSchmelter Heureux que vous l'ayez trouvé utile. Cela n'a pas de sens de répéter ici ce que l'article ou ma réponse (lié). C'est pourquoi je l'ai référencé.

— Kin Shah

12

Quelques autres options consistent simplement à renommer les tables, ou si elles ont des index clusterisés, vous pouvez désactiver l'index clusterisé.

— Chad Mattox
source

Merci. Je ne savais pas que la désactivation d'un index cluster rend la table inutilisable. Quels sont les avantages et les inconvénients de ces approches (+ schéma)?

— Tim Schmelter

5

@TimSchmelter a pour inconvénient de désactiver le CI que pour le réactiver, vous devez reconstruire l'index. Une autre option consiste à refuser les autorisations sur la table au rôle public bien que le propriétaire de la base de données ou les administrateurs sys les voient toujours et éventuellement via le chaînage de la propriété.

— Martin Smith

Avant de supprimer une table, ou de supprimer une colonne d'une table, je la renomme souvent en ajoutant "_deprecated" ou quelques-uns à la fin du nom. Ensuite, s'il n'y a pas d'erreurs, il ne doit pas y avoir de référence.

— Jay

Les modifications des autorisations sont hasardeuses. Si le compte de service exécutant une application est le dbo, ou pire administrateur système, il ignorera complètement tout type de DENY. J'espère que non, mais cela arrive.

— Kenneth Fisher

6

Supprimez les autorisations sur la table du (des) rôle (s) / groupe (s) / compte (s) qui [pourraient] l'utiliser.

Si quelque chose explose, remettez-les [rapidement].

Astuce: Utiliser un script pour faire ces changements serait vraiment une très bonne idée.

— Phill W.
source

Tout comme les tests sur une base de données hors production. ;) J'espère que c'était évident pour le PO, cependant.

— jpmc26

@ jpmc26. je vais d'abord tester dans une base de données hors production. Mais le problème est que je veux savoir si les fonctions ou les objets de base de données sont utilisés de l'extérieur (non seulement via les méthodes de webservice mais aussi directement sur la base de données ou les outils d'administration dans d'autres emplacements de l'entreprise).

— Tim Schmelter

Hm. Si vous recherchez un accès direct à la base de données par les administrateurs de base de données, il semble que la journalisation soit en règle. Il est peu probable que vous constatiez la même utilisation en prod et en non-prod à partir d'un travail manuel. Je ne sais pas vraiment à quel point il serait facile de consigner ces opérations, mais si vous aviez un identifiant de connexion, vous pouvez l'analyser pour rechercher des utilisations.

— jpmc26

@ jpmc26: ce n'est pas grave si ces administrateurs tombent sur leur visage, ils le signaleront. Pas d'accord avec les clients, mais cela peut être vérifié sur le système de test avant le déploiement.

— Tim Schmelter

3

La suppression des autorisations ne fonctionnera généralement pas car vous ne pouvez pas être CERTAIN que quelqu'un n'a pas d'autorisations. Peut-être à travers un groupe, un rôle ou même parce qu'ils sont administrateurs système (bien que nous espérons que non).

Pour les tableaux, vous pouvez les désactiver. Et c'est un processus rapide. Cependant, pour les activer, vous devez les reconstruire et disposer d'une grande table qui pourrait vous prendre un certain temps.

Votre meilleur pari sera de déplacer l'objet dans un nouveau schéma (comme vous l'avez suggéré) ou de renommer l'objet. Ces deux opérations sont rapides et faciles à faire et à annuler. Les autorisations resteront également en place dans les deux sens.

Une étape supplémentaire que vous pouvez prendre consiste à ajouter une "note TBD" dans les propriétés étendues de l'objet. Vous pouvez noter quand vous avez effectué le changement et / ou toutes les notes que vous pourriez avoir sur les raisons pour lesquelles vous pensez qu'il est sûr de s'en débarrasser.

Tout cela dit que j'exécuterais une session d'événements étendue (ou trace de profileur) pendant quelques jours pour être sûr que tous les objets sont utilisés. Vous pouvez limiter fortement la session uniquement au nom de l'objet et au moment où il a été touché pour réduire la surcharge. Assurez-vous également que vous exécutez cette session pendant quelques jours de chaque côté de la fin du mois et peut-être même de la fin du trimestre pour être sûr d'avoir tout.

— Kenneth Fisher
source

3

Supprimez les autorisations comme le suggère Phil W..

Supprimez également les autorisations de toutes les procédures stockées qui utilisent les tables. Dans SQL Server, (je ne connais pas les autres), les autorisations sont chaînées d'un objet appelant (par exemple la procédure stockée) à l'objet appelé (par exemple une table).

— Peter Bill
source

La tâche consistait à laisser échouer tous les outils, fonctions, objets, requêtes (même dans les bases de données distantes) qui tentent d'accéder à ces tables. Si je dois modifier une procédure stockée, je dois déjà savoir qu'elle l'utilise. Ou existe-t-il un moyen simple de déterminer qu'une table est utilisée par une procédure stockée?

— Tim Schmelter

Je n'ai pas suggéré de modifier la procédure stockée, mais seulement de supprimer son autorisation EXECUTE. Comme vous le dites, il est facile de restaurer l'autorisation si nécessaire. Vous pouvez voir quelles tables sont utilisées par une procédure stockée: Dans SQL Server Management Studio, Explorateur d'objets, sélectionnez votre base de données -> Programmabilité -> Procédures stockées. Cliquez avec le bouton droit sur un nom de sproc et choisissez Afficher les dépendances. Sélectionnez les objets dont dépend [nom sproc].

— Peter Bill