MS SQL DBA Dag till Dag


Ibland behöver alla en sql DBA, hjälpa till med dag-till-dag arbetet, är en checklista för bästa praxis och do och don’ts. Det ger en praktisk påminnels.
Du kommer aldrig att vara utan arbete som SQL dba, om du följer detta steg, lycka till. Lämna gärna några kommentarer om jag är fel.

Dag till Dag:

1.Kontrollera OS händelseloggar och SQL Server Loggar för ovanliga händelser.

2.Verify att alla planerade arbeten har köras.

3.Confirm att säkerhetskopior har gjorts och sparats till en säker plats.
4.Monitor diskutrymme för att säkerställa din SQL-servrar kommer inte springa ute om bricka utrymme. För bästa resultat bör alla diskar har 15% eller mer ledigt utrymme.
5.Throughout dagen regelbundet övervaka prestanda både via System Monitor och Profiler / SQL Trace.
6.Regularly övervaka och identifiera allvarliga problem.
7.Keep en logg över alla ändringar du gör i servrar, inklusive dokumentation av eventuella prestandaproblem du upptäcka och åtgärda.
8.Create SQL Server varningar för att meddela dig om eventuella problem och få dem e-post till dig. Vidta åtgärder som behövs.
9.Regularly återställa säkerhetskopior till en testserver för att verifiera att du kan återställa dem. Du behöver inte återställa alla säkerhetskopior varje dag, men inte så ofta att du är säker på att du har bra säkerhetskopior.
10.Take lite tid att lära sig något nytt som en DBA till ytterligare din professionella utveckling.

Installation
1.Always fullt dokument installeras så att din SQL Server-instanser lätt kan återges i en nödsituation.
2.If möjligt, installera och konfigurera alla dina SQL Server-instanser konsekvent, efter en överenskomna organisation standard.
3.Don inte installera SQL Server-tjänsterna på fall som inte använder dem, till exempel Microsoft fulltext-indexering, Reporting Services och Analysis Services.
4.Beträffande bästa prestanda i SQL Server körs under Windows, stäng av alla operativsystem tjänster som inte behövs.
5.Vid optimal SQL Server prestanda, vill du ägna din fysiska servrar för att bara köra en enda instans av SQL Server, tillsammans med några andra program.
6.For best I / O-prestanda, lokalisera databasfiler (. MDF) och log-filer (. LDF) på separata spindlar att isolera mönster diskåtkomst.
7.If tempdb kommer att användas mycket och satte den på en egen separat spindlar.
8.Do inte installera SQL Server på en domänkontrollant.
9.Be säker på att SQL Server är installerat på en NTFS-partition.
10.Don inte använda NTFS datafil kryptering (EFS) och tryck på SQL Server-databas och loggfiler.

Uppgradering
1.Run SQL Server Upgrade Advisor före uppgradering. Göra nödvändiga ändringar innan du utför uppgraderingen.
2.Perform ett test uppgradering av din testservrar SQL innan du uppgraderar din produktion servrar. Och glöm inte att testa dina program med den nya versionen också.
3.Before uppgraderingen vara säker på att du har en plan för att falla tillbaka till i fall att uppgraderingen är problematiskt.
4.Don inte uppgradera SQL Server kluster på plats. I stället bygga upp dem igen på ny hårdvara.
5.If uppgradering från en tidigare version av SQL Server, bör du uppdatera all den statistik på alla dina databaser. Detta beror på att statistiken inte uppdateras automatiskt under uppgraderingen.

Säkerhet
1.Säkerställa den fysiska säkerheten för varje SQL Server, förhindra att obehöriga användare från att fysiskt komma åt dina servrar.
2.Only installera de begärda nätverk bibliotek och nätverksprotokoll på din SQL Server-instanser.
3.Minimize antal systemadministratörer som har åtkomst till SQL Server.
4.As en DBA, logga in med sysadmin privilegier behövs endast när. Skapa separata räkenskaper för DBAs att få tillgång till SQL Server när sysadmin privilegier inte behövs.
5.Assign SA kontot en mycket dunkla lösenord, och aldrig använda den för att logga in på SQL Server. Stället använder en Windows-autentisering för att komma åt SQL Server som sysadmin.
6.Give användare minst mängd behörigheter de behöver för att utföra sitt arbete.
7.Use lagrade procedurer eller synpunkter så att användarna kan komma åt data istället för att låta dem direkt tillgång tabeller.
8.When möjligt inloggningar använda Windows-autentisering i stället för SQL Server inloggningar.
9.Use starka lösenord för alla SQL Server-inloggning konton.
10.Don inte ge behörighet till allmänheten databas roll.
11.Remove inloggnings-ID som inte längre behöver tillgång till SQL Server.
12.Disable gästen användarkontot från varje användare databas med hjälp återkalla ansluta från GÄST.
13.Don inte använda ömsesidig databas ägande kedja om det inte behövs.
14.Never bevilja tillstånd till xp_cmdshell till icke-systemadministratörer.
15.Remove prov databaser från all produktion SQL Server-instanser.
16.Use Windows globala grupper eller SQL Server roller att hantera grupper av användare som behöver liknande tillstånd.
17.Avoid skapa nätverk aktier på någon SQL Server.
18.Configure inloggning revision så att du kan se vem som har lyckats och misslyckats, att logga in.
19.Don inte använda SA konto eller logga in ID som är medlemmar i sysadmin grupp, konton som används för åtkomst SQL Server från applikationer.
20.Ensure att din SQL-servrar är bakom en brandvägg och inte utsätts direkt till Internet.
21.In SQL Server 2005 och tidigare, ta bort den inbyggda / gruppen Administratörer för att förhindra lokal server administratörer från att kunna få tillgång till SQL Server. I SQL Server 2008, den inbyggda / gruppen Administratörer finns inte som standard.
22.Run varje separat SQL Server-tjänsten under ett annat Windows-domän-konto.
23.Only ge SQL Server-tjänsten står de minsta rättigheter och behörigheter som krävs för att driva tjänsten. I de flesta fall är lokala administratörsrättigheter inte krävs och domän administratör rättigheter aldrig behövs.
24.When använder distribuerade frågor, använda länkade servrar istället för fjärrservrar. Fjärrservrar finns bara för bakåtkompatibilitet.
25.Do inte surfa på nätet från en produktions SQL Server-instansen.
26.Instead att installera virus / spionprogram skydd på en SQL Server, utföra genomsökningar från en fjärrserver under en del av dagen då användaren aktivitet är mindre.
27.Add operativsystemet och SQL Server Service Pack-och hotfixes snart efter att de släpps och testas, eftersom de ofta innehåller säkerhetsförbättringar.
28.Encrypt alla SQL Server backuper med en tredje part backup verktyg, såsom Red Gate SQL Backup Pro.
29.Only möjliggöra C2 revision eller Common Criteria följs om det behövs, eftersom de inte tillför betydande utförande overhead.
30.Consider kör en SQL Server-säkerhet scanner mot din SQL-servrar för att identifiera säkerhetshål.
31.Consider Enabling SSL eller IPSec för anslutningar mellan SQL Server och dess kunder.
32.If använder SQL Server 2005/2008, möjliggöra kontroll lösenord politik.
33.If använda SQL Server 2008 i en hög säkerhet, överväga att genomföra Transparent Data Encryption att skydda konfidentiella uppgifter.
34.If använda SQL Server 2005, inte använda SQL Server Surface Area Configuration verktyg för att låsa upp funktioner du inte absolut behöver.
35.If använder SQL Server 2005/2008 och du skapar endpoints endast bevilja CONNECT behörigheter till inloggningarna som behöver tillgång till dem. Uttryckligen förneka CONNECT behörigheter till slutpunkter som inte behövs av användarna.
 
Job Maintenance
1.Avoid överlappande jobb på samma SQL Server-instans. Helst bör varje jobb drivs separat vid olika tidpunkter.
2.När skapa arbetstillfällen, se till att inkludera fel fångstmetoder, log jobb aktivitet, och sätta upp varningar så du veta direkt när ett jobb misslyckas.
3.Create en speciell SQL Server inloggningskonto vars enda syfte är att köra jobb, och koppla den till alla jobb.
4.If ditt jobb inkluderar Transact-SQL-kod, se till att den är optimerad för att fungera effektivt.
5.Periodically (dagligen, veckovis eller månadsvis), bygga om eller omorganisera index för dina databaser för att ta bort logisk splittring och slösat utrymme.
6.Periodically, som en del av dina schemalagda aktiviteter underhålla databasen, köra DBCC CHECKDB på alla dina databaser verifiera databas integritet.
7.Avoid kör mest DBCC kommandon under tider på dagen. Dessa kommandon är ofta I / O intensiva och kan minska prestandan i SQL Server, negativt påverkar användarna.
8.If du sällan startar om SQL Server-tjänsten kan det hända att den aktuella SQL Server log blir mycket stora och tar lång tid att ladda och visa. Du kan stänga det aktuella felloggen och skapa ett nytt genom att köra sp_cycle_errorlog eller DBCC ERRORLOG, så att loggen inte blir alltför stor. Ställa in det som en gång i veckan jobb.
9.Script alla jobb och lagra dessa skript på ett säkert område så att de kan användas om du behöver återskapa servrar.
  
SQL Server Configuration Settings
1.SQL Server konfigurationsinställningar bör förbli på sina standardinställningar. Eventuella ändringar av dessa inställningar bör endast göras av en erfaren DBA som förstår fördelarna och nackdelarna med att göra ändringar.
2.Om du använder 32-bitars versionen av SQL Server, och om du använder 4 GB RAM eller mer, se till att du har alla AWE inställningar korrekt inställd.
3.In flesta fall “på inställningarna för” maximal server minne “och” minsta server minne bör överlåtas till standardvärden. Detta beror på standardvärden låta SQL Server för att dynamiskt allokera minne i servern för bästa övergripande optimala prestanda. Undantag från denna tumregel kan komma väl till pass om du använder 32-bitars AWE minne, eller 64-bitars minne, där du kan behöva ändra “Memory maximala server” till ett belopp som är mindre än mängden fysiskt RAM i servern.
 
Databasinställningar
1.Leave “Auto skapa statistik” och “auto statistik uppdatera” alternativ för alla användare databaser. Endast i mycket sällsynta fall bör dessa vara avstängd, och om de är avstängd, måste du manuellt uppdatera statistiken själv.
2.Don inte frestas att använda den “auto shrink” databas alternativet, eftersom det kan avfall SQL Server-resurserna i onödan och bidra till index fragmentering. Istället, om du behöver krympa en databas, gör det manuellt.
3.Don inte lita på AUTOGROWTH att automatiskt hantera storleken av din databas. Istället proaktivt övervaka och ändra databasens storlek som omständigheterna kräver. Använd endast AUTOGROWTH att hantera oväntade tillväxt.

Replication
1.Replication behov bör definieras tydligt innan du skapar en replikeringstopologi. Framgångsrika replikering kan vara svårt och kräver mycket förplanering.
2.Ideally bör förlag, distributörer och abonnenterna på separata fysiska hårdvara.
3.Create, dokumentera och testa en säkerhetskopiering och återställning strategi. Återställa replikerade databaser kan vara komplicerat och kräver mycket planering och praxis.
4.Script replikeringstopologin som en del av din disaster recovery plan så att du lätt kan återskapa din replikeringstopologi om det behövs.
5.Use standard replikeringsinställningar, såvida du inte kan se att en icke-standardinställning faktiskt förbättras replikering prestanda eller andra frågor. Vara säker på att du testar alla förändringar så att de blir så effektiva som förväntat.
6.Fully förstå konsekvenserna av att lägga till eller tappa artiklar, ändra publicering egenskaper och ändra schemat av publicerade databaser, innan någon av dessa förändringar.
7.Periodically, validera data mellan förlag och abonnenter.
8.Regularly övervaka replikering processer och jobb att se till att de fungerar.
9.Regularly övervaka replikering prestanda och prestanda melodi som behövs.
10.Add varningar till alla efterföljare jobb så att du informeras om alla jobb misslyckanden.
 
Hög tillgänglighet Best Practices : General High Availability
1.Physically skydda din SQL-servrar från obehöriga användare.
2.Physically dokument alla dina SQL Server-instanser. Inkorporera effektiva förändringar.
3.Always använda en RAID-aktiverat direkt attached storage array eller SAN för att lagra dina data.
4.Use SQL Server klustring, databasspegling, eller logga sjöfart att ge extra feltolerans.
5.Replication är inte ett effektivt sätt att skydda dina data från en hög tillgänglighet synvinkel.
6.Ensure att hela din IT-infrastruktur är överflödig. Det är inte starkare än dess svagaste länk.
7.Always använda server-class maskinvara och standardisera på samma hårdvara så mycket som möjligt.
8.Use hårdvara och mjukvara övervakningsverktyg så att du snabbt bli medveten om när problemen först uppkommer.
9.After grundlig testning, gälla alla nya service pack och hot fixes till OS och SQL Server.
10.Cross-utbilda personal så att det finns flera personer som kan hantera i stort sett alla problem eller problem.

Katastrofåterställning
1.You måste skapa en katastrofplan för återhämtning och omfatta alla detaljer du behöver för att återuppbygga era servrar.
2.As din SQL Servers förändras över tid, glöm inte att uppdatera din plan katastrofer.
3.Write katastrofen återhämtningsplan så att alla datakunniga person kommer att kunna läsa och följa den. Inte ta en DBA kommer att bygga om servrarna.
4.Fully testa din plan katastrofåterställning minst en gång om året.
5.Review alla de bästa metoderna du känner och genomföra dem på lämpligt sätt. Kom ihåg, som DBAs, är vi väktare av organisationens uppgifter. Detta är ett enormt ansvar.
Backup
1.All OLTP produktion databaser bör fastställas att använda fullständig återhämtning modellen. På detta sätt kan du skapa säkerhetskopior transaktionsförteckning på regelbunden basis.
2.Whenever möjligt göra en daglig fullständig säkerhetskopia av alla system och databaser användare.
3.För alla OLTP produktion databaser, utföra regelbundna säkerhetskopior transaktionsförteckning, minst en gång i timmen.
4.Perform fullständiga backuper under perioder med låg användarnas aktivitet för att minimera effekterna av säkerhetskopior på användarna.
5.Periodically utföra återställer test backup så att dina säkerhetskopior är bra och kan återställas.
6.Encrypt dina säkerhetskopior ifall de skulle bli “förlorade”.
7.Store säkerhetskopior offsite och på en säker plats.
8.If använda SQL Server kryptering bör du säkerhetskopiera lämpliga nycklar tjänsten master, databas master nycklar och certifikat.
9.If du tycker att backup gånger tar längre tid än din backup fönster, eller om backup filstorlekar tar upp för mycket plats på din lagringsenhet, överväga ett tredje parts program för säkerhetskopiering, som Red Gate SQL Backup Pro.
10.Document, steg för steg, i processen att återställa system och databaser användare på samma eller en annan server. Du vill inte att titta denna information under en nödsituation.
 
Clustering
1.Detailed planering är avgörande för framgången för varje SQL Server cluster installation. Fullt planera installationen innan du utför den faktiska installationen.
2.An dyr klustret är av föga värde om den infrastruktur som behövs inte också feltolerant. Till exempel, glöm inte makt redundans, redundans, etc.
3.Run bara en enda instans av SQL Server per nod. Oavsett om du har två eller åtta noder i klustret, gå minst en nod som en failover nod.
4.Cluster noder får inte vara domänkontrollanter, och alla noder måste tillhöra samma domän och bör ha tillgång till två eller flera domänkontrollanter.
5.All cluster hårdvara måste vara på Microsoft Windows Clustering Hardware Compatibility List, och certifierad att arbeta tillsammans som en del i ett kluster.
6.Since kluster är inte avsedd att skydda data (endast SQL Server-instanser), den delade lagringsenheten används av klustret måste införliva feltolerant teknik. Överväg log sjöfart, databasspegling, eller SAN-replikering för att ytterligare skydda din produktion databaser.
7.Before installera Windows Clustering och SQL Server Clustering, vara säker på att alla drivrutiner och programvara är up-to-date, inklusive den senaste Service Pack eller hot fixes.
8.Each nod i ett kluster ska ha samma hårdvara, drivrutiner, programvara och inställningar.
9.Fiber kanal delade arrayer är att föredra framför SCSI när man bygger ett kluster och Fiber Channel måste användas om man inkluderar fler än två noder i klustret.
10.In konventionell kluster, beslutförhet drivning skall på eget feltolerant, hängivna, disk på 500MB eller större
11.Once klustret har installerats, testa det ordentligt för alla tänkbara fel scenario.
12.Do kör inte antivirus-eller antispionprogram på en SQL Server-kluster.
13.Before du börjar installera Cluster Services eller SQL Server klustring, avgöra din virtuella namn och samla IP-adresser i förväg. Detta gör det enklare när det är dags att ange denna information när du installerar och konfigurerar kluster.
14.Monitor aktiv produktion kluster på daglig basis, letar efter eventuella problem. Periodiskt prov failover om produktionen servrar för att säkerställa alla fungerar bra.
15.Once du har en stabil SQL Server Cluster igång, vara mycket SLUG om att göra några ändringar i det, alls.
 
SQL Server 2005/2008 Mirroring
1.Det största databas och spegeln databas bör på separata fysiska hårdvara, helst på olika fysiska platser.
2.Den vittne server bör vara på separata fysiska hårdvara, och vara på ett separat nätverk (bäst om vid det tredje plats).
3.Initial databasspegling konfiguration bör göras under kortare tider, eftersom installationsprocessen kan försämra prestanda produktionen databas som speglas.
4.Use hög tillgänglighet läge så är möjligt, och högpresterande läge endast när de behövs.
5.Vid underlätta administrationen, hårdvaran, bör tillsammans med operativsystemet och SQL Server Configuration vara identiska (åtminstone väldigt lika) mellan de två servrarna.
6.While en snabb anslutning krävs inte mellan speglade servrar, snabbare uppkoppling och bättre kvalitet anslutningen, desto bättre.
7.You kommer att vilja optimera resultaten av de speglade databas så mycket som möjligt för att minska overhead orsakas av spegling själva processen.
8.Thoroughly test databasspegling innan det i produktion.
9.Övervaknings databasspegling dagligen för att säkerställa att den fungerar, och sammanträder resultatmål.
10.Develop en formell operativ och återkravsförfarande (och handling) för att stödja spegling. Regelbundet testa failover för att säkerställa att det fungerar.
 
Log Shipping
1.If du för närvarande inte anställa en koncentration eller databasspegling för SQL-servrar på grund av kostnad, att anställa log sjöfart att bidra till att öka din hög tillgänglighet. Det ger någorlunda hög tillgänglighet till låg kostnad.
2.Om du utnyttja SQL Server log shipping kapacitet, kommer du vill behålla loggen frakt tjänst för övervakning på en SQL Server på sitt eget, inte på källan eller mottagaren servrar som deltar i loggen sjöfarten. Detta är inte bara viktigt för feltolerans, men eftersom loggen frakt bevakningstjänst ådrar overhead som kan påverka resultatet av källan och servrar destination.
3.Monitor log shipping dagligen för att fungerar framgångsrikt.
4.Learn vad du behöver veta för att fastställa logga frakt om synkroniseringen förloras mellan produktion och säkerhetskopiera databaser.
5.Document och testa din plan server återhämtning, så du kommer att vara redo i händelse av en server fel.
Performance Tuning Best Practices
 
Prestandaövervakning
1.Regularly övervaka systemets prestanda med System Monitor eller liknande verktyg.
2.Regularly övervaka systemets prestanda med hjälp av Performance Monitor. Använd Performance Monitor för både analys i realtid och historisk / utgångsläget analys.
3.Vid kör SQL Server 2005 SP2 eller senare, installera gratisversionen SQL Server Performance Dashboard. Det kan användas för övervakning i realtid och prestanda felsökning. Om du använder SQL Server 2008, överväga att använda Performance Data Collector.
4.Regularly övervaka SQL Server aktivitet med hjälp av SQL Trace eller Profiler. Vara säker på att spåren är tagna under tider på dygnet som är representativa för den typiska verksamhet som pågår i varje server. När du kör SQL Trace eller Profiler, inte samla in mer information än du behöver för att samla in, för att minska belastningen från utför spår.
5.Perform resultatövervakning från en dator som inte är SQL Server du är övervakning. Kör verktyg för övervakning på en separat skrivbordet eller servern.
 
Hardware Performance Tuning
1.Although tunga hårdvara kan hjälpa SQL Server prestanda, tillämpning och databas design kan spela en större roll i övergripande resultat än hårdvara. Hålla detta i minnet, att kasta goda pengar efter dåliga på serverhårdvara inte alltid bestämma SQL Server prestanda problem. Innan allt snabbare maskinvara, se till att du noggrant har ställt dina program, Transact-SQL, och databasindexering.
2.In många fall ytterligare RAM-minne till en server är det billigaste och snabbaste sättet att öka hårdvara utföra en SQL Server. Men innan du lägger till mer RAM-minne till en SQL Server, först säkerställa att den kommer att användas av SQL Server. Lägga till mer RAM-minne betyder inte att SQL Server alltid kommer att använda det. Om den aktuella Buffer Hit Cache Ratio ligger över 99% och du har väl mer än 100 MB ledigt RAM-minne, kan din server inte dra nytta av att lägga till extra RAM-minne.
3.Vid din SQL Server totala CPU-användning är ligger över 80% eller mer, du behöver fler processorer, snabbare processorer, eller om du behöver hitta ett sätt att minska belastningen på aktuell server.
4.If den Logical Disk:% Idle Time counter är mindre än 50%, och den logiska Disk: Avg. Disk Sec / Läs motverka eller Logical Disk: Avg. Disk Sec / Write motverkar mer än 15ms, då har du troligtvis upplever en disk-I / O-prestanda problem och måste börja leta efter lösningar.
5.Don inte köra något program på din server än SQL Server, med undantag av nödvändiga nyttigheter.
6.NTFS-formaterade partitioner bör inte överstiga 85% av sin kapacitet. Till exempel, om du har en 100GB disk, den bör aldrig vara bättre än 85GB. Varför? NTFS behöver utrymme för att arbeta, och när du överstiger 85% kapacitet, blir NTFS mindre effektiv och I / O kan lida för det. Dessutom diskfil fragmentering utilities behöver minst 15% ledigt utrymme för att fungera korrekt.
7.If din SQL Server-databas upplevelser mestadels läser, sedan en RAID 5 array erbjuder bra skydd och tillräckliga prestanda. Om din SQL Server-databas för det mesta skriver, sedan använda en RAID-array 10 för bästa skydd och prestanda.
8.If din SQL Servers tempdb databas används i hög grad, anser placera det på en rad egna spindlar (t.ex. RAID 1 och RAID 10). Detta kommer att möjliggöra disk I / O för att bli mer jämnt fördelade för SQL Server-instans, minska disk-I / O påstående frågor och påskynda SQL Server övergripande resultat.
9.The fler spindlar du har i en array, desto snabbare disk-I / O kommer att bli. Kontrollera att diskkontroller kan hantera den extra I / O som att lägga till fler spindlar.
10.Ensure att all hårdvara är igång senast godkända drivrutiner.
 
Indexering
1.Periodically, kör Database Engine Tuning Advisor mot nuvarande Profiler spår kan identifiera saknas index.
2.Remove index som aldrig används.
3.Don inte skapa misstag överflödig index.
4.As en tumregel bör varje bord ha minst en klustrade index. Allmänhet, men inte alltid, bör Clustrade indexet på en kolumn som monotont ökar – till exempel en identitet kolumn, eller någon annan kolumn där värdet ökar – och är unikt. I många fall är primärnyckeln den perfekta kolumnen för klustrade index.
5.Since du kan bara skapa ett klustrade index per tabell, ta extra tid att noga överväga hur den ska användas. Överväga vilken typ av frågor som kommer att användas mot bordet, och gör en kvalificerad gissning om vilken fråga (den vanligaste köra mot bordet, kanske) är den mest kritiska, och om denna fråga kommer att dra mest nytta av att ha ett grupperat index.
6.When skapa ett sammansatt index, och när alla andra faktorer är lika, att göra de mest selektiva kolumn den första kolumnen i indexet.
7.Generally sett hålla “bredd” på din index så smal som möjligt. Detta minskar storleken på indexet och minskar antalet disk-I / O läser krävs för att läsa index, öka prestanda.
8.Avoid lägga till ett grupperat index till en GUID kolumn (uniqueidentifier datatyp). GUID tar upp 16-byte lagringsutrymme, mer än ett Identify kolonn, vilket gör att indexet större, vilket ökar I / O-läsningar, vilket kan skada prestandan.
9.Indexes bör övervägas för alla kolumner som ofta tillgängliga för JOIN, DÄR, ORDER BY, GROUP BY, TOP, och tydliga bestämmelser.
10.Don inte automatiskt lägga till index på ett bord, eftersom det verkar som det rätta att göra. Bara lägga index om du vet att de kommer att användas av frågor köra mot bordet.
11.When skapa index, försöka göra dem unika index om det överhuvudtaget är möjligt. SQL Server kan ofta söka igenom ett unikt index snabbare än ett icke unikt index eftersom på ett unikt index, är varje rad unika, och när det behövs rekord har hittats har SQL Server inte leta längre.
12.If du utföra regelbundna går mellan två eller flera tabeller på dina frågor, kommer resultatet att optimeras om varje gick kolumner har lämpliga index.
13.Don inte accepterar automatiskt standardvärdet på 100 för att fylla faktorn för ditt index. Det kanske eller kanske inte bäst motsvarar dina behov. En hög fyllnadsgrad är bra för sällan ändrade data, men mycket ändrade uppgifterna behöver en lägre fyllnadsgrad för att minska sida splitting.
14.Don inte över index din OLTP tabeller, som varje index du lägger ökar tiden det tar att utföra sätter, uppdaterar och tar bort. Det finns en fin linje mellan att ha den idealiska antalet index (för VÄLJER) och idealet nummer för att minimera den overhead som uppstår med index under data ändringar.
15.If du vet att din ansökan kommer att utföra samma fråga om och om igen på samma bord, överväga att skapa en icke-klustring täcker index på bordet. Ett omfattande index, som är en form av ett sammansatt index omfattar alla kolumner som nämns i SELECT, JOIN, och där klausuler i en fråga. På grund av detta, innehåller indexet de data du söker och SQL Server inte behöver söka upp de faktiska uppgifterna i tabellen, vilket minskar I / O, och ökad prestanda.
 
SQL Server 2008 Compression Best Practices
1.SQL Server 2008, Enterprise Edtition erbjuder både rad och kolumn kompression, som kan användas för att minska mängden utrymme data tar upp på disken och i bufferten poolen, vilket kan öka prestandan.
2.Compression kräver användning av extra CPU-cykler att genomföra. På grund av detta, om din server har för närvarande en CPU flaskhals, då kompression bör sannolikt undvikas.
3.Compression fungerar bäst för tabeller som upplever mest läser. Tabeller som upplever ett stort antal DML verksamhet bör nog inte vara komprimerade.
4.Don inte använda komprimering på borden föremål för tunga bilagor, såsom bulk skär.
 
SQL Server 2008 Data Collector Best Practices
1.Det SQL Server 2008 Data Collector kan användas för att samla in, lagra och analysera många olika typer av SQL Server prestanda aktiviteter.
2.Using SQL Server 2008 Data Collector medför vissa prestanda overhead, och på grund av detta kanske du vill minimera mängden data som samlas in av det.
3.While förvaltningen Data Warehouse kan finnas på varje instans av SQL Server, rekommenderas att en särskild SQL Server används för att lagra Management Data Warehouse används för att lagra de insamlade data.
 
Best Practices for Resource Governor
1.Det SQL Server 2008 Resource Governor kan användas för att begränsa hur mycket CPU och minne resurserna allokeras till en viss användare anslutning, vilket gör att DBA ge resurs företräde för vissa anslutningar via andra anslutningar.
2.Om du använder Resource Governor, se till att DAC är påslagen, eftersom det är det enda sättet att felsöka och åtgärda en dålig Resource Governor konfiguration.
3.Classifier användardefinierade funktionen ska väl testas och optimeras. Om felaktigt skrivet en klassificerare funktion kan orsaka anslutningar att bromsa, Time Out, och även skapa en oändlig loop som låser upp SQL Server.
4.Monitor Resource Governor efter genomförandet att bekräfta lämplig användning. Om du inte är försiktig, kan du introducera frågeprestandan problem som inte fanns innan du använder Resource Governor. Till exempel, om minnet är begränsat för mycket, kan det orsaka en optimal execution plan måste skapas och verkställas, vilket skadar prestandan.
5.Test din Resource Governor genomförande på testsystemet innan det på produktion
Ansökan Design och kodning Best Practices
 
Databasdesign
1.Bad logisk databasdesign resulterar i dålig fysisk databasdesign, och leder i allmänhet dålig databas prestanda. Så om det är ditt ansvar designa en databas från början, se till att du tar den tid och ansträngning för att få rätt logisk databasdesign. När den logiska utformning är rätt, måste du också ta tid att få den fysiska konstruktionen rätt.
2.När utforma en ny databas, genomföra konsekvent namngivning normer för alla dina objekt.
3.Take nytta av SQL Servers inbyggda referensintegritet. Du behöver inte skriva dina egna.
4.Always ange smalaste kolumner du kan. Dessutom alltid välja den minsta datatyp du behöver för att hålla de data du behöver för att lagra i en kolumn. Den smalare kolonnen, desto mindre mängd data SQL Server måste lagra, och snabbare SQL Server kan läsa och skriva data.
5.När utforma en ny databas, fullständigt dokumentera varje tabell, kolumn, default, check tvång och förhållande, så att andra kan lätt ta reda på vad de menar, eller hur de skall användas.
 
Frågor och lagrade procedurer
1.Maintain all kod i en källa kontrollsystem.
2.Keep transaktioner så kort som möjligt. Detta minskar låsning och ökar ansökan parallellt, vilket bidrar till att öka prestanda.
3.Avoid använder query tips om du inte vet exakt vad du gör, och du har kontrollerat att det hint faktiskt extra prestanda.
4.Encapsulate alla transaktioner inom lagrade procedurer, inklusive både påbörja transaktion och COMMIT uttalanden transaktion i förfarandet.
5.Use det minst begränsande transaktionen isolering nivå som möjligt för dina användare anslutning, i stället för att alltid använda standard READ ÅTAGANDEN. Naturligtvis gör inte någonting som kan äventyra integriteten och dina uppgifter.
6.Whenever ett klientprogram behöver skicka Transact-SQL för SQL Server, skicka det i form av en lagrad procedur i stället för ett skript eller inbäddade Transact-
 
SQL. Lagrade procedurer erbjuder många fördelar, bland annat:
a.Reduced nätverkstrafik och latens, höja programmets prestanda.
b.Stored förfarande utförande planer kan återanvändas, vistas sparat i SQL Server minne, minskar server overhead. Detta är också främst gäller för Transact-SQL-koden skickas till SQL Server utanför en lagrad procedur.
c.Client utförande önskemål är effektivare. Till exempel, om en ansökan behövs för att infoga ett stort binärt värde till en bild data kolumn inte använda en lagrad procedur, måste man konvertera det binära värdet till en teckensträng (som fördubblar dess storlek), och skicka den till SQL Server. När SQL Server tar emot det, det måste då konvertera tecknet värde tillbaka till binär form. Detta är en mycket bortkastad overhead. En lagrad procedur eliminerar denna fråga parametervärden stanna i binärt format hela vägen från ansökan till SQL Server, minska overhead och ökad prestanda.
d.Stored rutiner bidrar till att främja återanvändning av kod. Även om detta inte direkt stimulera en programmets prestanda, kan det öka produktiviteten för utvecklare genom att minska den mängd kod som behövs, samt minska felsökning tid.
e.Stored förfaranden kan kapsla logik. Du kan ändra en lagrad procedur i registret utan att påverka klienter (antar du om parametrarna samma och inte ta bort något resultat uppsättningar kolumner). Detta sparar utvecklare tid.
f.Stored förfaranden ger bättre säkerhet för dina data.   
7.SET NOCOUNT om i början av varje lagrad procedur du skriver.
8.Before rullande en lagrad procedur ut i produktion, granska den oanvänd kod, parametrar eller variabler som du kanske har glömt att ta bort när du skapade den, och ta bort dem.
 
Transact-SQL
1.Don inte rädd att liberal användning av in-line och kommentarer block i Transact-SQL-kod, kommer de inte att påverka resultatet av din ansökan och de kommer att öka produktiviteten när du och andra kommer tillbaka till koden och försöka ändra det.
2.If möjligt, undvika att använda SQL Server pekare. De använder vanligen mycket SQL Server-resurserna och försämrar prestandan och skalbarheten i dina program. Om du behöver utföra rad-för-rad operationer, försöka hitta en annan metod för att utföra uppgiften.
3.When med unionens förklaring, kom ihåg att, som standard, utför det motsvarar en SELECT DISTINCT på slutresultatet fastställs. Med andra ord tar UNIONEN resultaten av två likadana postuppsättningar, kombinerar dem, och sedan utför en SELECT DISTINCT i syfte att undanröja eventuella dubblerade rader. Detta sker även om det finns någon dubbel bokföring i den slutliga recordset. Om du vet att det finns dubbla poster, och detta utgör ett problem för din ansökan, sedan med alla medel använda unionens uppgift att eliminera dubbla rader.
4.Carefully bedöma om din VÄLJ frågan behöver DISTINCT klausul eller inte. Vissa utvecklare automatiskt lägga denna klausul alla deras SELECT uttalanden, även om det inte är nödvändigt.
5.In dina frågor, inte återvänder kolumnuppgifter du inte behöver. Till exempel bör du inte använda SELECT * att returnera alla kolumner från en tabell om du inte behöver all data från varje kolumn. Dessutom använder SELECT * kan förhindra användningen av täckningsindex ytterligare potentiellt skadar frågeprestandan.
6.Always innehålla en WHERE-klausul i ditt SELECT uttalande att minska antalet rader som returneras. Endast träffar på de rader du behöver.
7.If din ansökan låter användare köra frågor, men det går inte i din ansökan att enkelt hindra användarna från att komma tillbaka hundratals, kanske tusentals onödiga rader med data, överväga att använda TOP aktör inom SELECT-uttryck. På detta sätt kan du begränsa hur många rader returneras, även om användaren inte anger några kriterier för att minska antalet rader eller skickas till klienten.
8.Try att undvika när bestämmelser som är icke-sargable. Om en WHERE klausul sargable, innebär detta att man kan dra nytta av ett index (om det finns en sådan) för att påskynda slutförandet av frågan. Om en WHERE klausul om icke-sargable, innebär detta att WHERE (eller åtminstone delar av den) inte kan dra nytta av ett index, i stället göra en tabell / index scan, vilket kan orsaka frågan prestanda blir lidande. Icke sargable söka argument i WHERE klausulen, såsom “IS NULL”, “<>”, “!=”, “!>”, “!<“, “NOT”, “inte finns”, “inte särskilt “NOT LIKE” och “LIKE ‘% 500′” i allmänhet förhindrar (men inte alltid) att Frågeoptimeraren från att använda ett index för att utföra en sökning. Dessutom uttryck som innehåller en funktion för en kolumn, uttryck som har samma kolumn på båda sidor av operatören, eller jämförelser mot en kolumn (inte konstant), är inte sargable.
9.If du använder SQL Server 2008 debugger, bara köra den mot en test databas, aldrig en produktion databas.
 
SQL Server CLR
1.Använda CLR att komplettera Transact-SQL-kod, inte ersätta det.
2.Standard tillgång till data, till exempel SELECT, sätter, uppdaterar och tar bort är bäst sker via Transact-SQL-kod, inte CLR.
3.Computationally eller formellt intensiva affärslogik kan ofta vara inkapslade som funktioner körs i CLR.
4.Use CLR för felhantering, eftersom den är mer robust än vad Transact-SQL erbjuder.
5.Use CLR for string manipulation, eftersom det är oftast snabbare än att använda Transact-SQL.
6.Use CLR när du behöver utnyttja den stora bas klassbibliotek.
7.Use CLR när du vill få tillgång till externa resurser, såsom filsystem, Event Log, en webbtjänst, eller registret.
8.Set CLR Code Access Security till de mest restriktiva behörigheter som möjligt.
 
XML
1.XML är bäst för modellering data med en flexibel eller rik struktur.
2.Don inte använda XML för konventionella, strukturerad data.
3.Store objektegenskaper som XML-data i XML-datatyper.
4.When möjligt, använda skrivit XML-datatyper över untyped XML-data som ger högre prestanda.
5.Add primära och sekundära index till XML kolumner för att snabba hämtning.
 
SQL Server Component Best Practices: 

1.Schedule stora data import, export, eller ombyggnad på din produktion servrar under mindre hektiska perioder på dagen för att minska påverkan på användarna.
2.Consider har stora, resurskrävande SSIS-paket på en dedikerad fysisk server.
3.Rename alla standardnamn och egenskaper beskrivning med standard namngivningskonventioner. Detta gör det enklare för dig och andra att avlusa eller ändra dina paket.
4.Include kommentarer i ditt paket som gör det lättare för dig och andra, att förstå vad som händer.
5.Use Sequence Containers att organisera paketet strukturer i logiska arbetsenheter.
6.Use Namespaces för ditt paket.
7.Only utrymme variabler för de kärl som de behövs.
8.If du vet att data är redan försorterade, som IsSorted = SANT. Göra det kan bidra till att förhindra onödiga slag, som förbrukar resurser i onödan.
9.When välja kolumner i en tabell att återvända tillbaka bara vad som behövs. Dessutom använder Transact-SQL-satser i en OLE DB Källa komponent eller Uppslag komponent, i stället för att välja en hel tabell. Därigenom kan man undvika onödiga data från behandlas.
10.When Infoga data, använda SQL Server Destination stället för OLE DB Destination att öka prestanda.
 
Reporting Services 2008
1.Ideally, ägna en eller flera fysiska servrar för Reporting Services.
2.Den SQL Server-databaser används för att producera rådata för rapporter bör vara på sin egen dedikerade fysiska servrar.
3.Only tillbaka de faktiska uppgifter som du behöver i rapporten, varken mer eller mindre.
4.Optimize utförandet av Transact-SQL-kod du använder för att visa information för din rapport innan du utforma den fysiska utseende av rapporten.
5.Manage all rapport och kod. RDL filer med hjälp av ett system källkontroll.
 
Analys SSAS:
1.Always köra OLAP applikationer på sina egna dedikerade servrar, aldrig dela en server som kör OLTP applikationer. De två typer av program är ömsesidigt uteslutande när det gäller Performance Tuning.
2.När utforma OLAP-kuber, ingår inte åtgärder eller dimensioner som användarna inte kommer att använda. Det sättet att förhindra detta är bra system för analys och design. Oanvända data kommer att öka storleken på dina kuber och långsam prestanda.
3.When använder design Star schemat, minst, kommer du att skapa en icke-klustrade index på primärnyckeln i varje dimension bord och en icke-klustring index på varje tillhörande främmande nycklar. Därifrån kan du skapa icke-klustrade index på ytterligare kolumner som ska kontaktas på ofta.
4.When du skapar index på datalager och datamarts, använda en FILLFACTOR på 100 för att säkerställa att ett index är så fullständig som möjligt. Detta minskar onödig I / O, påskynda genomförandet.
5.Schedule kub uppdateringar på din produktion servrar under mindre hektiska perioder på dagen för att minska påverkan på användarna.
 
Service Broker
1.Planning för en Service Broker genomförande krävs att du besvarar dessa frågor:
a.Decide den roll som Service Broker kommer att spela i ansökan.
b.Identify information som krävs för varje steg i en konversation för att avsluta varje uppgift.
c.Select där meddelandet processorlogik kommer att köras.
d.Decide om vilken teknik som skall användas för att genomföra din ansökan
e.Identify vilken server komponenter kommer din ansökan använder mest.
2.Before rulla ut en Service Broker ansökan, testa den ordentligt i en testmiljö som nära motsvarar din faktiska produktionen miljö.
3.After en Service Broker ansökan har utformats och skrivits, måste det byggas ut. Detta sker i allmänhet med en uppsättning installationsskript som sprang för att skapa de nödvändiga typer av meddelanden, kontrakt, köer, tjänster och lagrade procedurer. Helst ska de DBA över dessa skript innan du kör dem.
4.Once installationen skript körs, är det en uppgift för DBA att konfigurera nödvändiga säkerheten huvudmän, intyg, Remote Service bindningar, och krävde rutter.
5.Because en Service Broker anläggning kan vara komplicerad, skall det dokumenteras utförligt så att den lätt kan kopieras och installeras vid behov.

Khan sql dba – mcitp

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