Databaseopslag optimaliseren
Als u databaseopslag wilt optimaliseren, moet u een proportionele opvulling en tempdb-configuratie overwegen.
Inzicht in I/O-prestaties
I/O-prestaties kunnen essentieel zijn voor een databasetoepassing. Azure SQL verbergt de fysieke bestandsplaatsing, maar er zijn methoden die ervoor zorgen dat u de I/O-prestaties krijgt die u nodig hebt.
Input/output per seconde (IOPS) kan belangrijk zijn voor uw toepassing. Zorg ervoor dat u de juiste servicelaag en vCores hebt gekozen voor uw IOPS-behoeften. Leer hoe u IOPS kunt meten voor uw queries on-premises als u migreert naar Azure. Als u beperkingen hebt qua IOPS, ziet u mogelijk lange I/O-wachttijden. In het vCore-aankoopmodel kunt u vCores omhoog schalen of overstappen op Bedrijfskritiek of Hyperscale als u onvoldoende IOPS hebt. Voor productieworkloads raden we u aan om bij het gebruik van DTU over te stappen naar de Premium-laag.
I/O-latentie is een ander belangrijk onderdeel voor I/O-prestaties. Voor een snellere I/O-latentie voor Azure SQL Database kunt u Bedrijfskritiek of Hyperscale overwegen. Voor een snellere I/O-latentie voor SQL Managed Instance, gaat u naar Bedrijfskritiek of vergroot u de bestandsgrootte of het aantal bestanden voor de database. Voor het verbeteren van de latentie van transactielogboeken moet u mogelijk multistatementtransacties gebruiken.
Bestanden en bestandsgroepen
SQL Server-professionals gebruiken vaak bestanden en bestandsgroepen om de I/O-prestaties te verbeteren via fysieke bestandsplaatsing. Met Azure SQL kunnen gebruikers geen bestanden op specifieke schijfsystemen plaatsen. Azure SQL heeft echter resourceverplichtingen voor I/O-prestaties met betrekking tot tarieven, IOPS en latenties. Op deze manier kan het samenstellen van de gebruiker van fysieke bestandsplaatsing een voordeel zijn.
Azure SQL Database heeft slechts één databasebestand (Hyperscale heeft meestal een aantal) en de maximale grootte wordt geconfigureerd via Azure-interfaces. Er is geen functionaliteit om meer bestanden te maken.
Azure SQL Managed Instance biedt ondersteuning voor het toevoegen van databasebestanden en het configureren van grootten, maar niet voor fysieke plaatsing van bestanden. U kunt het aantal bestanden en bestandsgrootten voor SQL Managed Instance gebruiken om de I/O-prestaties te verbeteren. Daarnaast worden door de gebruiker gedefinieerde bestandsgroepen ondersteund door SQL Managed Instance voor beheerbaarheid.
Beschrijf proportionele opvulling
Wanneer u 1 gigabyte aan gegevens invoegt in een SQL Server-database met twee gegevensbestanden, kunt u verwachten dat elk bestand met ongeveer 512 megabytes toeneemt. Dit is echter niet altijd het geval. SQL Server distribueert gegevens op basis van de grootte van elk bestand. Als beide gegevensbestanden bijvoorbeeld 2 gigabyte zijn, worden de gegevens gelijkmatig gedistribueerd. Maar als één bestand 10 gigabyte is en het andere 1 gigabyte is, gaat ongeveer 900 MB naar het grotere bestand en 100 MB naar de kleinere. Dit gedrag is gebruikelijk in elke database, maar in de schrijfintensieve tempdb kan een oneven schrijfpatroon een knelpunt in het grootste bestand maken, omdat er meer schrijfbewerkingen worden verwerkt.
Tempdb configureren in SQL Server
SQL Server stelt het aantal beschikbare CPU's vast tijdens het installatieproces en configureert het gepaste aantal bestanden, maximaal acht, met gelijkmatige grootte. Daarnaast worden het gedrag van traceringsvlagken 1117 en 1118 geïntegreerd in de database-engine, maar alleen voor tempdb. Voor tempdb-zware werkbelastingen kan het nuttig zijn om het aantal tempdb-bestanden te verhogen dat hoger is dan acht, wat overeenkomt met het aantal CPU's op uw computer.
U gebruikt tempdb op dezelfde manier voor zowel SQL Server als Azure SQL. Houd er echter rekening mee dat uw mogelijkheid om te configureren tempdb verschilt, waaronder de plaatsing van bestanden, het aantal en de grootte van bestanden en tempdb configuratieopties.
SQL Server gebruikt tempdb voor verschillende taken, behalve het opslaan van door de gebruiker gedefinieerde tijdelijke tabellen. Het wordt gebruikt voor werktabellen die tussenliggende queryresultaten, sorteerbewerkingen en het versiearchief voor rijversiebeheer opslaan, onder andere. Vanwege dit uitgebreide gebruik is het van cruciaal belang om tempdb te plaatsen op de opslag met de laagste latentie die beschikbaar is en om de gegevensbestanden correct te configureren.
De databasebestanden van tempdb worden altijd automatisch opgeslagen op lokale SSD-stations, dus I/O-prestaties mogen geen probleem zijn.
SQL Server-professionals gebruiken vaak meer dan één databasebestand om toewijzingen voor tempdb tabellen te partitioneren. Voor Azure SQL Database wordt het aantal bestanden geschaald met het aantal vCores (bijvoorbeeld twee vCores is gelijk aan vier bestanden) met een maximum van 16. Het aantal bestanden kan niet worden geconfigureerd via T-SQL tempdb, maar u kunt het configureren door de implementatieoptie te wijzigen. De maximale grootte van tempdb wordt geschaald op basis van het aantal vCores. U krijgt 12 bestanden met SQL Managed Instance, onafhankelijk van vCores.
De databaseoptie MIXED_PAGE_ALLOCATION is ingesteld op UIT en AUTOGROW_ALL_FILES is ingesteld op AAN. U kunt dit niet configureren, maar net als bij SQL Server zijn dit de aanbevolen standaardwaarden.
De tempdb functie voor optimalisatie van metagegevens die is geïntroduceerd in SQL Server 2019, wat zware vergrendelingsconflicten kan verlichten, is momenteel niet beschikbaar in Azure SQL Database of Azure SQL Managed Instance.
Databaseconfiguratie
Meestal configureert u een database met de T-SQL ALTER DATABASE en ALTER DATABASE SCOPED CONFIGURATION instructies. Veel van de configuratieopties voor prestaties zijn beschikbaar voor Azure SQL. Raadpleeg de T-SQL-verwijzing ALTER DATABASE en ALTER DATABASE SCOPED CONFIGURATION voor de verschillen tussen SQL Server, Azure SQL Database en Azure SQL Managed Instance.
In Azure SQL Database is het standaardherstelmodel volledig herstel, wat ervoor zorgt dat uw database kan voldoen aan Azure Service Level Agreements (SLA's). Dit betekent dat minimale logboekregistratie voor bulkbewerkingen niet wordt ondersteund, met uitzondering van tempdb, waarbij minimale logboekregistratie is toegestaan.
MAXDOP-configuratie
Het maximale niveau van parallelle uitvoering (MAXDOP) kan van invloed zijn op de prestaties van afzonderlijke query's. SQL Server en Azure SQL verwerken MAXDOP op dezelfde manier. Wanneer MAXDOP deze is ingesteld op een hogere waarde, worden er meer parallelle threads per query gebruikt, waardoor de uitvoering van query's mogelijk wordt versneld. Voor dit verhoogde parallellisme zijn echter extra geheugenbronnen vereist, wat kan leiden tot geheugendruk en invloed kan hebben op de opslagprestaties. Wanneer u bijvoorbeeld rijengroepen in een columnstore comprimeert, is voor parallelle uitvoering meer geheugen vereist, wat kan leiden tot geheugendruk en het bijsnijden van rijengroepen.
Omgekeerd kan het instellen van MAXDOP op een lagere waarde de geheugenbelasting verminderen, zodat het opslagsysteem efficiënter kan presteren. Dit is belangrijk in omgevingen met beperkte geheugenbronnen of hoge opslagvereisten. Door MAXDOP zorgvuldig te configureren, kunt u de prestaties van query's en de opslagefficiëntie verdelen, zodat u optimaal gebruik kunt maken van zowel CPU- als opslagbronnen.
U kunt MAXDOP in Azure SQL op dezelfde manier als in SQL Server configureren met behulp van de volgende technieken:
-
ALTER DATABASE SCOPED CONFIGURATIONom te configurerenMAXDOPwordt ondersteund voor Azure SQL. - De opgeslagen procedure
sp_configurevoor maximale mate van parallelle uitvoering wordt ondersteund voor SQL Managed Instance. -
MAXDOPquery hints worden volledig ondersteund. -
MAXDOPConfigureren met Resource Governor wordt ondersteund voor SQL Managed Instance.