Senaste inläggen 

Taggar 

2005     Business Intelligence     connection     HADR     SSRS 2008     data warehouse     login error     SQL server codename Denali     filter     sp_MSForEachDB     sql browser     package load     T-SQL     Säkerhet     SQL Server 2012     Trace Flag     reorganize index     CU1     improve     CTP1     Page life expectancy     SQL Denali     2011     Datawarehouse     parallelism     undocumented procedures     gratis verktyg     2008     DTA     Extended Event     create index     Techdays     constraint     Activity Monitor     page splits     0xC0010014     SQL2008     virtuell     CMS     SQL Server     profile     bugs     XP_cmdshell     rebuild     Logins     SSAS     Microsoft     Reports     connect     security     sql 2008     BOL     CTE     0xC0202009     function     concatenation     performance     temp table     Cluster     sp1     platsannons SQL utvecklare     features     clean up     resource governor     history     sql 2005     central management server     SSRS     transactions     dbmail     HEAP     access denied     2000     SSIS     #am_get_querystats     feedback     parameters     DECIMAL     error     CU3     AcquireConnection

Veckans fråga med svar - vecka 18

Skrivet den 09 maj 2012 i Indexering, SQL Server 2008, SQL Server 2008R2, SQL Server 2012, Level 200, Göran Rönnbäck, Håkan Winther, sv

En av nyheterna när det gäller SQL Server 2012 är möjlighet till 15 000 partitioner.

Veckans fråga v 18 till Håkan Winther handlar om just partitionering.

När skall man använda det och finns det någon bra tumregel för hur stora tabellerna skall vara ?
Vilka är fördelarna med partitionering och vilka eventuella nackdelar innebär det?

Svar:

Datakomprimering och partitionering är några av mina favorit features i SQL server som mycket väl kan motivera kostnaden för Enterprise edition fastän den är dyrare. I själva verket så kan man minska sina kostnader, öka tillgänglighet och prestanda med komprimering och partitionering.

När ska man använda partitionering? Som vanligt när det gäller SQL server så beror det på (”it depends”). Det finns dock flera scenarier där man ska överväga, testa och implementera partitionering:

- Laddning, arkivering eller borttagning av data skapar låsningar som påverkar andra processer, eller tar för lång tid
- Omindexering av en hel tabell tar för lång tid, påverkar för mycket eller service fönster saknas
- Man har frågor som enbart söker på delmängder (partitioner) av data
- Tabeller med columnstore index ska laddas med ny data
- Man vill spara på diskkostnad utan att förlora prestanda på den mest frekvent använda partitionen

Det finns dock inte några fördelar som inte har några nackdelar, framförallt så finns det en del begränsningar om man vill kunna nyttja ”fast partition switching” för att ladda eller arkivera data.

Några av fördelarna med partitionering är:

- Snabbare frågor som enbart hanterar ett fåtal paritioner
- Olika komprimeringsnivå kan ställas för olika partitioner
- En tabell kan spridas på flera filgrupper som kan placeras mot olika typer av disksystem
- Omindexering kan göras på enskilda partitioner, dock ej online
- Data kan flyttas blixtrande snabbt mellan tabller tack vare fast partition switching

Vid små tabeller så överväger nackdelarna men vid stor tabeller så överstiger normalt fördelarna, vilket gör att vinsten med partitionering på små tabeller inte är så stor. Finns det då någon bra tumregel som säger hur stor tabellen ska vara innan man utvärderar partitionering? Inte någon direkt officiell tumregel, men personligen så brukar jag överväga det vid tabeller på över 100GB eller om det finns problem som kan lösas av partitionering.

Det är relativt lätt att implementera partitioner, men det viktigaste att tänka på innan är att välja en bra partitioneringsnyckel

Du kan läsa mer om partitionering i kommande bloginlägg, men om du har några frågor som du vill ha svar på redan nu så är du varmt välkommen att kontakta mig eller några av våra SQL server konsulter.

/Håkan Winther

Skriv en kommentar