Som SQL Server konsult måste man iblant använda även andra verktyg än de strikt SQL Server relaterade, hur fel det än kan kännas…

Om säkerhetsföreskrifterna i din miljö föreskriver att du skall konfigurera SQL Server security så att den loggar både lyckade och misslyckade inloggningar kan det lätt medföra att dina errorloggar blir så stora att de i praktiken blir oläsliga. Orsaken är att du får en oändlig mängd meddelande av typen ”Login Succeeded for user xxxx”.

Jag använder ett enkelt trick för att komma runt detta: Kör följande kommando i ett kommandofönster, med errorlog katalogen som aktiv katalog: Find /V ”Login Succeeded” errorlog > el.txt

Det kommer att skapa en textfil som heter el.txt  som innehåller alla rader i den aktuella errorloggen som INTE innehåller texten Login Succeeded. På vissa av våra kunders SQL Server maskienr kan detta reducera den fil man behöver kontrollera från Gigabyte till Kilobyte, och underlättar på det sättet en snabb kontroll av status

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

User defined scalar valued function har funnits sedan SQL server 2000 och används, enligt våra SQL konsulter, väldigt ofta i databaser ut på marknaden. Funktionellt så är det rätt tänkt att kapsla in frekvent återkommande T-SQL kod i generella funktioner, men vad många inte vet är att prestandan i dessa funktioner är väldigt dålig. Det kan fungera bra när man jobbar med små volymer, men passerar man över 1000 rader så försämras prestandan drastiskt.

Detta prestanda problem uppstår eftersom SQL Server måste exekvera funktionen för varje rad i resultatsetet vilket resulterar i en cursor liknande prestanda förlust. För att komma runt detta problem så bör man sluta använda dessa funktioner i väntan på att Microsoft utvecklar Inline User defined Scalar Valued Functions. Vi hoppas att dessa funktioner kommer i nästa version av SQL server.

Om du är intresserad av att läsa mer om detta problem så kan du läsa nedanstående blogg:

http://sqlblog.com/blogs/adam_machanic/archive/2006/08/04/scalar-functions-inlining-and-performance-an-entertaining-title-for-a-boring-post.aspx

/Håkan Winther

Question: What is the performance difference between rebuilding indexes with parallelism set to 1 and parallelism set to 0? The question is both about the index rebuild itself as well as the performance of the database afterwords.