Základy vstupně-výstupních operací SQL Serveru

Platí pro:SQL ServerAzure SQL spravovaná instanceSQL Server na virtuálních počítačích Azure

Primárním účelem databáze SQL Serveru je ukládat a načítat data, takže vstupně-výstupní operace disku s intenzivním výkonem (V/V) je základním rysem databázového stroje. Vzhledem k tomu, že vstupně-výstupní operace disku můžou spotřebovávat mnoho prostředků a dokončení trvá poměrně dlouho, SQL Server se zaměřuje na vysoce efektivní vstupně-výstupní operace.

Subsystémy úložiště pro SQL Server jsou poskytovány v několika formách, včetně mechanických jednotek a úložiště SSD. Tento článek obsahuje podrobnosti o tom, jak používat principy ukládání jednotek do mezipaměti ke zlepšení vstupně-výstupních operací databázového stroje.

SQL Server vyžaduje, aby systémy podporovaly zaručené doručování do stabilních médií , jak je uvedeno v rámci požadavků na program spolehlivosti vstupně-výstupních operací SQL Serveru. Další informace o požadavcích na vstup a výstup pro databázový stroj SQL Serveru najdete v tématu Požadavky na vstup/výstup databázového stroje SQL Serveru (vstupně-výstupní operace).

Diskové I/O

Správce vyrovnávací paměti provádí jen čtení a zápisy do databáze. Další operace se soubory a databázemi, jako je otevření, zavření, rozšíření a zmenšení, provádí správce databáze a komponenty správce souborů.

Operace vstupu a výstupu na disku spravované správcem vyrovnávací paměti mají následující vlastnosti:

  • Vstupně-výstupní operace se obvykle provádí asynchronně, což umožňuje volajícímu vláknu pokračovat ve zpracování, zatímco vstupně-výstupní operace probíhá na pozadí. Za určitých okolností (například špatně sladěné operace vstupu/výstupu u protokolu) může dojít k synchronním operacím vstupu/výstupu.

  • Všechny vstupně-výstupní operace se vydávají ve vláknech volajícího, pokud se nepoužívá možnost spřažení I/O. Možnost Afinitní I/O masky připojí operace vstupů a výstupů disku v SQL Serveru k určené podmnožině CPU. V prostředí špičkového online zpracování transakcí SQL Serveru (OLTP) může toto rozšíření zvýšit výkon vláken SQL Serveru provádějících I/O operace.

  • Vstupně-výstupní operace s více stránkami se provádějí pomocí vstupně-výstupních operací s bodovým shromažďováním, což umožňuje přenos dat do nebo z nesouvislých oblastí paměti. To znamená, že SQL Server může rychle vyplnit nebo vyprázdnit mezipaměť vyrovnávací paměti a vyhnout se tak více fyzickým vstupně-výstupním požadavkům.

Dlouhé vstupně-výstupní požadavky

Správce vyrovnávací paměti hlásí všechny vstupně-výstupní požadavky, které jsou nevyřízeny nejméně po dobu 15 sekund. Tento proces pomáhá správci systému rozlišovat mezi problémy s SQL Serverem a problémy subsystému vstupně-výstupních operací. Chybová zpráva MSSQLSERVER_833 je hlášena a zobrazí se v protokolu chyb SQL Serveru následujícím způsobem:

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Dlouhá vstupně-výstupní operace může být buď čtení, nebo zápis; zpráva aktuálně nenaznačuje, o kterou se jedná. Dlouhé vstupně-výstupní zprávy jsou upozornění, ne chyby. Nenaznačují problémy s SQL Serverem, ale se základním vstupně-výstupním systémem. Zprávy pomáhají správci systému najít příčinu špatné doby odezvy SYSTÉMU SQL Server rychleji a rozlišovat problémy, které jsou mimo kontrolu SYSTÉMU SQL Server. Proto nevyžadují žádnou akci, ale správce systému by měl zjistit, proč vstupně-výstupní požadavek trval tak dlouho a jestli je čas spravedlivý.

Příčiny dlouhých vstupně-výstupních požadavků

Dlouhá vstupně-výstupní zpráva může znamenat, že vstupně-výstupní operace je trvale zablokovaná a nikdy se nedokončí (označuje se jako ztracená vstupně-výstupní operace), nebo jen že ještě není dokončená. Ze zprávy nemůžete zjistit, který scénář se týká, i když ztracená I/O operace často vede k vypršení časového limitu západky.

Dlouhé vstupně-výstupní operace často označují úlohu SQL Serveru, která je pro diskový subsystém příliš intenzivní. Nedostatečný diskový subsystém může být uveden v následujících případech:

  • V protokolu chyb se během náročné úlohy SQL Serveru zobrazí několik dlouhých vstupně-výstupních zpráv.
  • Počítadla sledování výkonu zobrazují dlouhé latence disku, dlouhé fronty na discích nebo žádný volný čas disku.

Komponenta v cestě I/O operace (například ovladač, kontroler nebo firmware) může způsobit dlouhé I/O operace tím, že nepřetržitě odkládá zpracování staré I/O žádosti ve prospěch obsluhy novějších požadavků. K tomuto problému může dojít v propojených prostředích, jako jsou sítě iSCSI a Fibre Channel (kvůli chybné konfiguraci nebo selhání cesty). Nástroj Sledování výkonu může potvrzení tohoto problému ztížit, protože většina vstupně-výstupních operací se obsluhuje pohotově. Úlohy, které provádějí velké objemy sekvenčních vstupně-výstupních operací, jako je zálohování a obnovení, prohledávání tabulek, řazení, vytváření indexů, hromadné načtení a vynulování souborů, můžou zhoršit dlouhé vstupně-výstupní požadavky.

Izolované dlouhé vstupně-výstupní operace, které se nezdají souviset s žádnou z předchozích podmínek, můžou být způsobeny problémy s hardwarem nebo ovladačem. Protokol událostí systému může obsahovat související událost, která pomáhá diagnostikovat problém.

Problémy s výkonem vstupně-výstupních operací způsobených neefektivními dotazy nebo ovladači filtru

Pomalé vstupně-výstupní operace můžou být způsobené dotazy, které nejsou efektivně napsané nebo správně vyladěné pomocí indexů a statistik. Dalším běžným faktorem latence vstupně-výstupních operací je přítomnost antivirového softwaru nebo jiných bezpečnostních programů, které kontrolují databázové soubory. Tento skenovací software se může rozšířit na síťovou vrstvu, která přidává latenci sítě a nepřímo ovlivňuje latenci databáze. I když scénář popsaný o 15sekundových vstupně-výstupních operacích je u hardwarových komponent častější, u neoptimalizovaných dotazů nebo chybně nakonfigurovaných antivirových programů dochází k kratším zpožděním vstupně-výstupních operací.

Podrobné informace o řešení těchto problémů najdete v tématu Řešení potíží s pomalým výkonem SQL Serveru způsobeným vstupně-výstupními operacemi.

Informace o tom, jak nakonfigurovat antivirovou ochranu na SQL Serveru, naleznete v tématu Konfigurace antivirového softwaru pro práci s SQL Serverem.

Zápisové ukládání do mezipaměti v řadičích úložiště

Přenosy I/O operací, které nepoužívají mezipaměť, mohou na mechanických jednotkách trvat mnohem déle kvůli rychlosti otáčení pevných disků, mechanické době potřebné k přesunutí hlav jednotek a dalším omezujícím faktorům. Instalace SQL Serveru cílí na systémy, které poskytují kontrolery vyrovnávací paměti. Tyto kontrolery zakazují mezipaměti na disku a poskytují stabilní mezipaměti médií pro splnění požadavků na vstupně-výstupní operace SQL Serveru. Vyhýbají se problémům s výkonem souvisejícím s hledáním úložiště a časem zápisu pomocí různých optimalizací kontroleru ukládání do mezipaměti.

Poznámka:

Někteří dodavatelé úložiště používají jako úložiště trvalou paměť (PMEM) místo mezipaměti, což může zlepšit celkový výkon. Další informace naleznete v tématu Konfigurace trvalé paměti (PMEM) pro SQL Server ve Windows a konfigurace trvalé paměti (PMEM) pro SQL Server v Linuxu.

Použití zapisovací mezipaměti (označované také jako zapisovací mezipaměť s návratem) může zlepšit výkon SQL Serveru. Řadiče ukládání do mezipaměti zápisu a subsystémy úložiště jsou pro SQL Server bezpečné, pokud jsou navrženy pro použití v prostředí transakčního databázového systému řízení (DBMS) kritického na data. Tyto funkce návrhu musí zachovat data uložená v mezipaměti, pokud dojde k selhání systému. Použití externího nerušitelného zdroje napájení (UPS) k dosažení této ochrany obecně nestačí, protože můžou nastat režimy selhání, které nesouvisejí s napájením.

Important

SQL Server závisí na zaručené doručení do stabilního média pro transakční integritu a obnovení. Nebezpečné ukládání do mezipaměti, které nezajistí zachování dat napříč selháními, může poškodit databáze bez ohledu na konzistenci zápisů transakčních protokolů. Vždy ověřte, že každý mechanismus ukládání do mezipaměti pro zápis poskytuje úplné záruky trvanlivosti.

Řadiče ukládání do mezipaměti a subsystémy úložiště mohou být bezpečné pro použití SQL Serverem. Většina nových účelově vytvořených serverových platforem, které tyto kontrolery obsahují, jsou bezpečné. Měli byste se ale s dodavatelem hardwaru ujistit, že subsystém úložiště byl testován a schválen pro použití v prostředí pro správu relačních databází kritických pro data.

Pokyny k zabezpečení subsystému mezipaměti

Řadiče pro ukládání do mezipaměti se zpětným zápisem můžou zlepšit výkon, pokud splňují specifické bezpečnostní požadavky:

  • Zahrnout mezipaměť s podporou baterie nebo nevolatilní paměť, jako je NVDIMM nebo superkondenzovaný flash.
  • Certifikujte dodavatele pro prostředí databáze OLTP kritické pro data.
  • Zajistěte ochranu, která pokrývá všechny podmínky selhání, nejen ztrátu napájení.

Important

Nespoléhejte pouze na vnější UPS. Chyby nesouvisející s napájením, jako jsou chyby firmwaru nebo selhání hardwaru, můžou vést ke ztrátě mezipaměti.

Protokolování před zápisem

Příkazy SQL Serveru pro úpravu dat generují logické zápisy na stránku. Tento datový proud zápisů si můžete zobrazit na dvou místech: protokol a samotná databáze. Z důvodů výkonu SQL Server odkládá zápisy do databáze prostřednictvím svého systému vyrovnávací paměti. Systém až do času COMMIT pouze krátce odkládá zápisy do záznamu. Tyto zápisy se neukládají do mezipaměti stejně jako zápisy dat. Vzhledem k tomu, že zápisy protokolů pro danou stránku vždy přicházejí před zápisy dat stránky, protokol se někdy označuje jako protokol Write-Ahead Log (WAL).

Protokol zapisování předem (WAL)

Term protocol je vynikající způsob, jak popsat WAL. WAL používaný SQL Serverem se označuje jako ARIES (algoritmus pro zotavení a izolaci využívající sémantiku). Další informace najdete v tématu Správa zrychleného obnovení databáze.

Jedná se o specifickou a definovanou sadu kroků implementace, které jsou nezbytné k zajištění správného uložení a výměny dat do známého stavu v případě selhání. Stejně jako síť obsahuje definovaný protokol pro výměnu dat konzistentním a chráněným způsobem, takže wal také popisuje protokol pro ochranu dat. Všechny verze SQL Serveru otevřou protokol a datové soubory pomocí funkce Win32 CreateFile . Prvek dwFlagsAndAttributes zahrnuje možnost FILE_FLAG_WRITE_THROUGH, když je otevřen prostřednictvím SQL Serveru.

Příznak zápisu přes FILE_FLAG_WRITE_THROUGH

SQL Server vytvoří soubory databáze pomocí příznaku FILE_FLAG_WRITE_THROUGH . Tato možnost dá systému pokyn, aby zapisoval přímo do úložiště, přičemž obchází jakoukoli mezipaměť. Systém může i nadále ukládat operace zápisu do mezipaměti, ale nemůže je líně vyprázdnit. Další informace naleznete v tématu CreateFileA.

Možnost FILE_FLAG_WRITE_THROUGH zajišťuje, že když operace zápisu vrátí úspěšné dokončení, data jsou správně uložena ve stabilním úložišti. Tato funkce odpovídá specifikaci protokolu WAL (Write-Ahead Logging), která zajišťuje integritu dat. Mnoho úložných zařízení na bázi NVMe, PCIe, SATA, ATA, SCSI a IDE obsahuje vestavěné mezipaměti o velikosti 512 kB, 1 MB a větší. Mezipaměti úložiště se obvykle spoléhají na kondenzátor a ne na řešení založeném na baterii. Tyto mechanismy ukládání do mezipaměti nemůžou zaručit zápisy v rámci cyklu napájení nebo podobného bodu selhání. Zaručují pouze úplné dokončení operací zápisu do sektoru. Vzhledem k tomu, že se úložná zařízení stále zvětšují, zvětšují se i mezipaměti, a mohou během selhání vystavit větší množství dat.

Další informace o podpoře FUA distribucí Linuxu a jejím účinkem na SQL Server najdete v tématu SQL Server v Linuxu: Interní informace o vynuceném přístupu k jednotce (FUA).

Transakční integrita a obnovení SQL Serveru

Transakční integrita je jedním ze základních konceptů relačního databázového systému. Transakce jsou atomické jednotky práce, které jsou buď zcela použity, nebo zcela vráceny zpět. Transakční protokol předběžných zápisů SQL Serveru je důležitou součástí implementace transakční integrity.

Jakýkoli relační databázový systém musí také řešit koncept úzce související s transakční integritou, což je obnovení z neplánovaného systémového selhání. Toto selhání může způsobit několik neideálových, reálných efektů. U mnoha systémů správy databází může selhání systému vést k zdlouhavé ručnímu procesu obnovení řízeného člověkem.

Naproti tomu mechanismus obnovení SQL Serveru je automatický a funguje bez zásahu člověka. SQL Server může například podporovat kritickou produkční aplikaci a zaznamenat selhání systému kvůli momentální kolísání výkonu. Po obnovení napájení se serverový hardware restartuje, síťový software se načte a inicializuje a SQL Server se restartuje. Při inicializaci SQL Serveru automaticky spustí proces obnovení na základě dat v transakčním protokolu. K tomuto celému procesu dochází bez zásahu člověka. Když se klientské pracovní stanice restartují, uživatelé najdou všechna data, která jsou k dispozici, až do poslední transakce, kterou zadali.

Transakční integrita a automatické obnovení v SQL Serveru představují výkonnou funkci úspory práce a času. Pokud řadič zajištění zápisu do mezipaměti není správně navržený pro použití v prostředí DBMS klíčové z hlediska integrace dat, může ohrozit schopnost SQL Serveru obnovit a potenciálně poškodit databázi. K tomuto problému může dojít v případě, že kontroler zachycuje zápisy transakčního protokolu SQL Serveru a uloží je do vyrovnávací paměti v mezipaměti hardwaru na desce kontroleru, ale během selhání systému tyto zapsané stránky nezachová.

Warning

Pokud se zápisy uložené v mezipaměti zahodí kvůli resetování systému, může dojít k poškození databáze i v případě, že je k dispozici UPS. Vždy se ujistěte, že mezipaměť zápisu zajišťuje baterie nebo ekvivalentní technologie, která zaručuje trvalost dat.

Rizika ukládání do mezipaměti na disku

Většina řadičů mezipaměti úložných zařízení provádí ukládání zápisů do mezipaměti. Funkci zápisového ukládání do mezipaměti nemůžete vždy zakázat.

I když server používá ups, zařízení nezaručuje zabezpečení zápisů uložených v mezipaměti. K mnoha typům selhání systému může dojít, které UPS neřeší. Například chyba parity paměti, soutisk operačního systému nebo chyba hardwaru, která způsobuje resetování systému, může způsobit nekontrolovatelné přerušení systému. Selhání paměti v hardwarové mezipaměti zápisu může také vést ke ztrátě důležitých informací protokolu.

Při vypnutí systému může dojít k dalšímu možnému problému souvisejícímu s kontrolerem ukládání do mezipaměti pro zápis. Není neobvyklé cyklovat operační systém nebo restartovat systém během změn konfigurace. I když opatrný operátor dodržuje doporučení operačního systému, aby před restartováním systému počkal na ukončení všech aktivit úložiště, mohou být zápisy uložené v mezipaměti stále přítomny v kontroleru. Ctrl + Alt + Del Při stisknutí kombinace kláves nebo stisknutí tlačítka pro resetování hardwaru je možné zahodit zápisy uložené v mezipaměti, což může poškodit databázi.

Je možné navrhnout mezipaměť pro zápis hardwaru, která bere v úvahu všechny možné příčiny zahození dat z mezipaměti, což umožňuje bezpečné použití databázovým serverem. Některé z těchto funkcí návrhu zahrnují zachycení signálu sběrnice RST (reset), aby se zabránilo nekontrolovanému resetování řadiče mezipaměti, palubní záložní baterii a paměť ECC s kontrolou a opravou chyb nebo zrcadlením. Obraťte se na dodavatele hardwaru a ujistěte se, že mezipaměť zápisu obsahuje tyto a všechny další funkce potřebné k tomu, aby nedošlo ke ztrátě dat.

Použití úložných cache se SQL Serverem

Databázový systém je především zodpovědný za přesné ukládání a načítání dat, a to i v případě neočekávaných selhání systému.

Systém musí zaručit atomicitu a trvanlivost transakcí, přičemž bere v úvahu současné provádění, více transakcí a různé body selhání. Tato vlastnost se často označuje jako vlastnosti ACID (Atomicita, Konzistence, Izolace a Trvanlivost).

Tato část se zabývá dopady cache paměti úložiště. Další informace o ukládání do mezipaměti a diskuzích o alternativním režimu selhání najdete v následujících článcích:

Projděte si také následující archivovaný obsah:

Koncepty v těchto dvou článcích zůstávají obecně použitelné pro aktuální verze SQL Serveru.

Řešení ukládání do mezipaměti s podporou baterie

Vylepšené systémy kontroleru ukládání do mezipaměti zakazují mezipaměť na disku a poskytují funkční řešení ukládání do mezipaměti založené na baterii. Tyto mezipaměti můžou uchovávat data v mezipaměti několik dní a dokonce umožňují umístit kartu do mezipaměti do druhého počítače. Při správném obnovení napájení jsou nezapsaná data zcela vymazána, než je povolen další přístup k datům. Mnoho z těchto systémů umožňuje vytvořit procento mezipaměti pro čtení a zápis pro optimální výkon. Některé systémy obsahují velké oblasti úložiště paměti. Někteří dodavatelé hardwaru poskytují systémy ukládání do mezipaměti s vysokým využitím baterie s více gigabajty mezipaměti. Tyto systémy mohou výrazně zlepšit výkon databáze. Řešení ukládání do mezipaměti založené na baterii poskytují odolnost a konzistenci dat, která SQL Server očekává.

Implementace subsystému úložiště

Subsystémy úložiště existují v mnoha typech. Dvěma běžnými příklady jsou RAID (redundantní pole nezávislých disků) a SAN (úložištní síťová oblast). Tyto systémy obvykle používají jednotky založené na rozhraní SCSI. Následující část popisuje důležité informace o úložišti vysoké úrovně.

SCSI, SAS a NVMe

Zařízení úložiště SCSI, SAS a NVMe:

  • Obvykle jsou navrženy pro použití s velkým zatížením.
  • Obvykle se zaměřují na víceuživatele, serverové implementace.
  • Obvykle mají lepší střední dobu do selhání než jiné implementace.
  • Obsahují sofistikované heuristiky, které pomáhají předpovídat bezprostřední selhání.

Poznámka:

SQL Server podporuje komponenty technologie iSCSI (Internet Small Computer System Interface), které splňují požadavky programu Kompatibilita hardwaru systému Windows. I když SQL Server nepracuje přímo se službou iSCSI, funguje bezproblémově, protože Windows prezentuje úložiště iSCSI jako standardní jednotky. SQL Server pak může číst a zapisovat do vzdáleného úložiště na úrovni bloků napříč sítěmi IP. Vzhledem k tomu, že rozhraní iSCSI závisí na sítích, můžete zaznamenat zpoždění nebo kritické body. Ujistěte se, že je výkon ukládání do mezipaměti serveru optimální a latence je minimalizovaná. Další informace najdete v tématu Omezení škálovatelnosti cílového serveru iSCSI.

Jiné než SCSI

Další implementace jednotek, jako je IDE, ATA a SATA:

  • Jsou obvykle navrženy pro lehké až střední použití.
  • Obvykle se zaměřují na aplikace s jedním uživatelem.

Řadiče bez rozhraní SCSI, desktopové řadiče vyžadují větší šířku pásma hlavního procesoru (CPU) a často jsou omezeny jedním aktivním příkazem. Pokud například jednotka bez SCSI upravuje chybný blok, jednotka vyžaduje, aby příkazy hostitele čekaly. Sběrnice ATA představuje další příklad: sběrnice ATA podporuje dvě zařízení, ale aktivní může být jenom jeden příkaz. Toto omezení ponechá jednu jednotku nečinnou, zatímco druhá jednotka obsluhuje čekající příkaz. Systémy RAID založené na desktopových technologiích mohou všechny tyto příznaky zaznamenat a být výrazně ovlivněny nejpomalejším reagátorem. Pokud tyto systémy nepoužívají pokročilé návrhy, jejich výkon není tak efektivní jako výkon systémů založených na rozhraní SCSI.

Aspekty úložišť

V některých situacích může být stolní disk nebo pole nízkonákladovým řešením. Pokud například nastavíte databázi určenou jen pro čtení pro vytváření sestav, při zakázání ukládání do mezipaměti jednotky se vyhnete mnoha faktorům výkonu databáze OLTP.

Velikosti úložných zařízení se stále zvyšují. Nízké náklady a vysokokapacitní disky mohou být lákavé. Když ale nakonfigurujete jednotku pro SQL Server a potřeby reakční doby vaší firmy, pečlivě zvažte následující aspekty:

  • Návrh cesty accessu
  • Požadavek na zakázání mezipaměti na disku

Mechanické pevné disky

Mechanické jednotky používají rotující magnetické desky k ukládání dat. Jsou dostupné v několika kapacitách a formách, jako jsou IDE, SATA, SCSI a SAS (Serial Attached SCSI). Některé jednotky SATA zahrnují konstrukce predikce selhání. Jednotky SCSI jsou navržené pro těžší cykly zatížení a snižují míru selhání.

Integrované vývojové prostředí (IDE) a systémy založené na ATA můžou odložit hostitelské příkazy při provádění aktivit, jako je například špatná úprava bloku, což vede k obdobím pozastavené vstupně-výstupní aktivity.

Výhody SAS zahrnují pokročilé fronty až do 256 úrovní, přičemž zahrnují řazení na začátek fronty a řazení mimo pořadí. Zadní rovina SAS je navržena způsobem, který umožňuje použití jednotek SAS i SATA v rámci stejného systému.

Instalace SQL Serveru závisí na schopnosti kontroleru zakázat mezipaměť na disku a zajistit stabilní vstupně-výstupní mezipaměť. Zapisování dat v nesprávném pořadí na různé jednotky není pro SQL Server překážkou, pokud řadič poskytuje správné funkce stabilního ukládání do mezipaměti médií. Složitost návrhu kontroleru se zvyšuje díky pokročilým technikám zabezpečení dat, jako je zrcadlení.

Pevné úložiště

Úložiště solid-state má výhody oproti mechanickým (rotujícím) pevným diskům, ale je náchylné k mnoha stejným vzorům selhání jako rotující média. SSD úložiště můžete připojit k serveru pomocí různých rozhraní, včetně NVM Express (NVMe), PCI Express (PCIe) a SATA. Zacházejte s médii SSD stejně jako s rotujícími médii a ujistěte se, že příslušná bezpečnostní opatření jsou zavedena pro selhání napájení, jako je například řadič mezipaměti s podporou baterie.

Mezi běžné problémy způsobené chybou napájení patří:

  • Poškození bitu: Záznamy ukazují náhodné chyby bitů.
  • Letící zápisy: Správně vytvořené záznamy končí na nesprávném místě.
  • Zápisy Shorn: Operace se částečně provádějí na úrovni pod očekávanou velikostí sektoru.
  • Poškození metadat: Metadata ve vrstvě dynamického překladu (FTL) jsou poškozena.
  • Nereagující zařízení: Zařízení vůbec nefunguje nebo většinou nefunguje.
  • Neserializovatelnost: Konečný stav úložiště není výsledkem serializovatelného pořadí operací.

512e

Většina úložných zařízení SSD hlásí velikost sektorů 512 bajtů, ale používá stránky o velikosti 4 KB uvnitř mazacích bloků o kapacitě 1 MB. Použití sektorů zarovnaných na 512 bajtů pro zařízení protokolu SQL Serveru může generovat více aktivit čtení/úpravy/zápisu (RMW), které mohou přispět k pomalejšímu výkonu a opotřebení jednotek.

Doporučení: Ujistěte se, že kontroler ukládání do mezipaměti ví o správné velikosti stránky úložného zařízení a dokáže správně zarovnat fyzické zápisy s infrastrukturou úložiště SSD.

0xFFFFFFFF

Nově naformátovaný disk obvykle obsahuje samé nuly. Vymazaný blok zařízení s pevnými stavy je zcela 1, takže nezpracované čtení vymazaného bloku obsahuje všechny 0xFF znaky. Je ale neobvyklé, že si uživatel během normálních vstupně-výstupních operací přečte odstraněný blok.

Tisk vzorů

Použitá technika v minulosti byla zapsat známý vzor na celý disk. Když se pak aktivita databáze provede na stejné jednotce, může být zjištěno nesprávné chování (zastaralé čtení, ztráta zápisu nebo čtení nesprávného posunu), když se vzor neočekávaně objeví.

Tato technika nefunguje dobře na úložišti SSD. Aktivity mazání a operace RMW pro zápisy naruší strukturu. Aktivita sběru odpadu u úložiště s pevným stavem (GC), nivelace opotřebení, bloky seznamů proporcionálního/set-aside, a další optimalizace mají tendenci způsobit, že zápisy se dostávají na různá fyzická umístění, na rozdíl od opětovného užití sektorů rotujících médií.

Firmware (vestavěný software)

Firmware používaný v úložišti ssd bývá ve srovnání s rotujícími multimediálními protějšky složitý. Mnoho jednotek používá více zpracovatelských jader ke zpracování příchozích požadavků a správě paměti. Ujistěte se, že máte aktuální firmware zařízení ssd, abyste se vyhnuli známým problémům.

Identifikace poškození dat a vyrovnání opotřebení.

Běžný přístup uvolňování paměti (GC) pro flashové úložiště pomáhá zabránit opakovanému poškození dat při čtení. Při opakovaném čtení stejné buňky je možné, že elektronová aktivita může utékat a způsobit poškození sousedních buněk. Solid-state storage chrání data různými úrovněmi kódu opravy chyb (ECC) a dalšími mechanismy.

Jeden takový mechanismus souvisí s vyrovnáním opotřebení. Úložiště ssd sleduje aktivitu čtení a zápisu na úložném zařízení. Správa paměti může určit horké body nebo lokality, které se opotřebovávají rychleji než jiné lokality. GC například určuje, že blok je ve stavu jen pro čtení a musí se přesunout. Tento pohyb směřuje obecně na blok s větším opotřebením, aby původní blok mohl být použit pro zápisy. Tento proces pomáhá vyrovnávat opotřebení na disku, ale přesouvá data jen pro čtení do umístění, které má větší opotřebení a matematicky zvyšuje pravděpodobnost selhání, i když mírně.

U SQL Serveru může dojít k dalšímu vedlejšímu efektu vyrovnání opotřebení. Předpokládejme, že spouštíte DBCC CHECKDB a hlásí chybu. Pokud ji spustíte podruhé, existuje malá šance, že DBCC CHECKDB nahlásí další nebo odlišné vzory chyb, protože aktivita GC v úložišti SSD může mezi DBCC CHECKDB spuštěními provést změny.

Chyba operačního systému 665 a defragmentace

Rotující média musí udržovat bloky blízko sebe, aby se snížil pohyb hlavy disku a zvýšila výkonnost. Úložiště ssd nemá fyzickou hlavu, která eliminuje dobu hledání. Mnoho zařízení s pevnými stavy je navrženo tak, aby umožňovalo paralelní operace na různých blocích. Defragmentace média ssd je proto zbytečná. Sériové aktivity jsou nejlepší vzory vstupně-výstupních operací pro maximalizaci propustnosti vstupně-výstupních operací na zařízeních úložiště SSD.

Poznámka:

Solidní úložná zařízení mají výhodu díky funkci trim, což je příkaz na úrovni operačního systému, který vymazává bloky považované za nepoužívané. Ve Windows použijte nástroj Optimalizovat jednotky k nastavení týdenního plánu pro optimalizaci jednotek.

Doporučení:

  • Použijte vhodný kontroler s bateriemi navržený pro optimalizaci aktivit zápisu. Tato volba může zlepšit výkon, snížit opotřebení disků a snížit úroveň fyzické fragmentace.

  • Zvažte použití systému souborů ReFS , abyste se vyhnuli omezením atributů NTFS.

  • Ujistěte se, že nastavení růstu souboru je vhodné.

Další informace o řešení potíží s chybou operačního systému 665 v souvislosti s fragmentací najdete v tématu Chyby operačního systému 665 a 1450 pro soubory SQL Serveru.

Komprese

Pokud jednotka udržuje záměr stabilního média, komprese může prodloužit životnost disku a může pozitivně ovlivnit výkon. Některé firmware ale už může zkomprimovat data neviditelně. Před nasazením do produkčního prostředí nezapomeňte otestovat nové scénáře úložiště.

Shrnutí

  • Udržujte správné postupy a procesy zálohování a zotavení po havárii.
  • Udržujte firmware v aktualizovaném stavu.
  • Pozorně si poslechněte pokyny výrobce hardwaru.

Konfigurace mezipaměti disku

Pokud chcete použít disk s SQL Serverem, zakažte cache jednotky. Ve výchozím nastavení je mezipaměť jednotek povolená. Ve Windows Server použijte kartu Vlastnosti disku - Hardware - Zásady a zakažte zápis do mezipaměti na úrovni operačního systému.

Nespoléhejte jenom na nastavení na úrovni operačního systému. Některé disky ignorují nastavení systému Windows a vyžadují nástroje poskytované výrobcem nebo nastavení firmwaru k zakázání ukládání do mezipaměti pro zápis. Ověřte prostřednictvím nástrojů dodavatelů, že ukládání do mezipaměti zápisu je skutečně zakázáno.

Poznámka:

I při zakázaném ukládání do mezipaměti zápisu může firmware jednotky interně optimalizovat, což zpožďuje příkazy pro vyprázdnění. Vždy ověřte efektivní stav mezipaměti před nasazením pomocí testovacích nástrojů, jako je SQLIOSim.

Úvahy o mezipaměti a SQLIOSim

Pokud chcete potvrdit záruky odolnosti transakcí, před přechodem do produkčního prostředí ověřte svůj subsystém vstupně-výstupních operací pomocí SQLIOSim . Tento nástroj simuluje těžkou asynchronní aktivitu čtení a zápisu do simulovaného datového zařízení a zařízení protokolu. Další informace naleznete v tématu Použití nástroje SQLIOSim k simulaci aktivity SYSTÉMU SQL Server v subsystému disku.

Poznámka:

Ujistěte se, že jakýkoli alternativní mechanismus ukládání do mezipaměti dokáže správně zpracovat více typů selhání.

Mnoho výrobců počítačů objednává jednotky se zakázanou mezipamětí zápisu. Testování však ukazuje, že tato podmínka nemusí vždy platit, takže byste ji měli vždy důkladně otestovat. Pokud máte jakékoli dotazy týkající se stavu ukládání do mezipaměti úložného zařízení, obraťte se na výrobce a získejte odpovídající nástroj, který zakáže operace ukládání do mezipaměti pro zápis. Na starších úložných médiích možná budete potřebovat také nastavení jumperů.

SQL Server vyžaduje, aby systémy podporovaly zaručené doručování stabilních médií, jak je uvedeno v požadavcích na program spolehlivosti vstupně-výstupních operací SQL Serveru. Další informace o požadavcích na vstup a výstup pro databázový stroj SQL Serveru najdete v tématu Požadavky na vstup/výstup databázového stroje SQL Serveru (vstupně-výstupní operace).

Nesprávná rizika ukládání do mezipaměti

Když povolíte ukládání do mezipaměti zápisu bez správných ochranných opatření, některé subsystémy úložiště potvrdí operace zápisu jako dokončené, než se data bezpečně zapíšou na trvalé médium. Pokud dojde ke ztrátě napájení nebo selhání systému, může tato podmínka vést k:

  • Ztráta dat, kdy potvrzené transakce nejsou nikdy trvalé.
  • Poškození databáze kvůli poškozeným zárukám pořadí zápisu

Important

Zakažte ukládání do mezipaměti pro data a protokoly SQL Serveru, pokud to nepotvrdíte prostřednictvím dokumentace dodavatele hardwaru, která:

  • Mezipaměť je zálohovaná na baterii nebo používá trvalé úložiště flash.
  • Pohon zaručuje odolnost při výpadkech napájení a chybových ukončeních systému.

Externí zařízení UPS nejsou dostatečná, protože nemusí chránit před všemi režimy selhání, jako je chyba firmwaru kontroleru.

Související obsah

  • Last updated on