I/O-subsysteemvereisten voor Microsoft SQL Server voor de tempdb-database

In dit artikel worden de I/O-subsysteemvereisten voor de tempdb-database in SQL Server geïntroduceerd.

Oorspronkelijke productversie: Microsoft SQL Server
Oorspronkelijk KB-nummer: 917047

Samenvatting

Microsoft SQL Server vereist dat het I/O-subsysteem dat wordt gebruikt voor het opslaan van systeem- en gebruikersdatabases, volledig voldoet aan de vereisten voor Write-Ahead Logging (WAL) via specifieke I/O-principals. Deze vereisten zijn nodig om de ACID-eigenschappen van transacties te respecteren: Atomisch, Consistent, Geïsoleerd en Duurzaam. Meer informatie over nalevingsvereisten voor I/O-subsystemen vindt u in de basisbeginselen van SQL Server I/O.

De volgende lijst is een kort overzicht van de vereisten:

  • Schrijfvolgorde moet worden gehandhaafd.
  • De consistentie van afhankelijke schrijfbewerkingen moet behouden blijven.
  • Schrijfbewerkingen moeten altijd worden beveiligd in/op stabiele media.
  • I/O-preventie moet worden gescheurd.

Onderhoud van duurzaamheid blijft essentieel voor alle andere databases, maar is mogelijk ontspannen voor de tempdb-database. De volgende tabel bevat een overzicht van verschillende essentiële I/O-vereisten voor SQL Server-databases.

I/O-vereiste Korte beschrijving Systeem of gebruiker tempdb
Schrijfvolgorde

Afhankelijke schrijfconsistentie		 De mogelijkheid van het subsysteem om de juiste volgorde van schrijfbewerkingen te behouden. Dit kan met name belangrijk zijn voor het spiegelen van oplossingen, vereisten voor groepsconsistentie en het gebruik van HET SQL Server WAL-protocol. Vereist Aanbevolen
Lezen na schrijven De mogelijkheid van het subsysteem voor het verwerken van leesaanvragen met de meest recente gegevensinstallatiekopieën wanneer de leesbewerking is uitgegeven nadat een schrijfbewerking is voltooid. Vereist Vereist
Overleven tijdens storing De mogelijkheid voor gegevens om volledig intact te blijven (Duurzaam) tijdens een storing, zoals het opnieuw opstarten van het systeem. Vereist Niet van toepassing
Gescheurde I/O-preventie De mogelijkheid van het systeem om te voorkomen dat afzonderlijke I/O-aanvragen worden gesplitst. Vereist Aanbevolen
Herschrijven van sector De sector kan alleen in zijn geheel worden geschreven en kan niet opnieuw worden geschreven vanwege een schrijfaanvraag voor een nabijgelegen sector. * Afgeraden, alleen toegestaan als transactioneel * Afgeraden, alleen toegestaan als transactioneel
Geharde gegevens De verwachting dat wanneer een schrijfaanvraag of een FlushFileBuffers-bewerking is voltooid, gegevens zijn opgeslagen op stabiele media. Vereist Niet van toepassing
Uitlijning en grootte van fysieke sector SQL Server ondervraagt de opslaglocaties voor gegevens- en logboekbestanden. Alle apparaten zijn vereist om sectorkenmerken te ondersteunen waarmee SQL Server schrijfbewerkingen kan uitvoeren op fysieke sectorgrenzen en in veelvouden van de sectorgrootte. Vereist Vereist

Herschrijven van transactionele sector omvat volledig geregistreerde bewerkingen door het subsysteem toe te staan dat een sector volledig kan worden verplaatst, vervangen of teruggedraaid naar de oorspronkelijke afbeelding. Deze herschrijven worden doorgaans afgeraden vanwege de extra overhead die nodig is om dergelijke acties uit te voeren. Een voorbeeld hiervan is een defragmentation hulpprogramma waarmee de bestandsgegevens worden verplaatst. De oorspronkelijke sector in het bestand kan niet worden vervangen door de nieuwe sectorlocatie totdat de nieuwe sector en gegevens zijn beveiligd. Het opnieuw toewijzen van de sector moet op transactionele wijze plaatsvinden, zodat elke storing, met inbegrip van een stroomstoring, de oorspronkelijke gegevens opnieuw tot stand brengt. Zorg ervoor dat er tijdens dit soort processen vergrendelingsmechanismen beschikbaar zijn om ongeldige gegevenstoegang te voorkomen, waardoor de andere tenants van SQL Server I/O worden gehandhaafd.

Overleven tijdens storing

De tempdb-database is een kladgebied voor SQL Server en wordt opnieuw opgebouwd bij elke SQL Server-opstartbewerking. De initialisatie vervangt alle noodzaak van gegevens om een herstart te overleven.

Herschrijfbewerkingen voor transactionele sector

Om het succes van de herstelprocessen te garanderen, zoals terugdraaien en crashherstel, moeten de logboekrecords correct worden opgeslagen op stabiele media voordat de gegevenspagina wordt opgeslagen en kunnen ze niet opnieuw worden geschreven zonder transactionele eigenschappen te respecteren. Hiervoor moeten het subsysteem en SQL Server specifieke kenmerken onderhouden, zoals schrijfvolgorde, schrijfbewerkingen die zijn afgestemd op de sector en de grootte van schrijfbewerkingen, en andere dergelijke I/O-veiligheidskenmerken die worden beschreven in de eerder genoemde documenten. Voor de tempdb-database is het crashherstel niet nodig omdat de database altijd wordt geïnitialiseerd tijdens het opstarten van SQL Server. Voor de tempdb-database zijn echter nog steeds terugdraaimogelijkheden vereist. Daarom kunnen sommige kenmerken van het WAL-protocol ontspannen.

De opslaglocatie voor de tempdb-database moet strikt handelen volgens de vastgestelde protocollen voor schijfstations. Op alle manieren moet het apparaat waarop de tempdb-database is opgeslagen, worden weergegeven en fungeren als een fysieke schijf die lezen na schrijfmogelijkheden biedt. Herschrijfbewerkingen in transactiesector kunnen een extra vereiste zijn voor specifieke implementaties. SQL Server biedt bijvoorbeeld geen ondersteuning voor databasewijzigingen met behulp van NTFS-bestandssysteemcompressie, omdat NTFS-compressie sectoren van het logboek kan herschrijven die al zijn geschreven en als beveiligd worden beschouwd. Een fout tijdens dit type herschrijven kan ertoe leiden dat de database onbruikbaar is, waardoor gegevens die SQL Server al als veilig beschouwd, beschadigd zijn.

Notitie

SQL Server biedt uitgebreide ondersteuning of compressie voor alleen-lezen databases en bestandsgroepen. Zie sql Server Books Online voor volledige informatie.

Herschrijfbewerkingen voor transactionele sector zijn relevant voor alle SQL Server-databases die de tempdb-database bevatten. Een groeiende verscheidenheid aan uitgebreide opslagtechnologieën maken gebruik van apparaten en hulpprogramma's die gegevens kunnen herschrijven die door SQL Server als veilig worden beschouwd. Sommige van de opkomende technologieën voeren bijvoorbeeld in-memory caching of gegevenscompressie uit. Om ernstige databaseschade te voorkomen, moet elke herschrijfbewerking van de sector volledige transactionele ondersteuning hebben op een zodanige manier dat als er een storing optreedt, de gegevens worden teruggedraaid naar de vorige sectorafbeeldingen. Dit garandeert dat SQL Server nooit wordt blootgesteld aan een onverwachte onderbreking of gegevensschade.

Mogelijk kunt u de tempdb-database op speciale subsystemen plaatsen, zoals RAM-schijven, solid state of andere snelle implementaties die niet kunnen worden gebruikt voor andere databases. De belangrijkste factoren die worden weergegeven in de sectie Meer informatie , moeten echter worden overwogen wanneer u deze opties evalueert.

Notitie

De lokale schijven in failoverclusteromgevingen worden alleen ondersteund met solid state- of high speed-implementaties. Dit komt doordat de RAM-schijf alleen kan worden gemaakt via een iSCSI-doel. Daarnaast kunnen de functies van het iSCSI-doel en failovercluster niet op dezelfde host worden gebruikt.

Meer informatie

Er moeten verschillende factoren zorgvuldig worden bestudeerd wanneer u de opslaglocatie van de tempdb-database evalueert. Het gebruik van de tempdb-database omvat bijvoorbeeld, maar is niet beperkt tot beslissingen over geheugenvoetafdruk, queryplan en I/O. De juiste afstemming en implementatie van de tempdb-database kan de schaalbaarheid en reactiesnelheid van een systeem verbeteren. In deze sectie worden de belangrijkste factoren besproken bij het bepalen van de opslagbehoeften voor de tempdb-database.

Snelle subsystemen

Er zijn verschillende high-speed subsysteem-implementaties beschikbaar op de markt die sql Server I/O-subsysteemprotocolvereisten bieden, maar die geen duurzaamheid van de media bieden.

Belangrijk

Bevestig altijd bij de productleverancier om volledige naleving van I/O-behoeften van SQL Server te garanderen.

Een RAM-schijf is een veelvoorkomend voorbeeld van een dergelijke implementatie. RAM-schijven installeren de benodigde stuurprogramma's en zorgen ervoor dat een deel van de hoofd-RAM-schijf wordt weergegeven als een schijfstation dat aan het systeem is gekoppeld. Alle I/O-subsystemen moeten volledige naleving bieden van de I/O-vereisten voor SQL Server. Het is echter duidelijk dat een RAM-schijf geen duurzame media is. Daarom kan een implementatie zoals een RAM-schijf alleen worden gebruikt als de locatie van de tempdb-database en kan deze niet worden gebruikt voor een andere database.

Sleutels om rekening mee te houden vóór implementatie en implementatie

Er zijn verschillende punten om rekening mee te houden voordat de tempdb-database op dit type subsysteem wordt geïmplementeerd. In deze sectie wordt een RAM-schijf gebruikt als basis voor discussie, maar er treden vergelijkbare resultaten op in andere implementaties met hoge snelheid.

I/O-veiligheid

De naleving van leesbewerkingen na schrijf- en transactionele schrijfbewerkingen is een must. Implementeer nooit SQL Server op een systeem dat niet volledig ondersteuning biedt voor de I/O-vereisten van SQL Server, of u riskeer schade en verlies van uw gegevens.

Pagina's die al in de cache zijn opgeslagen (dubbele RAM-cache)

Tijdelijke tabellen zijn net als alle andere tabellen in een database. Ze worden in de cache opgeslagen door de buffergroep en verwerkt door luie schrijfbewerkingen. Het opslaan van tijdelijke tabelpagina's op een RAM-schijf veroorzaakt dubbele RAM-cache, één in de buffergroep en één op de RAM-schijf. Dit neemt rechtstreeks weg van de totale mogelijke grootte van de buffergroep en vermindert doorgaans de prestaties van SQL Server.

RAM-geheugen opgeven

De RAM-schijf wijst een deel van het hoofd-RAM-geheugen aan zoals de naam al aangeeft. Er zijn verschillende implementaties van RAM-schijven en RAM-bestandencaches beschikbaar. Sommige schakelen ook fysieke I/O-backingbewerkingen in. Het belangrijkste element van de RAM-bestandscache is dat het rechtstreeks wegneemt van het fysieke geheugen dat kan worden gebruikt door SQL Server. Altijd sterk bewijs dat het toevoegen van een RAM-bestandscache de prestaties van de toepassing verbetert en geen andere query- of toepassingsprestaties vermindert.

Eerst afstemmen

Een toepassing moet afstemmen om onnodige en ongewenste sorteringen en hashes te verwijderen die het gebruik van de tempdb-database kunnen veroorzaken. Vaak kan de toevoeging van een index de noodzaak voor de sortering of hash in het plan volledig verwijderen, wat leidt tot optimale prestaties zonder het gebruik van de tempdb-database.

Mogelijke voordeelpunten

De voordelen van het plaatsen van de tempdb-database op een systeem met hoge snelheid kunnen alleen worden bepaald door strenge tests en metingen van de toepassingsworkloads. De workload moet zorgvuldig worden bestudeerd voor de kenmerken waarvan de tempdb-database kan profiteren en de I/O-veiligheid moet vóór de implementatie worden bevestigd.

De sorteer- en hashbewerkingen werken samen met de SQL Server-geheugenbeheerders om de grootte van het scratchgebied in het geheugen te bepalen voor elke sorteer- of hashbewerking. Zodra de sorteer- of hashgegevens het toegewezen scratchgebied in het geheugen overschrijden, kunnen gegevens naar de tempdb-database worden geschreven. Dit algoritme is uitgebreid in SQL Server, waardoor de gebruiksvereisten voor tempdb-databases ten opzichte van eerdere versies van SQL Server worden verminderd.

Let op

SQL Server is ontworpen om rekening te houden met geheugenniveaus en huidige queryactiviteiten bij het nemen van beslissingen over queryplannen die betrekking hebben op het gebruik van tempdb-databasebewerkingen. De prestatieverbeteringen variëren daarom aanzienlijk op basis van workloads en toepassingsontwerp. We raden u ten zeerste aan om het testen met de voorkeursoplossing te voltooien om mogelijke voordelen te bepalen en I/O-veiligheidsvereisten te evalueren voordat een dergelijke implementatie wordt uitgevoerd.

SQL Server maakt gebruik van de tempdb-database voor het afhandelen van verschillende activiteiten met betrekking tot sorteringen, hashes, het archief met rijversies en tijdelijke tabellen:

  • Tijdelijke tabellen worden onderhouden door de algemene buffergroeproutines voor gegevenspagina's en vertonen over het algemeen geen prestatievoordelen van speciale subsysteem-implementaties.
  • De tempdb-database wordt gebruikt als een scratchgebied voor hashes en sorteringen. Het verminderen van de I/O-latentie voor dergelijke bewerkingen kan nuttig zijn. Weet echter dat het toevoegen van een index om een hash of een sortering te voorkomen een vergelijkbaar voordeel kan bieden.

Voer basislijnen uit met en zonder de tempdb-database die is opgeslagen op het subsysteem met hoge snelheid om de voordelen te vergelijken. Een deel van de test moet query's bevatten voor de gebruikersdatabase waarvoor geen sortering, hashes of tijdelijke tabellen nodig zijn en controleer vervolgens of deze query's niet nadelig worden beïnvloed. Wanneer u het systeem evalueert, kunnen de volgende prestatie-indicatoren nuttig zijn.

Aanwijzer Beschrijving/gebruik
Pagina-lees- en schrijfbewerkingen Het verbeteren van de prestaties van de tempdb-database-I/Os kan de snelheid van paginalees- en schrijfbewerkingen voor de gebruikersdatabases wijzigen vanwege de verminderde latentie die is gekoppeld aan de tempdb-database-I/O. Voor gebruikersdatabasepagina's mag het totale aantal niet verschillen tussen dezelfde werkbelasting.
Fysieke lees- en schrijfbytes naar de tempdb-database Als u de tempdb-database verplaatst naar een apparaat, zoals een RAM-schijf, verhoogt u de werkelijke I/O voor de tempdb-database, wordt aangegeven dat het geheugen dat uit de buffergroep wordt gehaald, leidt tot een verhoogde tempdb-databaseactiviteit. Dit patroon is een indicator dat de levensverwachting van de pagina's van databasepagina's ook negatief kan worden beïnvloed.
Levensverwachting van pagina Een afname van de levensverwachting van pagina's kan duiden op een toename van de fysieke I/O-vereisten voor een gebruikersdatabase. De snelheidsvermindering kan waarschijnlijk aangeven dat het geheugen dat uit de buffergroep is gehaald, databasepagina's dwingt om de buffergroep voortijdig af te sluiten. Combineer met de andere indicatoren en test om de parametergrenzen volledig te begrijpen.
Totale doorvoer
CPU-gebruik
Schaalbaarheid
Responstijd		 Het primaire doel van een wijziging in de tempdb-databaseconfiguratie is het verhogen van de totale doorvoer. Uw tests moeten bestaan uit een combinatie van herhaalbare workloads die kunnen worden uitgeschaald om te bepalen hoe de doorvoer wordt beïnvloed.

Iets als een implementatie van een RAM-schijf op basis van compressie werkt mogelijk goed met 10 gebruikers. Met een verhoogde workload kan dit echter CPU-niveaus buiten de gewenste niveaus pushen en negatieve gevolgen hebben voor de reactietijd wanneer de workloads hoog zijn. Echte stresstests en toekomstige belastingvoorspellingstests worden aangemoedigd.
Acties voor het maken van werkbestanden en werktabellen Als u de tempdb-database verplaatst naar een apparaat, zoals een RAM-schijf, wijzigt u het queryplan door het aantal of de grootte van werkbestanden of werktabellen te verhogen, wordt aangegeven dat het geheugen dat uit de buffergroep is gehaald, een verhoogde tempdb-databaseactiviteit veroorzaakt. Dit patroon is een indicatie dat de levensverwachting van de pagina's van databasepagina's ook negatief kan worden beïnvloed.

Voorbeeld van herschrijven van transactionele sector

In het volgende voorbeeld wordt de gegevensbeveiliging uitgebreid die is vereist voor SQL Server-databases.

Stel dat een leverancier van een RAM-schijf gebruikmaakt van een in-memory compressie-implementatie. De implementatie moet correct worden ingekapseld door het fysieke uiterlijk van de bestandsstroom te bieden alsof de sector is uitgelijnd en de grootte ervan is aangepast, zodat SQL Server zich niet bewust en correct is beveiligd vanuit de onderliggende implementatie. Bekijk het voorbeeld van compressie dichterbij.

  • Sector 1 wordt naar het apparaat geschreven en wordt gecomprimeerd om ruimte te besparen.
  • Sector 2 wordt naar het apparaat geschreven en wordt gecomprimeerd met sector 1 om ruimte te besparen.

Het apparaat kan de volgende acties uitvoeren om de gegevens van sector 1 te beveiligen wanneer het wordt gecombineerd met de gegevens van sector 2.

  • Alle schrijfbewerkingen naar sectoren 1 en 2 blokkeren.
  • Hef decomprimerende sector 1 op in een kladgebied, waardoor de huidige sector 1 opslag blijft staan als de actieve gegevens die moeten worden opgehaald.
  • Comprimeer sectoren 1 en 2 in een nieuwe opslagindeling.
  • Alle lees- en schrijfbewerkingen van sectoren 1 en 2 blokkeren.
  • Oude opslag inwisselen voor sectoren 1 en 2 met nieuwe opslag. Als de exchange-poging mislukt (terugdraaien):
    • Herstel de oorspronkelijke opslag voor sectoren 1 en 2.
    • Verwijder de sectoren 1 en 2 gecombineerde gegevens uit het scratchgebied.
    • Mislukt de schrijfbewerking van sector 2.
  • Lees- en schrijfbewerkingen opheffen voor sectoren 1 en 2.

De mogelijkheid om vergrendelingsmechanismen rond de sectorwijzigingen te bieden en de wijzigingen terug te draaien wanneer de poging tot uitwisseling van de sector mislukt, wordt beschouwd als overgangsconform. Voor implementaties die gebruikmaken van fysieke opslag voor uitgebreide back-up, zou het de juiste aspecten van het transactielogboek bevatten om wijzigingen die zijn toegepast op de on-disk structuren te beveiligen en terug te draaien om de integriteit van de SQL Server-databasebestanden te behouden.

Elk apparaat dat het herschrijven van sectoren mogelijk maakt, moet de herschrijven op transactionele wijze ondersteunen, zodat SQL Server niet wordt blootgesteld aan gegevensverlies.

Notitie

Het exemplaar van SQL Server wordt opnieuw opgestart wanneer online-I/O- en terugdraaifouten optreden in de tempdb-database.

Wees voorzichtig wanneer u de tempdb-database verplaatst

Wees voorzichtig wanneer u de tempdb-database verplaatst, omdat als de tempdb-database niet kan worden gemaakt, SQL Server niet wordt gestart. Als de tempdb-database niet kan worden gemaakt, start u SQL Server met behulp van de opstartparameter (-f) en verplaatst u de tempdb-database naar een geldige locatie.

Voer de volgende stappen uit om de fysieke locatie van de tempdb-database te wijzigen:

  1. Gebruik de ALTER DATABASE instructie en de MODIFY FILE component om de namen van fysieke bestanden van elk bestand in de tempdb-database te wijzigen om te verwijzen naar de nieuwe fysieke locatie, zoals de nieuwe schijf.

    ALTER DATABASE tempdb MODIFY FILE 
(name = tempdev, filename = 'C:\MyPath\tempdb.mdf')

ALTER DATABASE tempdb MODIFY FILE 
(name = templog, filename = 'C:\MyPath\templog.ldf')

  2. Stop en start SQL Server opnieuw op.

Partnerproductcertificeringen zijn geen garantie voor compatibiliteit of veiligheid

Een product van derden of een bepaalde leverancier kan een Microsoft-logocertificering ontvangen. Partnercertificering of een specifiek Microsoft-logo certificeert echter geen compatibiliteit of geschiktheid voor een bepaald doel in SQL Server.

Ondersteuning

Als u een subsysteem gebruikt met SQL Server dat ondersteuning biedt voor de I/O-garanties voor het gebruik van transactionele databases, zoals beschreven in dit artikel, biedt Microsoft ondersteuning voor SQL Server- en SQL Server-toepassingen. Problemen met of veroorzaakt door het subsysteem worden echter naar de fabrikant verwezen.

Voor problemen met betrekking tot tempdb-databases vraagt Microsoft Ondersteuning Services u om de tempdb-database te verplaatsen. Neem contact op met de leverancier van uw apparaat om te controleren of u het apparaat correct hebt geïmplementeerd en geconfigureerd voor gebruik van transactionele databases.

Microsoft certificeert of valideert niet of producten van derden correct werken met SQL Server. Daarnaast biedt Microsoft geen garantie, garantie of verklaring van de geschiktheid van een product van derden voor gebruik met SQL Server.

Verwijzingen

Voor meer informatie, zie:

  • Last updated on