Jakie obiektywne czynniki wskazują, że nadszedł czas na wdrożenie replikacji SQL Server?

Staram się znaleźć równowagę między wysoką wydajnością naszej bazy danych a łatwością konserwacji. Rozważamy wykorzystanie replikacji w celu poprawy wydajności, replikując nasze raporty SSRS do fizycznie oddzielnej bazy danych od naszej transakcyjnej bazy danych. Jednak włączenie replikacji ma wiele wad z punktu widzenia programisty:

• Utrudnia to zmiany schematu
• Ingeruje w nasz automatyczny serwer integracji / kompilacji
• Wydaje się, że utrudnia to wdrożenie kontroli źródła SQL

Moje pytanie brzmi : kiedy wiesz, że nadszedł czas na replikację w świetle tych wad? Jak decydujesz, czy dodatkowa złożoność uzasadnia zyski?

Użyliśmy go już wcześniej, więc konfiguracja nie stanowi problemu. Chodzi raczej o podjęcie decyzji o jej włączeniu lub nie. Szukam niektórych wskaźników wydajności obiektu, które inni zaobserwowali podczas replikacji.

Oczywiście najlepiej byłoby przeprowadzić symulowane testy obciążenia na naszych własnych serwerach i sami to ustalić, ale mam nadzieję, że istnieją pewne ogólne wytyczne.

Należy rozważyć replikację na etapie projektowania wniosku. Jeśli masz rozproszoną geograficznie bazę pracowników / bazę użytkowników, posiadanie regionalnych baz danych i centralnych baz danych może mieć sens. Odłączone bazy danych na laptopach mogą „zsynchronizować się”, kiedy w końcu ponownie połączą się z siecią (pomyśl sprzedawców w drodze).

Jeśli chodzi o raportowanie, replikacja NIE jest odpowiedzią. Większość problemów z wydajnością w środowisku raportowania wynika z faktu, że raporty są zapisywane w systemie skonfigurowanym do przetwarzania transakcji online (OLTP).

Replikacja do celów sprawozdawczych polega po prostu na przeniesieniu danych OLTP na inny serwer, ale przy zachowaniu tej samej struktury nieprzyjaznej dla raportów. Zasadniczo rzucasz więcej sprzętu na problem i zwiększasz koszty konserwacji, ale dla uzyskania marginalnych korzyści.

To, na co powinieneś zwrócić uwagę, to jak uzyskać określone dane potrzebne w raportach i przekształcić je w bardziej użyteczny format. Utwórz kanał, który pobiera nowe transakcje z produkcyjnej bazy danych i przechowuje ją w bazie danych raportów, najlepiej na osobnym serwerze. Za każdym razem, gdy kanał się uruchamia, powinien pobrać wszystkie dane, które są nowsze od ostatniego uruchomienia, przekształcić te dane i zapisać je. Raporty, które obecnie uruchamiasz, dają dobry obraz typów wymaganych transformacji.

Postępując zgodnie z tym podejściem, będziesz czerpać ogromne korzyści z wydajności.

Z uwagi na to, że warto, replikacja okazała się pomocna w podobnej sytuacji, ponieważ autorzy raportów mogą „posiadać” indeksy w replikowanej bazie danych. Dało nam to możliwość poprawy wydajności zapytań poprzez dodanie indeksów, których twórcy aplikacji nigdy nie zaakceptowaliby w produkcji ze względu na ich negatywny wpływ na WSTAWKI i AKTUALIZACJE.

Może częścią twojego przypadku użycia jest skopiowanie niektórych tabel transakcyjnych, zmiana indeksowania i sprawdzenie, czy warto?

Mam nadzieję że to pomoże!