Dela via

Överväganden för inställningarna för automatisk tillväxt och automatisk skalning i SQL Server

  • Artikel

Ursprunglig produktversion: SQL Server
Ursprungligt KB-nummer: 315512

Sammanfattning

Standardinställningarna för autogrow och autoshrink är lämpliga för många SQL Server-system. Det finns dock miljöer där du kan behöva justera parametrarna för automatisk ökning och automatisk krympning. Den här artikeln innehåller viss bakgrundsinformation som vägleder dig när du ska välja de här inställningarna för din miljö.

Här följer några saker att tänka på om du bestämmer dig för att justera parametrarna autogrow och autoshrink.

Hur gör jag för att konfigurera inställningarna

  1. Du kan konfigurera eller ändra inställningarna för automatisk tillväxt och automatisk skalning med hjälp av något av följande:

    Kommentar

    Mer information om hur du ställer in de här inställningarna på databasfilnivå finns i Lägga till data eller loggfiler i en databas.

    Du kan också konfigurera alternativet för automatisk uppväxning när du skapar en databas.

    Om du vill visa de aktuella inställningarna kör du följande Transact-SQL-kommando:

    sp_helpdb [ [ @dbname= ] 'name' ]

  2. Tänk på att autogrow-inställningarna är per fil. Därför måste du ange dem på minst två platser för varje databas (en för den primära datafilen och en för den primära loggfilen). Om du har flera data- och/eller loggfiler måste du ange alternativen för varje fil. Beroende på din miljö kan du sluta med olika inställningar för varje databasfil.

Överväganden för AUTO_SHRINK

AUTO_SHRINK är ett databasalternativ i SQL Server. När du aktiverar det här alternativet för en databas blir den här databasen berättigad till krympning av en bakgrundsaktivitet. Den här bakgrundsaktiviteten utvärderar alla databaser som uppfyller kriterierna för att krympa och krympa data eller loggfiler.

Du måste noggrant utvärdera inställningen av det här alternativet för databaserna i en SQL Server-instans. Frekventa öknings- och krympåtgärder kan leda till olika prestandaproblem.

  • Om flera databaser ofta krymper och växer leder detta enkelt till fragmentering på filsystemnivå. Detta kan ha en allvarlig inverkan på prestandan. Detta gäller oavsett om du använder de automatiska inställningarna eller om du manuellt växer och krymper filerna ofta.

  • När AUTO_SHRINK data eller loggfilen har krympts kan en efterföljande DML- eller DDL-åtgärd minska avsevärt om utrymme krävs och filerna behöver växa.

  • Bakgrundsaktiviteten AUTO_SHRINK kan ta upp resurser när det finns många databaser som behöver krympas.

  • Bakgrundsaktiviteten AUTO_SHRINK måste hämta lås och annan synkronisering som kan vara i konflikt med annan vanlig programaktivitet.

Överväg att ange en nödvändig storlek på databaserna och utöka dem i förväg. Lämna det oanvända utrymmet i databasfilerna om du tror att programanvändningsmönstren behöver dem igen. Detta kan förhindra frekvent krympning och tillväxt av databasfilerna.

Överväganden för AUTOGROW

  • Om du kör en transaktion som kräver mer loggutrymme än vad som är tillgängligt och du har aktiverat autogrow-alternativet för transaktionsloggen för databasen, kommer den tid det tar att slutföra transaktionen att inkludera den tid det tar för transaktionsloggen att växa med det konfigurerade beloppet. Om tillväxtökningen är stor eller om det finns någon annan faktor som gör att det tar lång tid kan frågan där du öppnar transaktionen misslyckas på grund av ett timeoutfel. Samma typ av problem kan bero på en automatisk ökning av datadelen i databasen.

  • Om du kör en stor transaktion som kräver att loggen växer måste även andra transaktioner som kräver en skrivning till transaktionsloggen vänta tills tillväxtåtgärden har slutförts.

  • Om du har många filtillväxter i loggfilerna kan du ha ett alltför stort antal virtuella loggfiler (VLF). Detta kan leda till prestandaproblem med databasstart/onlineåtgärder, replikering, spegling och ändringsdatainsamling (CDC). Dessutom kan detta ibland orsaka prestandaproblem med dataändringar.

Kommentar

Om du kombinerar alternativen autogrow och autoshrink kan du skapa onödiga omkostnader. Kontrollera att tröskelvärdena som utlöser åtgärderna för att växa och krympa inte orsakar frekventa ändringar av upp- och nedstorleken. Du kan till exempel köra en transaktion som gör att transaktionsloggen växer med 100 MB när den checkas in. En stund efter det startar autoshrinken och krymper transaktionsloggen med 100 MB. Sedan kör du samma transaktion och gör att transaktionsloggen växer med 100 MB igen. I det exemplet skapar du onödiga omkostnader och potentiellt skapar fragmentering av loggfilen, vilket kan påverka prestanda negativt.

Om du utökar databasen med små steg, eller om du växer den och sedan krymper den, kan du få diskfragmentering. Diskfragmentering kan orsaka prestandaproblem under vissa omständigheter. Ett scenario med små tillväxtökningar kan också minska systemets prestanda.

I SQL Server kan du aktivera omedelbar filinitiering. Omedelbar filinitiering påskyndar endast filallokeringar för datafiler. Initiering av omedelbar fil gäller inte för loggfiler. Mer information finns i Databasinitiering av snabbfil.

Metodtips för autogrow och autoshrink

  • För ett hanterat produktionssystem måste du överväga att autogrow bara är en beredskap för oväntad tillväxt. Hantera inte dina data och loggtillväxt dagligen med automatisk tillväxt.

  • Du kan använda aviseringar eller övervakningsprogram för att övervaka filstorlekar och utöka filer proaktivt. Detta hjälper dig att undvika fragmentering och gör att du kan flytta dessa underhållsaktiviteter till icke-rusningstimmar.

  • Autoshrink och autogrow måste noggrant utvärderas av en tränad databasadministratör (DBA); De får inte lämnas ohanterade.

  • Din autogrow-ökning måste vara tillräckligt stor för att undvika de prestandapåföljder som anges i föregående avsnitt. Det exakta värdet som ska användas i konfigurationsinställningen och valet mellan en procentuell tillväxt och en viss MB-storlekstillväxt beror på många faktorer i din miljö. En allmän tumregel som du kan använda för testning är att ställa in autogrow-inställningen till ungefär en-åtta storleken på filen.

  • Aktivera inställningen \<MAXSIZE> för varje fil för att förhindra att en fil växer till en punkt där den använder allt tillgängligt diskutrymme.

  • Håll storleken på dina transaktioner så liten som möjligt för att förhindra oplanerad filtillväxt.

Varför behöver jag oroa mig för diskutrymme om storleksinställningarna kontrolleras automatiskt

  • Autogrow-inställningen kan inte öka databasstorleken utöver gränserna för det tillgängliga diskutrymmet på de enheter som filerna har definierats för. Om du förlitar dig på funktionen för automatisk uppväxning för att storleksanpassa dina databaser måste du därför fortfarande oberoende kontrollera det tillgängliga hårddiskutrymmet. Autogrow-inställningen begränsas också av den MAXSIZE parameter som du väljer för varje fil. För att minska risken för att utrymmet tar slut kan du övervaka prestandaövervakarens räknare SQL Server: Databases Object: Data File(s) Size (KB) och konfigurera en avisering när databasen når en viss storlek.

  • Oplanerad tillväxt av data eller loggfiler kan ta utrymme som andra program förväntar sig att vara tillgängliga och kan orsaka att dessa andra program får problem.

  • Ökningssteget för transaktionsloggen måste vara tillräckligt stort för att ligga före transaktionsenheternas behov. Även om autogrow är aktiverat kan du få ett meddelande om att transaktionsloggen är full, om den inte kan växa tillräckligt snabbt för att uppfylla behoven i din fråga.

  • SQL Server testar inte ständigt för databaser som har nått det konfigurerade tröskelvärdet för autoshrink. I stället tittar den på de tillgängliga databaserna och hittar den första som är konfigurerad för autoshrink. Den kontrollerar databasen och krymper databasen om det behövs. Sedan väntar den flera minuter innan nästa databas som har konfigurerats för autoshrink kontrolleras. Sql Server kontrollerar med andra ord inte alla databaser samtidigt och krymper dem alla samtidigt. Det fungerar genom databaserna på ett resursallokeringssätt för att sprida ut belastningen under en viss tidsperiod. Beroende på hur många databaser du har konfigurerat för att automatiskt krympa på en viss SQL Server-instans kan det därför ta flera timmar från det att databasen når tröskelvärdet tills den faktiskt krymper.

Referenser