brak ograniczenia liczby segmentów

Brak ograniczenia liczby segmentów to usterka architektury dopuszczająca nieograniczone tworzenie podziałów bazy odbiorców.

Na czym polega brak ograniczenia liczby segmentów

Brak ograniczenia liczby segmentów oznacza wadę projektu systemu, w którym można tworzyć kolejne podziały bazy odbiorców bez zdefiniowania maksymalnej liczby, zasad archiwizacji albo mechanizmu kontroli zużycia zasobów. Segment jest logicznym zbiorem rekordów wybranych według określonych kryteriów, na przykład cech konta, historii operacji lub przypisanych atrybutów. Samo tworzenie segmentów nie musi oznaczać fizycznego kopiowania danych, ponieważ segment może być zapisany jako zapytanie, zestaw identyfikatorów albo definicja reguł filtrowania.

Problem pojawia się wtedy, gdy system pozwala dowolnemu użytkownikowi lub procesowi automatycznemu tworzyć następne definicje bez sprawdzania ich liczby, właściciela, daty ostatniego użycia i kosztu obliczeniowego. W efekcie powstają segmenty tymczasowe, duplikaty oraz wzajemnie nakładające się zbiory. Nieograniczona liczba obiektów logicznych może zwiększać rozmiar tabel metadanych, liczbę relacji między tabelami oraz czas wykonywania operacji wyszukujących segmenty spełniające określone warunki.

Skutki niekontrolowanego wzrostu podziałów

Najbardziej widocznym skutkiem jest pogorszenie przewidywalności pracy systemu. Zapytanie dotyczące jednego odbiorcy może wymagać sprawdzenia wielu reguł segmentacji, a operacja aktualizacji danych może uruchamiać przebudowę lub ponowne wyliczanie licznych zbiorów. Jeżeli segmenty są materializowane, czyli przechowywane jako osobne zestawy identyfikatorów, rośnie także zużycie miejsca na dysku i obciążenie operacji zapisu. Jeżeli są obliczane dynamicznie, wzrasta koszt odczytu oraz liczba wykonywanych filtrów.

Nieograniczony model utrudnia również kontrolę spójności. Ten sam rekord może zostać przypisany do wielu segmentów, a zmiana reguły może nie objąć wcześniej zapisanych wyników. W systemach wykorzystujących kolejki zadań może dojść do nagromadzenia prac przeliczających segmenty. Objawami są wydłużone czasy odpowiedzi, blokady transakcji, rosnące użycie procesora, większa liczba operacji wejścia-wyjścia oraz błędy wynikające z przekroczenia limitów pamięci lub miejsca na dane. Zależności te trzeba potwierdzić pomiarami, ponieważ podobne symptomy mogą powodować także brak indeksu, nieoptymalne zapytanie albo niewłaściwa konfiguracja puli połączeń.

Rozróżnienie limitu logicznego i fizycznego

Ograniczenie liczby segmentów powinno być rozpatrywane na kilku poziomach. Limit globalny określa maksymalną liczbę segmentów w całej instalacji, natomiast limit właściciela, zespołu lub projektu zapobiega temu, aby jeden zakres działania zużył wszystkie dostępne zasoby. Osobne ograniczenia mogą dotyczyć liczby warunków w definicji segmentu, liczby rekordów w segmencie, częstotliwości przeliczania oraz liczby równoległych zadań. Warto także przechowywać stan segmentu, jego wersję reguł, czas utworzenia i ostatniego użycia.

Limit logiczny nie zastępuje kontroli zasobów fizycznych. Nawet niewielka liczba segmentów może generować duży koszt, jeżeli reguły zawierają złożone połączenia tabel, podzapytania lub operacje na dużych zakresach danych. Z kolei duża liczba prostych definicji może być względnie tania, jeśli system korzysta z właściwych indeksów i nie kopiuje wyników. Projekt powinien więc rozdzielać metadane segmentu od jego wyniku, definiować politykę wygaszania nieużywanych obiektów oraz odrzucać żądania po przekroczeniu ustalonego limitu zamiast dopuszczać do niekontrolowanego wzrostu.

Diagnostyka i przywrócenie kontroli nad segmentacją

Diagnostykę rozpoczyna się od ustalenia, gdzie segmenty są przechowywane i jak są obliczane. Należy sprawdzić schemat bazy, klucze obce, indeksy, rejestr zadań oraz kod odpowiedzialny za tworzenie, modyfikowanie i usuwanie definicji. Istotne jest porównanie liczby aktywnych segmentów z liczbą segmentów nieużywanych, powtarzających te same kryteria albo należących do zakończonych procesów. Analiza planów zapytań pozwala ocenić, czy problem wynika z samej liczby segmentów, czy z kosztu pojedynczych reguł. Logi powinny wskazać także, czy tworzenie segmentów odbywa się ręcznie, cyklicznie, czy w wyniku błędnie powtarzanej operacji.

Naprawa powinna objąć walidację przed zapisem, limity na poziomie odpowiedniego właściciela, wykrywanie duplikatów i bezpieczne usuwanie obiektów wygasłych. Zmiana schematu wymaga ochrony przed wyścigiem równoległych żądań, na przykład przez transakcję oraz unikalne ograniczenie dla identycznych definicji w tym samym zakresie. Po wdrożeniu należy obserwować czas zapytań, rozmiar tabel metadanych, liczbę zadań przeliczających i odsetek odrzuconych prób utworzenia segmentu. W środowisku z bazą danych działającą na laptopie lub komputerze PC sprawdza się dodatkowo obciążenie procesora, pamięci, dysku i usług zależnych, aby odróżnić błąd architektury aplikacji od problemu lokalnej konfiguracji sprzętowej.