Az SQL Server kialakításával kapcsolatos szempontok

A System Center Operations Managernek hozzáférésre van szüksége egy Microsoft SQL Server futtató kiszolgáló egy példányához az operatív, adattárház és ACS auditadatbázis támogatásához. Az operatív és az adatraktár-adatbázis a felügyeleti csoport első felügyeleti kiszolgálójának üzembe helyezéséhez szükséges, és a rendszer ennek a folyamatnak a részeként hozza létre. Az ACS-naplózási adatbázis akkor jön létre, amikor üzembe helyezi a felügyeleti csoport ACS-gyűjtőjét.

Laborkörnyezetben, illetve az Operations Manager kis léptékű használata esetén a felügyeleti csoport első felügyeleti kiszolgálójára telepítheti az SQL Servert is.

Közepes és nagyvállalati szintű elosztott rendszerek esetében azonban az SQL Server példányát egy dedikált, különálló kiszolgálóra, vagy egy magas rendelkezésre állású SQL Server-konfigurációra érdemes telepíteni. Az SQL Server-példányának mindkét esetben működnie kell, és elérhetőnek kell lennie, mielőtt megkezdi az első felügyeleti kiszolgáló vagy az ACS-gyűjtő telepítését.

Nem javasoljuk az Operations Manager-adatbázisok használatát olyan SQL-példányból, amely más alkalmazásadatbázisokkal rendelkezik. Ennek célja, hogy elkerülje az I/O-val és más hardvererőforrás-korlátozásokkal kapcsolatos esetleges problémákat.

Fontos

Az Operations Manager nem támogatja az SQL Platform as a Service (PaaS) példányait, beleértve az olyan termékeket, mint a Azure SQL Managed Instance vagy az Amazon Relational Database Service (AWS RDS). Használjon windowsos gépen telepített SQL Server egy példányát. Ez alól az egyetlen kivétel a felügyelt Azure Monitor SCOM-példány, amely Azure SQL MI-t használ, és nem újrakonfigurálható.

Az SQL Server rendszerre vonatkozó követelmények

A SQL Server Enterprise & Standard Edition következő verziói támogatottak a System Center Operations Manager verziójának meglévő telepítéséhez a jelentéskészítő kiszolgáló, az operatív, a Data Warehouse és az ACS-adatbázis üzemeltetésére:

• SQL Server 2022

• SQL Server 2019-ben a 8. kumulatív frissítéssel (CU8) vagy újabb verzióval, az itt részletezett módon

  Megjegyzés

  • Az Operations Manager 2022 támogatja az SQL 2019-et CU8 vagy újabb verzióval; azonban nem támogatja az SQL 2019 RTM-et.
  • Használja az ODBC 17.3-at vagy újabb verzióját, valamint az MSOLEDBSQL 18.2-s vagy újabb verzióját.

• SQL Server 2017-es és összesített Frissítések itt részletezve

A SQL Server frissítése előtt tekintse meg a 2017-re vonatkozó frissítési információkat és az SQL 2019 frissítési adatait.

Megjegyzés

• Az SCOM-infrastruktúrát támogató alábbi SQL Server összetevőknek ugyanazon SQL Server főverzióval kell rendelkeznie:
  • SQL Server adatbázismotor-példányok bármelyik SCOM-adatbázist üzemeltetik (azaz OperationManager, OperationManagerDW és SSRS-adatbázisok ReportServer & ReportServerTempDB).
  • SQL Server Reporting Services (SSRS) példány.
• A SQL Server rendezési beállításnak az alábbi SQL Server rendezési beállítás szakaszban leírtak szerint az egyik támogatott típusnak kell lennie.
• SQL Server teljes szöveges keresés szükséges az SCOM-adatbázisokat üzemeltető SQL Server adatbázismotor-példányokhoz.
• Az Operations Manager adatbázis-összetevői által támogatott Windows Server 2016 telepítési lehetőségek (Server Core, Server with Desktop Experience és Nano Server) azon alapulnak, hogy a Windows Server mely telepítési lehetőségeit támogatja SQL Server.

Megjegyzés

A System Center Operations Manager jelentéskészítési szolgáltatása nem telepíthető egymás mellett a jelentéskészítési szerepkör korábbi verziójával, és csak natív módban kell telepíteni (az integrált SharePoint-mód nem támogatott).

A kialakítás megtervezése során további hardveres és szoftveres szempontokat is figyelembe kell venni:

• Javasoljuk, hogy ntfs fájlformátumú számítógépeken futtassa SQL Server.
• Az operatív és az adatraktár-adatbázis legalább 1024 MB szabad helyet igényel. Az adatbázis létrehozásakor lesz kényszerítve, és a beállítás után valószínűleg jelentősen nőni fog.
• A .NET-keretrendszer 4-es verziója is szükséges.
• .NET-keretrendszer 4.8 az Operations Manager 2022-ben támogatott.
• A Jelentéskészítő kiszolgáló nem támogatott a Windows Server Core-on.

További információ: A SQL Server telepítésének hardver- és szoftverkövetelményei.

Megjegyzés

Bár az Operations Manager csak Windows-hitelesítést használ a telepítés során, az SQL Vegyes módú hitelesítés beállítása továbbra is működni fog, ha egyetlen helyi fiók sem rendelkezik db_owner szerepkörrel. A db_owner szerepkörrel rendelkező helyi fiókokról ismert, hogy problémákat okoznak a System Center Operations Managerrel kapcsolatban. A termék telepítése előtt távolítsa el a db_owner szerepkört az összes helyi fiókból, és a telepítés után ne adja hozzá a db_owner szerepkört egyik helyi fiókhoz sem.

Az SQL Server-rendezés beállítása

A System Center Operations Manager az alábbi SQL Server és Windows-rendezéseket támogatja.

Megjegyzés

A műveletek összehasonlításával vagy másolásával kapcsolatos kompatibilitási problémák elkerülése érdekében javasoljuk, hogy ugyanazt a rendezést használja az SQL- és az Operations Manager-adatbázishoz.

SQL Server-rendezés

• SQL_Latin1_General_CP1_CI_AS

Windows-rendezés

• 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

Ha a SQL Server példány nincs konfigurálva a korábban felsorolt támogatott rendezések egyikével, az Operations Manager új beállításának végrehajtása sikertelen lesz. A helyben végzett verzióváltás viszont sikerülni fog.

Tűzfal-konfiguráció

Az Operations Manager az SQL Server segítségével üzemelteti adatbázisait, valamint az operatív előzményadatok elemzésére és bemutatására szolgáló jelentéskészítő platformját. A felügyeleti kiszolgálói, üzemeltetési és webkonzol-szerepköröknek képesnek kell lenniük a SQL Server való sikeres kommunikációra, és fontos megérteni a kommunikációs útvonalat és a portokat a környezet megfelelő konfigurálásához.

Ha olyan elosztott üzembe helyezést tervez, amely megköveteli, hogy az SQL Always On rendelkezésre állási csoportok feladatátvételi funkciókat biztosítsanak az Operations Manager-adatbázisokhoz, további tűzfalkonfigurációs beállításokat kell megadnia a tűzfal biztonsági stratégiájához.

Az alábbi táblázat segítségével azonosíthatja az SQL Server azon tűzfalportjait, amelyeket feltétlenül engedélyezni kell ahhoz, hogy az Operations Manager felügyeleti csoportjához tartozó kiszolgálói szerepkörök kommunikálni tudjanak egymással.

Eset	Port	Irány	Operations Manager-szerepkör
Az Operations Manager adatbázisait futtató SQL Server	TCP 1433 *	Bejövő	felügyeleti kiszolgáló és webkonzol (az Application Advisorhoz és az Application Diagnosticshoz)
SQL Server Browser szolgáltatás	UDP 1434	Bejövő	Management kiszolgáló
SQL Server dedikált rendszergazdai kapcsolata	TCP 1434	Bejövő	Management kiszolgáló
A SQL Server által használt további portok – Távoli Microsoft-eljáráshívások (MS RPC) - Windows Management Instrumentation (WMI) - Microsoft Distributed Transaction Coordinator (MS DTC)	TCP 135	Bejövő	Management kiszolgáló
SQL Server AlwaysOn rendelkezésre állási csoport figyelője	A rendszergazda által beállított port	Bejövő	Management kiszolgáló
Az Operations Manager jelentéskészítő kiszolgálót futtató SQL Server Reporting Services	TCP 80 (alapértelmezés)/443 (SSL)	Bejövő	felügyeleti kiszolgáló és operatív konzol

* Bár a TCP 1433 az adatbázismotor alapértelmezett példányának szabványos portja, amikor létrehoz egy elnevezett példányt egy különálló SQL Server, vagy üzembe helyezett egy SQL Always On rendelkezésre állási csoportot, egy egyéni port lesz definiálva, és referenciaként dokumentálva kell lennie, hogy megfelelően konfigurálja a tűzfalakat, és adja meg ezeket az információkat a telepítés során.

A SQL Server tűzfalkövetelményeinek részletesebb áttekintéséért lásd: A Windows tűzfal konfigurálása SQL Server hozzáférés engedélyezésére.

Kapacitásra és tárhelyre vonatkozó szempontok

Operations Manager-adatbázis

Az Operations Manager-adatbázis olyan SQL Server-adatbázis, amely az Operations Manager által végzett napi figyelési műveletekhez szükséges adatokat tárolja. Az adatbázis-kiszolgáló méretezése és beállítása kritikus fontosságú a felügyeleti csoport általános teljesítménye szempontjából. Az Operations Manager-adatbázis legfontosabb erőforrása a tárolóalrendszer, de a processzor és a RAM is jelentős szerepet játszik kialakításában.

Az Operations Manager-adatbázis terhelését befolyásoló tényezők:

• A begyűjtött operatív adatok mennyisége. Operatív adatnak nevezzük az ügynök által gyűjtött, eseményekre, riasztásokra vagy állapotváltozásokra vonatkozó adatokat, valamint teljesítményadatokat. Az Operations Manager-adatbázis az általa elérhető erőforrások jelentős részét arra fordítja, hogy a lemezre írja a beérkező operatív adatokat. A rendszer általában egyre több operatív adatot gyűjt, ha további felügyeleti csomagokat importálnak, illetve újabb ügynököket vesznek fel. Az operatív adatok gyűjtésének mértékére az is hatással van, hogy milyen típusú számítógépeket figyelnek az ügynökök. Például egy üzleti szempontból kritikus fontosságú asztali számítógépet figyelő ügynök általában kevesebb adatot gyűjt, mint az az ügynök, amely egy nagy számú adatbázist tartalmazó SQL Server-példányt futtató kiszolgálót figyel.
• A példánytér változásainak gyakorisága. Az összegyűjtött adatok frissítése az Operations Manager-adatbázisban több erőforrást használ, mint az új operatív adatok lemezre írása. Ráadásul a példánytér váltása esetén a felügyeleti kiszolgálók újabb, a konfigurációt és a csoportokat érintő változások kiszámítására vonatkozó lekérdezéseket küldenek az Operations Manager-adatbázisnak. A példányterek közötti váltás gyakorisága nő, ha további felügyeleti csomagokat importál a felügyeleti csoportba. A példánytérváltás gyakorisága ideiglenesen akkor is felgyorsul, amikor új ügynököket vesz fel egy felügyeleti csoportba.
• Az egyszerre futó operatív konzolok és más SDK-kapcsolatok száma. Az operatív konzolok az Operations Manager-adatbázis adatait használják. Ezeknek az adatoknak a lekérdezése akár jelentős mértékű tárolási I/O-erőforrást, processzoridőt vagy RAM memóriát is igénybe vehet. Az operatív konzol Esemény, Állapot, Riasztás és Teljesítmény nézetében akár nagy mennyiségű operatív adat is megjelenhet. Általában ezek terhelik meg a legjobban az adatbázist.

Az Operations Manager a felügyeleti csoport rendszerkritikus meghibásodási pontja, így érdemes lehet az SQL Server Always On rendelkezésre állási csoportok vagy feladatátvételi fürtbeli példányok segítségével beállítani magas rendelkezésre állását.

Az Operations Manager-adatbázisokat meglévő SQL-Always-On beállításával állíthatja be és frissítheti anélkül, hogy a konfigurációt követően módosításokat kellene végeznie.

Sql Broker engedélyezése az Operations Manager-adatbázisban

A System Center Operations Manager az SQL Server Service Brokertől függ az összes feladatművelet implementálásához. Ha SQL Server Szolgáltatásközvetítő le van tiltva, minden tevékenységművelet érintett lesz. Az eredményként kapott viselkedés a kezdeményezett tevékenységtől függően változhat. Ezért fontos ellenőrizni az SQL Server Service Broker állapotát, amikor váratlan viselkedés figyelhető meg a System Center Operations Manager egyik feladatában.

A SQL Server Service Broker engedélyezéséhez kövesse az alábbi lépéseket:

1. Futtassa a következő SQL-lekérdezést:

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

2. Hagyja ki ezt a lépést, ha a mezőben megjelenített is_broker_enabled érték 1 (egy). Ellenkező esetben futtassa a következő SQL-lekérdezéseket:

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

Operations Manager adatraktár-adatbázis

System Center – Az Operations Manager közel valós időben szúr be adatokat a jelentéskészítési adattárházba. Fontos, hogy elegendő kapacitással rendelkezzen ezen a kiszolgálón, amely támogatja a jelentéskészítési adattárházba gyűjtött összes adat írását. Ahogy az Operations Manager-adatbázisnál, a jelentéskészítési célú adattárház legkritikusabb erőforrása is az I/O-tárolóalrendszer. A legtöbb rendszeren a jelentéskészítési adattárház betöltései hasonlóak az Operations Manager-adatbázishoz, de eltérőek lehetnek. Ezenfelül a jelentéskészítési célú adattárházat a jelentések eltérő módon terhelik meg, mint az operatív konzol használata az Operations Manager-adatbázist.

A jelentéskészítési célú adattárházat érő terhelést befolyásoló tényezők:

• A begyűjtött operatív adatok mennyisége. A jelentési funkciók hatékonyabb működése érdekében a jelentéskészítési célú adattárház csak korlátozott mennyiségű nyers adatot tárol, ehelyett főként összesített adatok generálásával és tárolásával foglalkozik. Ez azt jelenti, hogy több műveletet kell elvégezni, azaz az operatív adatok jelentéskészítési célú adattárházba való gyűjtése némileg több erőforrást igényel, mint az Operations Manager-adatbázis használata. Ezt ellensúlyozza, hogy a jelentéskészítési célú adattárház Operations Manager-adatbázisnál kevesebb erőforrást igényel a felderítési adatok feldolgozásához.
• Az adatbázist egyszerre használó jelentéskészítő felhasználók, illetve az ütemezett jelentéskészítések száma. Mivel a jelentések gyakran nagy adatmennyiséget foglalnak magukban, minden egyes jelentést készítő felhasználó komoly terhelést helyezhet a rendszerre. A kapacitásigényt az is befolyásolja, hogy egyszerre hány, illetve milyen típusú jelentést futtatnak a felhasználók. Általánosságban elmondható, hogy a nagy adattartományokat vagy nagy számú objektumot lekérdező jelentések több rendszererőforrást vesznek igénybe.

Ezen tényezők alapján a jelentéskészítési adattárház méretezése során több ajánlott eljárást is figyelembe kell venni:

• Válasszon megfelelő tárolóalrendszert. Mivel a jelentéskészítési adattárház a felügyeleti csoporton keresztüli teljes adatfolyam szerves része, fontos a jelentéskészítési adattárház megfelelő tárolási alrendszerének kiválasztása. Ahogy az Operations Manager-adatbázis esetében, itt is a RAID 0 + 1 a legjobb megoldás. Általánosságban elmondható, hogy érdemes az Operations Manager-adatbázisnál használthoz hasonló tárolóalrendszert választani a jelentéskészítési célú adattárházhoz, illetve kijelenthető, hogy az Operations Manager-adatbázisra vonatkozó útmutatások a jelentéskészítési célú adattárházra is érvényesek.
• Tervezze meg alaposan az adatnaplók és a tranzakciónaplók elhelyezését. Az Operations Manager-adatbázishoz hasonlóan az SQL-adatok és a tranzakciónaplók elkülönítése gyakran megfelelő választás az ügynökök számának felskálázása során. Ha az Operations Manager-adatbázis és a jelentéskészítési célú adattárház ugyanazon a kiszolgálón működik, és Ön szeretné elkülöníteni az adat- és tranzakciónaplókat, a legjobb megoldás, ha a jelentéskészítési célú adattárház naplóitól eltérő fizikai kötetre és lemezmeghajtóra helyezi az Operations Manager-adatbázis tranzakciónaplóit. Az Operations Manager-adatbázis és a jelentéskészítési adattárház adatfájljai ugyanazt a fizikai kötetet oszthatják meg, ha a kötet megfelelő kapacitást biztosít, és a lemez I/O-teljesítménye nem befolyásolja hátrányosan a monitorozási és jelentéskészítési funkciókat.
• Fontolja meg, hogy szükséges-e két különálló kiszolgálóra helyezni a jelentéskészítési célú adattárházat és az Operations Manager-adatbázist. Bár a kisebb léptékű üzemelő példányok gyakran összevonhatják az Operations Manager-adatbázist és a jelentéskészítési adattárházat ugyanazon a kiszolgálón, előnyös elkülöníteni őket az ügynökök számának és a bejövő operatív adatok mennyiségének felskálázása során. Ha a jelentéskészítési adattárház és a jelentéskészítő kiszolgáló az Operations Manager-adatbázistól eltérő kiszolgálón található, jobb jelentéskészítési teljesítményt tapasztalhat.

Az Operations Manager adatraktár-adatbázisa a felügyeleti csoport rendszerkritikus meghibásodási pontja, így érdemes lehet az SQL Server Always On rendelkezésre állási csoportok vagy feladatátvételi fürtbeli példányok segítségével beállítani magas rendelkezésre állását.

SQL Server Always On

Az SQL Server Always On rendelkezésre állási csoportok felhasználói adatbázisok (rendelkezésre állási adatbázisok) diszkrét készletei esetén támogatják a feladatátvételt. A rendelkezésre állási adatbázisok minden készlete egy rendelkezésre állási replikán található.

A System Center 2016-os és újabb – Operations Managerrel az SQL Always On előnyben részesíti a feladatátvételi fürtözést, hogy magas rendelkezésre állást biztosítson az adatbázisok számára. Az AlwaysOn rendelkezésre állási csoportok az összes adatbázist képesek futtatni, kivéve a natív módú Reporting Services rendszer két adatbázisát, amelyeknél elkülönül egymástól a perzisztens és az ideiglenes tárhely.

Az Operations Manager 2022-ben az Operations Manager-adatbázisokat meglévő SQL-Always-On beállítással állíthatja be és frissítheti anélkül, hogy a konfigurációt követő módosításokat kellene elvégeznie.

Rendelkezésre állási csoport beállításához telepítenie kell egy Windows Server feladatátvételi fürtszolgáltatást (WSFC) a rendelkezésre állási replika üzemeltetéséhez, és engedélyeznie kell az Always On beállítást a fürtcsomópontokon. Ezután hozzáadhatja az Operations Manager SQL Server-adatbázist rendelkezésre állási adatbázisként.

• További információ az Always On előfeltételeiről.
• További információ a WSFC always on rendelkezésre állási csoportokhoz való beállításáról.
• További információ a rendelkezésre állási csoportok beállításáról.

Megjegyzés

Miután üzembe helyezette az Operations Managert az SQL Always On-ban részt vevő SQL Server-csomópontokon, a CLR szigorú biztonságának engedélyezéséhez futtassa az SQL-szkriptet minden Operations Manager-adatbázison.

Több-alhálózati sztring

Az Operations Manager nem támogatja a kapcsolati karakterlánc kulcsszót (MultiSubnetFailover=True). Mivel egy rendelkezésre állási csoportnak van egy figyelőneve (a WSFC-fürtkezelőben a hálózatnév vagy az ügyfélelérési pont) a különböző alhálózatokból származó több IP-címtől függően, például a helyek közötti feladatátvételi konfigurációban való üzembe helyezéskor, a felügyeleti kiszolgálóktól a rendelkezésreállási csoport figyelőjéhez érkező ügyfélkapcsolati kérések kapcsolati időtúllépést kapnak.

Ha több alhálózatos környezetben telepítette a kiszolgálócsomópontokat a rendelkezésre állási csoportban, ajánlott megkerülni ezt a korlátozást:

1. Állítsa be a rendelkezésreállási csoport figyelőjének hálózatnevét úgy, hogy csak egyetlen aktív IP-címet regisztráljon a DNS-ben.
2. Konfigurálja úgy a fürtöt, hogy alacsony TTL-értéket használjon a regisztrált DNS-rekordhoz.

Ezek a beállítások lehetővé teszik a feladatátvételt egy másik alhálózaton lévő csomópontra a fürt nevének gyorsabb helyreállításához és az új IP-címmel való feloldásához.

A beállítások módosításához futtassa a következő PowerShell-parancsokat bármelyik SQL-csomóponton:

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"

Ha figyelőnévvel használja az Always On-t, ezeket a konfigurációs módosításokat is végezze el a figyelőn. A rendelkezésreállási csoport figyelőjének konfigurálásával kapcsolatos további információkért tekintse meg a következő dokumentációt: Rendelkezésreállási csoport figyelőjének konfigurálása – SQL Server Always On

Futtassa a következő PowerShell-parancsokat a figyelőt jelenleg üzemeltető SQL-csomóponton a beállításainak módosításához:

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>

Ha fürtözött vagy Always On SQL-példányt használ a magas rendelkezésre álláshoz, engedélyeznie kell az automatikus helyreállítási funkciót a felügyeleti kiszolgálókon, hogy elkerülje az Operations Manager adatelérési szolgáltatás újraindítását, amikor feladatátvétel történik a csomópontok között. Ennek konfigurálásáról a következő tudásbáziscikkben talál további információt: A System Center Management szolgáltatás leáll, miután egy SQL Server egy példánya offline állapotba kerül.

Az SQL Server optimalizálása

Általánosságban elmondható, hogy az ügyfelek korábbi üzembe helyezési tapasztalatai azt mutatják, hogy a teljesítményproblémákat általában nem a magas erőforrás-kihasználtság (vagyis a processzor vagy a memória) okozza SQL Server, hanem közvetlenül kapcsolódik a tárolóalrendszer konfigurálásához. A teljesítménybeli szűk keresztmetszetek általában úgy vannak beállítva, hogy nem követik az ajánlott konfigurációs útmutatást a SQL Server adatbázispéldány számára kiépített tárterülettel. Ilyenek például a következők:

• Nem rendelnek annyi lemezmeghajtót a LUN-okhoz, amennyire az Operations Manager I/O-igényei alapján szükség lenne.
• Ugyanazon a köteten tárolják a tranzakciónaplókat és az adatbázisfájlokat. Ez a két számítási feladat eltérő I/O- és késési jellemzőkkel rendelkezik.
• A TempDB konfigurálása helytelen az elhelyezés, a méretezés és így tovább.
• Az adatbázis-tranzakciónaplókat, adatbázisfájlokat és TempDB-t üzemeltető kötetek lemezpartíciós eltérése.
• Figyelmen kívül hagyva az alapvető SQL Server konfigurációt, például az AUTOGROW adatbázis- és tranzakciónapló-fájlokhoz való használatát, a lekérdezések párhuzamosságára vonatkozó MAXDOP-beállítást, cpu-magonként több TempDB-adatfájl létrehozását stb.

Az Operations Managerhez tartozó SQL Server beállításának egyik alapvető fontosságú összetevője a tárhely konfigurációja. Az adatbázis-kiszolgálók általában nagy mértékben I/O-kötöttek, mivel az adatbázis viszonylatában jelentős az olvasási és írási tevékenység, valamint a tranzakciónapló feldolgozása is komoly erőforrásokat igényel. Az Operations Manager I/O-viselkedési mintája általában 80%-os írási és 20%-os olvasási. Ennek eredményeképpen az I/O-alrendszerek helytelen konfigurálása a SQL Server rendszerek gyenge teljesítményéhez és működéséhez vezethet, és észrevehetővé válik az Operations Managerben.

Fontos, hogy tesztelje a SQL Server kialakítását az I/O-alrendszer átviteli sebességének tesztelésével a SQL Server üzembe helyezése előtt. Győződjön meg arról, hogy ezek a tesztek elfogadható késéssel érik el az I/O-követelményeket. A Diskspd segédprogrammal kiértékelheti a SQL Server támogató tárolóalrendszer I/O-kapacitását. A következő blogbejegyzés, amelyet a fájlkiszolgáló csapatának egy tagja készített a termékcsoportban, részletes útmutatást és javaslatokat nyújt arról, hogyan végezhet stressztesztelést ezzel az eszközzel néhány PowerShell-kóddal, és hogyan rögzítheti az eredményeket a PerfMon használatával. A kezdeti útmutatásért tekintse meg az Operations Manager méretezési segédjét is.

NTFS foglalási egységek mérete

Ha a RAID-eszközön kötetet hoz létre, mindenképpen végezze el a fájlrendszeren (NTFS) a kötetek illesztését (amelyre gyakran a szektorok illesztéseként is hivatkoznak). Ennek elmulasztása jelentős teljesítménycsökkenéshez vezethet, és leggyakrabban a partíciók sávegység-határokkal való helytelen elosztásának eredménye. Emellett a hardvergyorsítótár nem megfelelő kiosztásához is vezethet, ami a tömbgyorsítótár nem hatékony kihasználtságát eredményezi. A SQL Server adatfájlokhoz használt partíció formázásakor ajánlott 64 KB-os foglalási egységméretet (azaz 65 536 bájtot) használni az adatokhoz, a naplókhoz és a tempdb-hez. Vegye figyelembe azonban, hogy a 4 KB-nál nagyobb foglalási egységméretek használata esetén nem lehet NTFS-tömörítést használni a köteten. Bár a SQL Server támogatja a csak olvasható adatokat a tömörített köteteken, nem ajánlott.

Memória lefoglalása

Megjegyzés

Az ebben a szakaszban található információk nagy része Jonathan Kehayias blogbejegyzéséből származik, mennyi memóriára van szüksége a SQL Server valójában? (sqlskills.com).

A System Center Operations Manager (vagy a terméken kívüli egyéb számítási feladatok) támogatásához nem mindig könnyű azonosítani a megfelelő mennyiségű fizikai memóriát és processzort a SQL Server számára. A termékcsoport által biztosított méretezési kalkulátor útmutatást nyújt a számítási feladatok skálája alapján, de a javaslatok olyan tesztkörnyezetben végzett tesztelésen alapulnak, amely megfelelhet a tényleges számítási feladatnak és konfigurációnak.

SQL Server lehetővé teszi a folyamat által lefoglalt és felhasznált memória minimális és maximális mennyiségének konfigurálását. Az SQL Server alapértelmezés szerint képes dinamikusan, az elérhető rendszererőforrások szerint módosítani memóriaigényét. A minimális kiszolgálómemória alapértelmezett beállítása 0, a maximális kiszolgálómemória alapértelmezett beállítása pedig 2 147 483 647 MB.

A teljesítménnyel és a memóriával kapcsolatos problémák akkor merülhetnek fel, ha nem állít be megfelelő értéket a kiszolgáló maximális memóriájához. Számos tényező befolyásolja, hogy mennyi memóriát kell lefoglalnia a SQL Server annak érdekében, hogy az operációs rendszer támogassa a rendszeren futó egyéb folyamatokat, például a HBA-kártyát, a felügyeleti ügynököket és a vírusirtó valós idejű vizsgálatot. Ha nincs elegendő memória beállítva, az operációs rendszer és az SQL lemezre kerül. Ez a lemez I/O-jének növekedését okozhatja, tovább csökkentve a teljesítményt, és olyan hullámos hatást eredményezhet, amely észrevehetővé válik az Operations Managerben.

Javasoljuk, hogy legalább 4 GB RAM-ot adjon meg a minimális kiszolgálómemória számára. Ezt minden Olyan SQL-csomópont esetében el kell végezni, amely az Operations Manager-adatbázisok egyikét (operatív, adattárház, ACS) üzemelteti.

A maximális kiszolgálómemória esetében azt javasoljuk, hogy először foglaljon le összesen:

• 1 GB RAM az operációs rendszerhez
• 1 GB RAM minden telepített 4 GB RAM-ra (legfeljebb 16 GB RAM)
• 1 GB RAM minden telepített 8 GB RAM-ra (16 GB RAM felett)

Miután beállította ezeket az értékeket, figyelje a Windows Memória\Elérhető MBytes számlálóját annak megállapításához, hogy növelhető-e a SQL Server számára elérhető memória. A Windows azt jelzi, hogy a rendelkezésre álló fizikai memória 96 MB-nál alacsonyan fut, ezért ideális esetben a számlálónak nem szabad 200–300 MB-nál alacsonyabban futnia, hogy biztosan legyen puffere. A 256 GB-os vagy magasabb RAM-mal rendelkező kiszolgálók esetében érdemes gondoskodni arról, hogy az ne fusson 1 GB-nál alacsonyabban.

Ne feledje, hogy ezek a számítások feltételezik, hogy SQL Server szeretné használni az összes rendelkezésre álló memóriát, hacsak nem módosítja őket úgy, hogy más alkalmazásokat is figyelembe vegyenek. Vegye figyelembe az operációs rendszer, más alkalmazások, a SQL Server szálverem és más többoldalas allokátorok memóriakövetelményeit. Egy tipikus képlet a , ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators))ahol a szálverem memóriája = ((max worker threads) (stack size)). A verem mérete 512 KB x86 rendszerekhez, 2 MB x64 rendszerekhez és 4 MB IA64-rendszerekhez, és a maximális munkaszálak értékét a sys.dm_os_sys_info max_worker_count oszlopában találja.

Ezek a szempontok a virtuális gépeken való futtatás SQL Server memóriakövetelményeire is vonatkoznak. Mivel a SQL Server a pufferkészletben lévő adatok gyorsítótárazására szolgál, és általában a lehető legtöbb memóriát fogja használni, nehéz lehet meghatározni a szükséges ram ideális mennyiségét. Amikor csökkenti a SQL Server példány számára lefoglalt memóriát, végül el fog érni egy olyan pontot, ahol az alacsonyabb memóriakiosztást magasabb lemez I/O-hozzáférésre cseréli a rendszer.

Ha túlkiosztott környezetben szeretné konfigurálni SQL Server memóriát, először monitorozza a környezetet és az aktuális teljesítménymetrikákat, beleértve a SQL Server Pufferkezelő várható élettartamát és az oldalolvasások másodpercenkénti számát, valamint a fizikai lemez olvasási/másodperces értékeit. Ha a környezet memóriafelesleggel rendelkezik, a lap várható élettartama másodpercenként egy-egy értékkel nő anélkül, hogy csökkenne a számítási feladat alatt a gyorsítótárazás miatt; a SQL Server Buffer Manager oldalolvasási másodpercenkénti értéke alacsony lesz a gyorsítótár felgyorsulása után, és a fizikai lemez olvasási másodpercenkénti olvasási száma is alacsony marad.

Miután megismerte a környezeti alapkonfigurációt, 1 GB-tal csökkentheti a kiszolgáló maximális memóriáját , majd láthatja, hogy ez milyen hatással van a teljesítményszámlálókra (miután a kezdeti gyorsítótár kiürítése leáll). Ha a metrikák elfogadhatóak maradnak, csökkentse az értéket további 1 GB-tal, majd figyelje újra, majd ismételje meg a műveletet a kívánt módon, amíg meg nem határoz egy ideális konfigurációt.

További információ: Kiszolgáló memóriakonfigurációs beállításai.

A TempDB optimalizálása

A tempdb-adatbázis mérete és fizikai elhelyezése is befolyásolhatja az Operations Manager teljesítményét. Ha például túl alacsony méretet választ a tempdb-nek, minden alkalommal, amikor újraindítja az SQL Server-példányt, a rendszernek automatikusan a számítási feladatokhoz megfelelő méretre kell növelnie a tempdb-t, ami lefoglalja a feldolgozási terhelés egy részét. Az optimális teljesítmény elérése érdekében javasoljuk, hogy éles környezetben használja a következő tempdb-konfigurációt:

• Állítsa az EGYSZERŰ értékre a tempdb helyreállítási modelljét. Ez a modell automatikusan visszaveszi a naplózási helyet, így nem igényel túl sok kapacitást.
• Foglaljon le előzetesen helyet minden tempdb fájlnak. Ehhez állítsa a fájl méretét elég nagy értéket ahhoz, hogy kezelni tudja a környezet jellemző terhelését. Megakadályozza, hogy a tempdb túl gyakran bővül, ami hatással lehet a teljesítményre. A tempdb adatbázist automatikus növekedésre is állíthatja, ezt a funkciót azonban csak a váratlan kivételek által kiváltott lemezterület-növelés esetére javasoljuk.
• Hozzon létre annyi fájlt, amennyire csak szükség van, mivel ezzel maximalizálva a lemezsávszélességet. Több fájl használata csökkenti a tempdb storage versengését, és jobb méretezhetőséget eredményez. Ne hozzon létre azonban túl sok fájlt, mert csökkentheti a teljesítményt és növelheti a felügyeleti terhelést. Hozzon létre egy-egy adatfájlt a kiszolgálón működő összes logikai processzorhoz (vegye figyelembe az affinitásmaszk beállításait), majd szükség esetén csökkentse vagy növelje a fájlok számát. Általános szabály: ha a logikai processzorok száma 8 vagy kevesebb, használjon annyi adatfájlt, ahány logikai processzor van a kiszolgálón. Ha a logikai processzorok száma nagyobb, mint 8, használjon nyolc adatfájlt, majd ha a versengés folytatódik, növelje az adatfájlok számát 4 többszörösével (a logikai processzorok számáig), amíg a versengés elfogadható szintre nem csökken, vagy nem módosítja a számítási feladatot/kódot. Ha a versengés nem csökken, előfordulhat, hogy növelnie kell az adatfájlok számát.
• Minden adatfájlt azonos méretűre kell tenni, ami optimális, arányos kitöltési teljesítményt tesz lehetővé. Kritikus fontosságú, hogy azonos méretű adatfájlokat használjon, mivel az arányos fájlfeltöltési algoritmus a fájlok mérete alapján működik. Ha eltérő méretű adatfájlokat hoz létre, az arányos fájlfeltöltési algoritmus a legnagyobb fájlt próbálja meg használni a GAM-foglalásokhoz, ahelyett, hogy egyenletesen osztaná el a foglalásokat a fájlok között – pedig valójában ez lenne a több adatfájl létrehozásának előnye.
• Helyezze a tempdb-adatbázist egy gyors I/O-alrendszerre, amely a legoptimálisabb teljesítmény érdekében szilárdtest-meghajtókat használ. Ha sok közvetlenül csatlakoztatott lemez van a rendszerben, használjon csíkozást.
• A tempdb adatbázist ne helyezze a felhasználói adatbázisok által használt lemezekre.

A tempdb konfigurálásához futtassa a következő lekérdezést, vagy módosítsa az adatbázis tulajdonságait a Management Studióban.

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

Futtassa a T-SQL-lekérdezést SELECT * from sys.sysprocesses a tempdb-adatbázis oldalfoglalási versengésének észleléséhez. A rendszertábla kimenetében a várakozási erőforrás "2:1:1" (PFS-oldal) vagy "2:1:3" (megosztott globális foglalási térképoldal) néven jelenhet meg. A versengés mértékétől függően ez ahhoz vezethet, hogy az SQL Server rövid ideig nem válaszol. Másik megoldás, ha megvizsgáljuk a dinamikus felügyeleti nézeteket [sys.dm_exec_request vagy sys.dm_os_waiting_tasks]. Az eredmények azt mutatják, hogy ezek a kérések vagy feladatok a tempdb-erőforrásokra várnak, és hasonló értékekkel rendelkeznek, mint korábban a sys.sysprocesses lekérdezés végrehajtásakor.

Ha a korábbi javaslatok nem csökkentik jelentősen a foglalási versengést, és a versengés az SGAM-oldalakon található, implementálja a -T1118 nyomkövetési jelzőt a SQL Server indítási paramétereiben, hogy a nyomkövetési jelző még SQL Server újrafeldolgozása után is érvényben maradjon. A funkciókapcsoló használata esetén az SQL Server teljes egységeket foglal le minden adatbázis-objektumhoz, így megszünteti a versengést az SGAM-lapokért.

Megjegyzés

Ez a nyomkövetési jelző a SQL Server példányában lévő összes adatbázisra hatással van.

Maximális párhuzamossági fok

Az SQL Server alapértelmezett konfigurációja a legtöbb kis- és középvállalkozás számára megfelelő. Ha azonban a felügyeleti csoport számítási feladatai felfelé skálázhatók egy nagyvállalati szintű forgatókönyvre (általában több mint 2000 ügynök által felügyelt rendszer és egy fejlett monitorozási konfiguráció, amely magában foglalja a fejlett szintetikus tranzakciókkal végzett szolgáltatásszintű monitorozást, a hálózati eszközök monitorozását, a platformfüggetlen és így tovább), szükség van a dokumentum jelen szakaszában ismertetett SQL Server konfigurációjának optimalizálására. Az előző útmutatóban nem tárgyalt konfigurációs lehetőségek egyike a MAXDOP.

A Microsoft SQL Server maximális párhuzamossági fok (MAXDOP) beállítása azt szabályozza, hogy a párhuzamos tervekben egyszerre hány processzort használjon a rendszer a lekérdezések végrehajtásához. Ez a beállítás meghatározza, hogy mennyi számítási és szálerőforrást kapjanak a műveleteket párhuzamosan végző lekérdezési tervoperátorok. Attól függően, hogy SQL Server szimmetrikus többprocesszoros (SMP) számítógépen, nem egységes memóriaelérési (NUMA-) számítógépen vagy hyperthreading-kompatibilis processzorokon van-e beállítva, megfelelően kell konfigurálnia a párhuzamosság maximális fokát.

Ha az SQL Server egynél több mikroprocesszort vagy processzort tartalmazó számítógépen működik, képes észlelni a lehető legjobb párhuzamossági fokot, azaz azt, hogy hány processzort érdemes használni egy utasítás lefuttatásához az egyes párhuzamos tervek végrehajtása során. A beállítás alapértelmezett értéke 0, így az SQL Server határozhatja meg, hogy mekkora legyen a párhuzamosság maximális foka.

Az Operations Managerben előre definiált tárolt eljárások és lekérdezések, amelyek az operatív, adattárházi és akár auditadatbázishoz kapcsolódnak, nem tartalmazzák a MAXDOP lehetőséget, mivel a telepítés során nem lehet dinamikusan lekérdezni, hogy hány processzor jelenik meg az operációs rendszer számára, és nem próbálja meg a beállítás értékét meghatározni, ami negatív következményekkel járhat a lekérdezés végrehajtásakor.

Megjegyzés

A párhuzamosság konfigurálásának maximális foka nem korlátozza a SQL Server által használt processzorok számát. Az SQL Server által elérhető processzorok számának beállításához használja az affinitásmaszk konfigurációs lehetőséget.

• A nyolcnál több processzort tartalmazó kiszolgálóknál használja a MAXDOP=8 konfigurációt.
• Nyolc vagy kevesebb processzort használó kiszolgálók esetében használja a következő konfigurációt: MAXDOP=0–N

  Megjegyzés

  Ebben a konfigurációban az N a processzorok számát jelöli.