SQL Server - osobna baza danych dla raportów?

Na naszym SQL Server mamy bazę danych dla każdej z naszych aplikacji internetowych. W przypadku raportów korzystamy z usług Reporting Services, a wszystkie dane raportu (w tym parametry raportu) pochodzą z procedur przechowywanych.

Procedury składowane znajdują się w tej samej bazie danych, co dane w raporcie. Na przykład procesy obsługujące raporty zapasów znajdują się w bazie danych zapasów. Niektóre raporty pokazują informacje z więcej niż jednej bazy danych, a następnie proc będzie w jednej z tych źródłowych baz danych. Parametry raportu pobierają swoje dane z procesów w bazie danych Enterprise, która zawiera dane takie jak sklepy, pracownicy itp.

Oznacza to, że wszystkie raporty mają co najmniej połączenie z bazą danych Enterprise i inne połączenie z inną bazą danych - a czasem nawet więcej.

Moje pytanie brzmi: czy korzyść z przeniesienia procedur raportowania do osobnej bazy danych „Raporty” . Znam zalety przenoszenia raportów na inny serwer i nie mówię o tym - byłoby to na tym samym serwerze.

Mogą to mieć wpływ na:

• Czy posiadanie więcej niż jednego połączenia z bazą danych dla raportu wpływa na szybkość raportu?
• Czy proces raportowania w oddzielnej bazie danych od danych uniemożliwiłby nam korzystanie z widoków indeksowanych?
• Czy uważasz, że łatwiej / trudniej jest administrować raportami w osobnej bazie danych?

Proszę daj mi znać co myślisz.

Odpowiedź brzmi: tak, jest to korzystne. Raporty dotyczące operacyjnej bazy danych będą zużywać wiele zasobów i zakłócać działanie systemu operacyjnego. Pamiętaj, że wydajność bazy danych podlega ograniczeniom mechanicznym (głowice dysków poruszają się do przodu i do tyłu oraz opóźnienia obrotowe, gdy czekamy, aż odpowiedni sektor pojawi się pod głową). Masz dwie ogólne opcje strategii raportowania:

1. Replikuj bazę danych na innym serwerze i przenieś na nią sproki raportujące. Raporty są uruchamiane ze zreplikowanego serwera. Jest to najmniejszy wysiłek i może ponownie wykorzystać istniejące raporty i procedury przechowywane.
2. Zbuduj hurtownię danych, która konsoliduje dane z systemów produkcyjnych i przekształca je w formę, która jest znacznie bardziej przyjazna dla raportów . Jeśli masz wiele raportów statystycznych ad hoc, które można wykonać w sposób akceptowalny na podstawie migawki z „wczorajszego zamknięcia działalności”, lepszym rozwiązaniem może być hurtownia danych.

Myślę, że wiele zależy od rodzaju SP, którą prowadzisz. Jeśli są ciężkie i mogą wpływać na inne rzeczy działające na serwerze bazy danych, przenosiłbym je. W przeciwnym razie postaram się trzymać blisko bazy danych, na której się zgłaszają, jeśli będzie to łatwiejsze w utrzymaniu i śledzeniu. Posiadanie raportu blisko rzeczywistej bazy danych może również wpłynąć na wydajność, ale jeśli masz standardową konfigurację i nie przenosisz ogromnej ilości danych, to byłaby niewielka różnica.

Uważam również, że ten artykuł jest przydatny.

Odradzam przenoszenie procedur przechowywanych do innej bazy danych z kilku powodów. Z perspektywy programistycznej musisz odtworzyć dwie bazy danych za każdym razem, gdy chcesz wprowadzić zmiany. W rezultacie będziesz teraz, jak synchronizować schemat z bazy danych „data” i procedur przechowywanych z drugiej z wersjami produkcyjnymi. Jeśli chodzi o odzyskiwanie po awarii i tworzenie kopii zapasowych / przywracanie, musisz teraz zająć się przywróceniem 2 baz danych, aby uruchomić system.

Podczas testowania dodano również złożoność. Będziesz miał więcej punktów niepowodzenia w odniesieniu do uprawnień, wersji itp. Teraz, jeśli więcej niż 1 osoba pracuje nad różnymi inicjatywami w bazie danych, poświęcisz więcej czasu na koordynację. Teraz wyobraź sobie, że jest trzecia nad ranem, system jest wyłączony i musisz przeszukiwać uprawnienia we wszystkich bazach danych i upewnić się, że nikt nie zostawił funkcji lub procedury w niewłaściwej bazie danych podczas programowania.

Polecam użyć dwóch baz danych.

Wyprowadzanie raportów z „bieżącej” bazy danych powoduje problemy z wydajnością.

Ponieważ baza danych raportowania służy przede wszystkim do wyszukiwania, można tutaj dostosować indeksy, aby uzyskać lepszą wydajność. (Aktywna baza danych zawiera wstawki, na które niektóre indeksy miałyby negatywny wpływ)

Innym podejściem jest przeniesienie tabel raportowania do oddzielnego schematu i oddzielnej grupy plików. Pliki w raportowanej grupie plików można przenieść z dysków twardych z danymi. Ułatwia to administrację, przyszły rozwój i zarządzanie dostępem.