Zagadnienia dotyczące projektowania programu SQL Server

Program System Center Operations Manager wymaga dostępu do wystąpienia serwera z uruchomionym programem Microsoft SQL Server w celu obsługi operacyjnej bazy danych inspekcji, magazynu danych i usługi ACS. Operacyjne i bazy danych magazynu danych są wymagane i tworzone podczas wdrażania pierwszego serwera zarządzania w grupie zarządzania, podczas gdy baza danych ACS jest tworzona podczas wdrażania modułu zbierającego ACS w grupie zarządzania.

W środowisku laboratoryjnym lub w małym wdrożeniu programu Operations Manager program SQL Server może znajdować się na pierwszym serwerze zarządzania w grupie zarządzania.

W przypadku wdrożenia rozproszonego o średniej skali przedsiębiorstwa wystąpienie programu SQL Server powinno znajdować się na dedykowanym serwerze autonomicznym lub w konfiguracji wysokiej dostępności programu SQL Server. W obu przypadkach program SQL Server musi już istnieć i jest dostępny przed rozpoczęciem instalacji pierwszego serwera zarządzania lub modułu zbierającego ACS.

Nie zalecamy używania baz danych programu Operations Manager z wystąpienia SQL, które ma inne bazy danych aplikacji. Pozwala to uniknąć potencjalnych problemów z we/wy i innymi ograniczeniami zasobów sprzętowych.

Ważne

Program Operations Manager nie obsługuje wystąpień sql typu Platforma jako usługa (PaaS), w tym produktów, takich jak azure SQL Managed Instance lub Amazon Relational Database Service (AWS RDS). Użyj wystąpienia programu SQL Server zainstalowanego na maszynie z systemem Windows. Jedynym wyjątkiem jest wystąpienie zarządzane SCOM usługi Azure Monitor, które korzysta z wystąpienia zarządzanego usługi Azure SQL, i nie można go ponownie skonfigurować.

Wymagania dotyczące programu SQL Server

Następujące wersje programu SQL Server Enterprise i Standard Edition są obsługiwane w przypadku istniejącej instalacji programu System Center Operations Manager w celu hostowania serwera raportowania, operacyjnej, magazynu danych i bazy danych ACS:

• SQL Server 2022

• SQL Server 2019 z aktualizacją zbiorczą 8 (CU8) lub nowszą, jak opisano tutaj

  Uwaga

  • Program Operations Manager 2022 obsługuje program SQL 2019 z cu8 lub nowszym; nie obsługuje jednak programu SQL 2019 RTM.
  • Użyj wersji ODBC 17.3 lub 17.10.6 i MSOLEDBSQL 18.2 lub 18.7.2.

• Aktualizacje zbiorcze i sql Server 2017, jak opisano tutaj

Przed uaktualnieniem programu SQL Server zobacz informacje o uaktualnieniu dla programu SQL 2017 i informacje o uaktualnieniu programu SQL 2019.

Uwaga

• Każdy z następujących składników programu SQL Server obsługujących infrastrukturę SCOM musi być w tej samej wersji głównej programu SQL Server:
  • Wystąpienia aparatu bazy danych programu SQL Server hostujące dowolne bazy danych SCOM (czyli OperationManager, OperationManagerDW i SSRS Database ReportServer & ReportServerTempDB).
  • Wystąpienie usług SQL Server Reporting Services (SSRS).
• Ustawienie sortowania programu SQL Server musi być jednym z obsługiwanych typów, zgodnie z opisem w sekcji ustawienia sortowania programu SQL Server poniżej.
• Wyszukiwanie pełnotekstowe programu SQL Server jest wymagane dla wszystkich wystąpień aparatu bazy danych programu SQL Server hostowania dowolnych baz danych programu SCOM.
• Opcje instalacji systemu Windows Server 2016 (Server Core, Server with Desktop Experience i Nano Server) obsługiwane przez składniki bazy danych programu Operations Manager są oparte na opcjach instalacji systemu Windows Server obsługiwanych przez program SQL Server.

Uwaga

Nie można zainstalować raportowania programu System Center Operations Manager w sposób równoległy z poprzednią wersją roli raportowania i musi być zainstalowany tylko w trybie natywnym (tryb zintegrowany programu SharePoint nie jest obsługiwany).

Dodatkowe zagadnienia dotyczące sprzętu i oprogramowania mają zastosowanie w planowaniu projektu:

• Zalecamy uruchomienie programu SQL Server na komputerach z formatem pliku NTFS.
• Musi istnieć co najmniej 1024 MB wolnego miejsca na dysku dla operacyjnej bazy danych magazynu danych i magazynu danych. Jest on wymuszany w momencie tworzenia bazy danych i prawdopodobnie znacznie wzrośnie po skonfigurowaniu.
• Jest wymagany program .NET Framework 4.
• Program .NET Framework 4.8 jest obsługiwany w programie Operations Manager 2022.
• Serwer raportowania nie jest obsługiwany w systemie Windows Server Core.

Aby uzyskać więcej informacji, zobacz Wymagania sprzętowe i programowe dotyczące instalowania programu SQL Server.

Uwaga

Mimo że program Operations Manager używa tylko uwierzytelniania systemu Windows podczas instalacji, ustawienie uwierzytelniania w trybie mieszanym SQL nadal będzie działać, jeśli żadne konto lokalne nie ma roli db_owner. Konta lokalne z rolą db_owner są znane z problemów z programem System Center Operations Manager. Usuń rolę db_owner ze wszystkich kont lokalnych przed zainstalowaniem produktu i nie dodawaj roli db_owner do żadnego z kont lokalnych po instalacji.

Ustawienie sortowania programu SQL Server

Następujące sortowania programu SQL Server i systemu Windows są obsługiwane przez program System Center Operations Manager.

Uwaga

Aby uniknąć problemów ze zgodnością podczas porównywania lub kopiowania operacji, zalecamy użycie tego samego sortowania dla bazy danych SQL i Operations Manager.

Sortowanie programu SQL Server

• SQL_Latin1_General_CP1_CI_AS

Sortowanie systemu Windows

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

Jeśli wystąpienie programu SQL Server nie jest skonfigurowane przy użyciu jednego z obsługiwanych sortowania wymienionych wcześniej, wykonanie nowej konfiguracji programu Operations Manager zakończy się niepowodzeniem. Jednak uaktualnienie w miejscu zakończy się pomyślnie.

Konfiguracja zapory

Program Operations Manager zależy od programu SQL Server do hostowania baz danych i platformy raportowania w celu analizowania i prezentowania historycznych danych operacyjnych. Role serwera zarządzania, operacji i konsoli sieci Web muszą być w stanie pomyślnie komunikować się z programem SQL Server i ważne jest, aby zrozumieć ścieżkę komunikacji i porty w celu poprawnego skonfigurowania środowiska.

Jeśli projektujesz wdrożenie rozproszone, które będzie wymagać zawsze włączonych grup dostępności SQL w celu zapewnienia funkcji trybu failover dla baz danych programu Operations Manager, istnieją dodatkowe ustawienia konfiguracji zapory, które należy uwzględnić w strategii zabezpieczeń zapory.

Poniższa tabela ułatwia zidentyfikowanie portów zapory wymaganych przez program SQL Server, które muszą być dozwolone co najmniej w celu pomyślnego komunikowania się ról serwera w grupie zarządzania programu Operations Manager.

Scenariusz	Port	Kierunek	Rola programu Operations Manager
Program SQL Server hostuje bazy danych programu Operations Manager	TCP 1433 *	Przychodzący	serwer zarządzania i konsola sieci Web (dla usługi Application Advisor i diagnostyki aplikacji)
Usługa SQL Server Browser	UDP 1434	Przychodzący	serwer zarządzania
Dedykowane połączenie administratora programu SQL Server	TCP 1434	Przychodzący	serwer zarządzania
Dodatkowe porty używane przez program SQL Server - Zdalne wywołania procedur firmy Microsoft (MS RPC) — Instrumentacja zarządzania Windows (WMI) — Koordynator transakcji rozproszonych firmy Microsoft (MS DTC)	TCP 135	Przychodzący	serwer zarządzania
Odbiornik zawsze włączonej grupy dostępności programu SQL Server	Port skonfigurowany przez administratora	Przychodzący	serwer zarządzania
Sql Server Reporting Services hostujący serwer raportowania programu Operations Manager	TCP 80 (wartość domyślna)/443 (SSL)	Przychodzący	serwer zarządzania i konsola Operacje

* Chociaż tcp 1433 jest portem standardowym dla domyślnego wystąpienia aparatu bazy danych, podczas tworzenia nazwanego wystąpienia na autonomicznym serwerze SQL Server lub wdrożono zawsze włączoną grupę dostępności SQL, port niestandardowy zostanie zdefiniowany i powinien zostać udokumentowany do celów referencyjnych, aby prawidłowo skonfigurować zapory i wprowadzić te informacje podczas instalacji.

Aby uzyskać bardziej szczegółowe omówienie wymagań zapory dla programu SQL Server, zobacz Konfigurowanie zapory systemu Windows pod kątem zezwalania na dostęp do programu SQL Server.

Zagadnienia dotyczące pojemności i magazynu

Baza danych programu Operations Manager

Baza danych programu Operations Manager to baza danych programu SQL Server, która zawiera wszystkie dane wymagane przez program Operations Manager do codziennego monitorowania. Ustalanie rozmiaru i konfiguracja serwera bazy danych ma kluczowe znaczenie dla ogólnej wydajności grupy zarządzania. Najbardziej krytycznym zasobem używanym przez bazę danych programu Operations Manager jest podsystem magazynowania, ale procesor CPU i pamięć RAM są również istotne.

Czynniki wpływające na obciążenie bazy danych programu Operations Manager obejmują:

• Szybkość zbierania danych operacyjnych. Dane operacyjne składają się ze wszystkich zdarzeń, alertów, zmian stanu i danych wydajności zebranych przez agentów. Większość zasobów używanych przez bazę danych programu Operations Manager jest używana do zapisywania tych danych na dysku w miarę ich stosowania w systemie. Szybkość zebranych danych operacyjnych ma tendencję do wzrostu w miarę importowania dodatkowych pakietów administracyjnych i dodawania dodatkowych agentów. Typ komputera, który monitoruje agent, jest również ważnym czynnikiem używanym podczas określania ogólnej szybkości zbierania danych operacyjnych. Na przykład agent monitorujący komputer stacjonarny o krytycznym znaczeniu dla działania firmy może zbierać mniej danych niż agent monitorujący serwer z uruchomionym wystąpieniem programu SQL Server z dużą liczbą baz danych.
• Częstotliwość zmian przestrzeni wystąpień. Aktualizowanie tych danych w bazie danych programu Operations Manager jest kosztowne w stosunku do zapisywania nowych danych operacyjnych. Ponadto w przypadku zmiany danych obszaru wystąpienia serwery zarządzania tworzą dodatkowe zapytania do bazy danych programu Operations Manager w celu obliczenia zmian konfiguracji i grupowania. Częstotliwość zmian przestrzeni wystąpień zwiększa się w miarę importowania dodatkowych pakietów administracyjnych do grupy zarządzania. Dodanie nowych agentów do grupy zarządzania powoduje również tymczasowe zwiększenie szybkości zmian przestrzeni wystąpień.
• Liczba konsoli operacji i innych połączeń zestawu SDK uruchomionych jednocześnie. Każda konsola Operacje odczytuje dane z bazy danych programu Operations Manager. Wykonywanie zapytań dotyczących tych danych zużywa potencjalnie duże ilości zasobów we/wy magazynu, czasu procesora CPU i pamięci RAM. Konsole operacji, które wyświetlają duże ilości danych operacyjnych w widoku zdarzeń, widoku stanu, widoku alertów i widoku danych wydajności, zwykle powodują największe obciążenie bazy danych.

Baza danych programu Operations Manager jest pojedynczym źródłem awarii grupy zarządzania, więc można ją udostępnić w wysokiej dostępności przy użyciu obsługiwanych konfiguracji trybu failover, takich jak zawsze włączone grupy dostępności programu SQL Server lub wystąpienia klastra trybu failover.

Bazy danych programu Operations Manager można skonfigurować i uaktualnić przy użyciu istniejącej konfiguracji zawsze włączonej bazy danych SQL bez konieczności wprowadzania zmian konfiguracji.

Włączanie usługi SQL Broker w bazie danych programu Operations Manager

Program System Center Operations Manager zależy od usługi SQL Server Service Broker w celu zaimplementowania wszystkich operacji zadań. Jeśli usługa SQL Server Service Broker jest wyłączona, wszystkie operacje zadań będą miały wpływ. Wynikowe zachowanie może się różnić w zależności od zainicjowanego zadania. Dlatego ważne jest, aby sprawdzić stan usługi SQL Server Service Broker za każdym razem, gdy nieoczekiwane zachowanie jest obserwowane wokół zadania w programie System Center Operations Manager.

Aby włączyć usługę SQL Server Service Broker, wykonaj następujące kroki:

1. Uruchom następujące zapytanie SQL:

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. Pomiń ten krok, jeśli wartość wyświetlana w is_broker_enabled polu to 1 (jeden). W przeciwnym razie uruchom następujące zapytania SQL:

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Baza danych magazynu danych programu Operations Manager

System Center — Operations Manager wstawia dane do magazynu danych raportowania niemal w czasie rzeczywistym. Ważne jest, aby mieć wystarczającą pojemność na tym serwerze, który obsługuje zapisywanie wszystkich danych zbieranych w magazynie danych raportowania. Podobnie jak w przypadku bazy danych programu Operations Manager, najbardziej krytycznym zasobem w magazynie danych raportowania jest podsystem we/wy magazynu. W większości systemów obciążenia magazynu danych raportowania są podobne do bazy danych programu Operations Manager, ale mogą się różnić. Ponadto obciążenie umieszczone w magazynie danych raportowania przez raportowanie różni się od obciążenia umieszczonego w bazie danych programu Operations Manager według użycia konsoli Operacje.

Czynniki wpływające na obciążenie magazynu danych raportowania obejmują:

• Szybkość zbierania danych operacyjnych. Aby umożliwić wydajniejsze raportowanie, magazyn danych raportowania oblicza i przechowuje zagregowane dane oprócz ograniczonej ilości danych pierwotnych. Wykonanie tej dodatkowej pracy oznacza, że zbieranie danych operacyjnych w magazynie danych raportowania może być nieco bardziej kosztowne niż w bazie danych programu Operations Manager. Ten dodatkowy koszt jest zwykle zrównoważony przez obniżony koszt przetwarzania danych odnajdywania przez magazyn danych raportowania w porównaniu z bazą danych programu Operations Manager.
• Liczba współbieżnych użytkowników raportowania lub zaplanowane generowanie raportów. Ponieważ raporty często podsumowują duże ilości danych, każdy użytkownik raportowania może dodać znaczne obciążenie systemu. Liczba raportów uruchamianych jednocześnie, a typ uruchamianych raportów ma wpływ na ogólne potrzeby dotyczące pojemności. Ogólnie rzecz biorąc, raporty, które wysyłają zapytania o duże zakresy dat lub dużą liczbę obiektów, wymagają dodatkowych zasobów systemowych.

Na podstawie tych czynników istnieje kilka zalecanych rozwiązań, które należy wziąć pod uwagę podczas określania rozmiaru magazynu danych raportowania:

• Wybierz odpowiedni podsystem magazynowania. Ponieważ magazyn danych raportowania jest integralną częścią ogólnego przepływu danych przez grupę zarządzania, wybór odpowiedniego podsystemu magazynowania dla magazynu danych raportowania jest ważny. Podobnie jak w przypadku bazy danych programu Operations Manager, macierz RAID 0 + 1 jest często najlepszym wyborem. Ogólnie rzecz biorąc, podsystem magazynowania dla magazynu danych raportowania powinien być podobny do podsystemu magazynowania dla bazy danych programu Operations Manager, a wskazówki dotyczące bazy danych programu Operations Manager dotyczą również magazynu danych raportowania.
• Rozważ odpowiednie umieszczenie dzienników danych w porównaniu z dziennikami transakcji. Jeśli chodzi o bazę danych programu Operations Manager, oddzielenie danych SQL i dzienników transakcji jest często właściwym wyborem podczas skalowania w górę liczby agentów. Jeśli zarówno baza danych programu Operations Manager, jak i magazyn danych raportowania znajdują się na tym samym serwerze i chcesz oddzielić dzienniki danych i transakcji, należy umieścić dzienniki transakcji dla bazy danych programu Operations Manager na oddzielnym woluminie fizycznym i dyskach z magazynu danych raportowania, aby uzyskać wszelkie korzyści. Pliki danych bazy danych programu Operations Manager i magazynu danych raportowania mogą współdzielić ten sam wolumin fizyczny, o ile wolumin zapewnia odpowiednią pojemność, a wydajność we/wy dysku nie ma negatywnego wpływu na funkcje monitorowania i raportowania.
• Rozważ umieszczenie magazynu danych raportowania na osobnym serwerze z bazy danych programu Operations Manager. Chociaż wdrożenia o mniejszej skali mogą często konsolidować bazę danych programu Operations Manager i magazyn danych raportowania na tym samym serwerze, korzystne jest oddzielenie ich od skalowania w górę liczby agentów i ilości przychodzących danych operacyjnych. Gdy magazyn danych raportowania i serwer raportowania znajdują się na innym serwerze niż baza danych programu Operations Manager, wydajność raportowania jest lepsza.

Baza danych magazynu danych programu Operations Manager jest pojedynczym źródłem awarii grupy zarządzania, więc można ją udostępnić w wysokiej dostępności przy użyciu obsługiwanych konfiguracji trybu failover, takich jak zawsze włączone grupy dostępności programu SQL Server lub wystąpienia klastra trybu failover.

Zawsze włączony program SQL Server

Zawsze włączone grupy dostępności programu SQL Server obsługują środowiska trybu failover dla dyskretnego zestawu baz danych użytkowników (baz danych dostępności). Każdy zestaw baz danych dostępności jest hostowany przez replikę dostępności.

W programie System Center 2016 i nowszym — Operations Manager zawsze włączone jest preferowane klastrowanie trybu failover w celu zapewnienia wysokiej dostępności baz danych. Wszystkie bazy danych z wyjątkiem instalacji usług Reporting Services w trybie natywnym, która używa dwóch baz danych do oddzielenia magazynu trwałego od wymagań magazynu tymczasowego, mogą być hostowane w zawsze włączonej grupie dostępności.

Za pomocą programu Operations Manager 2022 można skonfigurować i uaktualnić bazy danych programu Operations Manager przy użyciu istniejącej konfiguracji zawsze włączonej bazy danych SQL bez konieczności wprowadzania zmian konfiguracji.

Aby skonfigurować grupę dostępności, należy wdrożyć klaster trybu failover systemu Windows Server (WSFC) do hostowania repliki dostępności i włączyć funkcję Always On w węzłach klastra. Następnie możesz dodać bazę danych programu SQL Server programu Operations Manager jako bazę danych dostępności.

• Dowiedz się więcej o wymaganiach wstępnych dotyczących funkcji Always On.
• Dowiedz się więcej o konfigurowaniu usługi WSFC dla zawsze włączonych grup dostępności.
• Dowiedz się więcej o konfigurowaniu grupy dostępności.

Uwaga

Po wdrożeniu programu Operations Manager w węzłach programu SQL Server uczestniczących w programie SQL Always On, aby włączyć ścisłe zabezpieczenia środowiska CLR, uruchom skrypt SQL w każdej bazie danych programu Operations Manager.

Ciąg z wieloma podsieciami

Program Operations Manager nie obsługuje słów kluczowych parametry połączenia (MultiSubnetFailover=True). Ponieważ grupa dostępności ma nazwę odbiornika (znaną jako nazwa sieci lub punkt dostępu klienta w Menedżerze klastra WSFC) w zależności od wielu adresów IP z różnych podsieci, takich jak podczas wdrażania w konfiguracji trybu failover między lokacjami, żądania połączenia klienta z serwerów zarządzania do odbiornika grupy dostępności osiągną limit czasu połączenia.

Zalecanym podejściem do obejścia tego ograniczenia podczas wdrażania węzłów serwera w grupie dostępności w środowisku z wieloma podsieciami jest wykonanie następujących czynności:

1. Ustaw nazwę sieci odbiornika grupy dostępności, aby zarejestrować tylko jeden aktywny adres IP w systemie DNS.
2. Skonfiguruj klaster tak, aby używał niskiej wartości czasu wygaśnięcia dla zarejestrowanego rekordu DNS.

Te ustawienia umożliwiają przejście w tryb failover do węzła w innej podsieci w celu szybszego odzyskiwania i rozpoznawania nazwy klastra przy użyciu nowego adresu IP.

Uruchom następujące polecenia programu PowerShell w dowolnym z węzłów SQL, aby zmodyfikować jego ustawienia:

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

Jeśli używasz funkcji Always On z nazwą odbiornika, należy również wprowadzić te zmiany konfiguracji na odbiorniku. Aby uzyskać więcej informacji na temat konfigurowania odbiornika grupy dostępności, zobacz dokumentację tutaj: Konfigurowanie odbiornika grupy dostępności — zawsze włączone programu SQL Server

Uruchom następujące polecenia programu PowerShell w węźle SQL, które obecnie hostuje odbiornik, aby zmodyfikować jego ustawienia:

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

Gdy klasterowane lub zawsze włączone wystąpienie SQL jest używane do wysokiej dostępności, należy włączyć funkcję automatycznego odzyskiwania na serwerach zarządzania, aby uniknąć ponownego uruchomienia usługi dostępu do danych programu Operations Manager w dowolnym momencie przejścia w tryb failover między węzłami. Aby uzyskać informacje na temat sposobu konfigurowania tej konfiguracji, zobacz następujący artykuł BAZY wiedzy Usługa System Center Management przestaje odpowiadać po przejściu wystąpienia programu SQL Server do trybu offline.

Optymalizowanie programu SQL Server

Ogólnie rzecz biorąc, poprzednie środowisko wdrażania z klientami pokazuje, że problemy z wydajnością zwykle nie są spowodowane wysokim wykorzystaniem zasobów (czyli procesorem lub pamięcią) z samym programem SQL Server; jest on bezpośrednio związany z konfiguracją podsystemu magazynowania. Wąskie gardła wydajności są często przypisywane nie zgodnie z zalecanymi wskazówkami dotyczącymi konfiguracji z aprowizowaną magazynem dla wystąpienia bazy danych programu SQL Server. Oto następujące przykłady:

• Niewystarczająca alokacja wrzecion dla jednostek LUN w celu obsługi wymagań we/wy programu Operations Manager.
• Hostowanie dzienników transakcji i plików bazy danych na tym samym woluminie. Te dwa obciążenia mają różne charakterystyki operacji we/wy i opóźnienia.
• Konfiguracja bazy danych TempDB jest niepoprawna w odniesieniu do umieszczania, określania rozmiaru itd.
• Niezgodność partycji dysku woluminów hostowania dzienników transakcji bazy danych, plików bazy danych i bazy danych TempDB.
• Pomijanie podstawowej konfiguracji programu SQL Server, takiej jak używanie funkcji AUTOGROW dla plików dziennika bazy danych i transakcji, ustawienie MAXDOP dla równoległości zapytań, tworzenie wielu plików danych bazy danych TempDB na rdzeń procesora CPU itd.

Konfiguracja magazynu jest jednym z krytycznych składników wdrożenia programu SQL Server dla programu Operations Manager. Serwery baz danych zwykle mają duże ograniczenia we/wy z powodu rygorystycznego działania odczytu i zapisu bazy danych oraz przetwarzania dziennika transakcji. Wzorzec zachowania we/wy programu Operations Manager zwykle wynosi 80% operacji zapisu i 20% odczytów. W rezultacie niewłaściwa konfiguracja podsystemów we/wy może prowadzić do niskiej wydajności i działania systemów programu SQL Server i staje się zauważalna w programie Operations Manager.

Ważne jest, aby przetestować projekt programu SQL Server przez przeprowadzenie testów przepływności podsystemu we/wy przed wdrożeniem programu SQL Server. Upewnij się, że te testy są w stanie spełnić wymagania dotyczące operacji we/wy z dopuszczalnym opóźnieniem. Użyj narzędzia Diskspd, aby ocenić pojemność we/wy podsystemu magazynowania obsługującego program SQL Server. Poniższy artykuł w blogu, utworzony przez członka zespołu serwera plików w grupie produktów, zawiera szczegółowe wskazówki i zalecenia dotyczące wykonywania testów obciążeniowych przy użyciu tego narzędzia z kodem programu PowerShell i przechwytywania wyników przy użyciu narzędzia PerfMon. Aby uzyskać wstępne wskazówki, możesz również zapoznać się z pomocnikiem określania rozmiaru programu Operations Manager.

Rozmiar jednostki alokacji NTFS

Wyrównanie woluminu, często określane jako wyrównanie sektora, należy wykonać w systemie plików (NTFS) za każdym razem, gdy wolumin jest tworzony na urządzeniu RAID. Niepowodzenie w tym celu może prowadzić do znacznego obniżenia wydajności i jest najczęściej wynikiem niezgodności partycji z granicami jednostek rozłożonych. Może to również prowadzić do niezgodności pamięci podręcznej sprzętowej, co powoduje nieefektywne wykorzystanie pamięci podręcznej tablicy. Podczas formatowania partycji, która będzie używana dla plików danych programu SQL Server, zaleca się użycie rozmiaru 64 KB jednostki alokacji (czyli 65 536 bajtów) dla danych, dzienników i bazy danych tempdb. Należy jednak pamiętać, że użycie rozmiarów jednostek alokacji większych niż 4 KB powoduje brak możliwości korzystania z kompresji NTFS na woluminie. Chociaż program SQL Server obsługuje dane tylko do odczytu na skompresowanych woluminach, nie jest zalecane.

Rezerwuj pamięć

Uwaga

Wiele informacji w tej sekcji pochodzi z Jonathan Kehayias w swoim wpisie na blogu Ile pamięci rzeczywiście potrzebuje mój program SQL Server? (sqlskills.com).

Nie zawsze łatwo jest zidentyfikować odpowiednią ilość pamięci fizycznej i procesorów do przydzielenia dla programu SQL Server w obsłudze programu System Center Operations Manager (lub innych obciążeń poza tym produktem). Kalkulator ustalania rozmiaru dostarczony przez grupę produktów zawiera wskazówki na podstawie skali obciążenia, ale jego zalecenia są oparte na testach wykonywanych w środowisku laboratoryjnym, które mogą lub nie są zgodne z rzeczywistym obciążeniem i konfiguracją.

Program SQL Server umożliwia skonfigurowanie minimalnej i maksymalnej ilości pamięci , która będzie zarezerwowana i używana przez jego proces. Domyślnie program SQL Server może dynamicznie zmieniać wymagania dotyczące pamięci na podstawie dostępnych zasobów systemowych. Ustawieniem domyślnym dla minimalnej pamięci serwera jest 0, a ustawieniem domyślnym maksymalnej pamięci serwera jest 2147 483 647 MB.

Problemy związane z wydajnością i pamięcią mogą wystąpić, jeśli nie ustawisz odpowiedniej wartości maksymalnej pamięci serwera. Wiele czynników wpływa na ilość pamięci, którą należy przydzielić do programu SQL Server, aby zapewnić, że system operacyjny może obsługiwać inne procesy uruchomione w tym systemie, takie jak karta HBA, agenci zarządzania i skanowanie antywirusowe w czasie rzeczywistym. Jeśli nie ustawiono wystarczającej ilości pamięci, system operacyjny i program SQL będą stronicować dysk. Może to spowodować zwiększenie operacji we/wy dysku, dalsze zmniejszenie wydajności i utworzenie efektu falowania, w którym staje się zauważalne w programie Operations Manager.

Zalecamy określenie co najmniej 4 GB pamięci RAM dla minimalnej pamięci serwera. Należy to zrobić dla każdego węzła SQL hostowania jednej z baz danych programu Operations Manager (operacyjnej, magazynu danych, usługi ACS).

W przypadku maksymalnej pamięci serwera zalecamy, aby początkowo zarezerwować sumę:

• 1 GB pamięci RAM dla systemu operacyjnego
• 1 GB pamięci RAM na co 4 GB zainstalowanej pamięci RAM (do 16 GB pamięci RAM)
• 1 GB pamięci RAM na każdy zainstalowany 8 GB pamięci RAM (powyżej 16 GB pamięci RAM)

Po ustawieniu tych wartości należy monitorować licznik Pamięci\Dostępne bajty MBytes w systemie Windows, aby określić, czy można zwiększyć ilość pamięci dostępnej dla programu SQL Server. System Windows sygnalizuje, że dostępna pamięć fizyczna jest niska na poziomie 96 MB, więc idealnie licznik nie powinien działać niż około 200–300 MB, aby upewnić się, że masz bufor. W przypadku serwerów z 256 GB pamięci RAM lub nowszej prawdopodobnie chcesz upewnić się, że nie działa on mniej niż 1 GB.

Pamiętaj, że te obliczenia zakładają, że program SQL Server ma mieć możliwość używania całej dostępnej pamięci, chyba że zmodyfikujesz je tak, aby uwzględniały inne aplikacje. Należy wziąć pod uwagę określone wymagania dotyczące pamięci dla systemu operacyjnego, innych aplikacji, stosu wątków programu SQL Server i innych alokatorów wielostronicowych. Typową formułą jest ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), gdzie pamięć dla stosu wątków = ((max worker threads) (stack size)). Rozmiar stosu to 512 KB dla systemów x86, 2 MB dla systemów x64 i 4 MB dla systemów IA64. Wartość maksymalnego wątku roboczego można znaleźć w kolumnie max_worker_count sys.dm_os_sys_info.

Te zagadnienia dotyczą również wymagań dotyczących pamięci programu SQL Server do uruchamiania na maszynie wirtualnej. Ponieważ program SQL Server jest przeznaczony do buforowania danych w puli i zwykle używa jak największej ilości pamięci, trudno jest określić idealną ilość potrzebnej pamięci RAM. W przypadku zmniejszenia ilości pamięci przydzielonej do wystąpienia programu SQL Server w końcu dojdziesz do punktu, w którym przydział mniejszej ilości pamięci jest wymieniany w celu uzyskania wyższego dostępu we/wy dysku.

Aby skonfigurować pamięć programu SQL Server w środowisku, które zostało nadmiernie aprowidowane, zacznij od monitorowania środowiska i bieżących metryk wydajności, w tym średniej długości życia strony Menedżera programu SQL Server oraz odczytów/s i odczytów/s dysku fizycznego/s wartości. Jeśli środowisko ma nadmiar pamięci, oczekiwana długość życia strony zwiększy się o wartość jednej sekundy bez żadnego spadku obciążenia ze względu na buforowanie; na stronie Menedżera programu SQL Server odczytuje/s wartość będzie niska po podwyższeniu pamięci podręcznej, a odczyty dysku fizycznego na sekundę również pozostaną niskie.

Po zrozumieniu punktu odniesienia środowiska można zmniejszyć maksymalną pamięć serwera o 1 GB, a następnie zobaczyć, jak wpływa to na liczniki wydajności (po ustąpieniu początkowej pamięci podręcznej). Jeśli metryki pozostaną akceptowalne, zmniejsz o kolejne 1 GB, a następnie ponownie monitoruj, powtarzając je zgodnie z potrzebami, aż określisz idealną konfigurację.

Aby uzyskać więcej informacji, zobacz Opcje konfiguracji pamięci serwera.

Optymalizowanie bazy danych TempDB

Rozmiar i fizyczne umieszczanie bazy danych tempdb mogą mieć wpływ na wydajność programu Operations Manager. Jeśli na przykład rozmiar zdefiniowany dla bazy danych tempdb jest zbyt mały, część obciążenia przetwarzania systemu może być zajęta przez automatyczne powiększanie bazy danych tempdb do rozmiaru wymaganego do obsługi obciążenia przy każdym ponownym uruchomieniu wystąpienia programu SQL Server. Aby uzyskać optymalną wydajność bazy danych tempdb, zalecamy następującą konfigurację bazy danych tempdb w środowisku produkcyjnym:

• Ustaw model odzyskiwania bazy danych tempdb na SIMPLE. Ten model automatycznie odzyskuje obszar dziennika, aby zachować małe wymagania dotyczące miejsca.
• Wstępnie przydziel miejsce dla wszystkich plików bazy danych tempdb, ustawiając rozmiar pliku na wartość wystarczająco dużą, aby pomieścić typowe obciążenie w środowisku. Zapobiega to zbyt częstemu rozszerzaniu bazy danych tempdb, co może mieć wpływ na wydajność. Bazę danych tempdb można ustawić na automatyczne zwiększanie, ale należy jej użyć do zwiększenia miejsca na dysku w przypadku nieplanowanych wyjątków.
• Utwórz dowolną liczbę plików, aby zmaksymalizować przepustowość dysku. Użycie wielu plików zmniejsza rywalizację o magazyn bazy danych tempdb i zapewnia lepszą skalowalność. Nie twórz jednak zbyt wielu plików, ponieważ może zmniejszyć wydajność i zwiększyć obciążenie związane z zarządzaniem. Ogólnie rzecz biorąc, utwórz jeden plik danych dla każdego procesora logicznego na serwerze (uwzględniając dowolne ustawienia maski koligacji), a następnie dostosuj liczbę plików w górę lub w dół w razie potrzeby. Ogólnie rzecz biorąc, jeśli liczba procesorów logicznych jest mniejsza lub równa 8, należy użyć tej samej liczby plików danych co procesory logiczne. Jeśli liczba procesorów logicznych jest większa niż 8, użyj ośmiu plików danych, a następnie jeśli rywalizacja będzie kontynuowana, zwiększ liczbę plików danych o wielokrotność 4 (do liczby procesorów logicznych), aż rywalizacja zostanie zmniejszona do akceptowalnych poziomów lub wprowadź zmiany w obciążeniu/kodzie. Jeśli rywalizacja nie zostanie zmniejszona, może być konieczne zwiększenie liczby plików danych.
• Ustaw każdy plik danych na taki sam rozmiar, co zapewnia optymalną wydajność wypełniania proporcjonalnego. Równe ustalanie rozmiaru plików danych ma kluczowe znaczenie, ponieważ algorytm wypełniania proporcjonalnego jest oparty na rozmiarze plików. Jeśli pliki danych są tworzone z nierównymi rozmiarami, algorytm wypełniania proporcjonalnego próbuje użyć największego pliku więcej dla alokacji GAM zamiast rozkładać alokacje między wszystkie pliki, tym samym pokonując cel tworzenia wielu plików danych.
• Umieść bazę danych tempdb w szybkim podsystemie we/wy przy użyciu dysków półprzewodnikowych, aby uzyskać najbardziej optymalną wydajność. Użyj usuwania dysku, jeśli istnieje wiele bezpośrednio dołączonych dysków.
• Umieść bazę danych tempdb na dyskach, które różnią się od tych, które są używane przez bazy danych użytkowników.

Aby skonfigurować bazę danych tempdb, możesz uruchomić następujące zapytanie lub zmodyfikować jego właściwości w programie Management Studio.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

Uruchom zapytanie SELECT * from sys.sysprocesses T-SQL, aby wykryć rywalizację o alokację stron dla bazy danych tempdb. W danych wyjściowych tabeli systemowej zasób oczekiwania może być wyświetlany jako "2:1:1" (strona PFS) lub "2:1:3" (udostępniona strona mapy alokacji globalnej). W zależności od stopnia rywalizacji może to również prowadzić do braku odpowiedzi programu SQL Server w krótkich okresach. Innym podejściem jest zbadanie dynamicznych widoków zarządzania [sys.dm_exec_request lub sys.dm_os_waiting_tasks]. Wyniki pokażą, że te żądania lub zadania oczekują na zasoby bazy danych tempdb i mają podobne wartości jak wyróżnione wcześniej podczas wykonywania zapytania sys.sysprocesses .

Jeśli poprzednie zalecenia nie zmniejszają znacząco rywalizacji o alokację, a rywalizacja znajduje się na stronach SGAM, zaimplementuj flagę śledzenia -T1118 w parametrach uruchamiania programu SQL Server, aby flaga śledzenia pozostała w mocy nawet po recyklingu programu SQL Server. W ramach tej flagi śledzenia program SQL Server przydziela pełne zakresy do każdego obiektu bazy danych, eliminując tym samym rywalizację na stronach SGAM.

Uwaga

Ta flaga śledzenia wpływa na każdą bazę danych w wystąpieniu programu SQL Server.

Maksymalny stopień równoległości

Domyślna konfiguracja programu SQL Server dla małych i średnich wdrożeń programu Operations Manager jest odpowiednia dla większości potrzeb. Jednak gdy obciążenie grupy zarządzania jest skalowane w górę w kierunku scenariusza klasy korporacyjnej (zazwyczaj 2000+ systemów zarządzanych przez agentów i zaawansowanej konfiguracji monitorowania, która obejmuje monitorowanie na poziomie usług z zaawansowanymi transakcjami syntetycznymi, monitorowanie urządzeń sieciowych, międzyplatformowe itd.), konieczne jest zoptymalizowanie konfiguracji programu SQL Server opisanego w tej sekcji dokumentu. Jedną z opcji konfiguracji, która nie została omówiona w poprzednich wskazówkach, jest MAXDOP.

Opcja konfiguracji max degree of parallelism (MAXDOP) programu Microsoft SQL Server kontroluje liczbę procesorów używanych do wykonywania zapytania w planie równoległym. Ta opcja określa zasoby obliczeniowe i wątkowe, które są używane dla operatorów planu zapytania, które wykonują pracę równolegle. W zależności od tego, czy program SQL Server jest skonfigurowany na komputerze z symetrycznym przetwarzaniem wieloprocesorowym (SMP), komputerze z dostępem do nieumundurowanej pamięci (NUMA) lub procesorami obsługującymi funkcję hyperthreading, należy odpowiednio skonfigurować maksymalny stopień równoległości.

Gdy program SQL Server działa na komputerze z więcej niż jednym mikroprocesorem lub procesorem CPU, wykrywa najlepszy stopień równoległości, czyli liczbę procesorów używanych do uruchamiania pojedynczej instrukcji dla każdego wykonania planu równoległego. Domyślnie jej wartość dla tej opcji to 0, co umożliwia programowi SQL Server określenie maksymalnego stopnia równoległości.

Procedury składowane i zapytania wstępnie zdefiniowane w programie Operations Manager w odniesieniu do operacyjnej, magazynu danych, a nawet bazy danych inspekcji nie obejmują opcji MAXDOP, ponieważ podczas instalacji nie ma możliwości dynamicznego wykonywania zapytania o liczbę procesorów przedstawionych w systemie operacyjnym, ani nie próbuje zakodować wartości tego ustawienia, co może mieć negatywne konsekwencje w przypadku wykonania zapytania.

Uwaga

Opcja konfiguracji maksymalnego stopnia równoległości nie ogranicza liczby procesorów używanych przez program SQL Server. Aby skonfigurować liczbę procesorów używanych przez program SQL Server, użyj opcji konfiguracji maski koligacji.

• W przypadku serwerów korzystających z więcej niż ośmiu procesorów należy użyć następującej konfiguracji: MAXDOP=8
• W przypadku serwerów korzystających z ośmiu lub mniej procesorów użyj następującej konfiguracji: MAXDOP=0 do N

  Uwaga

  W tej konfiguracji N reprezentuje liczbę procesorów.