Comment savoir si une base de données SQL Server est toujours utilisée?

Nous cherchons à mettre hors service une instance SQL Server contenant quelques bases de données.

Comment puis-je savoir s'ils sont encore utilisés par des utilisateurs ou par une application Web?

J'ai trouvé un fil de discussion contenant une requête T-SQL que vous pouvez exécuter pour récupérer la date de la dernière requête. Cela semble fonctionner, mais je veux savoir si cette information est suffisamment valide pour supprimer des bases de données. Est ce

Si vous avez d'autres méthodes, cela vous aiderait aussi.

Vous devez vous préoccuper des éléments qui ont été purgés du cache et que vous avez manqués, ou des bases de données dont l'utilisation est peu fréquente.

Plutôt que de laisser tomber les bases de données, mettez-les soit hors ligne pour empêcher l'accès sans les laisser tomber, soit en mode RESTRICTED_USER pour limiter l'accès. En faisant cela, vous pouvez les laisser dans cet état pendant un mois ou deux pour vérifier et voir s'il y a une utilisation occasionnelle.

Vous pouvez également utiliser un filtre de trace de profileur côté serveur sur cette base de données.

Ce sont les méthodes que j'ai utilisées dans le passé:

1. Déconnecter / déconnecter la base de données
2. DENY accès utilisateur / login
3. Trace de Profiler

Le problème est le suivant: combien de temps attendez-vous avant d'être certain que personne ne va accéder aux données? Pour les données financières, certains éléments sont exécutés quotidiennement, hebdomadairement, mensuellement, trimestriellement, semestriellement et annuellement. Mais une année suffit-elle? J'ai également vu des demandes de mise à disposition des données pendant au moins 7 ans et, dans un cas, on m'a dit que les données d'un système devaient être conservées indéfiniment, même si personne ne les utilisait.

Le meilleur conseil est le suivant: quoi que vous fassiez pour désactiver l'accès, assurez-vous de le réactiver immédiatement. J'ai trouvé que le détail fonctionnait mieux pour cela. Je voudrais simplement écrire un script et rattacher mon équipe à «si quelqu'un demande jamais où il se trouve, lancez ce script». Cela nous a donné la meilleure chance de remettre les choses en place le plus rapidement possible.

Je suis d'accord avec Nic avec son conseil. Si vous devez en être sûr, vous devrez alors utiliser Profiler (trace côté service), car certaines requêtes SQL ne seront pas mises en cache ou, pour une raison quelconque, le cache de procédure pourrait être purgé.

Je vérifierais normalement les informations de statistiques de fichier virtuel également pour voir s'il y a des lectures ou des écritures se produisant au niveau du fichier du système d'exploitation. Même si la base de données n'est PAS active, vous verrez toujours une petite lecture / écriture si vous effectuez des sauvegardes de journaux, des sauvegardes complètes, etc., mais cela vous donnera également une idée de l'activité de lecture / écriture sur cette base de données.

Avant de supprimer une base de données, je voudrais vous assurer que vous avez au moins 2 ou 3 sauvegardes lisibles (les tester) dans des emplacements distincts. Vous ne savez jamais quand vous en avez besoin.

La requête suivante montre les DB qui ne sont plus utilisés depuis le dernier redémarrage, sans que les plans de requête soient conservés dans le cache, car ils indiquent les entrées / sorties de l'utilisateur sur les index (et les segments). Cela revient en quelque sorte à utiliser des statistiques de fichier virtuel, mais le DMV utilisé ici exclut l'activité des E / S des sauvegardes. Il n'est pas nécessaire de laisser une trace de profileur en cours d'exécution, aucun déclencheur ni audit requis. Bien sûr, si vous redémarrez fréquemment votre serveur SQL (ou que vous attachez / arrêtez souvent des bases de données), cela pourrait ne pas être la solution :-)

Cela dit, acceptez quand même que même si cette requête semble confirmer qu’une base de données peut être supprimée, il est certain que vous devez déconnecter / déconnecter ou refuser l’accès des utilisateurs pendant un certain temps, ainsi que toute la diligence requise pour demander avant de réellement laisser tomber!

select [name] from sys.databases 
where database_id > 4
AND [name] NOT IN 
(select DB_NAME(database_id) 
from sys.dm_db_index_usage_stats
where coalesce(last_user_seek, last_user_scan, last_user_lookup,'1/1/1970') > 
(select login_time from sys.sysprocesses where spid = 1))

J'ai travaillé dans un endroit qui comptait un grand nombre de bases de données orphelines et semi-orphelines. Il était difficile de dire s’ils étaient vraiment orphelins, car de nombreuses tâches étaient saisonnières ou annuelles, de sorte que le site Web ne fonctionne que pendant 3 à 4 mois par an (par exemple, les formulaires W2 doivent être archivés de manière électronique le 1/31, de sorte que le traitement du site Web ceux-ci ne se sont déroulés que de la mi-janvier à la fin avril).

Ce qui a été fait était une combinaison de:
* demander à chaque développeur s'il utilisait une base de données ou une autre (ces courriels seraient envoyés tous les mois ou lorsque les sauvegardes prenaient trop de temps).
* prendre la base de données hors ligne et voir qui se plaint.
* renommer le serveur pour voir qui se plaint.

Étant donné que le patron aux cheveux pointus était uniquement disposé à autoriser une documentation "complète et complète", un wiki était expressément interdit, et les réductions de personnel entraînaient un déclin spectaculaire de la documentation conforme à la norme.

Si cela dépendait de moi, il y aurait une page wiki par serveur avec des noms de contacts pour chaque base de données (et peut-être une brève description de son utilité). Toute base de données non documentée sur le wiki constituerait un jeu équitable à supprimer.

Nous avions un grand client financier qui utilisait encore SQL Server 2000 jusqu'en 2009; nous avons donc dû laisser une instance de SQL Server 2000 fonctionner jusqu'à ce que ce client soit finalement transféré vers SQL Server 2005.

Deux autres alternatives sont:

1. Créez des déclencheurs sur la base de données qui vous informeront (ou stockeront dans des tables) de toute activité.

2. Activer l'audit sur les bases de données.

   • Dépend de votre version de base de données.

La solution suivante affiche les pages temporaires totales, propres et sales en Mo pour des bases de données particulières de votre instance (trouvées sur Internet et légèrement modifiées):

SELECT
    (CASE WHEN ([database_id] = 32767) THEN 'Resource Database' ELSE DB_NAME (database_id) END) AS 'Database Name',
    COUNT(*) *8/1024 AS [TotalPages in MB],
    SUM(CASE WHEN ([is_modified] = 1) THEN 0 ELSE 1 END) *8/1024 AS [CleanPages in MB],
    SUM(CASE WHEN ([is_modified] = 1) THEN 1 ELSE 0 END) *8/1024 AS [DirtyPages in MB]
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY DB_NAME(database_id)

ou

select value [DBid],attribute, last_execution_time ,text
from
sys.dm_exec_query_stats
cross apply
sys.dm_exec_plan_attributes(plan_handle)
cross apply
sys.dm_exec_sql_text(plan_handle)
where  attribute = 'dbid' 
order by last_execution_time desc

ou

select value [DBid],attribute, last_execution_time ,text
from
sys.dm_exec_query_stats
cross apply
sys.dm_exec_plan_attributes(plan_handle)
cross apply
sys.dm_exec_sql_text(plan_handle)
--where dbid=8
where 
      text like '%idAdministrator%' and
      attribute = 'dbid' 
      and value>= 5 -- dbid >=5 for user databases but include resource database which
                     --you can exclude by its numer I don't remember at the moment
order by last_execution_time desc