Wie kann ich feststellen, ob eine SQL Server-Datenbank noch verwendet wird?

Wir möchten eine SQL Server-Instanz außer Betrieb nehmen, auf der noch einige Datenbanken vorhanden sind.

Wie kann ich feststellen, ob sie noch von Benutzern oder einer Webanwendung verwendet werden?

Ich habe einen Forenthread mit einer T-SQL-Abfrage gefunden, mit der Sie das letzte Abfragedatum abrufen können. Es scheint zu funktionieren, aber ich möchte wissen, ob diese Informationen gültig genug sind, um Datenbanken zu löschen. Ist es?

Wenn Sie alternative Methoden haben, würde das auch helfen.

Sie müssen sich mit Elementen befassen, die aus dem Cache entfernt wurden und die Sie verpasst haben, oder mit Datenbanken, die nur selten verwendet werden.

Anstatt die Datenbanken aus der Hand zu werfen, setzen Sie sie entweder auf OFFLINE, um den Zugriff zu verhindern, ohne sie fallen zu lassen, oder auf RESTRICTED_USER, um den Zugriff zu beschränken. Auf diese Weise können Sie sie einen oder zwei Monate in diesem Zustand belassen, um zu überprüfen, ob gelegentliche Verwendung vorliegt.

Sie könnten auch versuchen, eine serverseitige Profiler-Ablaufverfolgungsfilterung für diese Datenbank zu verwenden.

Dies sind die Methoden, die ich in der Vergangenheit angewendet habe:

1. Datenbank offline schalten / trennen
2. Benutzer / Login-Zugang verweigern
3. Profiler-Ablaufverfolgung

Das Problem ist: Wie lange warten Sie, bis Sie sicher sind, dass niemand auf die Daten zugreifen wird? Bei Finanzdaten werden einige Elemente täglich, wöchentlich, monatlich, vierteljährlich, halbjährlich und jährlich ausgeführt. Aber ist ein Jahr lang genug? Ich habe auch Anfragen erhalten, Daten mindestens sieben Jahre lang verfügbar zu halten, und in einem Fall wurde mir mitgeteilt, dass die Daten in einem System für immer vorhanden sein müssen, obwohl sie von niemandem verwendet werden.

Der beste Rat ist: Was auch immer Sie tun, um den Zugriff zu deaktivieren, stellen Sie sicher, dass Sie ihn sofort wieder einschalten können. Ich fand, dass der Rückzieher dafür am besten funktionierte. Ich würde einfach das Reattach ausschreiben und mein Team anweisen, "wenn jemand jemals fragt, wo es ist, führe dieses Skript aus". Das gab uns die beste Chance, die Dinge so schnell wie möglich zurückzustellen.

Ich stimme Nic mit seinem Rat zu. Wenn Sie sicher sein müssen, müssen Sie sich für Profiler (Service Side Trace) entscheiden, da einige der SQL-Abfragen nicht zwischengespeichert werden oder der Prozedurcache aus irgendeinem Grund gelöscht werden kann.

Normalerweise überprüfe ich die Daten der virtuellen Dateistatistik auch, um festzustellen, ob Lese- oder Schreibvorgänge auf Betriebssystemdateiebene stattfinden. Selbst wenn die Datenbank NICHT aktiv ist, werden Sie immer noch kleine Lese- / Schreibvorgänge sehen, wenn Sie Protokollsicherungen, vollständige Sicherungen usw. durchführen. Dadurch erhalten Sie jedoch auch eine Vorstellung von Lese- / Schreibaktivitäten für diese Datenbank.

Vor dem Löschen einer Datenbank stelle ich sicher, dass Sie mindestens zwei oder drei lesbare Sicherungen an verschiedenen Speicherorten haben (testen). Sie wissen nie, wann Sie sie brauchen.

Die folgende Abfrage zeigt DBs, die seit dem letzten Neustart nicht mehr verwendet wurden, ohne auf Abfragepläne angewiesen zu sein, die im Cache gespeichert sind, da die Benutzer-E / A anhand der Indizes (und Heaps) angezeigt werden. Dies entspricht in etwa der Verwendung virtueller Dateistatistiken, aber die hier verwendete DMV schließt die E / A-Aktivität von Sicherungen aus. Es muss kein Profiler-Trace ausgeführt werden, es sind keine Trigger oder Audits erforderlich. Wenn Sie Ihren SQL Server häufig neu starten (oder Datenbanken häufig anhängen / herunterfahren), ist dies natürlich möglicherweise nicht der richtige Weg :-)

Dennoch stimmen Sie zu, dass Sie, auch wenn diese Abfrage zu bestätigen scheint, dass eine Datenbank gelöscht werden kann, auf jeden Fall den OFFLINE-Befehl ausführen / den Benutzerzugriff für einige Zeit trennen oder verweigern.

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))

Ich habe an einem Ort gearbeitet, an dem es eine große Anzahl verwaister und halbverwaister Datenbanken gab. Es war schwer zu sagen, ob sie tatsächlich verwaist waren, da es sich bei vielen Aufgaben um saisonale oder jährliche Aufgaben handelte - so dass die Website nur 3 bis 4 Monate pro Jahr ausgeführt wird (zum Beispiel müssen W2-Formulare zum 31. Januar elektronisch eingereicht werden, damit die Website verarbeitet werden kann Diese dauerten nur von Mitte Januar bis Ende April.

Was getan wurde, war eine Kombination aus:
* Fragen Sie jeden Entwickler, ob er eine Datenbank oder eine andere verwendet (diese E-Mails gingen monatlich aus, oder wann immer Backups zu lange dauerten).
* Schalten Sie die Datenbank offline und sehen Sie, wer sich beschwert.
* Benennen Sie den Server um, um zu sehen, wer sich beschwert.

Da der spitze Chef nur bereit war, "vollständige" Dokumentation zuzulassen, wurde ein Wiki ausdrücklich untersagt, und Personalabbau führte zu einem dramatischen Rückgang der Dokumentation, die den Standard erfüllte.

Wenn es nach mir ginge, gäbe es pro Server eine Wiki-Seite mit Kontaktnamen für jede Datenbank (und vielleicht eine kurze Beschreibung, wofür die Datenbank gedacht ist). Jede Datenbank, die im Wiki nicht dokumentiert ist, kann gelöscht werden.

Wir hatten einen großen Finanzclient, der noch SQL Server 2000 im Jahr 2009 verwendete, sodass eine SQL Server 2000-Instanz ausgeführt werden musste, bis dieser Client schließlich auf SQL Server 2005 umgestellt wurde.

Weitere zwei Alternativen sind:

1. Erstellen Sie Trigger in der Datenbank, die Sie über alle Aktivitäten benachrichtigen (oder in Tabellen speichern).

2. Aktivieren Sie die Überwachung für die DBs.

   • Hängt von Ihrer DB-Version ab.

Die nächste Lösung zeigt temporäre Gesamt-, Bereinigungs- und Dirty-Pages in MB für bestimmte Datenbanken unter Ihrer Instanz (im Internet gefunden und ein wenig geändert):

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)

oder

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

oder

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