Optimális szervezés az SQL tárolóban tárolt adattárolás, ablakok pro
Kétségtelen, hogy az adattárház az egyik fő összetevő, amely meghatározza az SQL Server nagy és kis példányainak teljesítményét és elérhetőségét. A szerverek és a virtuális szerverek növekvő számítási teljesítménye és a térfogati memória támogatása ellenére az adattárolók és az I / O alrendszer olyan szűk keresztmetszetek lehetnek, amelyek csökkentik az átfogó teljesítményt
ARUBA INSTANT WI-FI: EGYSZERŰ, KIADHATÓ, ELÉRHETŐ
Biztosítsa az adattárházak elérhetőségét és teljesítményét
Kétségtelen, hogy az adattárház az egyik fő összetevő, amely meghatározza az SQL Server nagy és kis példányainak teljesítményét és elérhetőségét. A kiszolgálók és a virtuális kiszolgálók megnövekedett számítási teljesítményének és a térfogati memória támogatásának ellenére az adattárolók és az I / O alrendszer olyan szűk keresztmetszetek lehetnek, amelyek csökkentik az átfogó teljesítményt. A problémákat elkerülheti, ha általános fogalma van arról, hogy az SQL Server hogyan használja az adattárházakat, és ismeri az SQL Server tárolási rendszerének optimalizálására szolgáló alapvető technikákat.
Adatok és naplófájlok
Az SQL Server adatraktárakkal végzett munka alapja, hogy az adatbázisok kétféle fájlt tartalmaznak:
- Adatfájlok. Ezek a fájlok tárolják az adatbázis információkat. Az SQL Server adatfájlok kiterjesztésű NTFS fájlok. MDF. A legegyszerűbb adatbázis általában egy adatfájlt tartalmaz, de több adatfájlból állhat egy vagy több lemezen.
- Naplófájlok. Ezek a fájlok tárolják az adatbázis-tranzakciókat, amelyek lehetővé teszik az adatbázis helyreállítását egy bizonyos időpontban. Az SQL Server tranzakciós naplófájljai a kiterjesztéssel rendelkező NTFS fájlok. ldf. Az adatbázisban sok naplófájl található egy vagy több lemezen.
Javasoljuk, hogy adatokat és naplófájlokat helyezzen el a különböző lemezekre. Az SQL Server minden adatbázis-tranzakciót a tranzakciós naplóba ír, így a naplófájlok kényelmesen megtalálhatók a nagysebességű lemezeken. Az adatfájlokat a kérések szolgáltatására használják, és gyakran sok olvasási műveletet kell végrehajtaniuk. Adatbázis létrehozásakor megadhatja az adatok és a naplófájlok helyét a T-SQL CREATE DATABASE parancs használatával. A meglévő adatfájlok és naplók helyének megváltoztatásához futtassa az ALTER DATABASE parancsot a MODIFY FILE paraméterrel. Az 1. lista példát mutat egy adatbázis adatfájl másik helyre történő áthelyezésére.
Nem mindenki egyetért azzal az ajánlással, hogy engedélyezze az AutoGrow módot az SQL Server adatbázisokhoz. Ha engedélyezi ezt a funkciót az adatbázis számára, akkor az adatok és a naplófájlok automatikusan növekszik, ha több helyre van szükség. Ez a paraméter nem teszi lehetővé a rendszer leállítását, ha nincs elég hely.
Az AutoGrow-t azonban az utolsó védelmi vonal mechanizmusának kell tekinteni. Nem szabad használni az adatbázis növekedésének kezelésének fő módjaként. Az összes adatfájl és napló növekedését manuálisan kell kezelni. Az adatbázis-tevékenység befejeződik, amikor az AutoGrow műveletek megtörténtek. A gyakori AutoGrow események jó mutatók az előre nem látható adatok növekedésének. A következő parancs bemutatja, hogyan állíthatja be az adatok és naplófájlok AutoGrow beállítását:
Szinte soha nem ajánlott aktiválni az adatbázis AutoShrink funkcióját. Az AutoGrow műveletekhez hasonlóan az AutoShrink műveletek leállítják az összes adatbázis műveletet. Ezenkívül az adminisztrátor nem tudja ellenőrizni az AutoShrink kezdési idejét. Az AutoShrink használata az AutoGrow műveletek spirálját eredményezheti, amelyet az AutoShrink követ, az eredmény pedig az adatbázis teljesítményének csökkenése és a fájlok túlzott töredezettsége. Elindíthatja az AutoShrink parancsot a következő paranccsal:
Egy másik hasznos módszer az adatraktárakhoz való azonnali inicializáláshoz az Instant File Initiation fájlok azonnali inicializálása. A cikkben tárgyalt lehetőségekkel ellentétben, az azonnali fájlbeolvasást a Windows Server házirend szabályozza. Az azonnali fájlok inicializálása nem állítja vissza a fájlhoz rendelt helyet, hanem egyszerűen elosztja a kívánt helyet. Az SQL Server az Instant File Initialization használatát az adatbázis létrehozása, az AutoGrow és az adatbázis-helyreállítási műveletek során használja. Az adminisztrációs menüben engedélyezheti az Instant File Initialization módot a kiszolgálón a helyi biztonsági házirend megnyitásához. Ezután bontsa ki a Helyi házirendek lehetőséget, és kattintson duplán a Teljesítményfigyelmeztetési feladatok elemre, amint azt a képernyőn látható.
A képernyő. Azonnali fájlbeindítás engedélyezése
Ez megnyitja a Tulajdonságok teljesítmény teljesítmény karbantartás párbeszédpanelt, amelyben megadhatja az SQL Server Service fiók nevét.
Adattárolási és RAID szintek
Miután elsajátította az SQL Server repositóriákat, elkezdheti feltérképezni a következő kritikus koncepciót - a RAID-szinteket, amelyeket a tároló alrendszeren lévő lemezekhez használhat. A RAID szintek nagyban befolyásolják a teljesítményt és a rendelkezésre állást. Amint várható, a drágább lehetőségek jobb teljesítményt és rendelkezésre állást kínálnak. A leggyakoribb RAID szintek a következők:
- RAID 0 (néha váltakozó lemezek). Ezen a RAID szinten az adatok az összes rendelkezésre álló lemez között oszlanak meg. Gyakran használják különböző adatbázis-teljesítmény tesztekben. A RAID 0 jó teljesítményt nyújt, de soha nem szabad használni egy gyártókiszolgálón, mivel egy meghajtó hibája adatvesztést okoz.
- RAID 1 (néha a lemezek tükrözése). A RAID 1 konfigurációban az adatok tükröződnek a lemezeken. Az olvasási és írási műveletek sebessége jó, de a lemezek teljes kapacitása felére csökkent. A RAID 1 gyakran használatos az SQL Server naplófájljaihoz. Egyetlen lemezhiba esetén az adatok nem kerülnek el.
- RAID 5 (néha váltakozó lemezek paritásvezérléssel). Egy RAID 5 konfigurációban az adatok több lemezen vannak elosztva az adat redundancia biztosításához. Gyakran használt adatfájlokhoz. Ez a RAID szint jó olvasási teljesítményt nyújt, és ellenáll az egylemezes meghibásodásnak. Azonban a felvételi sebesség alacsony.
- RAID 10 (néha tükrözõtárcsáknak nevezik). A RAID 10 kombinálja az alternatív opciók sebességét és a védelmet a tükrözéssel. A RAID 10 a RAID szintek között a legmagasabb szintű teljesítményt és rendelkezésre állást biztosítja. A RAID 10-ben kétszer annyi lemez van, mint a RAID 5, de a konfiguráció több lemezhibával szemben ellenálló. A RAID 10 tömb továbbra is sikeresen működik, ha a lemezek fele a készletben meghiúsul. A RAID 10 alkalmas mind az adatfájlokhoz, mind a naplókhoz.
Az SQL Server adattároló rendszer másik fontos eleme a tempdb. Ez egy SQL Server rendszer adatbázis, amely egy globális erőforrás, amely minden felhasználó számára elérhető. A Tempdb-t ideiglenes felhasználói objektumokhoz és az adatbázis-kezelő rendszer magjának belső műveleteihez használják, beleértve az egyesületeket, a statisztikai feldolgozást, a kurzorokat, a sort, a hasítást és a karakterláncok verzióját. Ellentétben egy tipikus felhasználói adatbázis adataival, a tempdb adatait nem lehet megőrizni az SQL Server letiltása után.
A tempdb tipikusan az egyik legaktívabb adatbázis az SQL Server egy működő példányában, ezért a következő ajánlások segítenek az SQL Server adatbázis jó teljesítményének biztosításában. Mindenekelőtt a tempdb adatokat és a naplófájlokat más fizikai lemezekre kell helyezni, mint a naplófájlokat és a működő adatbázisadatokat. A tempdb nagyon aktív használatának köszönhetően hasznosak a lemezek védelme RAID 1 tömb vagy RAID 10 tömb kölcsönzésével. A Microsoft SQL Server ügyfélszolgálati csapata (SQLCAT) szakértői azt javasolják, hogy a tempdb egyetlen adatfájlt tartalmaz minden processzor magjához. De ez az ajánlás a nagyon nagy munkaterhelésekre hatásos. Gyakran ajánlott, hogy az adatfájlok aránya a processzor magjaihoz képest 1: 2 vagy 1: 4 legyen. Mint a legtöbb esetben, ezek általános ajánlások; Az adott rendszer optimális megközelítései eltérhetnek egymástól. Ha nem tudja pontosan, hogy hány fájlt kell használni a tempdb-hez, négy adatfájllal kezdheti. Általában egy log fájl elegendő a tempdb-hez. A tempdb részletes ajánlásait megtalálja az "Oktatási szakirodalom" oldalsávon felsorolt anyagokban.
Ezenkívül a tempdb méretének elegendőnek kell lennie ahhoz, hogy elkerülje az AutoGrow műveleteket. Az egyedi adatbázisokhoz hasonlóan a tempdb az AutoGrow műveletek miatt késedelmet szenved. A tempdb alapértelmezés szerint 8 MB adatfájlt tartalmaz, 1 MB logaritmust és 10% -ot az AutoGrow számára, ami túl kicsi a legtöbb termelési terhelésnél. Fontos megjegyezni, hogy az SQL Server újraindításakor a tempdb méret visszaáll az utolsó megadott értékre.
A tempdb adatfájlok és naplók mérete és mozgása az "Adatok és naplófájlok" részben található kóddal határozható meg. A 2. listában (az MSDN webhelyen) található lekérdezés bemutatja a tempdb adatfájlok és naplók méretének és százalékos növekedésének meghatározását.
Tömör állapotú meghajtók
Számos magnak köszönhetően megnövekedett a feldolgozási teljesítmény, és sok modern rendszer nagyon sok RAM-ot támogat, ezért az I / O alrendszer számos terhelésnek szűk keresztmetszetévé vált. A hagyományos merevlemezek nagyobb méretűek lettek, de a teljesítmény csak alig nőtt. A probléma megoldható szilárdtestlemez (SSD) segítségével. A szilárdtest-lemezek viszonylag új technológiát jelentenek az adattároláshoz, amely az elmúlt egy évben az SQL Server piacán kezdett súlyosbodni. A múltban az SSD-eszközök költsége túl magas volt, és az információs kapacitás túlságosan kicsi a sok működő adatbázis számára. A szilárdtestalapú meghajtók növekvő népszerűségének egyik oka a hagyományos merevlemezek teljesítményelőnye, forgó orsóval. Például egy soros csatolású SCSI (SAS) lemez, amelynek orsós fordulatszáma 15 000 rpm, 200 MB / s átbocsátást biztosít. Összehasonlításképpen, a Serial ATA (SATA) SSD 6 megapixeles kapcsolattal rendelkezik, amely egyenletes átvitelt biztosít körülbelül 550 MB / s-nak. Az SSD-k kiemelkedő teljesítményének fő oka a keresési idő jelentős csökkenése. Amikor forgó merevlemezről kell adatokat szerezni, a fejnek új helyre kell költöznie. Az SSD lemeznek nincsenek mozgó alkatrészei, így az új tárolóhelyre történő áthelyezést a memóriacellák sebessége határozza meg.
A szilárdtest és nagysebességű flash tároló többféle módon is megvalósítható. Tipikus alkalmazások 2,5 hüvelykes SSD-k. Ezek az eszközök közvetlenül DAS típusú tárolóként vannak csatlakoztatva, és az elektronikus interfész ugyanaz, mint egy szabványos merevlemezen. Az SSD másik közös megvalósítása PCI Express (PCIe) kártyák formájában történik, amelyek közvetlenül a rendszerbuszhoz kapcsolódnak. Ez a megközelítés kihasználja a nagysebességű PCIe busz előnyeit, hogy növelje az I / O per másodpercet (IOPS) és az átvitelt a szabványos lemezterülethez képest. Emellett számos tárolási partíció SAN SSD és a funkció automatikus elosztása adatpartíciókat, amely lehetővé teszi, hogy a kritikus fontosságú terhelések nagy teljesítményű SSD partíció, így kevésbé kritikus terhelések lassabb és kevésbé költséges merevlemezeket.
Különböző típusú SSD-k vannak. Ezek közé tartoznak a flash memória technológián alapuló DRAM-alapú SSD és SSD tárolók, például egyszintű (SLC) és többszintű cellák (MLC). Minden típusnak előnyei és hátrányai vannak.
- DRAM. Mint a szokásos számítógép RAM, a DRAM nagyon gyors, de megbízhatatlan. A DRAM esetében állandó adatok szükségesek ahhoz, hogy adatokat tároljanak az adatok kikapcsolásakor. Az ilyen tárolókat gyakran a szerver szerverlapján telepített PCIe kártyák formájában adják ki.
- SLC. Az SLC tárolási sebessége és életciklusa magasabb, mint az MLC, ezért az SLC-t vállalati szintű SSD tárolóban használják. Ugyanakkor az SLC eszközök ára lényegesen magasabb, mint az MLC ára.
- MLC. Általában az MLC típusú flash memóriát fogyasztói eszközökben használják, és olcsóbb, mint az SLC. Az MLC azonban alacsonyabb felvételi sebességgel és sokkal nagyobb kopással rendelkezik, mint az SLC.
A sebességnél az SSD-k jobban teljesítik a merevlemezeket forgó orsón, de életük sokkal alacsonyabb. Az intenzív I / O alkalmazások, például az SQL Server, csökkentik az SSD meghajtó élettartamát. Ráadásul a lemez nagyobb része, annál kisebb a várható élettartam. Javasoljuk, hogy győződjön meg róla, hogy az SSD legalább 20% -át nem használja. A leolvasási sebesség stabil az eszköz teljes működésének ideje alatt. Az írási teljesítmény azonban működés közben lecsökken, vagyis a rögzítéshez szükséges idő nő. Fontos megjegyezni, hogy nincs szükség az SSD lemezek töredezettségmentesítésére, mivel az adatokhoz való hozzáférés módja eltér a merevlemezekhez. Valójában az ilyen típusú meghajtó töredezettségmentessége csak az életciklusát csökkenti.
Ha SSD-ket szeretne használni, ne használjon egyetlen SSD meghajtót, és készen álljon az SSD-k kicserélésére a szerver életében. Nézzük meg az SSD használatának lehetőségeit az SQL Server alkalmazásban.
- Az SSD-k indexeinek áthelyezése. Általánosságban az indexek nem túl nagyok, és az intenzív véletlenszerű műveletekhez kötődnek, így ideálisak az SSD-lemezek elhelyezésére.
- Adatfájlok SSD-kre történő áthelyezése. Az adatfájlok általában több olvasmányt tartalmaznak, mint írják, ezért a legtöbb esetben alkalmasak az SSD-re.
- A naplófájlok áthelyezése SSD-kre. A naplófájlok számos írási művelettel társulnak. Ezért, ha SSD-ket használnak naplófájlokhoz, használjon vállalati szintű SSD-ket és RAID 1 vagy RAID 10 konfigurációkat tükrözéssel.
- A tempdb áthelyezése egy SSD meghajtóba. Tipikusan a tempdb magas szintű rendezetlen írási műveletekkel jár, amelyek az SSD-k elrontásához vezethetnek. Ezért, ha SSD-ket használnak a tempdb-hez, akkor ez egy vállalati szintű SSD egy RAID 1 vagy RAID 10 konfigurációban tükrözéssel, és szükség van SSD helyettesítő tervre. Ezenkívül figyeljen a tempdb PCIe DRAM használatára. A DRAM tároló nagyobb írási teljesítményt nyújt, és korlátlan élettartammal rendelkezik. A DRAM tárolási ára azonban magas lehet.
Alapvető teljesítményszintek
Egy másik alapvető megközelítés a kiindulási teljesítményszintek elkészítése, és rendszeresen összehasonlítja a rendszer teljesítményét ezen alapvonalakkal. Ez nagyon hasznos lehet a hibaelhárításhoz, valamint az adatbázisok növekedésének követéséhez és más tendenciákhoz. Az alapvonalhoz való összehasonlítás az egyik legjobb módja a rendszerek proaktív irányítására. Az SQL Server teljesítményének mérése nem tartozik a jelen cikk hatálya alá, de az alábbiakban áttekintjük a legfontosabb mért adatraktári mérőszámokat.
A figyelni kívánt teljesítményszámlálók első csoportja a Windows rendszer monitor memóriájához kapcsolódó számlálók. Technikailag ezek nem adattároló számlálók, de ha nincs elég memória, a többi számláló nem számít. Ügyeljen arra, hogy figyelje a memóriaobjektum elérhető MBytes számlálóját. Ez a számláló mutatja a fizikai memória mennyiségét, amely rendelkezésre áll egy folyamat vagy rendszer számára. Ha az indikátor kevesebb, mint 100 MB, hasznos a memória méretének növelése. Egy másik fontos számláló a Paging File objektum% használata, amely megmutatja a lapozófájl használt mennyiségét a Windows rendszerben. Ennek az értéknek kevesebbnek kell lennie, mint 70%. Ha az érték magasabb, a rendszer valószínűleg több memóriát igényel.
A Windows memóriájához kapcsolódó számlálók mellett több Windows Server tárolási teljesítményszámláló is található. Azonban ezeknek a számlálóknak az olvasása csak akkor hasznos, ha az SQL Server példánya közvetlen csatolású DAS tárolórendszerrel működik. Ha SAN-t használ, figyelmet kell fordítania a SAN teljesítménymutatókra.
Ha az SQL Server példánya DAS-t használ, akkor először győződjön meg róla, hogy az NTFS meghajtón legalább 20% -a szabad. Később ellenőrizheti a Windows Server tárolópultjait a rendszer monitor segítségével. Az 1. táblázat felsorolja a legfontosabb számlálókat; minden a logikai lemez objektumhoz kapcsolódik.
