Oracle
 sql >> Baza danych >  >> RDS >> Oracle

Wymagania dotyczące odzyskiwania przed tworzeniem kopii zapasowych

Zbyt często widzę ludzi zadających pytania dotyczące strategii tworzenia kopii zapasowych, które powinni zastosować w swoich bazach danych. Wydaje się, że nigdy nie zawodzi, każde pytanie tego rodzaju, z którym natknąłem się na różnych forach, nigdy nie zawierało wymagań dotyczących odzyskiwania. Często zastanawiałem się nad wymaganiami dotyczącymi odzyskiwania przed zaprojektowaniem strategii tworzenia kopii zapasowych. Po naciśnięciu na wymagania, często otrzymuję wymagania dotyczące kopii zapasowej, na przykład:

  • Kopie zapasowe nie mogą powodować przestojów
  • Musisz mieć możliwość tworzenia kopii zapasowych zarchiwizowanych dzienników przeróbek
  • Kopie zapasowe muszą być zapisywane na taśmie

Te wymagania są dobre i dobre, ale moim zdaniem nigdy nie należy projektować strategii tworzenia kopii zapasowych bez uprzedniego udokumentowania wymagań dotyczących odzyskiwania i uzyskania zdarzenia związanego z zarządzaniem.

Oto kilka pytań, które zadaję sobie podczas projektowania strategii tworzenia kopii zapasowych. Zauważ, że wszystkie te pytania koncentrują się na stronie odzyskiwania.

  1. Na jaką utratę danych mogę sobie pozwolić podczas przywracania bazy danych? Zero utraty danych? Czy jedna godzina utraty danych jest akceptowalna po odzyskaniu bazy danych?
  2. Czy muszę przewijać jakiekolwiek transakcje, tj. wykonywać przywracanie do określonego momentu?
  3. Czy będę musiał przywrócić zawartość jednego schematu, pozostawiając inne nienaruszone?
  4. Ile czasu mam na uruchomienie bazy danych po awarii?
  5. Jakiego rodzaju awarie muszę naprawić? Oczywiście muszę być w stanie przywrócić po całkowitej awarii serwera lub utracie dysku. Ale czy muszę być w stanie odzyskać siły po ludzkich niepowodzeniach, jak ktoś, kto przypadkowo usunął tabelę?
  6. Czy będę musiał przywrócić kopię zapasową na inne serwery w ramach odświeżania programistycznych lub testowych baz danych z kopii produkcyjnej?

Jeśli poprosisz większość osób w społeczności Oracle w dzisiejszych czasach, powiedzą ci, aby użyć RMAN do tworzenia kopii zapasowych bazy danych. RMAN to świetny produkt i pod wieloma względami jest lepszy niż stare lub zimne kopie zapasowe zarządzane przez użytkownika. Niektóre administratorzy baz danych Oracle poinstruują Cię, aby używać RMAN do wykonywania kopii zapasowych na gorąco i uruchamiania produkcyjnej bazy danych w trybie dziennika archiwalnego. W ten sposób pokryjesz wiele scenariuszy powrotu do zdrowia, z którymi możesz się zmierzyć. Ale co, jeśli Twoja odpowiedź na pytanie 4 brzmi, że masz godzinę na przywrócenie i uruchomienie kopii zapasowej, a Twoja baza danych ma rozmiar 10 TB. Powodzenia w próbie całkowitego przywrócenia 10 TB bazy danych w ciągu 1 godziny za pomocą RMAN. A RMAN nie będzie w stanie pomóc w pytaniu 3, ponieważ RMAN nie tworzy kopii zapasowej na poziomie schematu.

DBA ma do dyspozycji wiele narzędzi do tworzenia kopii zapasowych i odzyskiwania danych w bazie danych. Narzędzia te obejmują między innymi:

  • Oracle Recovery Manager (RMAN)
  • Kopie zapasowe zarządzane przez użytkowników Oracle
  • Eksport/import Oracle lub Data Pump
  • Migawki oparte na dyskach
  • Replikacja na dysku
  • Ochrona danych Oracle

Więc którego używasz? Cóż, każdy ma swoje plusy i minusy. Gdy poznasz swoje wymagania dotyczące odzyskiwania, narzędzia do tworzenia kopii zapasowych bazy danych staną się bardziej przejrzyste. Może być konieczne użycie więcej niż jednego narzędzia do tworzenia kopii zapasowych, aby spełnić wszystkie wymagania dotyczące odzyskiwania. Jeśli używasz, zgodnie z sugestią, RMANa z trybem Archive Log i niczym więcej, a twój menedżer przychodzi do ciebie i mówi „musisz mieć kopię zapasową tej bazy danych o pojemności 10 TB w ciągu 1 godziny!” Twoja praca może być na linii.

Co prowadzi do następnego punktu, udokumentuj swoje wymagania dotyczące odzyskiwania i umieść je w umowie dotyczącej poziomu usług (SLA). Pisząc i sprawdzając umowę SLA, kierownictwo może powiedzieć, że chce zerowej utraty danych. Właśnie w tym momencie możesz wspomnieć o zaletach i wadach wdrożenia rozwiązania o zerowej utracie danych… a także wspomnieć o kosztach! Wiele firm wzdryga się przed wysokimi kosztami rozwiązania z zerową utratą danych, ale w przypadku innych firm koszt jest niewielki w porównaniu z obciążeniem finansowym związanym z utratą jakiejkolwiek transakcji. W tym momencie do gry wchodzą targi i handel wymienny. Jeśli kierownictwo nalega na rozwiązanie z zerową utratą danych, musi wymyślić fundusze na jego wsparcie, ponieważ RMAN (bezpłatny) nie zapewni tego. Po udokumentowaniu wymagań dotyczących odzyskiwania w umowie SLA kierownictwo może mieć trudności z poproszeniem Cię o odzyskanie czegoś, do obsługi czego nie została zaprojektowana strategia tworzenia kopii zapasowych. Jeśli umowa SLA jest wdrożona i proszą o odzyskanie każdej pojedynczej transakcji, a strategia tworzenia kopii zapasowych na to nie pozwala, masz dokument, który mówi, że zero utraty danych nigdy nie było wymagane, a to może pomóc uratować twoją pracę.

Biorąc to pod uwagę, po udokumentowaniu wymagań dotyczących odzyskiwania w umowie SLA należy upewnić się, że strategia tworzenia kopii zapasowych umożliwi wykonanie każdego scenariusza odzyskiwania udokumentowanego w umowie SLA. Twoja praca może od tego zależeć. Jeśli umowa SLA mówi o zerowej utracie danych, a Ty nie wdrażasz funkcji Data Guard, mimo że kierownictwo chciało to sfinansować, mogą Cię wypowiedzieć, ponieważ nie wykonywałeś swojej pracy.

Wreszcie, żadna strategia tworzenia kopii zapasowych/odzyskiwania nie jest kompletna, dopóki nie zostanie dokładnie przetestowana. Należy przetestować każdą wymaganą strategię odzyskiwania, aby upewnić się, że można spełnić wszystkie wymagania określone w umowie SLA. Testy należy przeprowadzać nie rzadziej niż raz w roku z dwóch powodów… po pierwsze, zapewnia, że ​​zmiany w systemie nie wpływają negatywnie na zdolność do wykonania wymaganego odzyskiwania, a po drugie, na bieżąco informujemy, jak przeprowadzać odzyskiwanie jeśli musisz to zrobić naprawdę, nie grzebiesz w procedurze. Podczas testów może się okazać, że Twoja metodologia tworzenia kopii zapasowych będzie obsługiwać scenariusze odzyskiwania, które są wymagane, ale warto je mieć, jeśli ich potrzebujesz.

I nie mogę tego wystarczająco powiedzieć… Testuj, testuj i testuj!


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Polityka poprawek

  2. DBCA Utwórz złą bazę danych REMOTE_LISTENER

  3. Zamówienie niestandardowe w Oracle SQL

  4. Uzyskaj dostęp do usługi sieciowej z procedury składowanej Oracle

  5. Funkcja ATAN2() w Oracle