Kvalitetsgranskning av databasmodell, SQL kod, databassäkerhet, backup/restore rutiner, utvecklingsrutiner och driftrutiner. Denna granskning syftar till…
I Enterprise versionerna av SQL server 2005 och SQL server 2008 så finns möjligheten att partitionera tabeller och index horisontellt. Genom partitionering så finns möjligheten att dela upp tabellerna exempelvis på tid, detta kan ge diverse fördelar:
– man kan arkivera data med “fast partition switching” eller “sliding window” som det också brukar kallas.
– man kan sprida gammalt data som inte uppdateras längre på andra filgrupper.
Detta gör att :
– man kan sätta dessa i read only läge för att minimera overheaden av låsningsmekanismen,
– man kan ha billigare diskar för data som inte används frekvent.
– minska tiden det tar att bygga om index eftersom “äldre” partitioner inte förändras
– läsprestandan ökas genom partitioneringseliminering
– det går att nyttja filgruppsbackuper.
– Olika partitioner kan ha olika grader av komprimering (enbart SQL server 2008 och senare), exempelvis så kan äldre partitioner ha page level compression medan nyare partitioner kan ha row level compression eller ingen kompression. Detta kan öka prestandan avsevärt i miljöer där IO normalt är flaskhals, men där det inte finns tillräckligt med CPU kraft för att komprimera allt.
SQL service har erfarenheter av sökningar på partitionerade tabeller som går dubbelt så snabbt som sökningar på motsvarande tabell utan partitioner. Som vanlig så finns det inga fördelar som inte har några nackdelar, i detta fall så är det ett antal ytterligare krav som ställs på tabellerna som skall partitioneras, speciellt om “fast partition switching” skall användas. Dessa krav är specificerade i SQL server books online där du kan läsa mer om dessa för att avgöra om partitionering är en möjlighet, alternativt så kan våra SQL konsulter som är erfarna på detta hjälpa dig att utvärdera och implementera partitioner.
/Håkan Winther