Gdzie zacząć rozumieć nieznaną bazę danych

Tak więc tytuł podsumowuje.

Mam bazę danych SQL Server z 28 tabelami i 86 procedurami składowanymi, które muszą być poddane inżynierii wstecznej. Jestem prawie pewien, że niektóre tabele nigdy nie są używane i że nie wszystkie procesy są również używane.

Największym problemem jest to, że wszystkie Usługi Windows, które zostały utworzone do użycia z tą bazą danych oraz cała dokumentacja oprogramowania i bazy danych zostały utracone, a osoby, która zaprojektowała cały system, nie ma nigdzie.

Udało mi się już stworzyć diagram ER, aby pomóc mi zrozumieć relacje, ale ponieważ nie mam doświadczenia w administrowaniu bazami danych, nie mam pojęcia, od czego powinienem zacząć.

Przepraszam również, jeśli nie ma tu zadawać tego rodzaju pytania.

Trzy bardzo szybkie kroki na początek:

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

Informuje o ostatnim użyciu każdego indeksu, w tym indeksu klastrowego. Więc przynajmniej daj smak, do którego tabele są otwierane (a które nie).

2) Włącz sesję zdarzeń rozszerzonych (lub śledzenie Profiler po stronie serwera, jeśli korzystasz z wersji wcześniejszej niż SQL 2012) na około godzinę, gdy aplikacja jest używana. Możesz także poprosić użytkownika o wykonanie różnych działań w aplikacji w określonej kolejności, abyś mógł skorelować go ze śledzeniem / sesją.

Pomocna sugestia: jeśli możesz zmodyfikować ciąg połączenia, którego aplikacja używa w ogóle, dołącz „; Nazwa aplikacji = AppNameGoesHere”, abyś mógł uruchomić filtrowanie śledzenia dla tej konkretnej nazwy aplikacji. W każdym razie dobra praktyka.

3) Pobierz wersję aplikacji działającą na serwerze nieprodukcyjnym. Opracuj listę testów opartych na zachowaniu dla aplikacji („Gdy użytkownik kliknie przycisk Nowy element, tworzy nowy element dla tego użytkownika” itp.) Rozpocznij łagodne usuwanie obiektów, które według ciebie nie mają wpływu na testy, zmieniając ich nazwy (Używam formatu typu objectName_DEPRECATED_YYYYMMDD - przy czym data jest dniem, w którym planuję go faktycznie usunąć.) Ponownie zweryfikuj wszystkie testy.

Dzięki połączeniu sesji Extended Events, użycia indeksu DMV i miękkiego usuwania, powinieneś być w stanie zidentyfikować główne obiekty używane przez aplikację i mieć dobrą ogólną zgodność co do tego, który obiekt robi co.

Powodzenia!

Najlepiej zacząć od udokumentowania bazy danych za pomocą SQL Power Doc

SQL Server i dokumentacja Windows za pomocą Windows PowerShell

SQL Power Doc to zbiór skryptów i modułów Windows PowerShell, które wykrywają, dokumentują i diagnozują wystąpienia SQL Server oraz ich leżące u ich podstaw konfiguracje systemu operacyjnego Windows i komputera. SQL Power Doc współpracuje ze wszystkimi wersjami SQL Server od SQL Server 2000 do 2014 oraz wszystkimi wersjami Windows Server i konsumenckich systemów operacyjnych Windows od Windows 2000 i Windows XP do Windows Server 2012 R2 i Windows 8. SQL Power Doc jest również zdolny do dokumentowanie baz danych SQL Azure.

Uwaga: Korzystałem z niego, dzięki czemu naprawdę dobrze zaczniesz dokumentować i rozumieć instancję serwera bazy danych.

Ponieważ byłem kiedyś w podobnej sytuacji, mogę powiedzieć, że będzie to trudna do niemożliwej praca. Miałem tylko kod źródłowy (> 100 tys. Wierszy kodu), działającą usługę, działającą bazę danych (~ 50 tabel) oraz brak dokumentacji i nikogo, kto mógłby o nią zapytać oprócz użytkownika tej aplikacji oraz kopii bazy danych i usług działających w środowisko testowe (które było kilka numerów wersji, ale bez kodu źródłowego). Kolejnym wymogiem było to, że usługi musiały działać 24 godziny na dobę, 7 dni w tygodniu, ponieważ były zewnętrzne dla klientów. Sytuacja powstała, ponieważ większość pracowników odeszła mniej więcej w tym samym czasie, w tym programiści i dokumentacja zniknęła w chaosie. Zrozumienie / dokumentacja zajęło mi ponad 6 miesięcy. Było wiele tabel i funkcji, które nie przyniosły żadnego efektu, ponieważ były przeznaczone do wykorzystania w przyszłości lub nigdy nie zostały w pełni wdrożone, wadliwe lub przestarzałe lub niepublikowane funkcje. Po 6 miesiącach musiałem przepisać dokumentację, ponieważ odkryłem nowe rzeczy lub relacje między nimi i wcześniej miałem błędne założenia.

Dlaczego to mówię? Ponieważ czasami w takiej sytuacji łatwiej i taniej jest zacząć od zera i napisać nową aplikację spełniającą wymagania starej (lub nowej, jeśli zmieniły się one z czasem lub chcesz wydać nową wersję główną). Lub powiedzieć ci, czego będziesz się spodziewać.

Jeśli naprawdę chcesz to odtworzyć, polecam następujące kroki:

• Wykonaj kopię zapasową całego systemu! (Po pierwsze: nigdy nie będziesz wiedział, kiedy będziesz go potrzebować. Po drugie: potrzebujesz go do następnego kroku)
• odtwórz kopię systemu (usług i bazy danych) do pracy i zapisz, jak ją utworzyć, ponieważ z pewnością będziesz musiał to zrobić wiele razy w ciągu najbliższych miesięcy, ponieważ popsuniesz ją wiele razy podczas inżynierii wstecznej
• utwórz diagram ER z zależnościami między tabelami
• przeglądać i dokumentować zależności każdej tabeli, procedury składowanej, ... ponieważ te najczęściej nie są uwzględnione w diagramach ER
• zrozumieć, co powinno zrobić oprogramowanie, pytając użytkowników i korzystając z niego (najlepiej zrób to w systemie testowym)
• Jeśli kod źródłowy usług jest dostępny: uzyskaj jego przegląd i wywołania do DB i udokumentuj go (doxygen jest dobrym narzędziem do uzyskania zgrubnej dokumentacji z hierarchiami wywołań funkcji)
• spróbuj uzyskać ogólny przegląd bazy danych, patrząc na nazwy tabel i ich kolumny
• obserwuj bazę danych podczas korzystania z niej
• w poprzednich 4 krokach podziel tabele na 3 kategorie (mogą się różnić w zależności od aplikacji): dane statyczne (dane, które nie zmieniają się podczas działania serwera, takie jak konfiguracja serwera, wyliczają w celu ograniczenia prawidłowych wartości w innych tabelach przy użyciu obcych kluczy do niego , ...), dane konfiguracyjne (dane, które rzadko się zmieniają, takie jak ustawienia użytkownika, ...) i dane OLTP (wiadomości użytkownika na serwerze czatu, posty na forum, wartości pomiarowe w systemie sterowania maszyną, bitwy w grze online, ...)
• powtarzaj poprzednie 5 kroków, aż będziesz zadowolony lub się poddasz
• Dokumentuj i koduj tak, jakby facet, który ostatecznie utrzyma TWÓJ kod / system / bazę danych, będzie brutalnym psychopatą, który wie, gdzie mieszkasz.

Życzę Ci szczęścia ;)

Nie mam wystarczającej liczby przedstawicieli, aby opublikować komentarz, ale chciałem pomóc w twoim pytaniu dotyczącym

getting the SQL Power Doc to work.

Jeśli wykonasz kroki na stronie z dokumentacją, będzie to działać dość łatwo. Po prostu zacznij od góry.

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