Sdílet prostřednictvím

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

Platí pro:SQL ServerSpravovaná instance Azure SQLSQL Server na virtuálním počítači 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. To 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; není aktuálně uvedena ve zprávě. 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 jsou hlášeny, aby správci systému pomohli rychleji najít příčinu špatné doby odezvy SQL Serveru 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 jsou trvale blokovány a nikdy se nedokončí (označuje se jako ztracené vstupně-výstupní operace) nebo jen že se ještě nedokončila. Ze zprávy není možné zjistit, který scénář je případ, i když ztracená operace vstup/výstup často vede k vypršení časového limitu přidržení.

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.

Dlouhé vstupně-výstupní operace můžou být způsobené také komponentou v cestě vstupně-výstupních operací (například ovladače, kontroleru nebo firmwaru), která nepřetržitě odloží údržbu staré vstupně-výstupní žádosti ve prospěch obsluhy novějších požadavků. K tomu může dojít v propojených prostředích, jako jsou sítě iSCSI a optické kanály (buď kvůli chybné konfiguraci nebo selhání cesty). Může být obtížné to potvrdit pomocí nástroje Sledování výkonu, protože většina I/O operací je zpracována okamžitě. Dlouhé vstupně-výstupní požadavky se můžou zhoršit úlohami, 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čítání a nulování souborů.

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 nejsou 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. Přestože scénář popsaný v 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ů se častěji vyskytuje menší latence 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 vstupně-výstupních operací, které se provádějí bez použití mezipaměti, můžou být u mechanických jednotek výrazně delší, a to z důvodu rychlosti otáčení pevných disků, mechanického času potřebného k přesunutí hlav jednotek a dalších omezujících faktorů. Instalace SQL Serveru jsou cílené na systémy, které poskytují kontrolery ukládání do mezipamě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 zápisu do mezipaměti a subsystémy úložiště jsou bezpečné pro SQL Server, pokud jsou navrženy pro použití v systému řízení transakčních databází (DBMS) v kritickém prostředí. Tyto funkce návrhu musí zachovat data uložená v mezipaměti, pokud dojde k selhání systému. Použití externího nepřerušitelného zdroje napájení (UPS) k dosažení tohoto problému obecně nestačí, protože můžou nastat režimy selhání, které nesouvisejí s napájením.

Ř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 platformy zahrnují, jsou bezpečné. Měli byste ale zkontrolovat dodavatele hardwaru, abyste měli jistotu, ž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 transakce(RDBMS).

Protokolování před zápisem

Příkazy SQL Serveru pro úpravu dat generují logické zápisy na stránku. Tento proud zápisů lze představit jako směřující do dvou míst: do protokolu a samotné databáze. Z důvodů výkonu SQL Server odkládá zápis do databáze prostřednictvím svého vlastního systému vyrovnávací paměti. Zápisy do protokolu jsou pouze na okamžik odloženy do COMMIT. Nejsou uloženy do mezipaměti stejným způsobem jako zápisy dat. Vzhledem k tomu, že zápisy protokolu pro danou stránku vždy předchází zápisům dat stránky, protokol se někdy označuje jako protokol WAL (write-ahead ).

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.

Tato FILE_FLAG_WRITE_THROUGH možnost zajistí, že když operace zápisu vrátí úspěšné dokončení, budou data správně uložena ve stabilním úložišti. To odpovídá specifikaci protokolu WAL (Write Ahead Logging) pro zajištění 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 považovány za 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. Při každém restartování klientských pracovních stanic by uživatelé našli všechna jejich data, 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č ukládání do mezipaměti při zápisu není správně navržený pro použití v prostředí transakčního DBMS kritického pro data, může ohrozit schopnost SQL Serveru obnovit databázi, čímž ji ohrožuje. K tomu může dojít v případě, že kontroler zachytí zápisy do protokolu transakcí SQL Serveru a uloží je do mezipaměti v hardwarové vyrovnávací paměti na desce řadiče, ale během selhání systému tyto zapsané stránky v mezipaměti nezachová.

Ukládání do mezipaměti a kontrolery úložných zařízení

Většina řadičů mezipaměti úložných zařízení provádí ukládání zápisů do mezipaměti. Funkce ukládání do mezipaměti při zápisu nelze vždy zakázat.

I když server používá ups, 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 hardwarovou mezipaměť pro zápis, která bere v úvahu všechny možné příčiny odstranění neuložených dat mezipaměti, což by bylo bezpečné pro použití databázovým serverem. Některé z těchto funkcí návrhu by zahrnovaly zachycení signálu sběrnice RST, aby se zabránilo nechtěnému resetování řadiče paměti cache, integrovanou bateriovou zálohu a zrcadlení paměti nebo kontrolu a opravu chyb (ECC). 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í. To se často označuje jako vlastnosti ACID (Atomicity, Consistency, Isolation a Durability).

Tato část se zabývá dopady cache paměti úložiště. Doporučujeme, abyste si přečetli následující články ve znalostní bázi Microsoft Knowledge Base pro další objasnění diskuzí o ukládání do mezipaměti a alternativním režimu selhání:

Doporučuje se také následující dokumenty:

Tyto dva dokumenty platí pro všechny aktuálně podporované 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 nich umožňuje vytvořit procento mezipaměti pro čtení a zápis pro optimální výkon. Některé 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. To může výrazně zlepšit výkon databáze. Použití řešení ukládání do mezipaměti založeného na baterii poskytuje odolnost a konzistenci dat, která SQL Server očekává.

Implementace subsystému úložiště

Existuje mnoho typů implementací subsystému. Raid (redundantní pole nezávislých disků) a SÍŤ SAN (storage area network) jsou dvěma příklady těchto typů implementací subsystému. Tyto systémy jsou obvykle sestavené pomocí jednotek založených na rozhraní SCSI. Existuje několik důvodů. Následující část obecně 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 se vyrábí pro těžké použití.
  • Obvykle se zaměřují na víceuživatele, serverové implementace.
  • Obvykle mají lepší průměrné doby mezi selháním než jiné implementace.
  • Obsahují sofistikované heuristiky, které pomáhají předpovídat bezprostřední selhání.

Poznámka:

SQL Server je podporován na součástech technologie iSCSI (Internet Small Computer System Interface), které splňují požadavky programu Windows Hardware Compatibility Program. 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 tak může číst a zapisovat do vzdáleného úložiště na úrovni bloků napříč sítěmi IP. Vzhledem k tomu, že iSCSI závisí na sítích, můžete zaznamenat zpoždění nebo kritické body, takže byste měli optimalizovat výkon ukládání do mezipaměti serveru a minimalizovat latenci. 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:

  • Obvykle se vyrábí pro lehké a střední použití.
  • Obvykle se zaměřují na aplikace založené na jednom uživateli.

Ř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. Tím zůstane jeden disk nečinný, zatímco druhý disk 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šť

Existují situace, kdy je stolní jednotka nebo pole vhodným nízkonákladovým řešením. Pokud například nastavíte databázi určenou jen pro čtení pro vytváření sestav, neměli byste při zakázání ukládání do mezipaměti disku narazit na mnoho výkonových faktorů databáze OLTP.

Velikosti úložných zařízení se stále zvyšují. Nízká cena, vysokokapacitní disky mohou být atraktivní. Když ale nakonfigurujete jednotku pro SQL Server a požadavky na dobu odezvy vašeho podniku, měli byste pečlivě zvážit následující problémy:

  • 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 k dispozici 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í.

Ukládání jednotek do mezipaměti by mělo být zakázané, aby bylo možné jednotku používat s SQL Serverem. Ve výchozím nastavení je mezipaměť jednotek povolená. V systému Windows Server použijte kartu Vlastnosti disku>Hardware pro přístup na kartu Vlastnosti>Zásady k řízení nastavení mezipaměti jednotky.

Poznámka:

Některé jednotky toto nastavení nerespektují. Tyto jednotky vyžadují k zakázání mezipaměti konkrétní nástroj výrobce.

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

Výhody SAS zahrnují pokročilé řazení front až do 256 úrovní, řízení fronty na začátku a řazení front 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í.

SSD ú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. Úložiště solid-state je připojené 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 vykazují chyby náhodného bitu.
  • 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 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žišť SSD uvádí velikost sektorů 512 bajtů, ale používá 4 KB stránky uvnitř 1 MB vymazávacích bloků. 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ů

Technika, kterou jsme použili v minulosti, je zapsat známý vzor na celou jednotku. Když pak spustíme databázové aktivity na stejné jednotce, můžeme zjistit nesprávné chování (zastaralé čtení / ztráta zápisu / čtení nesprávného posunu / atd.), když se vzor neočekávaně objeví.

Tato technika nefunguje dobře na úložišti SSD. Operace mazání a Read-Modify-Write (RMW) při zápisech ničí vzor. Aktivity související s uvolňováním paměti úložiště SSD (GC), vyrovnávání opotřebení, bloky proporčního a vyhrazeného seznamu a další optimalizace mají tendenci způsobovat, že zápisy získávají různá fyzická umístění, na rozdíl od opětovného využití sektorů u 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 v režimu jen pro čtení po určitou dobu 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. To 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, což eliminuje dobu hledání. Mnoho polovodičových zařízení je navrženo tak, aby umožňovalo paralelní operace na různých blocích současně. To znamená, že defragmentace média ssd není nutná. 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. To může zlepšit výkon, snížit opotřebení disků a stupeň fyzické fragmentace.

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

  • Ujistěte se, že velikosti růstu souboru jsou 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

Dokud pohon 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.
  • Pečlivě si poslechněte pokyny výrobců hardwaru.

Úvahy o mezipaměti a SQLIOSim

Pokud chcete data plně zabezpečit, měli byste zajistit správné zpracování všech ukládání dat do mezipaměti. V mnoha situacích to znamená, že musíte zakázat cache zápisu 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í.

Microsoft provedl testování na několika jednotkách SCSI a IDE pomocí nástroje 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 a podrobnosti o SQLIOSim naleznete v tématu Použití nástroje SQLIOSim k simulaci aktivity SQL Server v subsystému disku.

Mnoho výrobců počítačů objednává jednotky se zakázanou mezipamětí zápisu. Testování ale ukazuje, že to nemusí být vždy případ, takže byste ho měli vždy otestovat úplně. Pokud máte jakékoli dotazy týkající se stavu ukládání do mezipaměti vašeho úložného zařízení, obraťte se na výrobce a získejte příslušná nastavení softwareového nástroje nebo jumperu, abyste zakázali operace zápisu do mezipaměti.

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

Související obsah

  • Last updated on