Veritabanı bağımlılıklarını nasıl takip edebilirim?

Dahili uygulamalar birkaç yıl içinde geliştikçe, zaman zaman insanların artık alakalı olmadıklarına ve cull yapmak istediğine inandıkları bir takım tablolar olduğunu görüyorsunuz. Hem SQL ortamında hem de SSIS gibi şeylerde veritabanı bağımlılıklarını tanımlamak için pratik yöntemler nelerdir?

Oldukça acımasız seçeneklerin alındığı yerlerde çalıştım:

• Önce bırakın, sonra soru sorun (artık mevcut olmayan bir tabloyu çıkarmaya çalışırsa, bir veri ambarının yapısını öldürebilir)
• Önce izinleri kaldırın ve hataların bildirilmesini bekleyin (başarısızlık doğru şekilde gerçekleştirilmezse sessiz hatalara neden olabilir)

SQL Server'ın bu örnekteki bağımlılıkları izlemek için araçlar sağladığını takdir ediyorum, ancak farklı örneklerdeki veritabanlarınız varsa bunlar mücadele ediyor gibi görünüyor. Bağımlılıkları sorgulamayı kolaylaştıran, belki "Bu sütun nerede kullanılıyor?" Gibi soruları yanıtlayan seçenekler var mı? "Bu saklı yordamdaki diğer sunucuda" veya "Bu SSIS paketinde" gibi yanıtlar?

Bunu yapmanın kolay bir yolu yoktur. Tetikleyiciler çalışmaz, sanki bir tablodan seçtiğiniz gibi tetiklenmez. Bunu yapmanın en iyi yolu geliştiricilerin kullandıklarını izlemelerini sağlamak. Bir şey bırakılacaksa, tüm dev ekipleri kontrol edin ve herkes imzalandıktan sonra nesneyi yeniden adlandırın. Öyleyse bir ay boyunca hiçbir şey kırılmaz, veya nesne güvenli bir şekilde bırakılabilir.

1. Sys.sql_modules.definition ile kullanım için arama kodu: başvuruyor mu? Sonra...
2. İzinleri kontrol et: hangi müşteri kodu arayabilir? Sonra...
3. Profiler

Böylece:

• Referansı olmayan ve izni olmayan bir tablo için kullanılmaz.
• Referans yok ve bazı izinler olmadan, kullanımı görmek için profiler çalıştırın
• İzinsiz ve referanssız, kullanım günlüğü ekle

Daha önce yaptığım, masayı maskeleyen bir görünüm yapmak, sonra da görünümü kötü yapmak: (çapraz birleşme kendine özgü, belirgin). Aslında kaldırmazsınız, ancak müşteri zaman aşımına uğrar veya şikayet edersiniz ...

Geçmişte kullandığım hızlı bir yol (ve gerçekten tabloların boyutuna, endeks performansının sayısına vb. Bağlı), bir eylem gerçekleştirildiğinde bir zaman damgası kaydeden bir tetikleyici eklemektir. Bunun performans sorunları yaşayabileceğini söylediğim için dikkatli davranılması gerekiyor - ayrıca kayıt masanızın kimlik alanlarını kullanmadığını izleyin, çünkü @@ IDENTITY kullanan bazı eski kodları bozabilir. Elbette, bir uygulamadaki bir özelliğin bir süredir kullanılmadığını gösterebilir.

Veritabanını vurabilecek tüm kod veritabanında olmadığı zaman bağımlılıkları izlemek çok zordur, yani veritabanını sorgulayan rastgele istemciler.

EDIT: Bir tablonun SELECT tetikleyicisine sahip olamayacağı noktaya değinmek için, tablolarınızın indeksleri olduğunu varsaymak için çalışması gereken başka bir seçenek var (yalnızca 2008'de test edildi).

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' 

ancak sunucu yeniden başlatıldığında, çıkarıldığında vb. kullanım istatistikleri tablosunun temizlendiğini unutmayın. Dolayısıyla, verileri toplamak için bir iş ayarlamanız gerekir. Biraz hack biliyorum.

Geçmişte kullandığım bir yol, bunları kaldırmak ve daha sonra yeniden adlandırmak ve başarısızlık aramak için bir adaylar listesi oluşturmaktı.

Listeyi nasıl oluşturdum:

1. Hangi tabloların mevcut saklı yordamlarda, tetikleyicilerde ve işlevlerde kullanılmadığını görün

2. boş tablolar (sıfır kayıtlar);

3. referans verilmeyen tablolar (ilişkisi olmayan tablolar);

4. DB Sunucusu başlatıldığından beri hangi tabloların kullanılmadığını görün

Listeyi bir metin dosyasında oluşturduktan sonra .cs dosyalarımızı (sadece .net projeleri yapıyoruz) yerel eşlenmiş sürüm kontrol klasöründen ayrıştırıp bu tabloların .cs dosyalarında kullanılıp kullanılmadığını görecek bir toplu komut dosyası yaptım. olmamalı, ama hey .. sürprizlerim oldu). Eğer hayır ise, o zaman açık, evet ise, o zaman bir liste oluştururuz ve bu modülün hala kullanımda olup olmadığını kontrol etmek için geliştiricilere veririz.

Yani, kısacası, önceki adamlar haklı, gümüş mermi yok.

Şirketimde uyguladığım politika, SQL Server'a dokunan her şeyi merkezi bir yere, kaynak kontrolüne koymak.

• asp.net projeleri
• SSRS projeleri
• SSIS projeleri
• Hatta tüm veritabanı nesnelerini bir çeşit depoya ekledim.

Henüz ayarlamadım, ama sonunda belirli tabloları, sprocs'ları vb. Aramak için kullanabileceğim bir tür dizin / merkezi arama mekanizması uygulamak istiyorum. . Eski SQL objeleri henüz sorun değil, geleceği planlıyorum.

Yeniden adlandırma / izleme yaklaşımında gördüğüm sorun, bazı şeylerin yalnızca yıllık olarak çalıştığı ve her yıl değil. İnsanların yazmanızı istediği çeşitli geçici şeylerden bahsetmeyin ve aylar veya yıllar sonra tekrar isteyin.

Aşağıdakileri içeren bağımlılıkları izlemek için kullanılacak çeşitli araçlar ve teknikler vardır:

Bildiğim Araçlar:

• SQL Server Bağımlılığı görüntüleyici (ancak, tablo oluşturulmadan önce sp kullanılarak tablo oluşturulmuşsa sorunlar olabilir)
• Redgate SQL Bağımlılık İzleyici (@Eric Humphrey'in cevabı üzerinden)
• Resharper (arama yollarına bakmak için kullanılabilecek .net aracı, anahtar SQL çağrılarının nerede kullanıldığını izlemek için kullanılabileceğini düşünüyorum )

Yöntemler

• Kod, SQL nesnelerinin kullanımını araştırır (yine de yukarıdaki araçların bazılarını çoğaltır)

• Kullanım istatistiklerine bakın (yani: en son aranan SQL nesnesindeyken), aşağıdaki SQL'i kullanıyorum:

  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
  

Not : Sunucu yeniden başlatıldığında, çıkarıldığında vb. Kullanım istatistikleri tablosu silinir. Böylece verileri toplamak için bir iş ayarlamanız gerekir. Biraz hack biliyorum. (@Miles D'den)

Teknikler

• Son kullanım için arama yapın (yukarıdaki kullanım istatistiklerine bakın)
• Kullanıldığı yeri arayın (araçlara bakın)
• Geliştiricilerle kod kullanımını inceleyin (@MrDenny aracılığıyla)
• Nesneyi yeniden adlandırın (yani: _toBeDropped ile post / prefix) ve hataları izleyin
• İzinleri değiştirin ve hataları izleyin
• Nesneyi bırak ve dua et

Birkaç yıl önce, benzer şeyleri kontrol etmek için bir araç yapmaya çalıştım. TL; DR cevabı, o zaman mevcut kaynaklarla yapmanın mümkün olmadığını buldum.

Bu sütun nerede kullanılıyor?

Bu soru select *, sütunun bulunduğu tablodan çok sayıda sorgu, görüş ve saklı yordam kullandığının farkına vardığınızda daha da karmaşıklaşır . Ardından, bu sonuçları kullanan programlara bakmanız gerekir - bu nedenle biraz tarayıcı / dizinleyici / ayrıştırıcıya ihtiyacınız vardır. C #, Delphi, Java, VB, ASP (klasik) gibi kaynak kodlarını okuyabilen ve bu sütuna yapılan tüm referansları bulmaya çalışmak. O zaman bu kodun daha da aranıp çağrılmayacağını tespit etmek için bu programları analiz etmeniz gerekir.

SQL referanslarından vazgeçmeyecek, ancak Redgate'in SQL Bağımlılık İzleyicisine bir göz atmak isteyebilirsiniz . Güzel bir görselleştirme aracı.

Bu gerçekten sorunuza bir cevap değil, ama bence bahsetmek gerekir: Bu, veritabanınız dışındaki tüm sistemlerin görüş ve sprocs aracılığıyla iletişim kurmasının bir nedenidir . Aranabilir .sql dosyalarında bunlar için derleme komut dosyalarına sahipsiniz, böylece belirli bir tablo veya sütunun harici olarak kullanılıp kullanılmadığını kolayca görebilirsiniz.

Tabii ki SSIS normalde doğrudan masalara bağlanacak, bu yüzden şu anda ihtiyacınıza pek yardımcı olmuyor. Ancak geliştiriciler veritabanınıza bağlandıklarında ve sizi (veya DBA olarak hizmet eden) beklemeleri gerektiğinden şikayet etmeleri gerektiğinden şikayet ettiklerinde, şunları söyleyebilirsiniz: "Herhangi bir tablo veya sütun silinebilir veya yeniden adlandırılabilir." Sadece görüş ve sprocs değişikliklerinde sizi bilgilendirmek zorundayım. ” Ve sadece bu spesifik değişiklikler için regresyon testi yapmak zorundalar.

TSQL aşağıdaki kullanılabilir sys.dm_sql_referencing_entities veya sys.sql_expression_dependencies

Alternatif olarak, SQL Negotiator Pro, Redgate vb. Araçlar, GUI kullanarak sizin için görsel olarak oluşturabilir.