Oracle AI Database 23.26.2 pozwala na uruchomienie standby pluggable database (PDB) wraz z jej logami redo za pomocą pojedynczej komendy Data Guard Broker, eliminując rutynę ręcznego kopiowania plików, która od dawna spowalniała konfiguracje odzyskiwania po awarii (disaster recovery).

Dlaczego to ma znaczenie

Tworzenie fizycznej standby PDB wymagało serii manualnych działań: kopiowania każdego pliku danych (datafile) do kontenera standby, budowania standby redo logs (SRL) za pomocą jawnych poleceń ALTER oraz podwójnego sprawdzania całej konfiguracji. Każdy krok niesie ze sobą ryzyko literówki, pominięcia pliku lub niedopasowania grupy logów, co może opóźnić testy odzyskiwania lub, w najgorszym przypadku, uniemożliwić przełączenie awaryjne (failover). Automatyzacja tego procesu redukuje te ryzyka i pozwala administratorom baz danych (DBA) skupić się na zadaniach wyższego poziomu.

Jak budowano standby PDB wcześniej

W architekturze multitenant jedna główna baza CDB (container database) hostuje jedną lub więcej baz PDB. Aby zabezpieczyć PDB, administratorzy musieli:

  • Zidentyfikować i skopiować każdy datafile z hosta primary na hosta standby.
  • Ręcznie utworzyć SRL, które odzwierciedlają układ logów redo bazy primary.
  • Uruchomić operacje RMAN restore lub polecenia duplicate, aby zsynchronizować bazę standby.
  • Przeprowadzić serię kroków weryfikacyjnych, aby upewnić się, że baza standby może przyjąć switchover.

Cały proces mógł trwać wiele godzin, szczególnie w przypadku dużych baz PDB, a jakikolwiek błąd mógł sprawić, że baza standby stanie się bezużyteczna.

Co zmienia aktualizacja 23.26.2

Najnowsze wydanie Oracle AI Database osadza wymagane kroki w Data Guard Broker. Wydając pojedyncze polecenie ADD PLUGGABLE DATABASE, broker:

  1. Rejestruje nową standby PDB w bazie primary.
  2. Kopiuje niezbędne pliki danych w tle — nie jest wymagany RMAN restore ani ręczne kopiowanie plików.
  3. Generuje odpowiednie standby redo logs, automatycznie dodając je do standby CDB.
  4. Pozostawia PDB w trybie READ ONLY, gotową do fizycznego switchover na standby.

Komenda użyta w teście:

DGMGRL> ADD PLUGGABLE DATABASE 'amol' AT cdb2
       SOURCE IS 'amol' AT cdb1
       PDBFILENAMECONVERT IS "'/CDB1/','/CDB2/'";

Test w rzeczywistym środowisku

Autor utworzył standby PDB o nazwie AMOL na wtórnej bazie CDB (cdb2), która odzwierciedlała główną PDB na cdb1. Broker zakończył operację natychmiastowo. Nie uruchomiono RMAN restore, w logach systemu operacyjnego nie pojawiły się żadne ręczne kopie plików, a grupy standby redo log pojawiły się w katalogu bez użycia jakichkolwiek poleceń ALTER DATABASE.

Otwarcie PDB przełączyło ją w tryb READ ONLY, co potwierdziło jej status physical-standby. Szybka weryfikacja plików danych wykazała, że zostały one udostępnione po stronie standby. Proces redo apply był już uruchomiony, a broker zgłosił, że konfiguracja jest gotowa do switchover.

Implikacje dla DBA

Automatyzacja zmniejsza ryzyko błędu ludzkiego i drastycznie skraca czas od planowania do uruchomienia produkcyjnej bazy standby. Zespoły mogą teraz udostępniać standby PDB w kilka minut zamiast wielu godzin, co jest szczególnie cenne w środowiskach, w których często uruchamiane są nowe usługi.

Ceną za to jest większa zależność od wewnętrznej logiki Data Guard Broker. Niektórzy administratorzy (DBA) wolą samodzielnie skryptować każdy krok, aby zachować granularną kontrolę lub zintegrować proces z własnymi narzędziami monitorującymi. W złożonych konfiguracjach — wielu sieciach, heterogenicznych pamięciach masowych lub niestandardowych układach redo — administratorzy mogą nadal potrzebować weryfikacji, czy domyślne ustawienia brokera są zgodne z ich politykami.

Na co zwrócić uwagę w przyszłości

Oracle nie ogłosił dalszych rozszerzeń tej automatyzacji, ale ten krok sugeruje, że przyszłe wydania mogą przenieść więcej elementów workflow DR w architekturze multitenant do brokera. Należy wypatrywać:

  • Obsługi dodatkowych typów standby (np. logical standby PDBs).
  • Rozszerzonego logowania, które ujawnia decyzje brokera na potrzeby audytu.
  • Sprawdzania kompatybilności z zewnętrznymi narzędziami do backupu, które wcześniej polegały na manualnych krokach RMAN.

Jeśli Twoja organizacja korzysta z Oracle AI Database w konfiguracji wysokiej dostępności (high-availability), przetestowanie nowej komendy na nieprodukcyjnej bazie CDB jest najszybszym sposobem na ocenę jej wpływu.

Podsumowanie: Oracle AI Database 23.26.2 zmienia wieloetapową i podatną na błędy konfigurację standby PDB w operację jednowierszową, zapewniając szybsze i bardziej niezawodne odzyskiwanie po awarii w środowiskach multitenant.