Reorganizacje bazy danych: Dlaczego mają znaczenie i różnica między trybem on-line a off-line
Reorganizacje bazy danych są wykonywane w celu zaoszczędzenia miejsca na dane oraz poprawy wydajności i wydajności bazy danych. Ten artykuł wyjaśnia, dlaczego. Następny artykuł pokazuje, jak ponownie uporządkować wiele tabel i baz danych w środowisku Eclipse.
Dane w dużych tabelach RDBMS w końcu ulegają fragmentacji. Rozmiar tabel i indeksów zwiększa się w miarę rozmieszczania rekordów na większej liczbie stron danych. Więcej odczytów stron i wierszy w kolejności innej niż łączenie podczas wykonywania zapytania powoduje spowolnienie odpowiedzi na zapytanie. Aby odzyskać zmarnowaną przestrzeń, poprawić czas pracy bazy danych i przyspieszyć dostęp do danych (odpowiedzi na zapytania), rozważ strategię reorganizacji obiektów bazy danych.
Reorganizacje baz danych składają się z dwóch typów dla tych obiektów tabeli, indeksu i przestrzeni tabel:on-line (w miejscu) i off-line (klasyczny).
Baza danych online reorgs działają przyrostowo, przenosząc wiersze w istniejącej tabeli w celu przywrócenia klastrowania, odzyskania wolnego miejsca i wyeliminowania przepełnienia wierszy. Obiekty są niedostępne tylko przez krótki czas pod koniec, a nie podczas faz przeładowania i przebudowy, które mogą się przedłużyć w przypadku dużych obiektów. Pozwalają aplikacjom na łączenie się z bazą danych, ale często spowalniają ich wydajność i mogą w tym czasie tworzyć blokady.
Baza danych offline reorg są szybsze, ale mogą przełączyć bazę danych w tryb off-line (jeśli używane jest narzędzie reorg bazy danych). Dzięki tej metodzie dane są eksportowane z bazy danych do pliku zrzutu (rozładuj). Obiekty bazy danych są tworzone w kopii zapasowej na podstawie ekstraktu, zwykle z inną kolejnością (sortowanie). Są one następnie zwracane do tego samego obszaru tabel (ładowanie), gdzie indeksy są przywracane niejawnie (odbudowywanie).
DBA dbający o wydajność używają IRI FACT (szybkiego wyodrębniania) do rozładowywania, co tworzy przenośny płaski plik, który można sortować (za pomocą IRI CoSort) według podstawowego klucza indeksu zreorganizowanej tabeli. Dzięki takiemu podejściu mogą wystąpić inne operacje przekształcania i raportowania, a baza danych pozostaje w trybie online. Wstępnie posortowane, bezpośrednie ładowanie ścieżek omija także sortowanie (narzuty) programu ładującego bazy danych. Wszystkie te operacje są zautomatyzowane w kreatorze reorganizacji offline IRI Workbench.
Przechowywanie kopii danych w systemie plików dla każdej tabeli nie powinno być nadmiernie uciążliwe, ponieważ po posortowaniu i ponownym załadowaniu zwykłego pliku można go usunąć. Jednocześnie udostępnienie danych reorg na zewnątrz i udostępnienie ich CoSort umożliwia również inne wykorzystanie danych, w tym archiwizację, raportowanie, ochronę i migrację do innej bazy danych, narzędzia BI i celów aplikacji.
Zastrzeżeniem jest oczywiście to, że podczas rozładowywania inni użytkownicy systemu mogą czytać i aktualizować obszar tabel, więc wszelkie aktualizacje w tym czasie mogą pominąć ponowne załadowanie i stworzyć niespójności w celu. Dlatego zaleca się przeprowadzanie reorgów offline, gdy aktualizacje nie są wykonywane.
IRI oferuje rozwiązanie reorg w trybie offline, opisane i pokazane tutaj.
