Come posso sapere se un database di SQL Server è ancora in uso?


33

Stiamo cercando di smantellare un'istanza di SQL Server che contiene ancora un paio di database.

Come posso sapere se sono ancora utilizzati dagli utenti o da un'applicazione web?

Ho trovato un thread del forum che aveva una query T-SQL che potresti eseguire per recuperare l'ultima data della query. Sembra funzionare, ma voglio sapere se queste informazioni sono abbastanza valide per eliminare i database. È?

Se hai metodi alternativi che potrebbero aiutare pure.


1
Molte discussioni di seguito, ma vedi anche questo post sul blog .
Aaron Bertrand

Risposte:


29

Dovresti preoccuparti degli elementi che sono stati eliminati dalla cache e che hai perso, o per i database che hanno un uso poco frequente.

Anziché eliminare i database dalla mano, metterli offline per impedire l'accesso senza rilasciarli o in modalità RESTRICTED_USER per limitare l'accesso. In questo modo puoi lasciarli in quello stato per un mese o due per verificare e vedere se c'è un uso occasionale.

È inoltre possibile utilizzare un filtro di traccia profiler lato server su quel database.


24
Regola n. 1 di essere un DBA: non apportare mai modifiche che non è possibile annullare rapidamente se necessario.
Gaius,

14

Questi sono i metodi che ho usato in passato:

  1. Porta offline / Stacca il database
  2. Accesso utente / accesso DENY
  3. Traccia del profiler

Il problema è questo: quanto aspetti prima di essere certi che nessuno accederà ai dati? Per i dati finanziari, alcuni articoli vengono eseguiti quotidianamente, settimanalmente, mensilmente, trimestralmente, semestralmente e annualmente. Ma è un anno abbastanza lungo? Ho anche visto richieste di mantenere i dati disponibili per almeno 7 anni e in un caso mi è stato detto che i dati in un sistema dovevano essere lì per sempre, anche se nessuno li utilizzava.

Il miglior consiglio è questo: qualunque cosa tu faccia per disattivare l'accesso, assicurati di poterlo riattivare immediatamente. Ho scoperto che il distacco ha funzionato meglio per questo. Vorrei semplicemente scrivere la riattacca e istruire il mio team "se qualcuno mai chiede dove si trova, eseguire questo script". Questo ci ha dato la migliore possibilità di rimettere le cose il più rapidamente possibile.


Ci ho pensato, se il periodo di monitoraggio dell'uso del database fosse abbastanza lungo. Prendi semplicemente la natura di SQL Server e fai quella sentenza?
jsauni,

sì, a un certo punto fai in modo che tutti accettino di staccare la spina e di capire che se un processo canaglia fallisce, dovrai rimettere le cose rapidamente. fintanto che vanno bene con un'interruzione e si ripristinano rapidamente le cose online, si dovrebbe andare bene. ma non è facile convincere tutti!
SQLRockstar

13

Sono d'accordo con Nic con il suo consiglio. Se è necessario essere sicuri, è necessario utilizzare Profiler (traccia lato servizio) perché alcune query SQL non verranno memorizzate nella cache o per qualsiasi motivo è possibile eliminare la cache delle procedure.

Normalmente verificherei anche le informazioni sulle statistiche dei file virtuali per vedere se ci sono letture o scritture a livello di file del sistema operativo. Anche se il database NON è attivo, vedrai comunque piccole letture / scritture se stai eseguendo backup di log, backup completi ecc ... ma ciò ti darà anche un'idea dell'attività di lettura / scrittura su quel database.

Prima di eliminare qualsiasi database, mi assicurerei di avere almeno 2 o 3 backup leggibili (testarli) in posizioni separate. Non sai mai quando ne hai bisogno.


8

La query seguente mostra i DB che non hanno più avuto uso dall'ultimo riavvio, senza fare affidamento sui piani di query mantenuti nella cache, poiché mostra l'I / O dell'utente rispetto agli indici (e heap). Questo è un po 'come usare le statistiche dei file virtuali, ma il DMV usato qui esclude l'attività di I / O dai backup. Non è necessario mantenere in esecuzione una traccia del profiler, non sono necessari trigger o controlli. Naturalmente, se riavvii frequentemente il tuo server SQL (o connetti / chiudi spesso database), potrebbe non essere la strada da percorrere :-)

Detto questo, sono ancora d'accordo sul fatto che anche se questa query sembra confermare che un DB può essere eliminato, esegui definitivamente OFFLINE / scollega o nega l'accesso dell'utente per un po 'di tempo, oltre a qualsiasi due diligence nel chiedere prima di abbandonare effettivamente!

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

È fantastico se funziona bene. Posso chiederti perché stai prendendo la bilancia e confrontando con login_time? E perché non hai incluso last_user_update? È un tentativo intelligente di vedere se un database sta ricevendo INSERTI ma nessuno lo sta mai interrogando? O è possibile per questo DMV includere tutti i timestamp NULL?
Jason,

2

Ho lavorato in un posto che aveva un gran numero di database orfani e semi-orfani. Era difficile dire se fossero davvero orfani poiché molti compiti erano stagionali o annuali - quindi il sito Web funziona solo per 3-4 mesi all'anno (ad esempio, i moduli W2 devono essere archiviati elettronicamente 1/31, quindi l'elaborazione del sito Web questi hanno funzionato solo da metà gennaio a fine aprile).

Ciò che è stato fatto è stata una combinazione di:
* chiedi a tutti gli sviluppatori se stavano usando un database o l'altro (queste e-mail uscivano mensilmente o ogni volta che i backup impiegavano troppo tempo).
* Porta il database offline e vedi chi si lamenta.
* Rinomina il server per vedere chi si lamenta.

Dato che il capo dai capelli a punta era disposto solo a consentire la documentazione "completa e completa", una wiki era espressamente vietata e le riduzioni del personale portavano a un drammatico declino della documentazione che soddisfaceva lo standard.

Se dipendesse da me, ci sarebbe una pagina wiki per server con i nomi dei contatti per ciascun database (e forse una breve descrizione di cosa serve il database). Qualsiasi database non documentato sulla wiki sarebbe un gioco equo per la cancellazione.

Avevamo un grande client finanziario che utilizzava ancora SQL Server 2000 fino al 2009, quindi abbiamo dovuto mantenere in esecuzione un'istanza di SQL Server 2000 fino a quando quel client non si è finalmente spostato su SQL Server 2005.


2

Altre due alternative sono:

  1. Crea trigger sul DB che ti avviserà (o memorizzerà nelle tabelle) qualsiasi attività.
  2. Abilitare il controllo sui DB.

    • Dipende dalla versione del tuo DB.

2

La prossima soluzione mostra pagine totali, pulite e sporche temporanee in MB per particolari database sotto la tua istanza (trovati su Internet e modificati un po '):

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)

o

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

o

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

2
Potresti chiarire come risolve il problema originale?
dezso
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.