Bir SQL Server veritabanının hala kullanılmakta olup olmadığını nasıl anlarım?

Üzerinde hala kalan birkaç veritabanının bulunduğu bir SQL Server örneğinin kullanımdan kaldırılmasını istiyoruz.

Hala kullanıcılar tarafından mı yoksa bir web uygulaması tarafından mı kullanıldıklarını nasıl anlarım?

Son sorgu tarihini almak için çalıştırabileceğiniz bir T-SQL sorgusu olan bir forum başlığı buldum . İşe benziyor ama bu bilgilerin veritabanlarını bırakacak kadar geçerli olup olmadığını bilmek istiyorum. Bu mu?

Eğer yardımcı olabilecek alternatif yöntemleriniz varsa.

Önbellekten temizlenmiş ve kaçırmış olduğunuz öğelerle ya da nadir kullanılan veritabanları için endişelenmeniz gerekir.

Veritabanlarını elden bırakmak yerine, erişimi engellemeden erişimi engellemek için ÇEVRİMİÇİ ÇEVİRİ'yi ya da erişimi sınırlamak için RESTRICTED_USER modunda bırakın. Bunu yaparak, arada bir kullanım olup olmadığını kontrol etmek için bir veya iki ay boyunca bu durumda bırakabilirsiniz.

Ayrıca, o veritabanında filtreleme yapan bir sunucu tarafı profil oluşturucu izleme kullanmak da isteyebilirsiniz.

Geçmişte kullandığım yöntemler:

1. Veritabanını çevrimdışına al / Ayır
2. DENY kullanıcı / giriş erişimi
3. Profiler izleme

Sorun şu: Kimsenin verilere erişmeyeceğinden emin olmadan önce ne kadar beklersiniz? Finansal veriler için, bazı öğeleri günlük, haftalık, aylık, üç aylık, yarı yıllık ve yıllık olarak çalıştırırsınız. Ama bir yıl yeterince uzun mu? Ayrıca, verilerin en az 7 yıl boyunca saklanabilmesi için istekte bulunduğumu gördüm ve bir durumda, hiç kimseyi kullanmasa bile, bir sistemdeki verilerin sonsuza kadar orada olması gerektiği söylendi.

En iyi tavsiye şudur: Erişimi kapatmak için ne yaparsanız yapın, derhal açabileceğinizden emin olun. Tezgahın bunun için en iyi şekilde çalıştığını buldum. Kısaca yeniden bağlamayı bekliyorum ve ekibime "eğer biri nerede olduğunu sorarsa, bu betiği çalıştırsın" derdim. Bu bize mümkün olan en kısa sürede geri koymak için en iyi şansı verdi.

Önerisine Nic ile katılıyorum. Emin olmanız gerekiyorsa, o zaman bazı SQL sorguları önbelleğe alınmayacağından ya da herhangi bir nedenden ötürü işlem önbelleğinin temizlenebildiğinden Profiler (Servis tarafı izi) ile gitmeniz gerekir.

Normalde sanal dosya istatistiklerini de kontrol ediyorum ve OS dosya düzeyinde herhangi bir okuma olup olmadığına bakın. Veri tabanı aktif olmasa bile, günlük yedekleme, tam yedekleme vb. Alıyorsanız küçük bir okuma / yazma görürsünüz ... ancak bu, o veri tabanındaki okuma / yazma aktivitesi hakkında bir fikir verecektir.

Herhangi bir veritabanını düşürmeden önce, ayrı yerlerde en az 2 veya 3 okunabilir yedeğinizin (bunları test edin) olduğundan emin olurum. Ne zaman ihtiyacın olduğunu asla bilemezsin.

Aşağıdaki sorgu, en son yeniden başlatılmasından bu yana kullanımına sahip olmayan DB'leri gösterir; dizinlerde (ve yığınlarda) kullanıcı IO'sunu gösterdiğinden önbellekte tutulan sorgu planlarına güvenmez. Bu, sanal dosya istatistiklerini kullanma satırları boyuncadır, ancak burada kullanılan DMV, IO etkinliğini yedeklemelerin dışında tutar. Bir profiler izini çalışır durumda tutmaya gerek yok, tetikleyici veya denetim gerekli değil. Tabii ki, SQL sunucunuzu sık sık yeniden başlatırsanız (veya veritabanlarını sık sık eklerseniz / kapatırsanız), bu gitmenin yolu olmayabilir :-)

Diyelim ki, bu sorgu bir DB'nin bırakılabileceğini onaylasa bile, yine de kesinlikle ONLINE yapın / kullanıcı erişimini bir süre için reddedin ya da reddedin;

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

Çok sayıda yetim ve yarı yetim veritabanına sahip bir yerde çalıştım. Çok fazla mevsimlik mi yoksa yıllık mı olduğu için artık yetim kaldılar mı söylemek zordu - web sitesi yılda sadece 3-4 ay boyunca çalışıyor (örnek olarak, W2 formlarının elektronik olarak 1/31 dosyalanması gerekiyor, bu yüzden web sitesi işleme) bunlar sadece Ocak ortasından Nisan sonuna kadar koştu.

Yapılan şey şuydu: * her geliştiriciye bir veritabanı veya diğerini kullanıp kullanmadıklarını sorun (bu e-postalar aylık olarak veya yedeklemeler çok uzun sürdüğünde).
* veritabanını çevrimdışına al ve kimin şikayet ettiğini gör.
* kimin şikayet ettiğini görmek için sunucuyu yeniden adlandırın.

Sivri saçlı patronun yalnızca "tam ve eksiksiz" belgelere izin vermeye istekli olması nedeniyle, bir wiki açıkça yasaklandı ve personel indirimleri standardı karşılayan belgelerde çarpıcı bir düşüşe yol açtı.

Bana kalsa, her veritabanı için irtibat isimlerinin yer aldığı sunucu başına bir wiki sayfası (ve veritabanının ne için olduğuna dair kısa bir açıklama olabilir). Wiki'de belgelenmemiş herhangi bir veritabanı silinmek için adil bir oyundur.

2009 yılının sonlarında hala SQL Server 2000 kullanan bir büyük finansal müşterimiz vardı, bu yüzden o müşteri sonunda SQL Server 2005'e taşınana kadar bir SQL Server 2000 örneğini çalışır halde tutmak zorunda kaldık.

Diğer iki alternatif:

1. DB'de sizi herhangi bir faaliyetten haberdar edecek (veya tablolara saklayacak) tetikleyiciler oluşturun.

2. DB'lerde denetimi etkinleştirin.

   • DB sürümünüze göre değişir.

Bir sonraki çözüm, örneğinizin altındaki belirli veritabanları için MB’de geçici toplam, temiz ve kirli sayfalar gösteriyor (internette bulundu ve biraz değiştirildi):

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)

veya

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

veya

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