1 / 11

Hva gjør en database administrator? -Hvilke arbeidsoppgaver og utfordringer har vi?

Hva gjør en database administrator? -Hvilke arbeidsoppgaver og utfordringer har vi?. Rune Log Senior Konsulent, Ergogroup. Agenda. Arbeidsoppgaver til en DBA Performance Disk/system planlegging Nye applikasjoner Konsolidering Installasjon/patching/oppgradering Disaster recovery

sancha
Download Presentation

Hva gjør en database administrator? -Hvilke arbeidsoppgaver og utfordringer har vi?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hva gjør en database administrator?-Hvilke arbeidsoppgaver og utfordringer har vi? Rune Log Senior Konsulent, Ergogroup

  2. Agenda • Arbeidsoppgaver til en DBA • Performance • Disk/system planlegging • Nye applikasjoner • Konsolidering • Installasjon/patching/oppgradering • Disaster recovery • Backup/restore • Connectivity • Utfordringer i alle miljø • Trenger SA passordet • Skal bare installere noe på SQL Serveren • Doh, der kom det 200 nye brukere

  3. Performance Monitoring/Tuning • Bruk Microsoft SQL Server 2000 Performance Tuning – Technical reference som veiledning • Kapittel 6 Monitoring Performance with System Monitor (Performance Monitor) er basis for all perfmon jeg gjør • Hva kan jeg gjøre? • Kunne basis perfmon (oppdager ca 95% av feil) • Kontakt MS Support for de siste 5% (utrolig billig!!!) det er utrolig tidkrevende å analysere logger

  4. Capasity planning • Hvilke krav setter vi til ledig diskplass? • Lokal backup av alle databaser som er på instans/server • 50% vekst • Krav til ytelse på disk • Vi klassifiserer i: • Ingen • Høy • Minne • Minne er ”billig” • Memory Grants Pending,Target Server Memory og Total Server Memory countere i Perfmon for å finne ut hvor mye instans faktisk benytter

  5. Nye applikasjoner • Krever som regel SA rettigheter under installasjon • Installer separat og flytt databasen med de sikkerhetsinstillinger som kreves. Nyttig hvis konsolidering kommer senere – en har da dokumentasjon for hvordan dette skal gjøres. • Lag eller hent ut jobber som går mot database(r) på instans/server hvis flytting. • Planlegg restore og disaster recovery – test hvis tid. Noen (server)applikasjoner er skikkelig trøblete å få opp hvis de plutselig mister db.

  6. Konsolidering • Nye SQL Servere dukker opp hele tiden når en går fra ”unmanaged” til ”managed” miljø • Vi klassifiserer i 3 kategorier • Konsoliderbar database/server • Ikke konsoliderbar • Redusert SLA – f.eks når noen krever tilgang til master/system databaser (ikke aktuelt i SQL 2005) • Driftsmessig klassifiserer vi databaser som • Overvåkes (til ldf fil er riktig størrelse og innvirkning på tempdb) • Sjekkes (sjekker at forrige fase er ok – mulig vi justerer litt). • Drift (baser vi nesten ikke gjør noe med)

  7. Installasjon/Patching • Installasjon • Alltid dokumenter – ha gjerne en lokal kopi på server i tillegg til et dokument share som ”alle” kjenner til • Hvis mulig – kjør alltid gjennom konfigurasjoner i test/virtuelt miljø og dokumenter. • Finn kjente warnings og errors slik at når du installerer/patcher så er du i ”known state” • Patching • Mange servicepacks og patcher er ”uninstallable”. Test restore av SQL m/databaser og sjekk at backup virker (lokalt og fra tape). • LES hva sp/patch fikser – hvis du kan vente til SP og alt går greit så vent hvis ikke ”highly recommended”.

  8. Backup/Restore • Sjekk recovery mode på databaser i SQL 2005 • Default er Simple (krever lite ifbm log truncs) • Krever du transactional restore – bruk full eller bulklogged. • Best practice: • Test restore av viktigste applikasjoner 2 ganger i året. • Tidkrevende men god eksersis

  9. Disaster Recovery • Forbered alltid på ”bare-metal restore” • Hvordan endre config på applikasjonsservere og klienter (ved 2-lags arkitektur) • Ha alltid en systemdokumentasjon tilgjengelig for hele databasegruppen/driftsorganisasjonen for å vite hvordan ting er satt opp og installert. • DR tar TID!!!! Hvor mye tåler du (eller hvor mye penger har du ;)

  10. Connectivity • En av de største feilkilder i Enterprise miljøer • Default instance har port 1433 • Named instance har random port – må endres i etterkant. • I Cluster 64bit (ia og x64) går dette greit – har opplevd problemer å konfigurere flere cluster instanser på x32 (pre SP2) med • Multi domain miljø -> HOSTS og LMHOSTS filer MÅ være bannlyst. Sjekk DNS settings og FQDN. Kan være problematisk på applikasjonsservere/klienter som må ha host navn og ikke takler fqdn eller ip.

  11. Utfordringer • Installasjon av ”noe” på database servere • Bannlyst, test alltid i test og lag prosedyre for hvordan du vil importere i prod. • Slipp ALDRI inn applikasjonsleverandører inn på database servere i prod. • Test alltid selv ALL software som skal inn på servere • Untatt lagringssoftware, management software osv. • SA passord • Bytt med jevne mellomrom (vær enige med dine kollegaer når dette gjøres) • Applikasjoner bør aldri kjøres under sa konto • Hvis de må – så kjør det på egen instans

More Related