Table of contents
TOC
Tartalomjegyzék összecsukása
Tartalomjegyzék kibontása

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

Matt Goedtel|Utoljára frissítve:: 2017. 03. 02.
|
1 Közreműködő

A következőkre vonatkozik: System Center 2016 – Operations Manager

A System Center 2016 – Operations Manager működéséhez szükséges egy, az operatív, adattárház- és ACS-naplózási adatbázist futtató, a Microsoft SQL Server 2012, 2014 vagy az SQL Server 2016 verziót futtató kiszolgálópéldány. 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.

Az SQL Server rendszerre vonatkozó követelmények

Az Operations Manager új vagy meglévő telepített példányai az SQL Server alábbi verzióit támogatják.

ÖsszetevőSQL Server 2012, SP3 Enterprise/Standard (x64)SQL Server 2014, SP2 Enterprise/Standard (x64)SQL Server 2016 Enterprise/Standard (x64)
Az Operations Manager operatív adatbázisaigenigenigen
Az Operations Manager adatraktár-adatbázisaigenigenigen
Az Operations Manager ACS-adatbázisaigenigenigen
Az Operations Manager jelentéskészítő kiszolgálójaigenigenigen
Megjegyzés

A System Center 2016 – Operations Manager adatbázisainak az SQL Server ugyanazon verzióját kell használniuk, az SQL Server-rendezés beállításánál az adott szakaszban ismertetett alábbi támogatási típusoknak kell szerepelniük, és az SQL Server teljes szöveges keresési funkciójának használata is kötelező mind az operatív, mind az adattárház-adatbázisban. Az, hogy az Operation Manager adatbázis-összetevői a Windows Server 2016 mely telepítési lehetőségeit (Server Core, kiszolgáló asztali kezelőfelülettel és Nano Server) támogatják, azon alapulnak, hogy az SQL Server a Windows Server mely telepítési lehetőségeit támogatja.

Megjegyzés

A System Center 2016 – Operations Manager jelentéskészítőt nem lehet a System Center Operations Manager 2012 R2 jelentéskészítő mellé telepíteni. A jelentéskészítő kizárólag natív módban telepíthető. (A SharePoint-integrált 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 az SQL Server 2012-t, 2014-et és 2016-ot NTFS fájlrendszert használó számítógépeken futtassa.
  • Az operatív és az adatraktár-adatbázis legalább 1024 MB szabad helyet igényel. A rendszer az adatbázis létrehozásakor ellenőrzi, hogy van-e megfelelő mennyiségű szabad kapacitás. A telepítés után az adatbázis mérete várhatóan jelentősen meg fog nőni.
  • A .NET-keretrendszer 4-es verziója is szükséges.
  • A Jelentéskészítő kiszolgáló Windows Server Core telepítésen nem támogatott.

További információkért lásd: Hardware and Software Requirements for Installing SQL Server 2014 (Az SQL Server 2014 telepítési hardver- és szoftverkövetelményei) és Hardware and Software Requirements for Installing SQL Server 2016 (Az SQL Server 2016 telepítési hardver- és szoftverkövetelményei).

Megjegyzés

Az operatív adatbázis telepítésekor csak Windows-hitelesítést használjon az Operations Manager operatív adatbázisát tároló SQL-kiszolgálón. Ne használjon mixed (vegyes) módot (Windows-hitelesítés és SQL Server-hitelesítés), mert hibák léphetnek fel, ha az operatív adatbázis telepítésekor engedélyezve van az SQL Server-hitelesítés. Az Operations Manager operatív adatbázisát tároló SQL Server-kiszolgálón lehetőség van ugyan a mixed (vegyes) mód bekapcsolására, ez a megoldás nem támogatott, mert az adatbázissal létesített összes kapcsolat kizárólag Windows-fiókot használ.

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

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

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

Vegye figyelembe, hogy ha az SQL Server példánya nincs konfigurálva a fenti támogatott rendezések valamelyikével, az Operations Manager új telepítése meghiúsul. 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ó, az Operatív konzol és a Webkonzol szerepköröknek kommunikálniuk kell az SQL Serverrel. A környezet megfelelő beállításához elengedhetetlen, hogy tisztában legyen ennek a kommunikációnak az útvonalával és a hozzá tartozó portokkal.

Ha olyan elosztott rendszert konfigurál, amelyben SQL AlwaysOn rendelkezésre állási csoportok biztosítják az Operations Manager-adatbázisok feladatátvételét, a tűzfal biztonsági beállításaiban további konfigurációs lépéseket is el kell végeznie.

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.

ForgatókönyvPortIrányOperations Manager-szerepkör
Az Operations Manager adatbázisait futtató SQL ServerTCP 1433*Bejövőfelügyeleti kiszolgáló és webkonzol (az Application Advisorhoz és az Application Diagnosticshoz)
SQL Server Browser szolgáltatásUDP 1434BejövőManagement kiszolgáló
SQL Server dedikált rendszergazdai kapcsolataTCP 1434BejövőManagement kiszolgáló
SQL Server AlwaysOn rendelkezésre állási csoport figyelőjeA rendszergazda által beállított portBejövőManagement kiszolgáló
Az Operations Manager jelentéskészítő kiszolgálót futtató SQL Server Reporting ServicesTCP 80 (alapértelmezés)/443 (SSL)Bejövőfelügyeleti kiszolgáló és operatív konzol

*Az adatbázismotor alapértelmezett példányának szabványos portja a TCP 1433, ha azonban nevesített példányt hoz létre egy különálló SQL Serveren, vagy SQL AlwaysOn rendelkezésre állási csoportot helyezett üzembe, meg kell határoznia egy egyéni portot. Ezt érdemes feljegyezni, hogy később, a tűzfal konfigurálása során meg tudja adni.

Az SQL Server tűzfalakra vonatkozó követelményeiről további információkat talál a Configure the Windows Firewall to Allow SQL Server Access (A Windows Tűzfal beállítása az SQL Server hozzáférésének engedélyezésére) című cikkben.

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.

Operations Manager adatraktár-adatbázis

A System Center 2016 – Operations Manager közel valós időben helyezi el az adatokat a jelentéskészítési célú adattárházban, ezért fontos, hogy az összegyűjtött adatok adattárházba való írását támogató kiszolgáló megfelelő kapacitással rendelkezzen. 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 esetben a jelentéskészítési célú adattárházra hasonló mértékű terhelés nehezedik, mint az Operations Manager-adatbázisra, de ez nincs kőbe vésve. 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.

Ezeket figyelembe véve több gyakorlati tanáccsal is szolgálhatunk a jelentéskészítési célú adattárház méretezésére vonatkozóan:

  • Válasszon megfelelő tárolóalrendszert. Mivel a jelentéskészítési célú adattárház fontos szerepet játszik az adatoknak a felügyeleti csoporton való áthaladásában, rendkívül fontos, hogy jól válassza meg a jelentéskészítési célú adattárház tárolóalrendszerét. 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. Ahogy az Operations Manager-adatbázisnál, az ügynökök számának emelése esetében itt is érdemes lehet külön elhelyezni az SQL adat- és tranzakciónaplóit. 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 célú adattárház adatfájljait ugyanarra a fizikai kötetre is helyezheti, ha a köteten elegendő szabad hely áll rendelkezésre, és a lemezek I/O-teljesítménye megfelelő a figyelési és jelentéskészítési funkciókhoz.
  • 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. A kisebb léptékű rendszerekben általában ugyanazon a kiszolgálón is futhat az Operations Manager-adatbázis és a jelentéskészítési célú adattárház. Ha azonban nagyobb számú ügynököt telepít, és a bejövő operatív adatok mennyisége is nő, érdemes elkülöníteni ezt a két összetevőt, mivel a rendszer jobb teljesítményt nyújt, ha a jelentéskészítési célú adattárház és a jelentéskészítési kiszolgáló az Operations Manager-adatbázistól eltérő kiszolgálón található.

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ó.

Javasoljuk, hogy ha magas rendelkezésre állást szeretne biztosítani a System Center 2016 – Operations Manager adatbázisainak, feladatátvételi fürtözés helyett inkább az SQL AlwaysOn funkciót használja. 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.

A rendelkezésre állási csoportok beállításához telepítenie kell egy Windows Server feladatátvételi fürtszolgáltatási (Windows Server Failover Clustering – WSFC) fürtöt a rendelkezésre állási replika működtetésére, és engedélyeznie kell az AlwaysOn szolgáltatást a fürtcsomópontokon. Ezután hozzáadhatja az Operations Manager SQL Server-adatbázist rendelkezésre állási adatbázisként.

Az SQL Server optimalizálása

Az ügyfelek múltbéli tapasztalatai alapján általánosságban elmondható, hogy a teljesítménnyel kapcsolatos problémákat általában nem az SQL Server nagy mértékű erőforrás-felhasználása (azaz processzor- vagy memória-igénybevétele) okozza, hanem a tárolóalrendszer nem megfelelő beállítása. A leggyakoribb eset, hogy a felhasználók nem követik az SQL Server-adatbázispéldányhoz társított tárhelyre vonatkozó konfigurációs előírásokat.
Példá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. Ennek a két feladatnak nagy mértékben eltérőek az I/O- és a késési jellemzői.
  • A TempDB elhelyezése, mérete, illetve más beállításai nem megfelelőek.
  • Hibás az adatbázisok tranzakciónaplóit, fájljait, valamint a TempDB-t tartalmazó kötetek lemezpartícióinak illesztése.
  • Nem vették figyelembe az SQL Server alapvető konfigurációs szabályait: például nem megfelelően az automatikus növekedés funkciót használják az adatbázis és a tranzakciónaplók fájljaihoz, vagy a lekérdezések párhuzamosságához a MAXDOP beállítást, esetleg processzormagonként több TempDB-adatfájlt hoztak létre és így tovább.

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-működését általában 80% írás és 20% olvasás teszi ki. Ezért az I/O-tárolóalrendszerek nem megfelelő konfigurációja az SQL Server-rendszerek gyenge teljesítményét okozhatja, ez pedig észrevehetően csökkenti az Operations Manager sebességét is.

Rendkívül fontos, hogy az SQL Server üzembe helyezése előtt az I/O-alrendszer átviteli sebességének ellenőrzésével tesztelje az SQL Server kialakítását. A teszt segítségével megállapíthatja, hogy a környezet képes-e elfogadható késés mellett teljesíteni az I/O-követelményeket. Az SQLIO lemezalrendszer-tesztelési eszköz segítségével állapítsa meg az SQL Server mögött álló tárolóalrendszer I/O-kapacitását. Az alábbi blogbejegyzést a termékcsoport fájlrendszerekkel foglalkozó csapata írta; ebben részletes utasításokat és javaslatokat talál arra vonatkozóan, hogy hogyan végezze el az alrendszer stressztesztelését a fenti eszköz és egy kevés PowerShell-kódolás segítségével, valamint, hogy hogyan rögzítse az eredményeket a PerfMon használatával. A kezdeti beállítások elvégzésében az Operations Manager méretezési segédje is segítséget nyújthat.

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). Ha ezt nem teszi meg, előfordulhat, hogy a partíciók és a sávegységek határai nem fognak illeszkedni, ami jelentős teljesítménycsökkenéshez vezethet. A művelet elmulasztása a hardveres gyorsítótár hibás illesztését is okozhatja, ami a tömb gyorsítótárának nem megfelelő kihasználásával jár. Az SQL Server adatfájljainak tárolására használni kívánt partíció formázásakor javasoljuk, hogy az adatokhoz, naplókhoz és a tempdbhez a 64 KB-os, azaz 65 536 bájtos foglalásiegység-méretet használja. Ne feledje azonban, hogy a 4 KB feletti foglalásiegység-méretek használata azzal jár, hogy a köteten nem lehet NTFS-tömörítést használni. Az SQL Server ugyan támogatja a csak olvasható adatok tömörített köteteken való tárolását, de ezt nem javasoljuk.

Memória lefoglalása

Nem egyszerű feladat eldönteni, hogy pontosan mennyi fizikai memóriát és processzoridőt érdemes lefoglalni a Windows-kiszolgálón a System Center 2016 – Operations Managert támogató SQL Server 2014 vagy 2016 számára (ez persze más termékek esetében is így van). A termékcsoportban elérhető méretezési számológép a várható terhelést (azaz 500 rendszer, 1000 rendszer és így tovább) figyelembe véve ellátja Önt javaslatokkal, ezek azonban laborkörnyezetben végzett teszteken alapulnak, így közel sem biztos, hogy megfelelnek a való életben jellemző számítási feladatok és konfigurációk követelményeinek. Ezek a számok kiindulópontként szolgálnak, de a végső konfiguráció meghatározására nem alkalmasak.

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ói memóriaérték alapértelmezés szerint 0, a maximális kiszolgálói memóriaérték pedig 2147483647. A maximális kiszolgálói memóriaértékhez beállítható minimális memóriamennyiség 16 megabájt (MB). Gyakran az okozza a teljesítménnyel és memóriával kapcsolatos problémákat, hogy az ügyfél nem állította be a maximális kiszolgálói memóriaértéket, valószínűleg azért, mert nincs tisztában vele, hogy mi a megfelelő konfiguráció. Számos tényezőt figyelembe kell venni, hogy pontosan meghatározzuk, hogy mi az a maximális memóriamennyiség, amelyet még lefoglalhatunk az SQL számára, úgy, hogy az operációs rendszernek is elegendő memóriát hagyjunk a rendszeren futó többi folyamat (például gazdabuszadapter, felügyeleti ügynökök, valós idejű víruskeresés és így tovább) elvégzéséhez. Ellenkező esetben az operációs rendszer és az SQL működése növeli az I/O-felhasználást, így a teljesítménycsökkenés addig gyűrűzik, amíg már az Operations Managerben is érzékelhető lesz.

Az SQL Server ezért lehetővé teszi, hogy a felhasználó konfigurálja a folyamatai által minimálisan és maximálisan felhasználható memória mennyiségét. Javasoljuk, hogy állítson be legalább 4 GB RAM memóriát. Ezt tegye meg minden olyan SQL-csomóponton, amely valamelyik Operations Manager-adatbázist (operatív, adatraktár és így tovább) futtatja.

Javasoljuk, hogy első lépésként foglaljon le 1 GB-ot az operációs rendszernek, a 4 és 16 GB közötti memória esetén 4 GB-onként foglaljon le 1 GB RAM memóriát, 16 GB felett pedig minden 8 GB után újabb 1 GB memóriát. Ezt követően figyelje a Windows Memória\Rendelkezésre álló memória (MB) teljesítménymutatóját, és állapítsa meg, hogy lehet-e növelni az SQL Server számára kiosztott memória mennyiségét. (Megjegyzés: a számlálónak legalább a 150–300 MB közötti sávban kell lennie. A Windows a 96 MB-os értéknél megjeleníti a LowMemoryResourceNotification értesítést, így érdemes puffert is alkalmazni. A nagyobb, 256 GB vagy több RAM memóriával ellátott kiszolgálóknál az értéket érdemes 1 GB fölött tartani). Ez általában jó megoldás a dedikált SQL Server kiszolgálóként működő gépek esetében. Ennél jóval részletesebb módon is meghatározhatja a maximális kiszolgálói memória értékét, ha kiszámolja az operációs rendszer, az alkalmazások, valamint az SQL Server szálverem és a többi többlapos memóriafoglaló memóriaigényeit. Ennek képlete általában a következő: ((teljes rendszermemória) – (szálverem memóriaigénye) – (operációs rendszer memóriaigénye, kb. 2–4 GB) – (alkalmazások memóriaigénye) – (a többlapos memóriafoglalások, az SQLCLR, csatolt külső kiszolgálók stb. memóriaigénye)). A szálverem memóriaigénye = ((munkaszálak maximális száma)*(verem mérete)), és a verem mérete x86 rendszereken 512 KB, x64 típusú rendszereken 2 MB, IA64 rendszereken pedig 4 MB. A munkaszálak maximális értékét a sys.dm_os_sys_info fájl max_worker_count oszlopában találja. Fontos azonban leszögezni, hogy az alapvetés mindkét módszernél a következő: azt szeretnénk, hogy az SQL Server a gépen elérhető összes erőforrás felett rendelkezhessen, kivéve, ha más alkalmazásoknak is le kíván foglalni a memóriából.

Mivel egyre több ügyfél dönt az SQL Server virtualizálása mellett, relevánsabb kérdés, hogy legkevesebb mennyi memóriára van szükség ahhoz, hogy az SQL Server megfelelően fusson a virtuális gépen. Sajnos azt, hogy az egyes SQL Server-példányokhoz pontosan mennyi memória szükséges, nem lehet kiszámítani, mivel az SQL Server a pufferkészletben gyorsítótárazza az adatokat, így általában az összes memóriát felhasználja, amit a felhasználó lefoglal számára. Az SQL Server-példánynak lefoglalt memória csökkentésével kapcsolatban érdemes észben tartani, hogy előbb-utóbb elérkezik a pont, amikor a memóriacsökkentés a lemez I/O-elérési terhelésének növekedéséhez fog vezetni.

Ha egy, a szükségesnél több erőforrással ellátott környezetben igyekszik megtalálni az SQL Server megfelelő memóriakonfigurációját, a legjobb módszer, ha a környezet alapértékeivel, valamint az aktuális teljesítménymutatókkal kezdi a tervezést. A következő számlálókat érdemes figyelni:

  • SQL Server:Buffer Manager\Page Life Expectancy (Pufferkezelő\Lap várható élettartama)
  • SQL Server:Buffer Manager\Page reads/sec (Pufferkezelő\Lapolvasások másodpercenkénti száma)
  • Physical Disk\Disk Reads/sec (Fizikai lemez\Lemezolvasások másodpercenkénti száma)

Ha a környezetben a szükségesnél több memória áll a pufferkészlet rendelkezésére, a Page Life Expectancy (Lapok várható élettartama) számláló értéke folyamatosan, másodpercenként egyel nő, és terhelés esetén sem csökken, mivel a rendszer az összes adatlapot gyorsítótárazza. Ugyanakkor az SQL Server:Buffer Manager\Page reads/sec (Pufferkezelő\Lapolvasások másodpercenkénti száma) számláló értéke alacsonyabb lesz a gyorsítótárazás után, ami a Physical Disk\Disk Reads/sec (Fizikai lemez\Lemezolvasások másodpercenkénti száma) alacsony értékével is összefügg.

Ha megkapta a környezetre vonatkozó alapértékeket, módosítsa az sp_configure „max server memory” (maximális kiszolgálói memória) beállítását, és csökkentse 1 GB-tal a pufferkészlet méretét. Várja meg, hogy a rendszer stabilizálódjon a RECONFIGURE parancs kiadása utáni gyorsítótár-ürítés után, és figyelje meg, hogy a módosítás milyen hatást gyakorol a teljesítménymutatókra. Ha a Page Life Expectancy (Lapok várható élettartama) elfogadható szinten marad (ne feledje, hogy nagy mennyiségű RAM memóriával ellátott kiszolgálók esetében nem reális a >= 300 érték), és az SQL Server:Buffer Manager\Page reads/sec (Pufferkezelő\Lapolvasások másodpercenkénti száma) értéke is olyan, amit a lemez I/O-alrendszere a teljesítmény csökkenése nélkül támogatni tud, csökkentse újabb 1 GB-tal az sp_configure „max server memory” (maximális kiszolgálói memória) értékét, és figyelje meg, hogy ez milyen hatást gyakorol a környezetre.

Érdemes elolvasni az MSDN-en az SQL 2014-hez elérhető útmutatást.

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. Így a tempdb ritkábban fog növekedni, ami pozitívan befolyásolja a teljesítményt. 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. Ha több fájlt használ, csökken a tempdb-tárhelyért való versengés mértéke, és így a rendszer is könnyebben méretezhető. Ne hozzon létre azonban túl sok fájlt sem, mivel ez rontja a teljesítményt, és növeli a felügyelethez szükséges munkaterhelé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, hozzon létre 8 adatfájlt, és ha így is versengés tapasztalható, növelje addig a 4 többszöröseivel az adatfájlok számát, amíg a versengés elfogadható szintre nem csökken (de a logikai processzorok számát ne lépje túl), esetleg módosítsa a számítási feladatokat vagy a kódot. Ha nem csökken a versengés, elképzelhető, hogy még több adatfájlt kell létrehoznia.
  • Legyen az összes adatfájl azonos méretű, így optimális arányos fájlfeltöltési teljesítmény érhető el. 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.
  • A legjobb teljesítmény érdekében helyezze gyors, SSD-meghajtókat tartalmazó I/O-alrendszerre a tempdb adatbázist. 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 sys.sysprocesses alatti SELECT * T-SQL-lekérdezést, amely észleli az lapfoglalási versengést a tempdb adatbázisért. A rendszertábla kimenetében a waitresource paraméternél a „2:1:1” (PFS lap) vagy a „2:1:3” (SGAM lap) érték szerepelhet. 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ényekből kiderül, hogy ezek a kérések vagy feladatok tempdb-erőforrásokra várnak. Értékük hasonló lesz ahhoz, amit korábban, a sys.sysprocesses lekérdezés futtatásakor kiemeltünk.
Ha a fenti javaslatok nem csökkentik jelentősen a foglalási versengést, és az SGAM-lapokért tapasztalható versengés, vegye fel a -T1118 funkciókapcsolót az SQL Server indítási paraméterei közé, hogy a kapcsoló az SQL Server újraindítá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. Vegye figyelembe, hogy ez a funkciókapcsoló az SQL Server-példány összes adatbázisára érvényes lesz.

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ő. Az SQL Server konfigurációját azonban érdemes optimalizálni, ha a felügyeleti csoport terhelése eléri a nagyvállalati szintet (ezt általában akkor mondjuk, ha a környezethez több mint 2000 ügynök által felügyelt rendszer tartozik, illetve összetett, szolgáltatásszintű figyelést és speciális szintetikus tranzakciókat, több platformon megvalósított eszközfigyelést stb. alkalmaznak). Ebben a részben erről olvashat további információkat. A korábbi útmutatókban nem esett szó a MAXDOP konfigurációs lehetőségről.

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. A maximális párhuzamossági fokot aszerint kell beállítani, hogy az SQL Servert szimmetrikus többprocesszoros feldolgozást (SMP) vagy nem egységes memóriaelérést (NUMA) alkalmazó számítógépen, esetleg hiperszálkezelésre képes processzorokon futtatja.
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 tárolt, az operatív, adatraktár- és naplózási adatbázishoz kapcsolódó tárolt eljárások és lekérdezések nem tartalmazzák a MAXDOP beállítást, mivel a telepítés során nincs mód rá, hogy a program dinamikusan lekérdezze, hogy az operációs rendszer hány processzort ér el. A telepítő emellett rögzített értéket sem társít ehhez a paraméterhez, mivel ez negatív hatással lehet a rendszerre, amikor lefuttatja a lekérdezést.

Megjegyzés

A maximális párhuzamossági fok beállítása nem korlátozza az SQL Server által igénybe vehető 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.
  • A nyolc vagy kevesebb processzort tartalmazó kiszolgálók esetében használja a MAXDOP=0-tól N-ig konfigurációt. Megjegyzés: itt az „N” a processzorok számát képviseli.
  • A NUMA-val konfigurált kiszolgálóknál a MAXDOP értéke ne lépje túl az egyes NUMA-csomópontokhoz rendelt processzorok számát.
  • A hiperszálkezeléssel konfigurált kiszolgálóknál a MAXDOP értéke ne lépje túl a fizikai processzorok számát.
  • A NUMA-val és hiperszálkezeléssel konfigurált kiszolgálóknál a MAXDOP értéke ne lépje túl a NUMA-csomópontonként használt fizikai processzorok számát.

A párhuzamos feldolgozófolyamatok számát a sys.dm_os_tasks lekérdezéssel ellenőrizheti.
Egyik ügyfelünk az operatív adatbázist működtető SQL Server-példány kiszolgálójának jelentős teljesítménycsökkenéséről számolt be Operations Manager 2012-vel működő környezetben, amely több adatközpont-infrastruktúra terhelését figyelte ötezer windowsos ügynök által felügyelt rendszeren. A kiszolgáló hardveres konfigurációja: HP Blade G6 24 processzormaggal és 196 GB RAM memóriával. Az Operations Manager-adatbázist működtető példány MAXMEM beállítása 64 GB volt. Az itt leírt optimalizálási műveletek elvégzésével javult a teljesítmény, de a lekérdezések párhuzamossága továbbra is lassította a rendszert. Az ügyfél több beállítást is kipróbált, de a legjobb teljesítményt a MAXDOP=4 értékkel tudta elérni.

Az adatbázis kezdeti méretezése

Az Operations Manager-adatbázisok, különösen az operatív és az adatraktár-adatbázisok jövőbeni növekedésének mértékét a működés első néhány hónapjában nem egyszerű előre látni. Az Operations Manager méretezési segédje ugyan ellátja a felhasználót egy viszonylag használható becsléssel (amely a termékcsoport által a laborban végzett teszteken alapul), ez azonban számos olyan tényezőt nem vesz figyelembe, amely rövid és hosszú távon egyaránt hatással lehet a növekedés mértékére.

Javasoljuk, hogy a kezdeti beállítás során használja a méretezési segéd által javasolt értéket, mivel így elkerülheti a töredezettség kialakulását, és az ezzel járó pluszmunkát. Ezt az értéket az operatív és az adatraktár-adatbázisok telepítésekor lehet megadni. Ha telepítéskor nem áll rendelkezésre elegendő tárhely, az adatbázisok mérete később az SQL Management Studio segítségével is növelhető. Ezt követően érdemes elvégezni az adatbázisok újraindexelését, mivel ez hozzájárul a töredezettségmentesítéshez, és így az optimalizációhoz. Ez a javaslat az ACS-adatbázisra is érvényes.

Érdemes naponta vagy hetente proaktívan ellenőrizni az operatív és az adatraktár-adatbázis növekedését. Ezzel könnyen észlelheti, ha az adatbázisok váratlanul jelentős növekedést produkálnak, így megkezdheti a hibaelhárítást, és megállapíthatja, hogy a jelenséget a felügyeleti csomag munkafolyamatának (felderítési szabályok, teljesítménnyel kapcsolatos vagy eseménygyűjtési szabályok, figyelési vagy riasztási szabályok) hibája, vagy más, a kibocsátáskezelési folyamat tesztelési és minőség-ellenőrzési fázisában nem észlelt probléma okozza.

Az adatbázisok automatikus növekedése

Az SQL Server képes automatikusan, adott százalékkal vagy konkrét értékkel növelni az adatbázisfájlok méretét, amikor az adatbázis kitölti a számára a lemezen lefoglalt méretet. Ezenfelül beállíthatja az adatbázis maximális méretét is, hogy az ne foglalhassa el a lemez teljes kapacitását. Alapértelmezés szerint az Operations Manager-adatbázisnál nincs engedélyezve az automatikus növekedés, csak az adatraktár- és az ACS-adatbázisnál.

Javasoljuk, hogy az automatikus növekedés funkciót csak váratlan növekedés esetén, vészhelyzeti megoldásként alkalmazza. A nagy mértékben tranzakciós adatbázisok esetében érdemes figyelembe venni, hogy az automatikus növekedés használata teljesítménycsökkenéssel jár. A teljesítménycsökkenés például a következőkben nyilvánul meg:

  • Ha nem ad meg megfelelő növekedési lépést, a naplófájl vagy az adatbázis töredezetté válhat.
  • Ha egy tranzakcióhoz nincs elég naplózási hely, és bekapcsolta az adatbázis tranzakciónaplójának automatikus növelését, a tranzakció időtartamába bele fog számítani a tranzakciónapló beállított értékkel való növeléséhez szükséges idő is.
  • Ha olyan nagy tranzakciót indít, hogy a rendszernek meg kell növelnie a naplót, a tranzakciónapló írását igénylő többi tranzakciónak is meg kell várnia, hogy a növekedési művelet befejeződjön.

Az automatikus növekedési és az automatikus csökkentési funkciók együttes használata felesleges többletterheléshez vezethet. Úgy válassza meg a növekedési és csökkentési műveleteket kiváltó határértékeket, hogy ne eredményezzenek gyakori méretmódosítást. Példa: elindít egy tranzakciót, amelynek lefutásához a rendszer 100 MB-tal megnöveli a tranzakciónaplót. Ezt követően kevéssel elindul az automatikus csökkentés, amely 100 MB-tal lecsökkenti a tranzakciónaplót. Ezután ismét lefuttatja az előző tranzakciót: a tranzakciónapló mérete újra 100 MB-tal nő. Ebben az esetben a funkció felesleges többletterhelést okoz, és a naplófájl töredezettségének potenciális kialakuláshoz vezet. Mindkét eset negatívan befolyásolja a teljesítményt.

Legyen nagyon körültekintő, amikor beállítja ezt a két lehetőséget. A megfelelő konfigurációt mindig az Ön konkrét környezete határozza meg. Általánosságban elmondható, hogy a lemeztöredezettség elkerülése érdekében érdemes fix értékkel növelni az adatbázis méretét. Nézze meg például az alábbi ábrát, amelyen az a beállítás látható, hogy az adatbázis minden automatikus növekedési művelet során 1024 MB-tal nőjön.

Fürt-feladatátvételi szabályzatok

A Windows Server feladatátvételi fürtszolgáltatás egy magas rendelkezésre állást biztosító platform, amely folyamatosan figyeli a hálózati kapcsolatokat, valamint a fürthöz tartozó csomópontok állapotát. Ha egy csomópont nem érhető el a hálózaton keresztül, a rendszer helyreállítási műveleteket indít el, és áthelyezi az alkalmazásokat és a szolgáltatásokat a fürt egy másik csomópontjára. Az alapértelmezett beállításokat arra az esetre vannak optimalizálva, ha egy kiszolgáló teljesen kiesik. Ez általában helyreállíthatatlan hibát, például egy nem redundáns hardverelem meghibásodását, vagy a tápellátás elvesztését jelent. A feladatátvételi fürtszolgáltatás célja, hogy minél gyorsabban észlelje, ha a kiszolgáló meghibásodik, és helyreállítsa a szolgáltatásokat a fürt egy másik kiszolgálóján. A súlyos hibák utáni gyors helyreállítást a szolgáltatás úgy éri el, hogy alapértelmezés szerint viszonylag agresszív fürtállapot-figyelési megoldásokat alkalmaz. Ezek a funkciók azonban teljes mértékben konfigurálhatók, így más típusú forgatókönyvekre is optimalizálhatja a rendszer működését.

A legtöbb ügyfél számára az alapértelmezett beállítások jelentik a legjobb megoldást. Ma azonban, amikor a fürtök gyakran nem néhány centiméteres, hanem akár több kilométeres távolságra is vannak egymástól, előfordul, hogy működésüket a csomópontok közötti más nem megbízható hálózati összetevők is veszélyeztetik. A másik tényező, hogy a kereskedelmi forgalomban kapható kiszolgálók egyre megbízhatóbbá válnak, és egyre több hibatűrési, redundanciát biztosító összetevő (például kettős tápegységek, hálózatiadapter-összevonás, többutas I/O) lát napvilágot, így viszonylag ritkán fordul elő, hogy egy nem redundáns hardver meghibásodik. Mivel ritkábbak a kritikus hibák, egyes ügyfelek érdemesnek találhatják, hogy inkább az átmeneti hibák (például a csomópontok közötti hálózati kapcsolat ideiglenes megszakadásának) kivédésére hangolják a fürtöt. Az alapértelmezett hibakorlátok növelésével csökkentheti a rendszer érzékenységét a rövid ideig tartó hálózati problémákra.

Fontos megérteni, hogy itt nincs egyetlen helyes válasz, az optimális beállításokat a felhasználó üzleti igényei, valamint a szolgáltatásiszint-szerződések is határozzák meg.

Az SQL Server virtualizálása

Virtuális környezetekben a megfelelő teljesítmény biztosítása érdekében javasoljuk, hogy az operatív adatbázist és az adatraktár-adatbázist közvetlenül csatlakoztatott tárolóeszközre, és ne virtuális lemezre helyezze. A szükséges IOPS-érték meghatározásához használja az Operations Manager méretezési segédjét, és az értéket stressztesztek végrehajtásával is ellenőrizze. Ehhez a feladathoz az SQLIO eszközt is igénybe veheti. Az Operations Manager virtualizált környezetben való használatával kapcsolatos további információkért olvassa el A virtualizáció támogatása az Operations Manager programban című cikket.

Az AlwaysOn és a helyreállítási modell

Nem járul hozzá ugyan az optimalizációhoz, de fontos megemlíteni, hogy az AlwaysOn rendelkezési állási csoportok használatához az adatbázisoknak a „Teljes” helyreállítási modellt kell használniuk. Ez azt jelenti, hogy a tranzakciónaplókat csak akkor törli a rendszer, ha teljes biztonsági mentés készül, vagy elkészül a tranzakciós napló biztonsági másolata. Ezért biztonsági mentési stratégiát kialakítani nem csupán lehetőség, hanem kötelező része az Operations Manager-adatbázisok AlwaysOn-megoldás alá vonásának. Ellenkező esetben a tranzakciónaplókat tároló lemezek idővel meg fognak telni.

A biztonsági mentési stratégia létrehozása során vegye figyelembe a környezet sajátosságait. Az alábbi táblázatban egy jellemző biztonsági mentési ütemezést mutatunk be.

Biztonsági mentés típusaÜtemezés
Csak a tranzakciónaplóÓránként
TeljesHetente, minden vasárnap 3:00 órakor

Az SQL Server Reporting Services optimalizálása

A Reporting Services-példány az adatraktár-adatbázisban tárolt adatok elérésére szolgáló proxyként működik. A példány a felügyeleti csomagokban tárolt sablonok alapján hozza létre, illetve jeleníti meg a jelentéseket.

A Reporting Services mögött egy SQL Server-adatbázispéldány fut, amely működteti a ReportServer és a ReportServerTempDB adatbázisokat. A példány optimális teljesítményének beállításához használja az erre vonatkozó általános útmutatást.

© 2017 Microsoft