Dlaczego baza sama się nie defragmentuje

Można zadać pytanie, czy baza sama nie powinna wykonać defragmentacji tabel i indeksów po usunięciu danych?

Defragmentacja jest dosyć czasochłonną operacją, generującą duże obciążenie CPU i I/O. Im większa tabela/indeks, tym dłużej trwa defragmentacja i tym więcej zasobów konsumuje. Przy naprawdę dużych tabelach może potrwać naprawdę długo. Ile konkretnie? To zależy od wielkości tabeli/indeksu i wydajności naszego sprzętu. Przy tabelach wielkości 40-50 GB defragmentacja tabeli indeksów trwa zazwyczaj kilkanaście-dwadzieścia kilka minut.

Wyobraźmy sobie, że planujemy usunąć 50% danych z wielkiej tabeli. Aby nie usuwać na raz zbyt dużej ilości danych (możliwe problemy z lock-ami, rollback-iem itp.) podzieliliśmy to 10 paczek po 5% danych.

Gdyby baza samodzielnie zadecydowała o defragmentacji po usunięciu każdej paczki danych, to wykonywałaby defragmentację po każdej paczce, 10 razy zamiast raz. Na dodatek wykonywałaby ją w czasie naszej pracy (i innych użytkowników), co wydłużyłoby czas operacji usuwania danych i mocno utrudniło pracę innych użytkowników.

Dlatego też defragmentacja tabel/indeksów nie jest wykonywana samoczynnie, to administrator decyduje czy i kiedy może zostać wykonana. Oczywiście defragmentacja może być robiona w sposób automatyczny, np. przez mechanizmy typu scheduler, ale to administrator decyduje kiedy / z jaką częstotliwością i ew. w jakim zakresie ma być wykonywana defragmetacja.

Poszczególne silniki bazodanowe różnią się mechanizmami defragmentacji. Jednak prawie zawsze kompleksowa defragmentacja może wiązać się ze znacznym spadkiem wydajności aplikacji, problemami z lock-ami na bazie lub wręcz błędami w działaniu aplikacji (np. indeksy w stanie UNUSABLE). Dlatego też kompleksową defragentację dobrze jest wykonać w czasie kiedy aplikacji nie pracuje.

Kompleksowa defragmentacja bazy rzędu wielkości 1 TB trwa zazwyczaj 6 do 12h. Kiedy znaleźć na to czas dla aplikacji działającej w trybie 24×7? Idealnym momentem jest wymiana nowego sprzętu.

Dlaczego podczas wdrażania nowego sprzętu dostawca/ zespół IT nie wykonał defragmentacji?

Istnieje wiele metod migracji bazy danych na nowy sprzęt. Można skopiować pliki, można utworzyć bazę stand-by na nowej maszynie, a następnie przełączyć ją w tryb produkcyjny. Można wcześniej odtworzyć bazę z backup-u, a następnie zaaplikować jej ostatnie zmiany. Są także metody pozwalające migrować on-line lub z ew. bardzo krótką. Można także wykonać export/import danych.

Nie opisuję tutaj migracji maszyn wirtualnych, to zupełnie inne metody i temat na zupełnie inny artykuł.

Każda metoda ma swoje wady i zalety. W większości wybierana jest metoda najprostsza, która także często jest najszybsza. Do najtrudniejszych i najdłuższych metod należy eksport/import danych. Jednak ta metoda „przy okazji” wykonuje kompletną defragmentację całej bazy.

W przypadku systemów bardzo wysokiej dostępności, gdzie maksymalny czas niedostępności liczony jest w minutach, a nawet w sekundach, stosuje się zazwyczaj rozwiązania wspomagane sprzętowo. W systemach klasy Enterprise lub Midrange stosuje się rozwiązania typu Parallel Sysplex, różnego rodzaju kopie migawkowe itp.

Czasem sama baza danych ma mechanizmy wspomagające migrację on-line. Np. w Oracle RAC możliwe jest dodanie nowych nodów, a następnie usunięcie starych.

Większość dostawców woli wykonać migrację metodą kopiowania plików lub (jeżeli zależy na czasie) różnego rodzaju warianty standby/odtworzenia z backupu. Są to stosunkowo proste metody, z raczej niewielką możliwością pojawienia się poważniejszych problemów. No i co najważniejsze wymaga niewielkich nakładów pracy. W związku z tym można podać niższą cenę za usługą migracji lub też więcej na niej zarobić. Niestety metody te przenoszą całą bazę taką, jaka jest, bez defragmentacji.

Dużo trudniejszą metodą jest metoda eksportu/importu danych. O ile eksport nie powinien przysporzyć problemów, o tyle w trakcie importu pojawiają się różnego rodzaju problemy. W większości wypadków są to błahostki (np. podczas importu widoków, widok A korzysta z widoku B, który nie został jeszcze zaimportowany), wystarczy po migracji wykonać rekompilację błędnych obiektów. Czasem zdarzają się problemy bardziej złożone, na których rozwiązanie  trzeba czasem poświęcić nawet kilka dni. Dlatego też przed migracją produkcyjną należy przeprowadzić migrację testową, aby wcześniej znaleźć rozwiązanie ew. problemów i przetestować działanie bazy po migracji.

Metoda ta ma kilka bardzo ważnych zalet:

– kompleksowo defragmentuje całą bazę, przez co zmniejsza rozmiar bazy i zwiększa jej wydajność

– nadaje się do migracji bazy pomiędzy różnymi wersjami bazy, nawet bardzo odległymi (np. Oracle 10g->19c) lub platformami (Windows, Linux, Unix), gdzie standardowe metody wymagają kilku kroków, instalacji kilku wersji bazy itp.

– porządkuje wewnętrzne struktury bazy, co powoduje szybsze działanie samego silnika bazy danych

Niestety ta metoda wymaga więcej czasu i większego nakładu pracy. Na jej przeprowadzenie należy założyć co najmniej kilka dniówek więcej niż w przypadku tradycyjnych metod. Musi być droższa niż tradycyjne metody, dlatego też, choć jest lepsza dla klienta, dostawcy rzadko ją proponują. Bo ich oferta może przegrać z innymi, tańszymi. A klient, który często nie ma świadomości zalet tej metody, kieruje się ceną.

Na pewno metoda ta nie nadaje się dla wszystkich systemów. Wszędzie tam, gdzie czas niedostępności systemu musi być jak najkrótszy (idealnie, gdyby udało się wykonać migrację w ciągu minut) ta metoda się nie sprawdzi. Jednak, jeżeli uda nam się wygospodarować okienko serwisowe rzędu kilku godzin, możemy zastanowić się nad tą metodą.

Jakie korzyści możemy osiągnąć

Przykład: Branża produkcyjna, baza wielkości 1,2TB.

Projekt dotyczył migracji bazy Oracle w wersji 11.2 Standard Edition do środowiska RAC w wersji 11.2 Standard Edition. Maksymalna niedostępność aplikacji – do 24h.

Oszacowaliśmy, że migracja klasyczną metodą przeniesienie (przeniesienie plików + migracja do AMS) zajmie ok. 4h.

Migracja metodą utworzenia bazy stand-by i przełączenia na produkcję – ok. 3h

Klasyczna metoda eksport/import – ok. 30h (była to baza SE, wszystko wykonywało się jednowątkowo, więc czas klasycznego importu bazy był bardzo długi).

Teoretycznie nie było możliwości wykonania migracji metodą eksport/import, ale przecież specjalizujemy się w wydajności, zaczęliśmy pracować nad przyspieszeniem importu.

Nie chcę wdawać się w szczegóły techniczne, ale dzięki tymczasowej zmianie parametrów bazy danych (SGA, PGA), wielkości redolog-ów, tymczasowemu ustawieniu tablespace-ów w tryb nologging, oraz ręcznym wykonaniu części czynności udało się skrócić łączny czas eksportu/importu do 6h. Możliwe było jeszcze dalsze przyspieszanie procesu migracji, ale 6h było zupełnie wystarczające.

Efekt końcowy – migracja została przeprowadzona w 6h (zaledwie ok. 2 razy wolniej niż najszybsza metoda),  baza po imporcie miała 570GB (ponad 2 razy mniej) i działała o ok. 20% szybciej niż wynikałoby to z prostego przeliczenia różnicy mocy obliczeniowej procesorów.

Tego się nie da zrobić w tak krótkim  czasie

Tak jak wspominałem powyżej, dzięki optymalizacji samego procesu migracji udało się skrócić czas migracji metodą eksport/import z 30h do 6h. Jeżeli ktoś nie specjalizuje się wydajności (czyli większość DBA) wykonałby import standardowo, w 30h. Dlatego też, nawet jeżeli ktoś powie wam, że zastosowanie tej metody jest niemożliwe, że nie da się tego zrobić w tak krótkim czasie, wcale nie musi to być prawdą. Zweryfikujcie tą informację u kogoś innego, najlepiej kogoś, kto dobrze zna się na wydajności.

Nie gwarantuję, że każdy eksport import da się przyspieszyć 5 razy. Zależy od bardzo dużej ilości czynników (np. wielkość tabel, ilość indeksów, ilość pól typu lob/blob/clob, ilość constraint-ów, wersja bazy, ilość core, wielkość RAM, ilość obiektów typu view/procedury/funkcje itd.). Ale na pewno warto to sprawdzić, myślę, że w zdecydowanej większości wypadków możliwe jest przyspieszenie co najmniej 2-3 razy.

Jak widać na poprzednim przykładzie zyskiem z wyboru metody eksport/import może być znaczne „odchudzenie” bazy danych i całkiem spory wzrost wydajności, osiągnięty niejako przy okazji, przy stosunkowo małym nakładzie pracy.

Podsumowanie

Podczas wdrożenia nowego serwera bazodanowego (i migracji bazy) możemy za stosunkowo niewielką kwotę osiągnąć całkiem spory, dodatkowy wzrost wydajności związany z defragmentacją.

Dzięki defragmentacji możemy także zaoszczędzić miejsce – zazwyczaj po operacji eksportu/importu baza jest od kilkunastu do kilkudziesięciu procent mniejsza.

Defragmentację można teoretycznie wykonać w innym czasie, jednak często wymaga to przestoju aplikacji i w praktyce nie jest wykonywane wcale.

Jeżeli kogoś zainteresował ten temat i chciałby się dowiedzieć czegoś więcej, zachęcam do kontaktu: kontakt@commit-it.pl