Beschrijving van algoritmen voor logboekregistratie en gegevensopslag waarmee de betrouwbaarheid van gegevens in SQL Server wordt uitgebreid
Oorspronkelijke productversie: SQL Server 2014, SQL Server 2012, SQL Server 2008, SQL Server 2005
Oorspronkelijk KB-nummer: 230785
Samenvatting
In dit artikel wordt beschreven hoe logboekregistratie en gegevensalgoritmen van Microsoft SQL Server de betrouwbaarheid en integriteit van gegevens uitbreiden.
Zie het volgende document ACM-transacties op databasesystemen (onder Volume 17, Number 1, Maart 1992) voor meer informatie over de onderliggende concepten van de engines en over Algorithm for Recovery and Isolation Exploiting Semantics (ARIES):
Externe koppeling: ARIES: een methode voor transactieherstel ter ondersteuning van fine-granulariteitsvergrendeling en gedeeltelijke terugdraaiacties met behulp van write-ahead-logboekregistratie
In het document worden de SQL Server-technieken beschreven om de betrouwbaarheid en integriteit van gegevens uit te breiden als het gaat om fouten.
We raden u aan de volgende artikelen in de Microsoft Knowledge Base te lezen voor meer informatie over discussies in de cache en alternatieve foutmodus:
Termen die in dit artikel worden gebruikt
Voordat we beginnen met de uitgebreide discussie, worden sommige termen die in dit artikel worden gebruikt, gedefinieerd in de volgende tabel.
WAL-protocol (Write-Ahead Logging)
Het termprotocol is een uitstekende manier om WAL te beschrijven. Het is een specifieke en gedefinieerde set implementatiestappen die nodig zijn om ervoor te zorgen dat gegevens worden opgeslagen en correct worden uitgewisseld en kunnen worden hersteld naar een bekende status als er een fout optreedt. Net zoals een netwerk een gedefinieerd protocol bevat voor het uitwisselen van gegevens op een consistente en beveiligde manier, beschrijft de WAL ook het protocol om gegevens te beveiligen.
Het ARIES-document definieert de WAL als volgt:
Het WAL-protocol bevestigt dat de logboekrecords die wijzigingen in sommige gegevens vertegenwoordigen, al in stabiele opslag moeten zijn voordat de gewijzigde gegevens de vorige versie van de gegevens in niet-compatibele opslag mogen vervangen. Dat wil wel dat het systeem geen bijgewerkte pagina mag schrijven naar de niet-compatibele opslagversie van de pagina totdat ten minste de gedeelten van de logboekrecords ongedaan worden gemaakt, waarin de updates voor de pagina zijn geschreven naar stabiele opslag.
Zie het onderwerp Write-Ahead Transaction Log op SQL Server Books Online voor meer informatie over logboekregistratie voor write-ahead.
SQL Server en de WAL
SQL Server maakt gebruik van het WAL-protocol. Om ervoor te zorgen dat een transactie correct wordt doorgevoerd, moeten alle logboekrecords die aan de transactie zijn gekoppeld, worden beveiligd in stabiele opslag.
Bekijk het volgende specifieke voorbeeld om deze situatie te verduidelijken.
Notitie
In dit voorbeeld wordt ervan uitgegaan dat er geen index is en dat de betreffende pagina pagina 150 is.
BEGIN TRANSACTION
INSERT INTO tblTest VALUES (1)
COMMIT TRANSACTION
Vervolgens kunt u de activiteit opsplitsen in eenvoudige logboekregistratiestappen, zoals beschreven in de volgende tabel.
| Instructie | Uitgevoerde acties |
|---|---|
| TRANSACTIE STARTEN | Geschreven naar het logboekcachegebied. Het is echter niet nodig om naar stabiele opslag te worden leeggemaakt omdat de SQL Server geen fysieke wijzigingen heeft aangebracht. |
| INSERT INTO tblTest | 1. Gegevenspagina 150 wordt opgehaald in sql Server-gegevenscache, indien nog niet beschikbaar. 2. De pagina wordt vergrendeld, vastgemaakt en gemarkeerd vuil, en de juiste sloten worden verkregen. 3. Er wordt een record voor het invoegen van logboeken gemaakt en toegevoegd aan de logboekcache. 4. Er wordt een nieuwe rij toegevoegd aan de gegevenspagina. 5. De vergrendeling wordt losgelaten. 6. De logboekrecords die zijn gekoppeld aan de transactie of pagina hoeven op dit moment niet te worden leeggemaakt, omdat alle wijzigingen in vluchtige opslag aanwezig blijven. |
| DOORVOERTRANSACTIE | 1. Er wordt een doorvoerlogboekrecord gevormd en de logboekrecords die aan de transactie zijn gekoppeld, moeten naar stabiele opslag worden geschreven. De transactie wordt pas als doorgevoerd beschouwd als de logboekrecords correct zijn toegewezen aan stabiele opslag. 2. Gegevenspagina 150 blijft in sql Server-gegevenscache en wordt niet onmiddellijk leeggemaakt naar stabiele opslag. Wanneer de logboekrecords correct zijn beveiligd, kan herstel de bewerking opnieuw uitvoeren als dit nodig is. 3. Transactionele vergrendelingen worden vrijgegeven. |
Verwar niet de termen 'vergrendelen' en 'logboekregistratie'. Hoewel belangrijk, vergrendelen en logboekregistratie afzonderlijke problemen zijn wanneer u met de WAL omgaat. In het vorige voorbeeld bevat SQL Server over het algemeen de vergrendeling op pagina 150 die nodig is om de fysieke invoegwijzigingen op de pagina uit te voeren, niet de volledige tijd van de transactie. Het juiste vergrendelingstype wordt ingesteld om de rij, het bereik, de pagina of de tabel zo nodig te beveiligen. Raadpleeg de secties sql Server Books Online-vergrendeling voor meer informatie over vergrendelingstypen.
Als u het voorbeeld in meer detail bekijkt, kunt u vragen wat er gebeurt wanneer de LazyWriter- of CheckPoint-processen worden uitgevoerd. SQL Server problemen met alle geschikte flushes naar stabiele opslag voor transactionele logboekrecords die zijn gekoppeld aan de vervuilde en vastgemaakte pagina. Dit zorgt ervoor dat de gegevenspagina van het WAL-protocol nooit naar stabiele opslag kan worden geschreven totdat de bijbehorende transactionele logboekrecords zijn leeggemaakt.
SQL Server en stabiele opslag
SQL Server verbetert logboek- en gegevenspaginabewerkingen door de kennis van schijfsectorgrootten (meestal 4.096 bytes of 512 bytes) op te nemen.
Als u de ACID-eigenschappen van een transactie wilt behouden, moet de SQL Server rekening houden met storingspunten. Tijdens een storing garanderen veel schijfstationspecificaties slechts een beperkt aantal schrijfbewerkingen in de sector. De meeste specificaties garanderen dat schrijfbewerkingen in één sector worden voltooid wanneer er een storing optreedt.
SQL Server maakt gebruik van 8 KB-gegevenspagina's en het logboek (indien leeggemaakt) op veelvouden van de sectorgrootte. (De meeste schijfstations gebruiken 512 bytes als standaardsectorgrootte.) Als er een fout optreedt, kan SQL Server rekening houden met schrijfbewerkingen die groter zijn dan een sector door gebruik te maken van logboekpariteit en gescheurde schrijftechnieken.
Detectie van gescheurde pagina's
Met deze optie kan SQL Server onvolledige I/O-bewerkingen detecteren die worden veroorzaakt door stroomstoringen of andere systeemstoringen. Wanneer waar, wordt er een beetje gespiegeld voor elke sector van 512 bytes op een databasepagina van 8 kilobyte (KB) wanneer de pagina naar de schijf wordt geschreven. Als een bit de verkeerde status heeft wanneer de pagina later wordt gelezen door SQL Server, is de pagina onjuist geschreven; er wordt een gescheurde pagina gedetecteerd. Tijdens het herstel worden gescheurde pagina's gedetecteerd omdat een pagina die onjuist is geschreven waarschijnlijk wordt gelezen door herstel.
Hoewel sql Server-databasepagina's 8 kB zijn, voeren schijven I/O-bewerkingen uit met behulp van een sector van 512 bytes. Daarom worden er 16 sectoren per databasepagina geschreven. Er kan een gescheurde pagina optreden als het systeem uitvalt (bijvoorbeeld vanwege een stroomstoring) tussen de tijd dat het besturingssysteem de eerste 512-byte-sector naar schijf schrijft en de voltooiing van de I/O-bewerking van 8 kB. Als de eerste sector van een databasepagina is geschreven voordat de fout optreedt, wordt de databasepagina op schijf weergegeven als bijgewerkt, hoewel deze mogelijk niet is geslaagd.
Door gebruik te maken van caches met schijfcontroller met batterijsteun, kunt u ervoor zorgen dat gegevens naar schijf zijn geschreven of helemaal niet zijn geschreven. In deze situatie stelt u de detectie van gescheurde pagina's niet in op 'true' omdat dit niet nodig is.
Notitie
Paginadetectie voor gescheurde pagina's is niet standaard ingeschakeld in SQL Server. Zie ALTER DATABASE SET Options (Transact-SQL) voor meer informatie.
Logboekpariteit
Controle van logboekpariteit is vergelijkbaar met de detectie van gescheurde pagina's. Elke sector van 512 bytes bevat pariteits bits. Deze pariteitsbits worden altijd geschreven met de logboekrecord en geëvalueerd wanneer de logboekrecord wordt opgehaald. Door logboekschrijfbewerkingen af te dwingen op een grens van 512 bytes, kan SQL Server ervoor zorgen dat doorvoerbewerkingen naar de fysieke schijfsectoren worden geschreven.
Gevolgen voor prestaties
Alle versies van SQL Server openen het logboek en gegevensbestanden met behulp van de functie Win32 CreateFile. Het lid dwFlagsAndAttributes bevat de FILE_FLAG_WRITE_THROUGH optie wanneer ze worden geopend door SQL Server.
FILE_FLAG_WRITE_THROUGH geeft het systeem de opdracht om door een tussenliggende cache te schrijven en rechtstreeks naar de schijf te gaan. Het systeem kan nog steeds schrijfbewerkingen in de cache opslaan, maar kan ze niet lui leegmaken.
De FILE_FLAG_WRITE_THROUGH optie zorgt ervoor dat wanneer een schrijfbewerking een geslaagde voltooiing retourneert, de gegevens correct worden opgeslagen in stabiele opslag. Dit komt overeen met het WAL-protocol dat ervoor zorgt dat de gegevens worden gegarandeerd.
Veel schijfstations (SCSI en IDE) bevatten onboardcaches van 512 KB, 1 MB of groter. De stationscaches zijn echter meestal afhankelijk van een condensator en niet van een oplossing met batterijsteun. Deze cachingmechanismen kunnen geen schrijfbewerkingen garanderen voor een stroomcyclus of een vergelijkbaar storingspunt. Ze garanderen alleen de voltooiing van de schrijfbewerkingen in de sector. Dit is met name waarom de detectie van gescheurde schrijf- en logboekpariteit is ingebouwd in SQL Server 7.0 en latere versies. Naarmate de stations steeds groter worden, worden de caches groter en kunnen ze grotere hoeveelheden gegevens beschikbaar maken tijdens een fout.
Veel hardwareleveranciers bieden oplossingen voor schijfcontrollers met batterijsteun. Deze controllercaches kunnen de gegevens enkele dagen in de cache onderhouden en zelfs toestaan dat de cachehardware op een tweede computer wordt geplaatst. Wanneer de stroom correct wordt hersteld, worden de niet-geschreven gegevens leeggemaakt voordat verdere gegevenstoegang is toegestaan. Veel daarvan maken het mogelijk om een percentage lees- en schrijfcache tot stand te brengen voor optimale prestaties. Sommige bevatten grote geheugenopslaggebieden. In feite bieden sommige hardwareleveranciers voor een specifiek segment van de markt high-end schijfcachingcontrollersystemen met een cache van 6 GB aan cache. Deze kunnen de databaseprestaties aanzienlijk verbeteren.
Geavanceerde caching-implementaties verwerken de FILE_FLAG_WRITE_THROUGH aanvraag door de controllercache niet uit te schakelen, omdat ze echte herschrijfmogelijkheden kunnen bieden in het geval van een systeemherstel, stroomstoring of een ander storingspunt.
I/O-overdrachten zonder het gebruik van een cache kunnen langer zijn vanwege de mechanische tijd die nodig is om de aandrijfkoppen, spinsnelheden en andere beperkende factoren te verplaatsen.
Sectorvolgorde
Een veelgebruikte techniek die wordt gebruikt om de I/O-prestaties te verhogen, is sectorvolgorde. Om mechanische hoofdbewegingen te voorkomen, worden de lees-/schrijfaanvragen gesorteerd, waardoor een consistentere beweging van het hoofd gegevens kan ophalen of opslaan.
De cache kan meerdere aanvragen voor logboek- en gegevensschrijfbewerkingen tegelijk bevatten. Voor het WAL-protocol en de SQL Server-implementatie van het WAL-protocol moeten de logboekschrijfbewerkingen worden leeggemaakt naar stabiele opslag voordat de pagina-schrijfbewerking kan worden uitgegeven. Het gebruik van de cache kan echter een succes retourneren van een aanvraag voor het schrijven van logboeken zonder dat de gegevens naar het werkelijke station worden geschreven (dat wil gezegd, geschreven naar stabiele opslag). Dit kan ertoe leiden dat sql Server de schrijfaanvraag voor de gegevenspagina uitgeeft.
Met de betrokkenheid van de schrijfcache worden de gegevens nog steeds beschouwd als vluchtige opslag. Vanuit de Win32 API WriteFile-aanroep is echter precies hoe SQL Server de activiteit ziet, een geslaagde retourcode verkregen. SQL Server of een proces dat gebruikmaakt van de WriteFile-API-aanroep kan alleen bepalen of de gegevens een stabiele opslag hebben verkregen.
Voor discussiedoeleinden wordt ervan uitgegaan dat alle sectoren van de gegevenspagina worden gesorteerd om te schrijven vóór de sectoren van de overeenkomende logboekrecords. Dit schendt onmiddellijk het WAL-protocol. De cache schrijft een gegevenspagina vóór de logboekrecords. Tenzij de cache volledig door de batterij wordt ondersteund, kan een storing onherstelbare resultaten veroorzaken.
Wanneer u de optimale prestatiefactoren voor een databaseserver evalueert, zijn er veel factoren die u moet overwegen. Het belangrijkste hiervan is: 'Staat mijn systeem geldige FILE_FLAG_WRITE_THROUGH mogelijkheden toe?'
Notitie
Elke cache die u gebruikt, moet een oplossing met batterijondersteuning volledig ondersteunen. Alle andere cachemechanismen zijn gevoelig voor gegevensbeschadiging en gegevensverlies. SQL Server doet er alles aan om ervoor te zorgen dat de WAL wordt ingeschakeld FILE_FLAG_WRITE_THROUGH.
Testen heeft aangetoond dat veel schijfstationconfiguraties schrijfcache kunnen bevatten zonder de juiste back-up van de batterij. SCSI-, IDE- en EIDE-stations profiteren optimaal van schrijfcaches. Zie het volgende blogartikel over CSS SQL Server Engineers voor meer informatie over hoe SSD's samenwerken met SQL Server:
SQL Server en SSDs - Leernotities van RDORR - deel 1
In veel configuraties is de enige manier om de schrijfcaching van een IDE- of EIDE-station correct uit te schakelen met behulp van een specifiek hulpprogramma van de fabrikant of met behulp van jumpers die zich op het station zelf bevinden. Neem contact op met de fabrikant van het station om ervoor te zorgen dat de schrijfcache is uitgeschakeld voor het station zelf.
SCSI-stations hebben ook schrijfcaches. Deze caches kunnen echter vaak worden uitgeschakeld door het besturingssysteem. Als er een vraag is, neemt u contact op met de fabrikant van het station voor de juiste hulpprogramma's.
Stacking van schrijfcache
Write Cache Stacking is vergelijkbaar met sectorvolgorde. De volgende definitie is rechtstreeks afkomstig van een toonaangevende website van de fabrikant van het IDE-station:
Normaal gesproken is deze modus actief. De schrijfcachemodus accepteert de hostschrijfgegevens in de buffer totdat de buffer vol is of de hostoverdracht is voltooid.
Een schijfschrijftaak begint de hostgegevens op schijf op te slaan. Host-schrijfopdrachten blijven geaccepteerd en gegevens die naar de buffer worden overgebracht totdat de schrijfopdrachtstack vol is of de gegevensbuffer vol is. Het station kan schrijfopdrachten opnieuw ordenen om de doorvoer van stations te optimaliseren.
Automatische toewijzing van schrijfbewerkingen (AWR)
Een andere veelgebruikte techniek die wordt gebruikt om gegevens te beveiligen, is het detecteren van slechte sectoren tijdens het bewerken van gegevens. De volgende uitleg is afkomstig van de website van een toonaangevende IDE-stationsfabrikant:
Deze functie maakt deel uit van de schrijfcache en vermindert het risico op gegevensverlies tijdens uitgestelde schrijfbewerkingen. Als er een schijffout optreedt tijdens het schijfschrijfproces, stopt de schijftaak en wordt de verdachte sector opnieuw toegewezen aan een groep alternatieve sectoren die zich aan het einde van het station bevinden. Na de herlocatie wordt de schrijftaak van de schijf voortgezet totdat deze is voltooid.
Dit kan een krachtige functie zijn als de back-up van de batterij is opgegeven voor de cache. Dit biedt de juiste wijziging bij het opnieuw opstarten. Het verdient de voorkeur om de schijffouten te detecteren, maar de gegevensbeveiliging van het WAL-protocol vereist opnieuw dat dit realtime wordt uitgevoerd en niet op een uitgestelde manier. Binnen de WAL-parameters kan de AWR-techniek geen rekening houden met een situatie waarin het schrijven van logboeken mislukt vanwege een sectorfout, maar het station vol is. De database-engine moet onmiddellijk op de hoogte zijn van de fout, zodat de transactie correct kan worden afgebroken, de beheerder kan worden gewaarschuwd en de juiste stappen worden ondernomen om de gegevens te beveiligen en de situatie met mediafouten te corrigeren.
Gegevensveiligheid
Er zijn verschillende voorzorgsmaatregelen die een databasebeheerder moet nemen om de veiligheid van de gegevens te waarborgen.
- Het is altijd een goed idee om ervoor te zorgen dat uw back-upstrategie voldoende is om te herstellen van een catastrofale fout. Externe opslag en andere voorzorgsmaatregelen zijn geschikt.
- Test de herstelbewerking van de database in een secundaire database of testdatabase regelmatig.
- Zorg ervoor dat alle cachingapparaten alle storingssituaties kunnen afhandelen (stroomstoringen, slechte sectoren, slechte stations, systeemstoringen, vergrendelingen, stroompieken, enzovoort).
- Zorg ervoor dat uw cacheapparaat:
- Heeft geïntegreerde batterij back-up
- Kan schrijfbewerkingen opnieuw uitschrijven op power-up
- Kan volledig worden uitgeschakeld als dit nodig is
- Verwerkt slechte sector opnieuw toewijzen in realtime
- Schakel de detectie van gescheurde pagina's in. (Dit heeft weinig effect op prestaties.)
- Configureer RAID-stations voor een hot swap van een ongeldig schijfstation, indien mogelijk.
- Gebruik nieuwere cachecontrollers waarmee u meer schijfruimte kunt toevoegen zonder het besturingssysteem opnieuw op te starten. Dit kan een ideale oplossing zijn.
Teststations
Als u uw gegevens volledig wilt beveiligen, moet u ervoor zorgen dat alle gegevenscache correct worden verwerkt. In veel gevallen moet u de schrijfcache van het schijfstation uitschakelen.
Notitie
Zorg ervoor dat een alternatief cachingmechanisme meerdere typen fouten correct kan verwerken.
Microsoft heeft tests uitgevoerd op verschillende SCSI- en IDE-stations met behulp van het SQLIOSim hulpprogramma. Dit hulpprogramma simuleert zware asynchrone lees-/schrijfactiviteit naar een gesimuleerd gegevensapparaat en logboekapparaat. Testprestatiestatistieken tonen de gemiddelde schrijfbewerkingen per seconde tussen 50 en 70 voor een station met uitgeschakelde schrijfcache en een RPM-bereik tussen 5.200 en 7.200.
Zie het volgende artikel in de Microsoft Knowledge Base voor meer informatie over het SQLIOSim hulpprogramma:
Het hulpprogramma SQLIOSim gebruiken om SQL Server-activiteit op een schijfsubsysteem te simuleren
Veel computerfabrikanten bestellen de stations door de schrijfcache uitgeschakeld te hebben. Uit het testen blijkt echter dat dit mogelijk niet altijd het geval is. Test daarom altijd volledig.
Gegevensapparaten
In alle, maar niet-vastgelegde situaties, is voor SQL Server alleen vereist dat de logboekrecords worden leeggemaakt. Wanneer u niet-geregistreerde bewerkingen uitvoert, moeten de gegevenspagina's ook worden leeggemaakt naar stabiele opslag; er zijn geen afzonderlijke logboekrecords om de acties opnieuw te genereren in het geval van een fout.
De gegevenspagina's kunnen in de cache blijven staan totdat het LazyWriter- of CheckPoint-proces ze leegmaakt in stabiele opslag. Door het WAL-protocol te gebruiken om ervoor te zorgen dat de logboekrecords correct zijn opgeslagen, zorgt u ervoor dat herstel een gegevenspagina naar een bekende status kan herstellen.
Dit betekent niet dat het raadzaam is om gegevensbestanden op een station in de cache te plaatsen. Wanneer de SQL Server de gegevenspagina's leegzet naar stabiele opslag, kunnen de logboekrecords worden afgekapt uit het transactielogboek. Als de gegevenspagina's worden opgeslagen in vluchtige cache, kunt u logboekrecords afkappen die worden gebruikt om een pagina te herstellen in het geval van een fout. Zorg ervoor dat zowel uw gegevens- als logboekapparaten een stabiele opslag correct bieden.
Verbeterde prestaties
De eerste vraag die voor u kan optreden, is: "Ik heb een IDE-station dat in de cache was opgeslagen. Maar toen ik het uitgeschakeld had, werden mijn prestaties minder dan verwacht. Waarom?
Veel van de IDE-stations die door Microsoft worden getest, worden uitgevoerd op 5.200 RPM en de SCSI-stations met 7.200 RPM. Wanneer u de schrijfcache van het IDE-station uitschakelt, kunnen de mechanische prestaties een factor worden.
Om het prestatieverschil aan te pakken, is de te volgen methode duidelijk: 'Adres de transactiesnelheid'.
Veel OLTP-systemen (Online Transaction Processing) vereisen een hoge transactiesnelheid. Voor deze systemen kunt u overwegen een cachecontroller te gebruiken die de juiste ondersteuning kan bieden voor een schrijfcache en de gewenste prestatieverbeteringen kan bieden en tegelijkertijd de gegevensintegriteit blijft garanderen.
Om belangrijke prestatiewijzigingen te observeren die optreden in SQL Server op een cachestation, is de transactiesnelheid verhoogd met behulp van kleine transacties.
Testen laat zien dat een hoge schrijfactiviteit van buffers die kleiner is dan 512 kB of groter dan 2 MB, trage prestaties kan veroorzaken.
Kijk een naar het volgende voorbeeld:
CREATE TABLE tblTest ( iID int IDENTITY(1,1), strData char(10))
GO
SET NOCOUNT ON
GO
INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 10000
INSERT INTO tblTest VALUES ('Test')
Hier volgen voorbeeldtestresultaten voor SQL Server:
SCSI(7200 RPM) 84 seconds
SCSI(7200 RPM) 15 seconds (Caching controller)
IDE(5200 RPM) 14 seconds (Drive cache enabled)
IDE(5200 RPM) 160 seconds
Het proces van het verpakken van INSERT de volledige reeks bewerkingen in één transactie wordt in ongeveer vier seconden uitgevoerd in alle configuraties. Dit komt door het aantal logboeken dat nodig is. Als u geen enkele transactie maakt, wordt elke INSERT transactie verwerkt als een afzonderlijke transactie. Daarom moeten alle logboekrecords voor de transactie worden leeggemaakt. Elke flush is 512 bytes groot. Hiervoor is een aanzienlijke mechanische aandrijving vereist.
Wanneer één transactie wordt gebruikt, kunnen de logboekrecords voor de transactie worden gebundeld en kan één grotere schrijfbewerking worden gebruikt om de verzamelde logboekrecords leeg te maken. Dit vermindert de mechanische interventie aanzienlijk.
Waarschuwing
U wordt aangeraden het transactiebereik niet te verhogen. Langlopende transacties kunnen overmatige en ongewenste blokkeringen en verhoogde overhead veroorzaken. Gebruik de prestatiemeteritems van SQL Server:Databases SQL Server om de op transactielogboeken gebaseerde tellers weer te geven. Logboekbytes leeggemaakt per seconde kunnen duiden op veel kleine transacties die een hoge mechanische schijfactiviteit kunnen veroorzaken.
Bekijk de instructies die zijn gekoppeld aan het leegmaken van het logboek om te bepalen of de waarde voor leeggemaakte bytes per seconde kan worden verminderd. In het vorige voorbeeld is één transactie gebruikt. In veel scenario's kan dit echter ongewenst vergrendelingsgedrag veroorzaken. Bekijk het ontwerp van de transactie. U kunt code gebruiken die vergelijkbaar is met de volgende code om batches uit te voeren om de frequente en kleine activiteiten voor het leegmaken van logboeken te verminderen:
BEGIN TRAN
GO
INSERT INTO tblTest VALUES ('Test')
WHILE @@IDENTITY < 50
BEGIN
INSERT INTO tblTest VALUES ('Test')
if(0 = cast(@@IDENTITY as int) % 10)
BEGIN
PRINT 'Commit tran batch'
COMMIT TRAN
BEGIN TRAN
END
END
GO
COMMIT TRAN
GO
SQL Server vereist dat systemen gegarandeerde levering van stabiele media ondersteunen, zoals beschreven in het downloaddocument voor het SQL Server I/O-betrouwbaarheidsprogramma. Zie de invoer- en uitvoervereisten voor de SQL Server-database-engine voor meer informatie over de invoer- en uitvoervereisten voor de SQL Server-database-engine.