it-swarm.it

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

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 la data dell'ultima query. Sembra funzionare, ma voglio sapere se queste informazioni sono abbastanza valide per eliminare i database. È?

Se hai metodi alternativi che potrebbero aiutare pure.

34
jsauni

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

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.

Potresti anche cercare di utilizzare un filtro di traccia del profiler lato server su quel database.

30
NicCain

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: per quanto tempo attendi prima di essere sicuro 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.

14
SQLRockstar

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.

13
Sankar Reddy

La query seguente mostra i DB che non sono stati utilizzati dall'ultimo riavvio, senza fare affidamento sui piani di query mantenuti nella cache, poiché mostra user IO rispetto agli indici (e heap). una specie di come usare le statistiche dei file virtuali, ma il DMV usato qui esclude IO 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 colleghi spesso/chiudi database spesso) questo potrebbe non essere il modo giusto :-)

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

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

Ho lavorato in un posto che aveva un gran numero di database orfani e semi-orfani. Era difficile dire se fossero davvero rimasti orfani in quanto 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 offline il database 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 ciò che il database serve). 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 è passato a SQL Server 2005.

3
Tangurena

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
SQL Server Frant

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
StanleyJohns