Överväganden för inställningarna för automatisk storleksökning 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 autogrow och autoshrink. Den här artikeln innehåller bakgrundsinformation som hjälper dig att 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 storleksökning och automatisk skalning med hjälp av något av följande:

    Obs!

    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 storleksökning 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 för 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 sakta ned 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 ställa in databaser till en nödvändig storlek och utöka dem i förväg. Lämna det outnyttjade utrymmet i databasfilerna om du tror att programanvändningsmönstren kommer att behöva 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 alternativet för automatisk storleksökning för databasens transaktionslogg, kommer den tid det tar för transaktionen att slutföras att omfatta 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 timeout-fel. 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 dina loggfiler kan du ha ett alltför stort antal virtuella loggfiler (VLF). Detta kan leda till prestandaproblem med databasstart/onlineåtgärder, replikering, spegling och insamling av ändringsdata (CDC). Dessutom kan detta ibland orsaka prestandaproblem med dataändringar.

Obs!

Om du kombinerar alternativen autogrow och autoshrink kan du skapa onödiga omkostnader. Kontrollera att de tröskelvärden som utlöser åtgärderna för att växa och krympa inte orsakar frekventa ändringar i 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 tid 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 odlar den och sedan krymper den, kan du få diskfragmentering. Diskfragmentering kan orsaka prestandaproblem under vissa omständigheter. Ett scenario med små tillväxtsteg kan också minska systemets prestanda.

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

Metodtips för automatisk storleksökning och automatisk skalning

  • För ett hanterat produktionssystem måste du överväga att autogrow bara är en katastrof 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 autoskalningsökning måste vara tillräckligt stor för att undvika prestandapåföljderna 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 upp 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

  • Inställningen för automatisk storleksökning kan inte öka databasstorleken utöver gränserna för det tillgängliga diskutrymmet på de enheter som filer har definierats för. Om du förlitar dig på funktionen för automatisk storleksökning för 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: Databasobjekt: Datafilsstorlek (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 behoven i dina transaktionsenheter. Ä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 automatisk skalning. 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. Med andra ord kontrollerar SQL Server inte alla databaser samtidigt och krymper dem alla samtidigt. Det fungerar genom databaserna på ett resursallokerings sätt för att sprida ut belastningen över en viss tidsperiod. Beroende på hur många databaser som 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