Topp 5 SQL Server DBA uppgifter som är ett slöseri med tid

Topp 5 SQL Server DBA uppgifter som är ett slöseri med tid:        Ja, jag menar slöseri med tid

Vissa arbetsuppgifter som utförs av DBAs regelbundet inte bara har liten eller ingen nytta för SQL Server, men kan faktiskt vara skadligt för hälsan hos sina miljöer. I den här artikeln ska jag täcka några sådana uppgifter. Om du gör någon av dessa, hoppas jag att ni sluta att göra dem så snart som möjligt.

1. Krympa databas

Daglig krympning av databasen är dåligt för några orsaker. Från den tekniska sidan, den största effekten kommer du att se en kraftigt ökad index uppsplittring efter varje databas krympa. Dessutom krymper databasfilerna ökar både fysisk fil fragmenteringen på disken delsystem och I / O belastningen på servern, vilket minskar prestandan för andra funktioner medan krympa verksamheten är igång.

Nu är det inte den faktiska minskningen av databasen som orsakar splittring, men eftersom filerna återföds ständigt sig och du fortsätter att krympa dem kommer databasen att bli mer och mer splittrad som den autogrows.

Om du krympa loggfilen, finns det också en dålig bieffekt av att behöva återföds ständigt det. När loggfilen fyller och behöver autogrow, alla operationer i databasen stannade som transaktionsloggen växer. Detta kan ta en sekund eller två på ett väldigt aktivt system, så att alla typer av låsning och blockering som processer vänta transaktionsloggen att växa.

Den andra nackdelen är att när underhålla databasen börjar löpa igen kommer filerna måste växa, som tar CPU och resurser disk att slutföra. Detta orsakar sedan underhålla databasen för att ta ännu längre tid, speciellt på SQL Server 2000 och äldre, eller på SQL Server 2005 och up som inte har omedelbar filen initiering aktiverad.

Från ett management sida, kan detta ge dig en falsk känsla av trygghet eftersom du inte vet hur mycket utrymme din databas som faktiskt måste ta upp. Med andra ord, om din databas växer från 100 GBs till 130 GBs varje gång du kör processen underhålla databasen på den, och sedan krympa den åter ned till 70 GBs igen, har du ingen aning om hur mycket utrymme i databasen faktiskt behov. Behöver den 80 GBs eller 120 GBs? Svaret är att det behövs 120 GBs utrymme så att den kan utföra de nödvändiga databasen underhåll. Om du krympa ner det och sedan lägga andra data på disken, kanske du inte har tillräckligt med utrymme för att utföra ditt underhålla databasen och jobbet kommer att misslyckas.

2. Avkortande transaktionsloggen

En av de vanligaste inställningar jag ser på nätet är följande databas underhållsplanen:

Log Backup
Index Rebuild
Full Backup
Trunkera Log
Log Backups var 40 minuter

Vad som görs här är indexen håller på att byggas, och en fullständig säkerhetskopia tas på. So far so good, eller hur? Loggen sedan trunkeras som bryter log kedjan – att göra alla log säkerhetskopior tas efter denna värdelösa tills nästa fullständig säkerhetskopia tas. Detta beror på att logga Sequence Number (LSN) kedjan bryts av trunkerar log steg.

Varje gång en transaktion sker, är en LSN skrivs till transaktionsförteckning. När en backup tas, den första och sista LSN ingår i säkerhetskopian skrivs till rubriken loggen backup. När stockarna är återställd, det LSNs från en logg backup till nästa måste gränsa. Om de inte gränsar till varandra, då SQL Server vet att logga register saknas och log säkerhetskopior kan inte återställas.

I detta scenario kan hela backupen återställas till databasen. Tyvärr loggen säkerhetskopior som görs är värdelösa. Detta beror på att sista LSN i transaktionsloggen backup kommer inte vara samma som den LSN från första trunkering tas log backup efter loggen är avskuren, eftersom trunkerar log-kommandot ändrar LSN antalet loggen.

Ett annat scenario som jag ser ganska ofta är att trunkera loggen och sedan göra en fullständig säkerhetskopiering. Detta är bättre, men inte mycket. Alla transaktioner mellan trunkerar uttalande och nästa fullständig säkerhetskopiering kan inte återställas om den ordinarie säkerhetskopieringen är skadad. Varför? Eftersom du inte kan återställa full två dagar tidigare och sedan rulla stockarna framåt sedan trunkerar log steg kommer fortfarande att återställa LSN nummer. Och ja, byta logga in enkla återställningsläge gör exakt samma sak.

Om du trunkera din transaktionsförteckning så att du kan krympa den så bläddrar du upp och läsa avsnittet ovan.

Om du nu inte behöver transaktionsloggen intakt, men har databasen i full återbetalning, bör du ändra databasen till enkla återställningsläge. Detta sätt transaktionsloggen kommer inte växa eftersom loggposterna skrivs över istället för att bevaras tills nästa log backup.

3. Återställa en fullständig säkerhetskopia av loggen Shipping mål

Det här är en som förhoppningsvis du inte gör på daglig basis. Det första tecknet på att logga sjöfarten startades av någon som inte fullt ut förstår hur transaktionsloggen verk är att log sjöfarten konfigurationen är inställd för att återställa en fullständig säkerhetskopia på loggen sjöfarten målservern dagligen eller varje vecka. Detta är ett slöseri med tid eftersom loggen Shipping mål som redan har alla de transaktioner som tillämpas i denna för att återställa full backup är bara slöseri med tid och bandbredd om du loggar sjöfarten mål i ett annat kontor eller datahall.

När du säkerhetskopierar transaktionsloggen, allt som har hänt i databasen sedan den senaste loggen backup ingår. Detta inkluderar ny kolumner och tabeller, index återskapas, etc. Genom att återställa full backup för att fånga upp allt som är missat, du är helt enkelt släppa destinationen databasen och återställa den till exakt samma skick som då gällde alla stockarna fram som säkerhetskopieras medan fullständig säkerhetskopiering höll på att återställas. Allt detta gör är att öka risken för att en logg backup will be missed.

4. Defragging sedan en ombyggnad av index

Som du (förhoppningsvis) redan vet så finns det två sätt att cleanup din databas index. Du kan defragmentera index med hjälp av REORG parametern, eller så kan du göra en fullständig ombyggnad av indexet. Med de nya planerna underhålla databasen i SQL Server 2005, dock blir det mycket lätt att göra båda.

Även om detta inte uttryckligen skada databasen, är det ett stort slöseri med tid (inte underhålla databasen, men utför både operationer mot samma index). Detta beror på att resultatet från båda verksamheter är samma sak – ett index som inte är fragmenterad och har en god fyllnadsgrad som fastställts för samtliga databas sidor.

Om du ofta utför ett index omorganisation följt av ett index återuppbygga, då CPU-kraft och disk-I / O, att du spenderar gör reorg är bortkastad eftersom indexet kommer att vara helt återuppbyggdes av indexet återuppbygga kommandot. Du borde göra det ena eller det andra – inte både och. Om du är osäker på vilken som skall användas, finns det gott om produkter som du kan köpa för att hantera detta automatiskt (Quest förmåga Manager eller Idera SQL defrag chef, till exempel), eller så kan du hitta några av de fria skript tillgängliga online.

5. Manuellt läser igenom fel loggar

Många DBAs i mindre butiker kommer att ta tid att läsa igenom fel loggar dagligen för att leta efter problem. När du bara har en eller två servrar för att hantera, tar det inte särskilt länge. När du börjar lägga på fler och fler SQL-servrar, dock går igenom dessa loggfiler manuellt kan börja ta mycket lång tid.

Du skulle vara bättre att komma med ett automatiserat sätt att läsa dessa loggfiler och leta efter fel stockar. Detta kan spara dig mycket tid, särskilt som loggfilerna växa, så att du finns att arbeta med projekt som kan lägga mer till företagets resultat.

Om du har en övervakande lösning på plats, har det förmodligen ett sätt att läsa ansökan log. Något allvarligt fel i ErrorLog filen kommer också att skrivas till Windows applikation log. Om du inte har någon form av övervakning ansökan, eller om den inte stöder läst fel loggen kan du ladda ErrorLog fil och / eller ansökan logga in på ett bord och leta efter fel.

Kom ihåg, medan det finns massor av dagliga uppgifter som kan berika din organisation, det finns andra som inte bara tillför något mervärde till näringslivet och / eller SQL Server, men i själva verket är att förringa den nedersta raden. Det är en bra idé att ta ett steg tillbaka och titta på alla dessa uppgifter för att utvärdera vad de faktiskt gör, och se om dessa uppgifter är att ge en verklig kostnad nytta (säkerhetskopiering, till exempel) eller inte (manuellt läsa igenom loggfiler).

Från Khan  sql dba – mcitp

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: