Oracle Multitenant: Architektura, którą musisz zrozumieć, zanim zaczniesz konsolidować bazy

Geneza architektury Multitenant i dlaczego Oracle poszedł w tym kierunku

Przez lata pracowałem z setkami instancji Oracle w różnych organizacjach. Schemat był zawsze podobny: dziesiątki serwerów, każdy z własną instancją bazy, każdy z własnym zestawem procesów tła, własnym SGA, własnym maintenance window. Marnotrawstwo zasobów było kolosalne.

Oracle wprowadził architekturę Multitenant w wersji 12c, odpowiadając na realne problemy administratorów. Zamiast utrzymywać osobną instancję dla każdej bazy danych, możemy teraz hostować wiele izolowanych baz (Pluggable Databases) w ramach jednego kontenera (Container Database). To nie jest wirtualizacja w tradycyjnym sensie; to natywna cecha silnika bazodanowego.

W wersji 19c, która jest obecnie najpopularniejszą wersją Long Term Support, architektura Multitenant osiągnęła pełną dojrzałość. Mechanizmy klonowania, relokacji i zarządzania zasobami działają stabilnie w środowiskach produkcyjnych na całym świecie.

Po migracji 47 osobnych instancji do jednego CDB z 47 PDB, nasz zespół zredukował czas poświęcany na rutynowe zadania administracyjne o 60%. To nie teoria; to twarde dane z projektu konsolidacyjnego w sektorze finansowym.

Anatomia Container Database: Root, Seed i System Container

Zrozumienie struktury CDB jest fundamentalne dla każdego DBA pracującego z Multitenant. Container Database składa się z kilku kluczowych komponentów, które współpracują ze sobą w ściśle określony sposób.

CDB Root (CDB$ROOT)

CDB Root to serce całego kontenera. Zawiera metadane Oracle, słownik danych wspólny dla wszystkich PDB oraz użytkowników typu common (widocznych we wszystkich kontenerach). Gdy łączysz się z CDB jako SYSDBA bez wskazania konkretnego PDB, trafiasz właśnie tutaj.

Root przechowuje również informacje o wszystkich pluggable databases zarejestrowanych w kontenerze. To tutaj znajdują się widoki typu CDB_* pozwalające na agregację danych ze wszystkich PDB jednym zapytaniem.

PDB$SEED

Seed to szablon służący do tworzenia nowych pluggable databases. Jest to PDB w trybie tylko do odczytu, którego nie należy modyfikować. Każda operacja CREATE PLUGGABLE DATABASE bez wskazania źródła kopiuje strukturę właśnie z seeda.

W praktyce warto zadbać o to, żeby seed zawierał aktualne patche i podstawową konfigurację zgodną ze standardami organizacji. Oszczędza to czas przy tworzeniu kolejnych PDB.

System Container

System Container to logiczny konstrukt obejmujący CDB Root oraz wszystkie PDB. Gdy mówimy o operacjach na poziomie systemu; takich jak backup całego CDB czy zarządzanie pamięcią; operujemy właśnie w kontekście System Container.

Pluggable Databases: izolacja bez kompromisów

PDB to właściwa jednostka pracy w architekturze Multitenant. Z perspektywy aplikacji PDB wygląda i zachowuje się jak tradycyjna baza danych Oracle. Ma własny zestaw schematów, własnych użytkowników lokalnych, własne tablespace'y i własną konfigurację.

Typy PDB i ich zastosowania

Dokumentacja Oracle wyróżnia kilka typów pluggable databases, z których każdy służy innemu celowi:

• Standardowy PDB: podstawowy typ używany w większości scenariuszy produkcyjnych
• Application Container: kontener dla aplikacji wielodostępnych (multi-tenant SaaS)
• Proxy PDB: specjalny typ referencyjny wskazujący na PDB w innym CDB
• Refreshable Clone PDB: klon z możliwością okresowej synchronizacji ze źródłem

W codziennej pracy najczęściej spotykam standardowe PDB oraz klony odświeżalne. Te drugie są nieocenione przy utrzymywaniu środowisk testowych zsynchronizowanych z produkcją.

Nazewnictwo i identyfikacja PDB

Każdy PDB ma unikalną nazwę w ramach CDB oraz globalnie unikalny identyfikator GUID. Nazwa PDB musi być unikalna, ale tylko w obrębie jednego kontenera. To oznacza, że możesz mieć PDB o nazwie HRDB w CDB1 i drugi PDB o tej samej nazwie w CDB2.

Ważna uwaga praktyczna: przy planowaniu nazewnictwa warto uwzględnić przyszłe migracje między kontenerami. Kolizje nazw podczas operacji plug/unplug potrafią skutecznie skomplikować życie.

Słownik danych w architekturze Multitenant: separacja i współdzielenie

Jednym z najbardziej eleganckich rozwiązań w architekturze Multitenant jest sposób organizacji słownika danych. Oracle zastosował tutaj mechanizmy metadata links i data links, które pozwalają na współdzielenie definicji obiektów bez duplikowania danych.

Metadata Links

Większość obiektów słownika danych w PDB to tak naprawdę wskaźniki (metadata links) do definicji przechowywanych w CDB Root. Dotyczy to przede wszystkim obiektów dostarczanych przez Oracle, takich jak pakiety PL/SQL (DBMS_*), widoki słownika czy typy systemowe.

Dzięki temu mechanizmowi upgrade pojedynczego CDB automatycznie aktualizuje definicje we wszystkich PDB. Nie trzeba patchować każdej bazy osobno; wystarczy zaktualizować root.

Data Links

Data links idą o krok dalej: pozwalają na współdzielenie nie tylko metadanych, ale również rzeczywistych danych między kontenerami. Typowy przykład to informacje o strefach czasowych przechowywane centralnie w root i dostępne dla wszystkich PDB.

Konsekwencje dla widoków słownika

W praktyce DBA musi rozróżniać trzy rodziny widoków słownika:

• DBA_*: dane tylko z bieżącego kontenera (PDB lub root)
• CDB_*: agregacja danych ze wszystkich kontenerów (dostępne tylko z poziomu root)
• V$* i GV$*: widoki dynamiczne z kolumną CON_ID identyfikującą kontener

Kolumna CON_ID to klucz do pracy z widokami w środowisku Multitenant. Wartość 0 oznacza cały CDB, 1 to root, 2 to seed, a wartości od 3 wzwyż to kolejne PDB.

Najczęstszy błąd początkujących administratorów Multitenant: uruchamianie skryptów diagnostycznych bez sprawdzenia bieżącego kontenera. Polecenie SHOW CON_NAME powinno stać się nawykiem przed każdą operacją.

Tworzenie PDB: cztery ścieżki do celu

Oracle oferuje kilka metod tworzenia nowych pluggable databases. Wybór właściwej metody zależy od scenariusza i wymagań dotyczących czasu oraz przestrzeni dyskowej.

Tworzenie z seeda

Najprostsza metoda, idealna dla nowych środowisk. Polecenie CREATE PLUGGABLE DATABASE bez klauzuli FROM kopiuje strukturę z PDB$SEED. Proces jest szybki, ale otrzymujesz pustą bazę wymagającą dalszej konfiguracji.

Składnia podstawowa wygląda następująco:

CREATE PLUGGABLE DATABASE nowy_pdb ADMIN USER pdb_admin IDENTIFIED BY haslo FILE_NAME_CONVERT = ('/seed/', '/nowy_pdb/');

Klonowanie istniejącego PDB

Klonowanie to najpopularniejsza metoda w środowiskach deweloperskich i testowych. Możemy sklonować PDB lokalnie (w ramach tego samego CDB) lub zdalnie (z innego CDB przez database link).

Kluczowe opcje klonowania:

• Hot clone: klonowanie bez zamykania źródłowego PDB (wymaga trybu ARCHIVELOG)
• Snapshot clone: wykorzystanie technologii copy-on-write storage (bardzo szybkie)
• Refreshable clone: klon z możliwością okresowej synchronizacji

W Oracle 19c klonowanie hot clone działa naprawdę dobrze. Wielokrotnie klonowałem produkcyjne PDB o rozmiarze kilkuset gigabajtów bez zauważalnego wpływu na wydajność źródła.

Plugging: przenoszenie PDB między kontenerami

Operacja unplug/plug pozwala na przeniesienie PDB między różnymi CDB. Proces składa się z dwóch kroków: najpierw odpinamy PDB ze źródłowego kontenera (generując plik XML z metadanymi), następnie podpinamy go do docelowego CDB.

Ta metoda jest szczególnie przydatna przy migracjach między serwerami, upgrade'ach czy reorganizacji środowisk. Plik XML zawiera wszystkie informacje potrzebne do odtworzenia PDB w nowym kontenerze.

Relokacja PDB

Wprowadzona w Oracle 12.2 relokacja to najbardziej zaawansowana metoda przenoszenia PDB. W przeciwieństwie do klasycznego unplug/plug, relokacja minimalizuje przestój: PDB pozostaje dostępny podczas większości procesu kopiowania.

Relokacja wykorzystuje mechanizm podobny do Data Guard: zmiany są na bieżąco replikowane do docelowego kontenera. Przełączenie następuje dopiero po zsynchronizowaniu obu kopii, co redukuje przestój do sekund.

Proxy PDB: federacja bez komplikacji

Proxy PDB to fascynująca funkcjonalność pozwalająca na tworzenie lokalnych referencji do PDB znajdujących się w innych kontenerach. Z perspektywy aplikacji proxy wygląda jak zwykły PDB, ale wszystkie operacje są transparentnie przekierowywane do rzeczywistego PDB przez database link.

Scenariusze użycia

Proxy PDB sprawdza się w architekturach rozproszonych, gdzie aplikacja musi mieć dostęp do danych z wielu źródeł bez konieczności zarządzania wieloma connection stringami. Typowe zastosowania to:

• Centralizacja dostępu do rozproszonych danych
• Implementacja wzorców hub-and-spoke
• Uproszczenie konfiguracji aplikacji wieloregionalnych

Należy pamiętać, że proxy wprowadza dodatkową warstwę komunikacji. W scenariuszach wymagających niskich latencji może to być problematyczne.

Database Links w środowisku Multitenant

Tradycyjne database linki działają w architekturze Multitenant, ale wymagają przemyślanej konfiguracji. Link utworzony w jednym PDB nie jest widoczny w innych; izolacja działa również na tym poziomie.

Warto rozważyć utworzenie common database links na poziomie CDB Root, jeśli wiele PDB potrzebuje dostępu do tego samego zewnętrznego źródła. Upraszcza to zarządzanie i redukuje duplikację konfiguracji.

Linki między PDB w tym samym CDB

Ciekawostka: PDB w ramach jednego CDB mogą komunikować się przez database linki bez konieczności konfiguracji sieciowej. Wystarczy utworzyć link wskazujący na service name docelowego PDB. Komunikacja odbywa się przez shared memory, co zapewnia doskonałą wydajność.

Praktyczne aspekty konsolidacji: co musisz wiedzieć przed startem

Decyzja o konsolidacji baz w architekturę Multitenant wymaga starannego planowania. Na podstawie wielu przeprowadzonych migracji mogę wskazać kluczowe czynniki sukcesu.

Planowanie zasobów

Resource Manager w środowisku Multitenant pozwala na precyzyjne przydzielanie zasobów CPU i I/O poszczególnym PDB. Bez właściwej konfiguracji jeden agresywny PDB może zdegradować wydajność pozostałych.

Zalecam rozpoczęcie od konserwatywnych limitów i stopniowe ich dostosowywanie na podstawie rzeczywistych wzorców obciążenia. Widoki V$RSRCPDBMETRIC dostarczają cennych danych o wykorzystaniu zasobów przez poszczególne kontenery.

Strategia backupu

RMAN w pełni wspiera architekturę Multitenant. Możemy wykonywać backup całego CDB, pojedynczych PDB lub nawet poszczególnych tablespace'ów. Kluczowa decyzja dotyczy granularności: czy chcemy odtwarzać całe środowisko, czy poszczególne bazy niezależnie?

W większości przypadków rekomenduję backup na poziomie CDB z możliwością granularnego odtwarzania PDB. RMAN obsługuje scenariusz point-in-time recovery dla pojedynczego PDB bez wpływu na pozostałe kontenery.

Bezpieczeństwo i izolacja

Izolacja między PDB jest solidna, ale wymaga świadomego podejścia do konfiguracji. Common users (utworzeni w root) widzą wszystkie PDB, co może być zagrożeniem w środowiskach wielodostępnych. Dla maksymalnej izolacji warto ograniczyć common users do minimum i korzystać z local users w poszczególnych PDB.

Mechanizm lockdown profiles pozwala na dodatkowe ograniczenie funkcjonalności dostępnych w poszczególnych PDB. Możemy zablokować dostęp do sieci, operacje na plikach czy określone pakiety PL/SQL.

Konsolidacja to nie tylko technologia. To zmiana procesów, odpowiedzialności i sposobu myślenia o zarządzaniu bazami danych. Techniczne aspekty Multitenant opanujesz w tygodnie; zmiana kultury organizacyjnej może zająć miesiące.