Bilinmeyen bir veritabanını anlamaya nereden başlamalı?

Yani, başlık özetliyor.

Bir SQL Server veritabanı 28 tabloları ve ters mühendislik gerekir 86 saklı yordamları ile var. Bazı tabloların asla kullanılmadığından ve tüm procs'ların da kullanılmadığından eminim.

En büyük sorun, bu DB ile kullanılmak üzere oluşturulan tüm Windows Hizmetlerinin ve tüm yazılım ve veritabanı belgelerinin kaybolması ve tüm sistemi tasarlayan kişinin bulunamamasıdır.

İlişkileri anlamama yardımcı olacak bir ER diyagramı oluşturmayı başardım, ancak veritabanı yönetiminde deneyimli olmadığım için nereden başlamam gerektiği konusunda hiçbir fikrim yok.

Ayrıca bu tür bir sorunun burada sorulması istenmediği için üzgünüm.

Başlamanız için üç çok hızlı adım:

1)

USE DatabaseName

SELECT    [TableName] = OBJECT_NAME(object_id),
last_user_update, last_user_seek, last_user_scan, last_user_lookup
FROM    sys.dm_db_index_usage_stats
WHERE    database_id = DB_ID('DatabaseName')

Kümelenmiş dizin de dahil olmak üzere her bir dizinin en son ne zaman kullanıldığını size bildirir. Yani en azından hangi tablolara erişildiği (ve hangilerinin olmadığı) bir lezzet verin.

2) Uygulama kullanılırken bir Uzun Süreli oturumunu (veya SQL 2012 öncesi SQL Server çalıştırıyorsanız sunucu tarafı Profiler izini) açın. Ayrıca bir kullanıcıdan uygulamada çeşitli eylemleri belirli bir sırayla gerçekleştirmesini isteyebilirsiniz, böylece izleme / oturumla ilişkilendirebilirsiniz.

Yararlı bir öneri: uygulamanın kullandığı bağlantı dizesini değiştirebiliyorsanız, "; Application Name = AppNameGoesHere" ifadesini ekleyin, böylece söz konusu Uygulama Adı üzerinde bir izleme filtresi çalıştırabilirsiniz. Yine de iyi uygulama.

3) Uygulamanın üretim dışı bir sunucuda çalışan bir sürümünü edinin. Uygulama için davranış odaklı testlerin bir listesini geliştirin ("Kullanıcı Yeni Öğe düğmesini tıkladığında, o kullanıcı için yeni bir öğe oluşturur" vb.) Yeniden adlandırarak testlerde etkili olmadığını düşündüğünüz yumuşak silme nesnelerine başlayın (ObjectName_DEPRECATED_YYYYMMDD gibi bir biçim kullanıyorum - tarih gerçekten silmeyi planladığım gün.) Tüm testlerinizi yeniden doğrulayın.

Genişletilmiş Olaylar oturumunun, dizin kullanımı DMV'sinin ve yumuşak silme işleminizin bir kombinasyonu yoluyla, uygulama tarafından kullanılan ana nesneleri ve hangi nesnenin ne yaptığına ilişkin iyi bir genel fikir birliğini tanımlayabilmeniz gerekir.

İyi şanslar!

Başlamak için en iyi seçenek, veritabanınızı SQL Power Doc kullanarak belgelendirmektir

Windows PowerShell Kullanarak SQL Server ve Windows Belgeleri

SQL Power Doc, SQL Server örneklerini ve bunların altında yatan Windows işletim sistemi ve makine yapılandırmalarını keşfeden, belgeleyen ve teşhis eden bir Windows PowerShell komut dosyaları ve modülleri koleksiyonudur. SQL Power Doc, SQL Server 2000'den 2014'e kadar tüm SQL Server sürümleriyle ve Windows 2000 ile Windows Server 2012 R2'den Windows Server 2012 R2 ve Windows 8'den tüketici Windows İşletim Sistemlerinin tüm sürümleriyle çalışır. Windows Azure SQL Veritabanlarını belgeleme.

Not: Ben kullandım ve veritabanı sunucusu örneğinizi belgelemek ve anlamak için size gerçekten iyi bir başlangıç ​​sağlayacaktır.

Bir zamanlar benzer bir durumda olduğum için, bunun imkansız bir işin zor olacağını söyleyebilirim. Ben sadece kaynak kodu (> 100k kod satırları), çalışan servis, çalışan veritabanı (~ 50 tablo) ve hiçbir belge ve bu uygulamanın bir kullanıcı ve çalışan veritabanı ve hizmetlerin bir kopyası dışında sormak için kimse yoktu bir test ortamı (kaynak kodsuz birkaç sürüm numarasıydı). Diğer bir gereklilik de hizmetlerin 7/24 çalışması gerektiğiydi, çünkü bunlar müşterilerin dışındaydı. Durum ortaya çıktı çünkü çoğu personel, geliştiriciler ve kaos içinde kaybolan belgeler de dahil olmak üzere yaklaşık aynı zamanda ayrıldı. Genel bir değerlendirme / dokümantasyon almak 6 aydan fazla sürdü. Gelecekteki kullanım için oldukları veya hiçbir zaman tam olarak uygulanmadığı için hiçbir etkisi olmayan birçok tablo ve işlev vardı, hatalı veya kullanımdan kaldırılmış veya yayınlanmamış özellikler. 6 aydan sonra belgeleri yeniden yazmak zorunda kaldım çünkü şeyler arasında yeni şeyler veya ilişkiler keşfettim ve daha önce yanlış varsayımlarda bulundum.

Bunu neden söylüyorum? Çünkü bazen böyle bir durumda sıfırdan başlamak ve eskisinin gereksinimlerini karşılayan yeni bir uygulama (veya zaman içinde değiştiyse veya yeni bir büyük sürüm istiyorsanız) yeni bir uygulama yazmak daha kolay ve daha ucuzdur. Ya da ne beklemeniz gerektiğini söylemek için.

Gerçekten tersine mühendislik yapmak istiyorsanız, aşağıdaki adımları tavsiye ederim:

• Tüm sistemin bir yedeğini alın! (Birincisi: Ne zaman ihtiyacınız olacağını asla bilemezsiniz. İkincisi: Bir sonraki adım için ihtiyacınız olacak)
• sistemin (hizmetler ve veritabanı) bir kopyasını yeniden oluşturun ve nasıl oluşturulacağını yazın, çünkü bunu önümüzdeki aylarda mutlaka tekrarlamanız gerekecek çünkü tersine mühendislik yaparken birden çok kez karışacaksınız.
• tablolar arasındaki bağımlılıkları içeren bir ER diyagramı oluşturun
• her tablonun bağımlılıklarını, saklı yordamı görüntüleyebilir ve belgeleyebilir, çünkü bunlar çoğunlukla ER diyagramlarına dahil edilmez
• yazılımın kullanıcılara sorarak ve kendisini kullanarak ne yapması gerektiğini anlamak (en iyisi test sisteminde yapmak)
• Hizmetlerin kaynak kodu mevcutsa: hizmete bir genel bakış edinin ve DB'yi arayın ve belgeleyin (doxygen, işlev çağrısı hiyerarşileriyle kaba bir belge almak için iyi bir araçtır)
• tablo adlarına ve sütunlarına bakarak DB hakkında genel bilgiler edinmeye çalışın
• kullanırken veritabanını izle
• önceki 4 adımda tabloları 3 kategoriye ayırın (uygulamanıza bağlı olarak sizin için farklılık gösterebilir): statik veriler (sunucuyu sunucu yapılandırması gibi çalıştırırken değişmeyen veriler, yabancı tablolar kullanarak diğer tablolardaki geçerli değerleri kısıtlamak için numaralandırılır) , ...), yapılandırma verileri (kullanıcı ayarları gibi nadiren değişen veriler ...) ve OLTP verileri (sohbet sunucusundaki kullanıcı mesajları, bir forumdaki gönderiler, bir makine kontrol sistemindeki ölçüm değerleri, çevrimiçi bir oyunda yapılan savaşlar, ...)
• Memnun olana veya pes edene kadar önceki 5 adımı tekrarlayın
• Kodunuzu / sisteminizi / veritabanınızı koruyan adam, nerede yaşadığınızı bilen şiddetli bir psikopat olacaktır.

Size iyi şanslar diliyorum ;)

Yorum göndermek için yeterli temsilcim yok, ancak sorunuzla ilgili yardım etmek istedim

getting the SQL Power Doc to work.

Dokümantasyon sayfasındaki adımları izlerseniz oldukça kolay çalışır. En baştan başlayın.

https://sqlpowerdoc.codeplex.com/wikipage?title=Guide%20For%20PowerShell%20Beginners