W jakie obszary wiedzy DBA powinien się zgłębić programista? [Zamknięte]

Muszę przyznać, że pytanie jest dość szerokie, więc spróbuję go nieco zawęzić. W naszej firmie jesteśmy 3-4 programistami i posiadamy instalacje oparte na SQL Server w witrynach naszych klientów (rozmiary baz danych do 100 GB, do 100 jednoczesnych użytkowników, aplikacje intranetowe). Nikt z nas nie ma naprawdę dobrego doświadczenia w prowadzeniu / utrzymywaniu / administrowaniu bazami danych. Klienci nawet nie tak bardzo. Do tej pory działa dobrze, ale nie jestem pewien, czy to dlatego, że robimy wszystko dobrze, czy po prostu nie trafiliśmy w obszary / sytuacje, w których nie jesteśmy biegli.

Tak więc szukam podstawowych rzeczy, które powinieneś wiedzieć, prowadząc bazę danych z punktu widzenia DBA . Znasz twarde fakty i wiesz, co najważniejsze w twoim codziennym życiu zawodowym.

Na których tematach powinienem gromadzić głębszą wiedzę, o czym powinienem słyszeć i na czym mogę się przejmować dopiero po raz pierwszy?

Zdaję sobie sprawę z pytania Inżynierów oprogramowania i DBA , ale nie do końca tego szukałem. Wokół jest też wiele książek, ale chciałbym usłyszeć je od osób z praktycznym doświadczeniem.

Jestem skłonny zgodzić się z @Catcall, odzyskiwanie bazy danych powinno znajdować się na szczycie listy. Implikacje zarówno opcji tworzenia kopii zapasowych, jak i odzyskiwania są zwykle najsłabiej zrozumiane poza zespołem DBA i najprawdopodobniej doprowadzą do katastrofy.

• Upewnij się, że zdefiniowałeś i uzgodniono (przez zarządzanie techniczne i nietechniczne) RPO (Recovery Point Objective) i RTO (Recovery Time Objective) dla wszystkich baz danych i systemów.
• Dokumentuj procedury tworzenia kopii zapasowych i odzyskiwania danych w zakresie, w jakim mogą być przestrzegane przez personel nietechniczny.
• Upewnij się, że cała dokumentacja jest przechowywana zarówno w formie drukowanej, jak i elektronicznej, zarówno na miejscu, jak i poza nim. Runbook odzyskiwania po awarii przechowywany w sieci lokalnej nie będzie miał większego zastosowania, jeśli budynki się podpalą.
• Często testuj każdy aspekt procedur odzyskiwania. Kopie zapasowe są nieistotne, przywracają znaczenie.

Następnie, z perspektywy agnostycznej bazy danych, rozumiemy, do czego służy serwer bazy danych; zapewniają atomowość, spójność, izolację i trwałość transakcji i danych. Często źle rozumiane, często przyczyną problemów z wydajnością i głównym źródłem niespójności danych.

W przypadku wybranej platformy zapoznaj się z wewnętrznymi zasadami implementacji zgodności z ACID. Spójrz na taką tematyką jak co dziennika transakcji robi, co do zapisu z wyprzedzeniem-rejestrowanie jest poziomów izolacji i wewnętrznych magazynowych . Zrozumienie kluczowych aspektów wewnętrznych elementów bazy danych znacznie ułatwia zrozumienie innych aspektów pracy DBA, dostrajania wydajności i zarządzania zasobami.

Dwie rzeczy, z którymi mam do czynienia na co dzień.

1. Odzyskiwanie po awarii.

2. Podnoszenie wydajności. (Zarówno dla pojedynczych zapytań, jak i dla samych dbms.)

Twój plan odzyskiwania po awarii musi być

• skrypty
• przetestowane i
• doświadczony.

Używam skryptów w znaczeniu czegoś, co podążałby aktor, a nie czegoś napisanego w Pythonie. Powinien powiedzieć wszystkim, którzy muszą być zaangażowani dokładnie, co robić. (I często dokładnie to, co powiedzieć.)

Strojenie wydajności dla zapytań obejmuje zrozumienie kluczy, indeksów i normalizacji. (Często problemy z dostrajaniem są w rzeczywistości problemami strukturalnymi.)