Problemy z przestrzenią w Oracle rzadko wynikają z braku miejsca na dysku. Znacznie częściej ich źródłem jest nieefektywne wykorzystanie już przydzielonej przestrzeni, wysokie HWM i fragmentacja, której większość administratorów nie rozumie prawidłowo.
- High Water Mark to główny winowajca wolnych Full Table Scanów po masowym usuwaniu danych
- Segment Advisor generuje rekomendacje automatycznie, ale wymaga krytycznej oceny przed wdrożeniem
- Shrink Space działa online, ale tylko na segmentach z włączonym row movement
- Większość reorganizacji indeksów w środowiskach produkcyjnych jest zbędna i nie przynosi korzyści wydajnościowych
Jak Oracle zarządza przestrzenią
Zanim przejdziemy do narzędzi analitycznych, musimy zrozumieć fundamenty organizacji danych w Oracle. Hierarchia jest prosta: tablespace zawiera segmenty, segmenty składają się z extentów, a extenty z bloków. Każdy poziom ma swoje znaczenie dla wydajności i zarządzania przestrzenią.
Tablespace to logiczny kontener grupujący powiązane obiekty. Segment odpowiada jednemu obiektowi bazodanowemu: tabeli, indeksowi, partycji lub segmentowi LOB. Extent to ciągły obszar bloków przydzielany segmentowi w momencie, gdy potrzebuje więcej miejsca. Blok to najmniejsza jednostka I/O, typowo 8KB.
Oracle przydziela przestrzeń segmentom w miarę potrzeb, alokując kolejne extenty. Problem w tym, że zwalnianie przestrzeni nie działa symetrycznie. Gdy usuwasz dane z tabeli, bloki zostają oznaczone jako wolne wewnątrz segmentu, ale segment nie oddaje ich do tablespace automatycznie. To fundamentalna różnica, którą wielu administratorów ignoruje.
Fragmentacja w Oracle: fakty i mity
Termin fragmentacja jest jednym z najbardziej nadużywanych pojęć w administracji bazami danych. W kontekście Oracle musimy rozróżnić kilka zupełnie różnych zjawisk, które często są mylone.
Fragmentacja tablespace występuje, gdy wolne miejsce jest rozproszone w małych, nieciągłych obszarach. W erze lokalnie zarządzanych tablespace'ów z uniform extent size ten problem praktycznie nie istnieje. Jeśli używasz AUTOALLOCATE, Oracle radzi sobie z tym sprawnie.
Fragmentacja wewnątrz segmentu to sytuacja, w której bloki tabeli zawierają dużo wolnego miejsca po operacjach DELETE lub UPDATE zmniejszających rozmiar wierszy. To realne zjawisko, ale jego wpływ na wydajność zależy od wzorców dostępu.
W mojej wieloletniej praktyce widziałem setki reorganizacji wykonywanych z powodu rzekomej fragmentacji. W może 10% przypadków przyniosły one mierzalną poprawę wydajności. Pozostałe 90% to zmarnowany czas i niepotrzebne ryzyko.
Prawdziwy problem pojawia się, gdy połączymy wewnętrzną fragmentację z wysokim High Water Mark. Wtedy Full Table Scan musi przeczytać wszystkie bloki do HWM, nawet jeśli większość z nich jest pusta.
High Water Mark: cichy zabójca wydajności
High Water Mark to znacznik wskazujący najwyższy blok, który kiedykolwiek zawierał dane w segmencie. Oracle podczas Full Table Scan czyta wszystkie bloki od początku segmentu do HWM, niezależnie od tego, czy zawierają dane.
Wyobraź sobie tabelę, która urosła do 100GB, a następnie usunąłeś 90% danych. Segment nadal zajmuje 100GB, HWM pozostaje na tym samym poziomie, a każdy Full Table Scan czyta 100GB zamiast 10GB rzeczywistych danych. DELETE nie obniża HWM.
Operacje, które obniżają HWM to: TRUNCATE (natychmiastowo), ALTER TABLE SHRINK SPACE, ALTER TABLE MOVE oraz export/import danych. Zwykłe DELETE, nawet z COMMIT, nie ma żadnego wpływu na HWM.
Identyfikacja problemu z HWM wymaga porównania rozmiaru segmentu z rzeczywistą ilością danych. Zapytanie wykorzystujące DBMS_SPACE.SPACE_USAGE pokaże, ile bloków jest faktycznie wykorzystanych, a ile pustych poniżej HWM.
Segment Advisor: automatyczna analiza przestrzeni
Segment Advisor to komponent Automatic Database Diagnostic Monitor (ADDM), który analizuje wykorzystanie przestrzeni przez segmenty i generuje rekomendacje. W wersjach Enterprise Edition z Diagnostic Pack działa automatycznie w ramach okna maintenance.
Advisor analizuje segmenty pod kątem trzech głównych metryk: procent wykorzystania przestrzeni w blokach, ilość miejsca możliwego do odzyskania oraz potencjalne korzyści z reorganizacji. Rekomendacje zapisywane są w słowniku danych i dostępne przez widoki DBA_ADVISOR_*.
Automatyczna analiza obejmuje segmenty przekraczające określone progi wielkości. Domyślnie Segment Advisor ignoruje małe obiekty, koncentrując się na tych, gdzie potencjalne oszczędności są znaczące. Progi można konfigurować.
Uruchamianie i interpretacja Segment Advisor
Ręczne uruchomienie analizy dla konkretnej tabeli wymaga użycia pakietu DBMS_ADVISOR lub interfejsu graficznego w Enterprise Manager. Procedura składa się z utworzenia zadania, dodania obiektu do analizy i wykonania:
DECLARE task_name VARCHAR2(100) := 'SEGMENT_TASK_1'; obj_id NUMBER; BEGIN DBMS_ADVISOR.CREATE_TASK('Segment Advisor', task_name); DBMS_ADVISOR.CREATE_OBJECT(task_name, 'TABLE', 'SCHEMA_NAME', 'TABLE_NAME', NULL, NULL, obj_id); DBMS_ADVISOR.SET_TASK_PARAMETER(task_name, 'RECOMMEND_ALL', 'TRUE'); DBMS_ADVISOR.EXECUTE_TASK(task_name); END;
Wyniki analizy znajdziesz w widokach DBA_ADVISOR_FINDINGS i DBA_ADVISOR_RECOMMENDATIONS. Kluczowe kolumny to BENEFIT (szacowane oszczędności w bajtach) oraz MESSAGE opisujący rekomendację.
Interpretacja wymaga krytycznego podejścia. Advisor może zasugerować shrink dla tabeli z 30% wolnej przestrzeni, ale jeśli tabela rośnie o 5% miesięcznie, reorganizacja jest bezcelowa. Kontekst biznesowy i wzorce wzrostu danych są kluczowe.
Shrink Space: mechanizm i ograniczenia
ALTER TABLE SHRINK SPACE to operacja online wprowadzona w Oracle 10g. Działa poprzez przesuwanie wierszy z końca segmentu w wolne miejsca bliżej początku, a następnie obniżanie HWM. Proces odbywa się w dwóch fazach.
Faza kompaktowania przenosi wiersze, co wymaga włączonego row movement na tabeli: ALTER TABLE tabela ENABLE ROW MOVEMENT. Ta faza może działać długo i generuje logi REDO. Faza obniżania HWM jest szybka, ale wymaga krótkiej blokady exclusive.
Ograniczenia są istotne: shrink nie działa na tabelach z kolumnami LONG, tabelach klastrowych, tabelach z funkcyjnymi indeksami bitmapowymi (w starszych wersjach) oraz na indeksach typu IOT z overflow. Tabele muszą znajdować się w tablespace z automatycznym zarządzaniem segmentami (ASSM).
Opcja SHRINK SPACE COMPACT wykonuje tylko kompaktowanie bez obniżania HWM, co pozwala rozłożyć operację w czasie. Później możesz wykonać SHRINK SPACE, które szybko obniży HWM.
Rebuild czy Shrink: kryteria wyboru
ALTER TABLE MOVE przenosi całą tabelę do nowego segmentu, co automatycznie eliminuje fragmentację i obniża HWM. Wadą jest konieczność przebudowy wszystkich indeksów (stają się UNUSABLE) oraz blokada tabeli podczas operacji. W wersjach 12.2+ dostępna jest opcja MOVE ONLINE.
SHRINK SPACE działa online i nie wymaga przebudowy indeksów, ponieważ Oracle aktualizuje je inkrementalnie podczas przesuwania wierszy. Jest bezpieczniejszy dla środowisk produkcyjnych wymagających ciągłej dostępności.
Dla indeksów sytuacja jest inna. ALTER INDEX REBUILD tworzy nowy segment, co jest szybkie, ale wymaga dodatkowej przestrzeni. ALTER INDEX COALESCE łączy sąsiednie bloki liści bez zmiany struktury, jest wolniejszy, ale nie wymaga dodatkowego miejsca.
- Shrink: preferowany dla tabel produkcyjnych wymagających dostępności 24/7
- Move: lepszy gdy potrzebujesz zmiany tablespace lub kompresji
- Rebuild indeksu: rzadko potrzebny, zazwyczaj tylko przy ekstremalnej fragmentacji
- Coalesce: bezpieczniejsza alternatywa dla rebuild w środowiskach wrażliwych
Analiza wykorzystania przestrzeni w praktyce
Podstawowe widoki do monitorowania to DBA_SEGMENTS (rozmiar segmentów), DBA_FREE_SPACE (wolne miejsce w tablespace), DBA_TABLES (statystyki tabel) oraz DBA_TABLESPACE_USAGE_METRICS (zagregowane metryki).
Pakiet DBMS_SPACE oferuje procedury do szczegółowej analizy. SPACE_USAGE zwraca informacje o wykorzystaniu bloków w segmencie ASSM: pełnych, częściowo wypełnionych i pustych. UNUSED_SPACE pokazuje przestrzeń powyżej HWM.
Do codziennego monitorowania polecam utworzenie widoku łączącego dane z DBA_SEGMENTS z wynikami DBMS_SPACE, filtrując obiekty powyżej określonego rozmiaru i z wykorzystaniem poniżej np. 60%. To daje listę kandydatów do przeglądu.
Praktyczne przypadki ze środowisk produkcyjnych
Przypadek 1: Tabela auditowa rosła przez lata do 500GB. Polityka retencji wymagała przechowywania tylko 90 dni danych. Po wdrożeniu partycjonowania i usunięciu historycznych partycji, segment główny nadal zajmował 450GB. Rozwiązaniem był SHRINK SPACE, który odzyskał 420GB i skrócił raporty agregujące z 40 do 6 minut.
Przypadek 2: Indeks na tabeli transakcyjnej z intensywnym INSERT/DELETE. Segment Advisor sugerował rebuild. Analiza pokazała, że indeks miał stabilny rozmiar przez ostatnie 6 miesięcy, a współczynnik clustering factor był akceptowalny. Rekomendacja została zignorowana, bez negatywnych konsekwencji.
Przypadek 3: Tabela 200GB z 80% pustych bloków po migracji danych. SHRINK SPACE działał 18 godzin i generował ogromne ilości REDO. Lepszym rozwiązaniem okazał się MOVE ONLINE w oknie maintenance, który zakończył się w 3 godziny.
Najczęstsze błędy administratorów
Ślepe wykonywanie rekomendacji Segment Advisor bez analizy kontekstu prowadzi do zbędnych operacji. Advisor nie zna Twoich wzorców dostępu ani planów rozwoju aplikacji.
Regularne przebudowy indeksów według harmonogramu to mit odziedziczony z lat 90. Współczesne indeksy B-tree w Oracle są samobalansujące. Rebuild jest uzasadniony przy współczynniku deleted entries powyżej 20-30%, nie jako rutyna.
Reorganizacja tabel przed analizą wzorców wzrostu to strata czasu. Jeśli tabela rośnie, odzyskana przestrzeń zostanie natychmiast wykorzystana. Shrink ma sens dla tabel statycznych lub kurczących się.
Ignorowanie wpływu na REDO i wydajność I/O podczas operacji shrink może przeciążyć system produkcyjny. Planuj takie operacje na okresy niskiego obciążenia.