Som SQL DBA måste följa upp sättning bästa practices för att säkerställa en smidig och mycket optimerad databaser tillgänglighet. Jag har lärt mig från mina misstag eller p.g.a stress eller tidbrist(hitta på orskan) här är några vanliga misstag som jag har identifierat och skulle rekommendera att fixa om du har stött på eller se något liknande. Inte minst jag har sett små och stora företag data och deras SQL Server-säkerhet, det går inte beskriva, data lever mycket farlig nivå. Back to point.
En. Inte förberedelse och godkännande av en pålitlig backup och återställning politik med säkerhetskopior Lagringstiden för databaser enligt överenskomna dataförlust och tillämpning driftstopp det kan orsaka att tillfriskna databaser.
Mycket ofta några DBA: s starkt beroende av att lägga en plan för databasunderhåll bara för regelbunden säkerhetskopiering och med tanke på det gjort. Jag tror det är inte tillräckligt; en DBA ofta måste kontrollera hur lång tid det tar att återställa databaser och bör kontrollera backup filer för tidpunkt återhämtning. Också, beroende på databasens storlek kan det ta längre tid än väntat tid att göra databasen återhämtning. Därför kan ta säkerhetskopior inte lösa dina krav och det är rådet att använda standby-server med log shipping eller databas spegling för snabb databaslösningar DR.
Två. Att inte veta gränser server hårdvara och utnyttjande. Det är måste att se System resursutnyttjandet och identifiera flaskhalsar på regelbundna intervall för DISKIO, minne, CPU, Lås & Blocking etc räknare. Denna information kan ge insikt om hur mycket serverhårdvara resurser utnyttjas / tillgängliga för nuvarande och kommande arbetsbörda som genereras av applikation (er). Denna information kan hjälpa att stabilisera prestanda för en längre period, liksom att veta sina begränsningar.
Tre. Inte verifiera SQL Server-säkerhet, och inte tillämpar senaste Service Pack 1, 2, 3, 4 / version. Det rekommenderas att plåstret och tillämpa buggfixar så snart som möjligt. En föråldrad SQL server build / version rekommenderas inte att hålla igång för produktion servrar. Har kontrollera att du noga har valt rollen sysadmin medlemmar och tas bort alltför tillstånd från normala användarna av databasen. Det är en allmän praxis att endast SQL alternativ / inställningar som krävs liknande – xp_cmdshell, CLR etc och använda sig av kryptering & revision för att skydda kritiska data.
Fyra. Inte defragging index eller springer Databas konsistenskontrollerna. Också inte kör regelbundet underhåll aktiviteter såsom uppdatera statistik om produktion databaser. Eller i vissa fall verkställande underhåll och andra höga resurskrävande verksamhet under produktion arbetstid.
Fem. Inte kontrollera hur mycket ledigt utrymme finns på data eller loggfiler och krympande databaser och om igen. Eller inställning “Auto Shrink” databas alternativet till sant är likvärdigt skadligt.
Sex. Skapa databaser för Dev, Staging, UAT, Test, QA etc på produktion SQL Server eller instans. Detta majorly orsakar manuell / mänskliga misstag genom att radera / ändra objekt eller felaktigt tilldela behörigheter.
Sju. Proaktiv övervakning: Ställer inte in SQL-varningar med e-post för allvarlighetsgrad fel från 17 till 25, ledigt utrymme check, CPU-användning, SQL / Agent / SSRS / SSAS tjänster omstart osv. Det är mycket lämpligt att inrätta automatiska registreringar om SQL Server för kritiska händelser. Så att du är fullt medveten och känner sig trygga att alla händelser når till dig / lag även om de inte sitter framför datorskärmen. Framöver kan du använda Policy förvaltning för att fånga händelser och effektivisera olika SQL instanser i din miljö.
Åtta. Inte använder / tillämpar Hög tillgänglighet tekniker (kluster, spegling, log shipping) för kritiska databaser. En DBA måste identifiera verksamhetens krav och tillämpa hög tillgänglighet tekniker enligt redan fastställda SLA mål. Det garanterar snabb tillgång till databaser för tillämpningar i händelse av fel.
Nio. Kör SQL profiler på produktionen utan filter och sluttid. Detta är bland de vanligaste som händer misstag. En DBA måste förstå att köra Profiler utan filter kommer att fånga alla händelser och T-SQL-frågor vilket genererar extra arbetsbelastning en på produktionen. Dess mycket rekommenderas att använda Profiler med försiktighet.
En Tia. Inställnings alternativ databas återvinning till “full” och aldrig tar transaktionsloggbackups. Jag har sett fall där transaktionsförteckning filstorlek har ökat 100 gånger till faktiska data på grund av säkerhetskopiering oaktsamhet. Kontrollera att du väljer modell databas återvinning efter behov och använda backup politik därefter. Dessutom noga titta på dina transaktionsförteckning säkerhetskopieringar av med mera. Om du har några frågor eller förslag, skriv mig.
Khan – SQL DBA, MCTS.
