Come posso tenere traccia delle dipendenze del database?

Man mano che le applicazioni interne si evolvono nel corso degli anni, a volte scopri che ci sono un certo numero di tabelle che le persone credono non siano più pertinenti e che vogliono abbattere. Quali sono i metodi pratici per identificare le dipendenze del database, sia all'interno dell'ambiente SQL, sia in seguito in cose come SSIS?

Ho lavorato in luoghi in cui sono state scelte opzioni piuttosto brutali come:

• Rilascia prima, fai domande in seguito (può uccidere una build del data warehouse se tenta di estrarre una tabella che non esiste più)
• Rimuovere prima le autorizzazioni e attendere la segnalazione degli errori (può causare bug silenziosi, se l'errore non viene gestito correttamente)

Apprezzo che SQL Server sia dotato di strumenti per tenere traccia delle dipendenze all'interno di tale istanza, ma queste sembrano avere difficoltà se si dispone di database in istanze diverse. Esistono opzioni che semplificano l'interrogazione delle dipendenze, magari rispondendo a domande come "Dove viene utilizzata questa colonna?" con risposte come "Over su questo altro server in questa procedura memorizzata" o "Over in questo pacchetto SSIS"?

Non esiste un modo semplice per farlo. I trigger non funzionano, come se si selezionasse da una tabella nessun trigger viene attivato. Il modo migliore che ho trovato per fare questo è di fare in modo che gli sviluppatori seguano ciò che usano. Quando qualcosa sta per essere eliminato, controlla con tutti i team di sviluppo e dopo che tutti hanno firmato, rinomina l'oggetto. Quindi non si rompe nulla per un mese o per, l'oggetto può essere tranquillamente lasciato cadere.

1. Cerca il codice per l'utilizzo con sys.sql_modules.definition: è referenziato? Poi...
2. Verifica autorizzazioni: quale codice client può chiamarlo? Poi...
3. Profiler

Così:

• Per una tabella senza riferimento e senza autorizzazioni, non viene utilizzata.
• Senza riferimenti e alcune autorizzazioni, esegui profiler per vedere l'utilizzo
• Senza autorizzazioni e riferimenti, aggiungi la registrazione dell'utilizzo

Ciò che ho fatto in precedenza è rendere la tabella una vista mascherando la tabella e quindi rendere la vista mal funzionante: (incrociare se stesso, distinto). In realtà non lo rimuovi ma generi timeout o reclami dei clienti ...

Un modo rapido che ho usato in passato (e dipende davvero dalla dimensione delle tabelle, dal numero di prestazioni degli indici, ecc.) È quello di aggiungere un trigger, che registra un timestamp quando viene eseguita un'azione sulla tabella. Come ho già detto, questo può avere problemi di prestazioni, quindi è necessario essere trattati con cautela - anche guardare la tabella di registrazione non utilizza i campi di identità, in quanto ciò può rovinare qualche vecchio codice che utilizza @@ IDENTITY. Ovviamente potrebbe solo mostrare che una funzione in un'applicazione non è stata utilizzata per qualche tempo.

È molto difficile tenere traccia delle dipendenze quando tutto il codice che può colpire il database non è nel database, vale a dire i client casuali che interrogano il database.

EDIT: per affrontare il punto in cui una tabella non può avere trigger SELECT, ecco un'altra opzione che dovrebbe funzionare supponendo che le tabelle abbiano indici (testato solo nel 2008).

SELECT          
    last_user_seek,
    last_user_scan,
    last_user_lookup,
    last_user_update
FROM
    sys.dm_db_index_usage_stats AS usage_stats
INNER JOIN
sys.tables AS tables ON tables.object_id = usage_stats.object_id
WHERE
    database_id = DB_ID() AND
    tables.name = 'mytable' 

ma nota che la tabella delle statistiche di utilizzo viene cancellata quando il server viene riavviato, scollegato, ecc. Quindi dovrai impostare un lavoro per raccogliere i dati. Un po 'di hack che conosco.

Un modo che ho usato in passato è stato quello di stabilire un elenco di tabelle dei candidati da rimuovere, quindi rinominarle e cercare errori.

Come ho stabilito l'elenco era:

1. vedere quali tabelle non sono in uso nelle attuali procedure, trigger e funzioni memorizzati

2. tabelle vuote (zero record);

3. tabelle non referenziate (tabelle che non hanno alcuna relazione);

4. vedere quali tabelle non sono state utilizzate da quando è stato avviato il DB Server (DMV)

Dopo aver creato l'elenco in un file di testo, ho creato uno script batch che analizzerebbe i nostri file .cs (stiamo avendo solo progetti .net) dalla cartella di controllo della versione mappata locale e vedere se tali tabelle sono utilizzate nei file .cs ( non dovrebbe succedere, ma ehi .. ho avuto sorprese). Se no, allora è chiaro, se sì, allora costruiamo un elenco e diamo agli sviluppatori di verificare se quel modulo è ancora in uso.

Quindi, in breve, i ragazzi precedenti hanno ragione, non c'è proiettile d'argento.

La politica che sto implementando nella mia azienda è quella di mettere tutto ciò che tocca SQL Server sotto il controllo del codice sorgente, in una posizione centrale.

• progetti asp.net
• Progetti SSRS
• Progetti SSIS
• Scrivo persino tutti gli oggetti del database in una specie di archivio.

Non l'ho ancora impostato, ma alla fine voglio implementare una sorta di meccanismo di ricerca indice / centrale che potrei usare per cercare specifiche tabelle, sprocs, ecc. Siamo in realtà un nuovo negozio di SQL Server - conversione da FoxPro . Quindi i vecchi oggetti SQL non rappresentano ancora un problema, ma sto pianificando il futuro.

Il problema che vedo con l'approccio di rinominare / tracciare è che alcune cose vengono eseguite solo annualmente e nemmeno ogni anno. Per non parlare delle varie cose ad hoc che le persone ti chiedono di scrivere e poi chiedono di nuovo mesi o anni dopo.

Esistono una varietà di strumenti e tecniche da utilizzare nel rilevamento delle dipendenze, che coinvolgono:

Strumenti che conosco:

• Visualizzatore dipendenze di SQL Server (ma può avere problemi se la tabella sp using è stata creata prima della creazione della tabella)
• Redgate SQL Dependency Tracker (tramite la risposta di @Eric Humphrey)
• Resharper (strumento .net che può essere utilizzato per esaminare i percorsi delle chiamate, penso che possa essere utilizzato per tenere traccia di dove vengono utilizzate le chiamate SQL chiave)

metodi

• Ricerche di codice per l'uso di oggetti SQL (replica alcuni degli strumenti sopra)

• Guarda le statistiche di utilizzo (ovvero: quando è stato chiamato per l'ultima volta un oggetto SQL), utilizzo l'SQL sottostante:

  SELECT 
      last_execution_time,   
      (SELECT TOP 1 
          SUBSTRING(s2.text,statement_start_offset / 2+1 , 
              ((CASE WHEN statement_end_offset = -1 THEN 
                  (LEN(CONVERT(nvarchar(max),s2.text)) * 2) 
              ELSE statement_end_offset END) - statement_start_offset) / 2+1)
      )  AS sql_statement,
      execution_count
  FROM sys.dm_exec_query_stats AS s1 
  CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS s2  
  WHERE 
      s2.text like '%[OBJECT NAME]%' 
      and last_execution_time > [DATE YOU CARE ABOUT]
  ORDER BY last_execution_time desc

Nota : la tabella delle statistiche di utilizzo viene cancellata quando il server viene riavviato, scollegato, ecc. Quindi è necessario impostare un processo per raccogliere i dati. Un po 'di hack che conosco. (da @Miles D)

tecniche

• Cerca l'ultimo utilizzo (vedi le statistiche di utilizzo sopra)
• Cerca dove viene utilizzato (vedi strumenti)
• Rivedi l'utilizzo del codice con gli sviluppatori (tramite @MrDenny)
• Rinomina oggetto (ad es .: post / prefisso con _toBeDropped) e osserva gli errori
• Modifica le autorizzazioni e controlla gli errori
• Rilascia l'oggetto e prega

Diversi anni fa, ho provato a costruire uno strumento per controllare cose simili. La risposta TL; DR è che in quel momento non ho trovato a che fare con le risorse disponibili.

Dove viene utilizzata questa colonna?

Questa domanda diventa più complicata quando ti rendi conto che un numero di query, viste e procedure memorizzate usano select *dalla tabella in cui risiede la colonna. Quindi devi guardare i programmi che usano quei risultati - quindi hai bisogno di scanner / indicizzatore / parser in grado di leggere il codice sorgente che può essere C #, Delphi, Java, VB, ASP (classico) e così via solo per cercare di cercare ogni riferimento a quella colonna. Quindi è necessario analizzare quei programmi per provare a identificare se quel codice viene persino più chiamato.

Non gestirà i riferimenti SQL, ma potresti voler dare un'occhiata al Tracker dipendenze SQL di Redgate . È un bel strumento di visualizzazione.

Questa non è davvero una risposta alla tua domanda, ma penso che meriti di essere menzionata: questo è uno dei motivi per cui tutti i sistemi al di fuori del tuo database dovrebbero comunicare tramite visualizzazioni e sprocs . Hai gli script di build per questi in file .sql ricercabili, quindi puoi facilmente vedere se una particolare tabella o colonna viene utilizzata esternamente.

Ovviamente SSIS si connetterà normalmente direttamente alle tabelle, quindi probabilmente questo non è di grande aiuto in questo momento. Ma quando gli sviluppatori si connettono al tuo database e si lamentano di dover aspettare che tu (o chiunque funga da DBA) per effettuare le visualizzazioni e gli sprocessuali di cui hanno bisogno, puoi dire loro: "Qualsiasi tabella o colonna può essere cancellata o rinominata. I ' sono obbligato solo a tenerti informato delle modifiche alle visualizzazioni e agli sprocs. " E devono fare solo test di regressione per questi cambiamenti specifici.

TSQL è possibile utilizzare quanto segue sys.dm_sql_referencing_entities o sys.sql_expression_dependencies

In alternativa, strumenti come SQL Negotiator Pro, Redgate ecc. Possono generarlo visivamente usando una GUI