Kompresja danych

Dane wierszy w tabelach i fragmentach tabel oraz duże obiekty proste w obszarach dbspace można kompresować i dekompresować. Istnieje także możliwość skonsolidowania wolnej pamięci w tabeli lub fragmencie, a także zwrócenia wolnej pamięci do obszaru dbspace. Przed skompresowaniem danych można oszacować ilość miejsca na dysku, jaką uda się odzyskać w wyniku kompresji.

Kompresowanie danych, konsolidowanie danych i zwiększanie ilości wolnej pamięci ma następujące zalety:

• Zwiększenie ilości wolnej pamięci masowej na dysku
• Zmniejszenie wykorzystania dysku dla skompresowanych fragmentów
• Znaczące zmniejszenie wykorzystania dziennika logicznego, co dodatkowo przyczynia się do zaoszczędzenia pamięci i może zapobiegać wąskim gardłom w przypadku transakcji OLTP wymagających wysokiej przepustowości, po zakończeniu kompresji.
• Mniejsza liczba odczytów stron, ponieważ więcej wierszy mieści się na stronie
• Mniejsze pule buforów, ponieważ więcej danych mieści się w puli o tej samej wielkości
• Zmniejszona aktywność we/wy, ponieważ:
  • Na stronie mieści się więcej wierszy skompresowanych niż nieskompresowanych
  • Rekordy dziennika przeznaczone do wykonywania operacji wstawiania, aktualizowania i usuwania skompresowanych wierszy, są mniejsze
• Istnieje możliwość skompresowania starszych fragmentów danych, do których dostęp nie jest często uzyskiwany, oraz możliwość pozostawienia nowszych danych - do których dostęp jest uzyskiwany częściej - w formie nieskompresowanej
• Możliwość zwolnienia miejsca, które nie jest już wymagane przez tabelę.
• Szybsze tworzenie i odtwarzanie kopii zapasowych

Tabele ograniczone do wejścia/wyjścia, dla których istnieją niskie współczynniki trafienia w pamięci podręcznej, są dobrymi kandydatami do kompresji. W środowiskach OLTP kompresja tabel ograniczonych do wejścia/wyjścia może przyczynić się do zwiększenia wydajności.

Jeśli aplikacje działają z wyższymi współczynnikami trafienia w pamięci podręcznej buforu, a wysoka wydajność jest ważniejsza niż ilość wykorzystanej pamięci, wówczas kompresja danych może być niepożądana, ponieważ kompresja może zmniejszać wydajność.

Zapytania mogą uzyskiwać dostęp do danych w skompresowanej tabeli.

Dane skompresowane obejmują mniej stron i zawierają więcej wierszy na stronę niż dane nieskompresowane, dlatego po kompresji optymalizator zapytań może wybrać inne metody postępowania.

W przypadku korzystania z programu Enterprise Replication (ER) kompresja danych na jednym serwerze replikacji nie wpływa na dane na innym serwerze replikacji.

Jeśli stosowana jest metoda HDR (High-Availability Data Replication), to dane skompresowane w tabeli źródłowej są skompresowane w tabeli docelowej. Operacji kompresji nie można wykonywać na serwerze pomocniczym HDR, serwerze pomocniczym RS ani serwerze pomocniczym SD, ponieważ docelowy serwer HDR musi zawierać takie same dane i układ fizyczny, co serwer źródłowy.

Nie można korzystać z programów narzędziowych onload i onunload w celu przenoszenia skompresowanych danych z jednej bazy danych do innej. Przed użyciem programów narzędziowych onload i onunload należy zdekompresować dane w skompresowanych tabelach i fragmentach.

Operacje powiązane z kompresją można wykonywać za pomocą narzędzia IBM® OpenAdmin Tool (OAT) for Informix lub poprzez wykonywanie instrukcji SQL zawierających komendy administracyjnego interfejsu API języka SQL z parametrami kompresji. Uruchomienie komendy create dictionary administracyjnego interfejsu API języka SQL lub wydanie na początku komendy compress dotyczącej tabel lub fragmentów tabel powoduje włączenie od tego momentu automatycznego kompresowania ładowanych obciążeń zawierających 2000 lub więcej wierszy danych.

Główną alternatywą dla kompresji jest kupno większej ilości fizycznej pamięci masowej. Najlepszą alternatywą w ograniczaniu liczby wąskich gardeł w obciążeniach we/wy jest zakup większej pamięci fizycznej, co umożliwi rozbudowę pul buforów.