Så åtgärdar du tre dåliga arv från SQL 2000

Det finns ett antal databasinställningar som tidigare var rimliga att göra, men som idag snarare försämrar prestanda och säkerhet. Databasen kan ha ärvt dessa från SQL Server 2000 genom uppgraderingar, konsolideringar eller ännu värre, genom att nya databaser skapats från gamla create-script.  Även databaser skapade i SQL Express och som sedan flyttats kan ha fått med sig vissa av inställningarna som default från tidigare. En bra rutin är därför att kontrollera inställningarna nedan en extra gång innan du tar över ansvaret för databaser som du inte varit med att installera själv.

AUTO_CLOSE

Denna funktion stänger ner en databas som inte har aktiva anslutningar. I teorin låter det bra, då resurser kan frigöras när den stänger ned databasen. I praktiken innebär det oftare en prestanda-försämring då nya anslutningar får vänta extra länge eftersom SQL Servern måste starta upp databasen igen när den varit stängd. Detta kan exempelvis vara fallet om du har en applikation som ansluter ofta med korta sessioner. En annan konsekvens är att många av de DMV´s som används i felsökning och optimering töms på information/värden varje gång databasen stängs ned. Detta är några exempel på effekterna av AUTO_CLOSE och som gör att du inte bör ha denna databasinställning påslagen.

AUTO_SHRINK

AUTO_SHRINK har flera negativa effekter på prestandan vilket gör att den också bör vara avslagen. Den största påverkan är att den fragmenterar indexen genom att den flyttar omkring data för att krympa databasen. Du vet inte när AUTO_SHRINK slår till vilket gör att den kan den ta en massa CPU och I/O när den börjar. Dessutom kan den förstöra det index-underhåll som körts och göra att dina frågor går långsammare än nödvändigt.

Har du dessutom en databas som både har AUTO_SHRINK och AUTO_GROWTH påslaget kan du få en jojo-effekt av ökning, krympning, ökning … som gör att du dessutom får fragmentering på NTFS-nivån vilket också gör sitt för att sänka prestandan. Det är onödigt resurs-utnyttjande att låta databasen krympas utan anledning. En aktiv databas mår bra av att ha arbetsutrymme, så krymp inte databaserna regelbundet och ha inte AUTO_SHRINK påslaget.

PAGE_VERIFY_OPTION = Torn_Page_Detection

Den här inställningen är en av de viktigaste när det gäller hur snabbt du får reda på om du drabbats av korruption i databasen. Det handlar om hur SQL Server kontrollerar den skrivna sidan på disk. En kort beskrivning av valen du har:

• NONE – Ingen kontroll alls
• TORN_PAGE_DETECTION – skriver de 2 första bits per 512 bytes som skrivs till disk till att använda för en enkel kontroll av att sidan blev skriven till disk.
• CHECKSUM – skapar en checksumma på hela datasidan när den skrivs till disk som sedan används för verifikation när sidan läses från disk nästa gång.

CHECKSUM är det klart bästa alternativet när det gäller att upptäcka korruption och säkerställa att datat på disk är det som skrivits dit.

Tillsammans med en regelbunden DBCC CheckDB gör detta att du får en god möjlighet att fånga korruption i ett tidigt skede och chans att reparera så tidigt som möjligt, innan det är för sent. För att kontrollera dessa tre inställningar kan du använda scriptet nedan:

select
   name, 
   is_auto_close_on, 
   is_auto_shrink_on, 
   page_verify_option_desc
from sys.databases

Och om du skulle se något annat än 0 i de två första kolumnerna eller något annat än CHECKSUM i sista kolumnen kan du gå igenom databaserna och ändra till rätt inställningar med dessa rader:

ALTER DATABASE [Your Database] SET AUTO_CLOSE OFF
GO
ALTER DATABASE [Your Database] SET AUTO_SHRINK OFF
GO
ALTER DATABASE [Your Database] SET PAGE_VERIFY CHECKSUM
GO

Detta är enkla, men viktiga saker att kontrollera. När det smäller är det oftast försent att korrigera liknande inställningar, så passa på att ägna dina databaser lite tid i förebyggande syfte.

Här kan du ladda ner vår guide med fem tips som förenklar din administration av SQL Server