Algemene replicatieprestaties verbeteren

Van toepassing op:SQL ServerAzure SQL Managed Instance

U kunt de algemene prestaties voor alle typen replicatie in uw toepassing en in uw netwerk verbeteren met behulp van de richtlijnen die in dit onderwerp worden beschreven.

Server en netwerk

  • Stel de minimale en maximale hoeveelheid geheugen in die is toegewezen aan Microsoft SQL Server Database Engine.

    Standaard wijzigt de Database Engine de geheugenvereisten dynamisch op basis van beschikbare systeembronnen. Als u de beschikbaarheid van weinig geheugen tijdens replicatieactiviteiten wilt voorkomen, gebruikt u de minimale servergeheugenoptie om het minimaal beschikbare geheugen in te stellen. Om te voorkomen dat het besturingssysteem schijfgeheugen gebruikt voor paging, kunt u ook een maximale hoeveelheid geheugen instellen met de optie max server memory. Zie De configuratieopties voor servergeheugenservers voor meer informatie.

  • Zorg voor de juiste toewijzing van databasegegevensbestanden en logboekbestanden. Gebruik een afzonderlijk schijfstation voor het transactielogboek voor alle databases die betrokken zijn bij replicatie.

    U kunt de tijd die nodig is voor het schrijven van transacties verminderen door de logboekbestanden op een ander schijfstation op te slaan dan het station dat wordt gebruikt om de database op te slaan. U kunt dat station spiegelen met behulp van een redundante matrix met goedkope schijven (RAID)-1 als u fouttolerantie nodig hebt. Gebruik RAID 0 of 0+1 (afhankelijk van uw behoefte aan fouttolerantie) voor andere databasebestanden. Dit is een goede gewoonte, ongeacht of replicatie al dan niet wordt gebruikt.

  • Overweeg geheugen toe te voegen aan servers die worden gebruikt in replicatie, met name de Distributeur.

  • Gebruik multiprocessorcomputers.

    Replicatieagents kunnen profiteren van extra processors op de server. Als u een hoog CPU-gebruik gebruikt, kunt u overwegen om een snellere CPU of meerdere CPU's te installeren.

  • Gebruik een snel netwerk.

    Het netwerk kan een aanzienlijk prestatieknelpunt zijn, met name voor transactionele replicatie. De doorgifte van wijzigingen aan abonnees kan aanzienlijk worden verbeterd door een snel netwerk van 100 megabits per seconde (Mbps) of sneller te gebruiken. Als het netwerk traag is, geeft u de juiste netwerkinstellingen en agentparameters op.

Databaseontwerp

  • Volg de aanbevolen procedures voor databaseontwerp.

    Een gerepliceerde database profiteert over het algemeen van dezelfde prestatieoptimalisaties als een niet-gerepliceerde database. Indexen moeten echter met voorzichtigheid worden gebruikt op de Subscriber: de primaire sleutelkolom op de Subscriber moet worden geïndexeerd, maar extra indexen kunnen de prestaties van invoeg-, update- en verwijderbewerkingen beïnvloeden.

  • Overweeg de databaseoptie READ_COMMITTED_SNAPSHOT in te stellen.

    Als u conflicten tussen gebruikersactiviteit en replicatieagentactiviteit wilt verminderen, stelt u deze optie in voor de publicatie- en abonnementsdatabases:

    ALTER DATABASE AdventureWorks  
SET READ_COMMITTED_SNAPSHOT ON

    Zie (Transact-SQL) voor meer informatieALTER DATABASE.

  • Wees voorzichtig met toepassingslogica in triggers.

    Bedrijfslogica in door de gebruiker gedefinieerde triggers op de Subscriber kan de replicatie van wijzigingen naar de Subscriber vertragen:

    Als u triggers gebruikt om referentiële integriteit te behouden in tabellen die zijn gepubliceerd voor samenvoegreplicatie, geeft u de verwerkingsvolgorde van tabellen op om het aantal nieuwe pogingen te verminderen dat vereist is voor de Merge Agent. Zie Opties voor merge-replicatie opgeven voor meer informatie.

  • Beperk het gebruik van LOB-gegevenstypen (Large Object).

    LOBs vereisen meer opslagruimte en verwerking dan andere kolomgegevenstypen. Neem deze kolommen niet op in artikelen, tenzij dit nodig is voor uw toepassing. De gegevenstypen tekst, ntext en afbeelding zijn afgeschaft. Als u LOBs opneemt, raden we u aan de gegevenstypen varchar(max), nvarchar(max), varbinary(max), respectievelijk te gebruiken.

    Voor transactionele replicatie kunt u het Distribution Agent profiel met de naam Distributieprofiel gebruiken voor OLEDB-streaming. Zie Replicatieagentprofielen voor meer informatie.

Publicatieontwerp

  • Alleen de vereiste gegevens publiceren.

    Omdat replicatie eenvoudig is in te stellen, is er een tendens om meer gegevens te publiceren dan daadwerkelijk vereist is. Dit kan extra resources in de distributiedatabases en momentopnamebestanden verbruiken en kan de doorvoer voor vereiste gegevens verlagen. Vermijd het publiceren van onnodige tabellen en overweeg minder vaak publicaties bij te werken.

  • Minimaliseer conflicten door publicatieontwerp en toepassingsgedrag.

    Met de volgende typen replicatie kunnen gegevens bij abonnees worden gewijzigd: samenvoegreplicatie, transactionele replicatie met bijwerkbare abonnementen en transactionele peer-to-peer-replicatie. Samenvoeging van replicatie en transactionele replicatie met bijgewerkte abonnementen bieden ondersteuning voor gegevensconflicten als een bepaalde rij op meer dan één knooppunt tussen synchronisaties wordt bijgewerkt. Peer-to-peer-replicatie biedt geen ondersteuning voor gegevensconflicten; gegevenswijzigingen moeten worden gepartitioneerd. Ongeacht het type replicatie dat wordt gebruikt, raden we u aan om indien mogelijk wijzigingen te partitioneren, omdat dit de verwerking vermindert die nodig is voor conflictdetectie en -oplossing.

    Wijzigingen kunnen worden gepartitioneerd door subsets van gegevens naar elke abonnee te publiceren of door een toepassing directe wijzigingen aan te brengen voor een bepaalde rij in een bepaald knooppunt:

    • Samenvoegingsreplicatie maakt het mogelijk gegevenssubsets te publiceren met geparameteriseerde filters in één publicatie. Zie Geparameteriseerde rijfiltersvoor meer informatie.

    • Transactionele replicatie ondersteunt het publiceren van subsets van gegevens met behulp van statische filters met meerdere publicaties. Zie Gepubliceerde gegevens filteren voor meer informatie.

  • Gebruik rijfilters oordeelkundig.

    Wanneer een transactionele publicatie een of meer artikelen bevat die rijfilters gebruiken, moet de logboeklezeragent het filter toepassen op elke rij die wordt beïnvloed door een update van de tabel terwijl het transactielogboek wordt gescand. De verwerkingssnelheid van de Log Reader Agent wordt daarom beïnvloed.

    Op dezelfde manier moet samenvoegreplicatie gewijzigde of verwijderde rijen evalueren om te bepalen welke abonnees deze rijen moeten ontvangen. Wanneer rijfilters worden gebruikt om de vereiste gegevens voor een abonnee te verminderen, is deze verwerking complexer en kan dit trager zijn dan wanneer u alle rijen in een tabel publiceert. Overweeg zorgvuldig de afweging tussen verminderde opslagvereisten voor elke abonnee en de noodzaak om maximale doorvoer te bereiken. Zie Gepubliceerde gegevens filteren voor meer informatie over filteren.

Overwegingen voor abonnementen

  • Gebruik pull-abonnementen wanneer er een groot aantal abonnees is.

    De Distribution Agent en Merge Agent uitgevoerd bij de Distributeur voor pushabonnementen en bij Abonnees voor pull-abonnementen. Het gebruik van pull-abonnementen kan de prestaties verbeteren door agentverwerking van de distributeur naar abonnees te verplaatsen. Voor meer informatie, zie Abonneer je op publicaties.

  • Overweeg de herinitialisatie van het abonnement als abonnees te ver achterblijven.

    Wanneer grote hoeveelheden wijzigingen naar abonnees moeten worden verzonden, kan het opnieuw initialiseren van deze wijzigingen met een nieuwe momentopname sneller zijn dan het gebruik van replicatie om de afzonderlijke wijzigingen te verplaatsen. Zie Abonnementen opnieuw initialiseren voor meer informatie.

    Voor transactionele replicatie geeft Replication Monitor op het tabblad Niet-gedistribueerde opdrachten informatie weer over: het aantal transacties in de distributiedatabase dat nog niet aan een Abonnee is gedistribueerd; en de geschatte tijd die nodig is om deze transacties te distribueren. Zie Informatie weergeven en taken uitvoeren met behulp van Replicatiecontrolevoor meer informatie.

Overwegingen voor momentopnamen

  • Voer de Snapshot Agent alleen uit wanneer dat nodig is en op daluren.

    De Snapshot Agent kopieert gegevens in bulk vanuit de gepubliceerde tabel op de Publisher naar een bestand in de momentopnamemap op de Distributor. Het genereren van een momentopname kan een resource-intensief proces zijn en wordt het beste gepland tijdens daluren.

  • Gebruik een momentopname in de systeemeigen modus, tenzij een momentopname van de tekenmodus is vereist.

    Gebruik de standaardmomentopname in de systeemeigen modus voor alle Subscribers, met uitzondering van Subscribers die geen SQL Server gebruiken en Subscribers waarop SQL Server Compact wordt uitgevoerd, waarvoor een momentopname in tekenmodus is vereist.

  • Gebruik één momentopnamemap voor een publicatie.

    Wanneer u de publicatie-eigenschappen opgeeft die betrekking hebben op de locatie van de momentopname, kunt u ervoor kiezen om momentopnamebestanden te genereren naar de standaardmap voor momentopnamen, naar een alternatieve momentopnamemap of naar beide. Voor het genereren van momentopnamebestanden op beide locaties is extra schijfruimte en meer verwerking vereist wanneer de Snapshot Agent wordt uitgevoerd.

  • Plaats de snapshotmap op een station dat lokaal is voor de Distributor en niet wordt gebruikt voor de opslag van database- of logbestanden.

    De Snapshot Agent voert een sequentiële schrijfbewerking van gegevens uit naar de map met momentopnamen. Het plaatsen van de momentopnamemap op een afzonderlijk station van een database of logboekbestanden vermindert conflicten tussen de schijven en helpt het momentopnameproces sneller te voltooien.

  • Wanneer u de abonnementsdatabase bij de abonnee maakt, kunt u overwegen om een herstelmodel op te geven van eenvoudig of bulksgewijs geregistreerd. Dit maakt minimale logboekregistratie mogelijk van de bulkinvoegingen die worden uitgevoerd tijdens de toepassing van de momentopname bij de abonnee. Nadat de momentopname is toegepast op de abonnementsdatabase, kunt u indien nodig overschakelen naar een ander herstelmodel (gerepliceerde databases kunnen een van de herstelmodellen gebruiken). Zie Herstel- en hersteloverzicht (SQL Server) voor meer informatie over het selecteren van een herstelmodel.

  • Overweeg het gebruik van de alternatieve momentopnamemap en gecomprimeerde momentopnamen op verwisselbare media voor netwerken met lage bandbreedte.

    Het comprimeren van momentopnamebestanden in de alternatieve map voor momentopnamen kan de opslagvereisten voor de schijfopslag van momentopnamen verminderen en het eenvoudiger maken om momentopnamebestanden over te dragen op verwisselbare media.

    Gecomprimeerde momentopnamen kunnen in sommige gevallen de prestaties van het overdragen van momentopnamebestanden in het netwerk verbeteren. Het comprimeren van de momentopname vereist echter extra verwerking door de Snapshot Agent bij het genereren van de momentopnamebestanden en door de Distribution Agent of Merge Agent bij het toepassen van de momentopnamebestanden. Dit kan het genereren van momentopnamen vertragen en de tijd verhogen die nodig is om een momentopname toe te passen in sommige gevallen. Bovendien kunnen gecomprimeerde momentopnamen niet worden hervat als er een netwerkfout optreedt; daarom zijn ze niet geschikt voor onbetrouwbare netwerken. Houd rekening met deze afwegingen wanneer u gecomprimeerde momentopnamen in een netwerk gebruikt. Zie Momentopnameopties wijzigen voor meer informatie.

  • U kunt een abonnement handmatig initialiseren.

    In sommige scenario's, zoals die met grote initiële gegevenssets, is het raadzaam om een abonnement te initialiseren met een andere methode dan een momentopname. Zie Een transactioneel abonnement initialiseren zonder momentopname voor meer informatie.

Parameters van de agent

  • Verlaag het detailniveau van replicatieagenten, behalve tijdens de initiële testfase, controle of foutopsporing.

    Verminder de parameter –HistoryVerboseLevel en de parameter –OutputVerboseLevel voor de distributieagents of Merge Agents. Dit vermindert het aantal nieuwe rijen dat is ingevoegd om de agentgeschiedenis en uitvoer bij te houden. In plaats daarvan worden eerdere geschiedenisberichten met dezelfde status bijgewerkt naar de nieuwe geschiedenisgegevens. Verhoog de logniveaus voor testen, monitoring en foutopsporing, zodat u zoveel mogelijk informatie hebt over de activiteiten van de agent.

  • Gebruik de parameter –MaxBCPThreads van de Snapshot Agent, Merge Agent en Distribution Agent (het aantal opgegeven threads mag het aantal processors op de computer niet overschrijden). Met deze parameter geeft u het aantal bulkkopiebewerkingen op dat parallel kan worden uitgevoerd wanneer de momentopname wordt gemaakt en toegepast.

  • Gebruik de parameter –UseInprocLoader van de Distribution Agent en de Merge Agent (deze parameter kan niet worden gebruikt als gepubliceerde tabellen XML-kolommen bevatten). Deze parameter zorgt ervoor dat de agent de BULK INSERT opdracht gebruikt wanneer de momentopname wordt toegepast.

Agentparameters kunnen worden opgegeven in agentprofielen en op de opdrachtregel. Voor meer informatie, zie:

  • Last updated on