Zachowanie i harmonogram każdego komponentu usług przenoszenia danych można konfigurować w celu dopasowania ich do różnych wymagań środowisk projektowania, testowania i środowiska produkcyjnego. Zmiana konfiguracji jednego komponentu może mieć bezpośredni wpływ na zachowanie innych, zależnych od niego komponentów.
Ogólnie występują dwie zależności:
- Komponent przechwytujący wywołuje okresowo komponent cyklu życia elementów źródłowych.
Jeśli komponent przechwytujący nie został uruchomiony, nie zostaje wymuszony żaden cykl życia elementów źródłowych. Istnieje możliwość konfigurowania opóźnienia między wywołaniami komponentu cyklu życia.
Na powyższym rysunku komponent cyklu życia elementów źródłowych jest wywoływany co 3 jednostki czasu, wykonuje kilka działań, a następnie zwraca sterowanie komponentowi przechwytującemu, który kontynuuje przetwarzanie.
- Komponent ETL i komponent cyklu życia elementów docelowych są wywoływane przez komponent wprowadzający po pomyślnym przeniesieniu danych ze źródłowej do docelowej bazy danych. Komponenty ETL i cyklu życia elementów docelowych są wywoływane jedynie wtedy, gdy działa komponent wprowadzający.
Z uwagi na to, że komponenty zależne działają według innych harmonogramów niż komponent, od którego są zależne, wynikiem wywołania nie musi być wykonanie komponentu. Zamiast tego każdy zależny komponent sprawdza swój harmonogram po wywołaniu i jeśli w tym czasie nie ma żadnych zadań do wykonania, zwraca sterowanie komponentowi wywołującemu. W powyższym przykładzie komponenty ETL i cyklu życia elementów docelowych mogą zostać wykonane tylko dwukrotnie, jeśli harmonogram obu komponentów nie pozwala wywoływać ich częściej niż raz na każde 5 jednostek czasu.

Komponent ETL (i komponent cyklu życia elementów docelowych) jest wywoływany i wykonywany w czasie T2 (i odpowiednio T3). Następne wykonanie występuje około czasu T6. Ponieważ od ostatniego wykonania upłynęło mniej niż 5 jednostek czasu, sterowanie jest natychmiast zwracane do komponentu wprowadzającego. W wyniku późniejszego wywołania, które ma miejsce w przybliżeniu w czasie T8 (odpowiednio T9), dochodzi do wykonania, ponieważ upłynęło ponad 5 jednostek czasu. Każdy komponent jest implementowany przez jedną lub więcej instancji komponentu. Każdą z tych instancji można skonfigurować osobno, co pozwoli na bardziej dokładne sterowanie.
Uwaga: Jeśli wprowadzono zmiany, odnoszą one natychmiastowy skutek (o ile nie podano innych informacji).
Konfiguracja domyślna komponentów przechwytujących i wprowadzających może być modyfikowana. W tym celu należy zmienić odpowiednie tabele sterujące lub nadpisać je przy użyciu parametrów wiersza komend w skryptach uruchamiających. Komponent ETL i komponent wymuszający cykl życia można skonfigurować, aktualizując jedną z tabel sterujących.
Opisane niżej czynności należy wykonać, aby dostosować komponenty usługi przenoszenia danych do wymagań środowisk programistycznych, testowych i produkcyjnych.
Konfiguracja instancji komponentu przechwytującego zmiany danych źródłowych
Instancja komponentu przechwytującego jest odpowiednikiem narzędzia replikacji DB2 Capture. Domyślnie to narzędzie jest skonfigurowane w taki sposób, aby nieustannie
przechwytywało zmiany w tabelach źródłowych i zapisywało je w wewnętrznych tabelach roboczych. Zazwyczaj nie trzeba zmieniać domyślnej konfiguracji instancji komponentu przechwytującego.
- Identyfikowanie instancji komponentu przechwytującego.
Do przechwycenia danych związanych z
modelem
miar
biznesowych zostanie użytych wiele
instancji komponentu przechwytującego (to znaczy narzędzi DB2 Capture). Aby określić, które narzędzia przechwytujące mają udostępniać usługi dla
modelu
miar
biznesowych:
- Zidentyfikuj usługę przenoszenia danych, dla której ma zostać zmieniona konfiguracja narzędzia przechwytującego.
- Przejrzyj tabelę metadanych WBIRMADM.RMMETADATA w bazie danych stanu (dla usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych) lub w wykonawczej bazie danych (dla usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych) i zidentyfikuj wszystkie nazwy narzędzia przechwytującego (kolumna SRC_RM_CAP_SVR_NAME).
Przykład: Zapytanie "SELECT OM_NAME, SRC_TAB_NAME, SERVICE_NAME, SRC_RM_CAP_SVR_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime' " może zwrócić następujący wynik:
W powyższym przykładzie narzędzie przechwytujące CAPTURE_1 przechwytuje wszystkie zmiany wprowadzane w dwóch tabelach źródłowych, które są powiązane z modelem miar biznesowych STEW_S w bazie danych stanu.
- Zmienianie odstępu czasu między operacjami czyszczenia tabeli roboczej komponentu przechwytującego.
Narzędzia przechwytujące czyszczą automatycznie swoje tabele robocze co 300 sekund (wartość domyślna parametru prune_interval), jeśli funkcja czyszczenia automatycznego jest włączona (parametr autoprune ma wartość "y"). Każda operacja czyszczenia automatycznie wywołuje instancję komponentu cyklu życia elementów źródłowych. Zachowanie to jest implementowane za pomocą wyzwalacza bazy danych. Zmiana parametru odstępu czasu między operacjami czyszczenia dla narzędzia przechwytującego ma bezpośredni wpływ na częstotliwość czyszczenia tabel źródłowych przez komponent cyklu życia elementów źródłowych. Poniższy rysunek ilustruje wpływ zmiany odstępu czasu między operacjami czyszczenia dla komponentu przechwytującego na wywołanie instancji komponentu cyklu życia elementów źródłowych.
Zwiększenie wartości parametru prune_interval instancji komponentu przechwytującego z 2 jednostek czasu (na przykład 300 sekund)
do 3 jednostek czasu (na przykład 450 sekund) spowoduje, że:
- Wiersze w tabeli roboczej komponentu przechwytującego, które można już usunąć, pozostaną dłużej w tej tabeli, zwiększając tym samym potencjalne zapotrzebowanie na miejsce w tabeli.
Tabele robocze się powiększą, ale obciążenie systemu i ryzyko awarii może być mniejsze.
- Wiersze w tabelach źródłowych, które zgodnie ze strategią cyklu życia dotyczącą czasu przechowywania mogą być już usunięte, pozostaną w tabeli źródłowej dłużej niż oczekiwano.
Jeśli parametr prune_interval komponentu przechwytującego ma wartość większą niż wartość parametru prune_interval komponentu cyklu życia, pierwszeństwo ma ustawienie parametru komponentu przechwytującego. Jeśli narzędzie przechwytujące nie działa lub jeśli jego funkcja automatycznego czyszczenia jest wyłączona, nie zostanie wymuszony żaden cykl życia elementów źródłowych.
Konfigurowanie komponentu cyklu życia elementów źródłowych
W każdej źródłowej bazie danych (bazie danych stanu i wykonawczej bazie danych) używanych jest wiele instancji komponentu cyklu życia. Każda
instancja, która jest implementowana przez wyzwalacz, narzuca takie strategie czasu przechowywania, jakie zostały zdefiniowane w tabeli sterującej WBIRMADM.RMPRUNECTRL znajdującej się w źródłowej bazie danych określonej usługi przenoszenia danych. Strategie czasu przechowywania cyklu życia są określane dla każdej tabeli. Zatem jeden wiersz w tabeli WBIRMADM.RMPRUNECTRL odpowiada jednej tabeli wymagającej czyszczenia.
- Identyfikowanie instancji komponentu cyklu życia elementów źródłowych.
Czynności konieczne do określenia,
które wyzwalacze narzucają strategie czasu przechowywania dla danego
modelu
miar
biznesowych:
- Zidentyfikuj usługę przenoszenia danych, dla której ma zostać zmieniona konfiguracja ETL.
- Przejrzyj tabelę WBIRMADM.RMMETADATA w bazie danych stanu (dla usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych) lub w wykonawczej bazie danych (dla usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych) i wyszukaj nazwy powiązanych wyzwalaczy w kolumnie SRC_RM_PRUNE_TRG_NAME.
Przykład: Zapytanie "SELECT OM_NAME,
SRC_TAB_NAME, SERVICE_NAME, SRC_RM_PRUNE_TRG_NAME FROM WBIRMADM.RMMETADATA
WHERE SERVICE_NAME='State to Runtime'" może zwrócić następujący wynik:
W tym
przykładzie dwa wyzwalacze (WBIRMADM.MCPruneTrig_8 oraz
WBIRMADM.MCPruneTrig_9) narzucają strategię czasu przechowywania cyklu życia dwóm tabelom źródłowym
modelu
miar
biznesowych STEW_S w bazie danych stanu. Ponieważ strategie czasu przechowywania są definiowane według tabeli, a nie według nazwy instancji komponentu cyklu życia, podczas planowania zmian w zachowaniu funkcji narzucania cyklu życia należy śledzić kolumnę SRC_TAB_NAME.
- Modyfikowanie konfiguracji instancji komponentu cyklu życia elementów źródłowych.
- Włączanie i wyłączanie instancji komponentu cyklu życia:
Czyszczenie może mieć duży wpływ na wydajność systemu. Włączenie funkcji czyszczenia pozwala zmniejszyć ilość
informacji obsługiwanych przez serwery transakcji (stanu) i serwery
raportowania (wykonawcze). Tabele te zostaną też w niewielkim stopniu dodatkowo obciążone przez każde z wywołań (zgodnie z parametrami komponentu cyklu życia). Wyłączenie funkcji czyszczenia spowoduje natomiast wzrost wielkości tabel źródłowych, co z czasem może doprowadzić do pogorszenia wydajności.
Domyślnie
tabele źródłowe są automatycznie czyszczone zgodnie z ich strategią czasu
przechowywania cyklu życia. Aby czasowo wyłączyć czyszczenie, należy
zmodyfikować odpowiednie wpisy w tabeli WBIRMADM.RMPRUNECTRL: ustawienie w
kolumnie PRUNE_ENABLED wartości 1 spowoduje włączenie czyszczenia, a ustawienie innej wartości
liczbowej (najlepiej wartości 0) spowoduje wyłączenie tej funkcji.
Jeśli zostanie użyta poniższa
konfiguracja, będą czyszczone wiersze tabeli źródłowej wbi.CTX_TQ4MUFT42JOT5F6R3KSDQDE2UI, ale nie będą czyszczone wiersze
tabeli wbi.AI_BVSOYAP1DRWFD5HNQJR5HFQQQE. Zapytanie: "SELECT TABLE_NAME, PRUNE_ENABLED FROM WBIRMADM.RMPRUNECTRL"
może zwrócić następujące wyniki:
- Zmiana strategii czasu przechowywania:
Strategie czasu
przechowywania mogą być zmieniane tylko dla tabel źródłowych znajdujących się w wykonawczej bazie danych. Wszystkim tabelom znajdującym się w bazie
danych stanu narzucany jest czas przechowywania równy 0, niezależnie od ustawień w tabeli WBIRMADM.RMPRUNECTRL. Czas przechowywania jest definiowany jako minimalny czas, przez jaki wiersz musi być przechowywany w tabeli, zanim będzie możliwe jego usunięcie, o ile spełnione zostaną dwa kryteria. Tylko jedno z tych dwóch kryteriów można dostosować za pomocą tabeli sterującej: określany w minutach czas przechowywania. Każdy wiersz, który został oznaczony jako gotowy do usunięcia i był przechowywany w tabeli źródłowej przez czas równy lub większy niż wartość RETENTION_IN_MINUTES (czas przechowywania w minutach), może zostać usunięty.
W przypadku użycia domyślnej konfiguracji tabel źródłowych w wykonawczej bazie danych, wiersze oznaczone przez serwer jako gotowe do usunięcia muszą być przechowywane przez jeden dzień (1440 minut), zanim będą mogły zostać usunięte. Zapytanie: "SELECT
TABLE_NAME, RETENTION_IN_MINUTES FROM WBIRMADM.RMPRUNECTRL" może zwrócić następujące wyniki:
Zmiany we
wpisach tabeli sterującej WBIRMADM.RMPRUNECTRL będą pobierane za każdym razem, gdy wywoływany jest komponent cyklu życia elementów źródłowych.
- Ustawianie harmonogramu czyszczenia danych źródłowych:
Istnieje zależność między odstępem czasu czyszczenia tabeli roboczej komponentu przechwytującego a wywołaniem komponentu cyklu życia elementów źródłowych.
Wywołanie nie doprowadzi do wykonania, jeśli nie upłynęło dość czasu między wywołaniami instancji komponentu cyklu życia elementów źródłowych (sytuację tę przedstawiono na następującym rysunku):
Zakładając, że zgodnie z harmonogramem komponent cyklu życia elementów źródłowych ma być uruchamiany co 4 jednostki czasu, a komponent przechwytujący czyści swoje tabele robocze co 2 jednostki czasu, to w wyniku wywołania w czasie T4 nie dojdzie do wykonania.
Aby zmienić domyślny harmonogram, należy znaleźć odpowiednie wpisy w tabeli WBIRMADM.RMPRUNECTRL i zmienić wartość w kolumnie PRUNE_INTERVAL, która reprezentuje minimalne opóźnienie między wykonaniami (w minutach).
W wyniku zwiększenia tej wartości rzadziej dochodzi do wykonań (ale liczba wywołań pozostaje taka sama). W wyniku każdego wykonania zostaną określone wiersze tabeli źródłowej, które mogą zostać usunięte, a następnie zostaną one usunięte. Należy regularnie monitorować źródłowe bazy danych, aby w porę zidentyfikować i wyeliminować potencjalne problemy dotyczące wydajności, których przyczyną są blokady powstałe na skutek wykonania tych operacji usuwania.
Konfigurowanie instancji docelowego komponentu wprowadzającego (APPLY)
Instancją komponentu wprowadzającego jest program narzędziowy
replikacji DB2 Apply. Zmiany przechwycone przez przechwytujące programy narzędziowe są nieustannie wprowadzane do tabel pomostowych w docelowej bazie danych (według ustawień domyślnych). Domyślne parametry konfiguracji programu narzędziowego powinny być odpowiednie dla większości środowisk i nie należy ich zmieniać.
- Identyfikowanie instancji komponentu wprowadzającego.
Do wprowadzania zmian danych do wewnętrznych tabel pomostowych powiązanych z
modelem
miar
biznesowych używanych jest wiele instancji komponentu wprowadzającego (narzędzi DB2 Apply). Aby określić, które z narzędzi wprowadzających zostały wyznaczone jako udostępniające usługi dla
modelu
miar
biznesowych:
- Zidentyfikuj usługę przenoszenia danych, dla której ma zostać zmieniona konfiguracja narzędzia wprowadzającego.
- Przejrzyj tabelę metadanych WBIRMADM.RMMETADATA w wykonawczej bazie danych (dla usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych) lub w bazie danych historycznych (dla usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych) i zidentyfikuj wszystkie nazwy narzędzia wprowadzającego (kolumna TGT_RM_APP_SVR_NAME). Zapytanie: "SELECT OM_NAME, SRC_TAB_NAME,
SERVICE_NAME, TGT_RM_APP_SVR_NAME FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State
to Runtime'" może zwrócić następujący wynik:
W tym przykładzie wszystkie zmiany danych w tabeli STEW_S modelu
miar
biznesowych, które zostały przechwycone w bazie danych stanu, zostaną wprowadzone do tabel pomostowych w wykonawczej bazie danych przez narzędzie wprowadzające APPLY_4.
Za każdym razem, gdy komponent program wprowadzającego zmiany zakończy przetwarzanie wszystkich zatwierdzonych zmian, które zostały zarejestrowane przez narzędzie przechwytujące, wywoływana jest co najmniej jedna instancja komponentu ETL oraz co najmniej jedna instancja cyklu życia elementów docelowych.
Konfigurowanie komponentu ETL
Komponenty ETL zostały zaimplementowane w programie WebSphere
Business Monitor jako procedury składowane w bazie
danych. Te procedury składowane zawsze rezydują w docelowej bazie danych każdej usługi przenoszenia danych. Co za tym idzie, wszystkie procedury składowane ETL przypisane do usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych znajdują się w wykonawczej bazie danych. Natomiast procedury składowane ETL przypisane do usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych znajdują się w bazie danych historycznych.
- Identyfikowanie instancji komponentu ETL.
Do przetwarzania danych, które zostały dodane do
wewnętrznych tabel pomostowych powiązanych z
modelem
miar
biznesowych, ustawionych jest wiele instancji
komponentu ETL.
Aby określić, które procedury składowane zostały wyznaczone jako udostępniające usługi dla danego
modelu
miar
biznesowych:
- Zidentyfikuj usługę przenoszenia danych, dla której ma zostać zmieniona konfiguracja ETL.
- Przejrzyj tabelę metadanych WBIRMADM.RMMETADATA w wykonawczej bazie danych (dla usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych) lub w bazie danych historycznych (dla usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych) i zidentyfikuj wszystkie nazwy procedur składowanych ETL (kolumna TGT_RM_SPETL_NAME). Zapytanie:
"SELECT OM_NAME, SRC_TAB_NAME, TGT_TAB_NAME, SERVICE_NAME, TGT_RM_SPETL_NAME
FROM WBIRMADM.RMMETADATA WHERE SERVICE_NAME='State to Runtime'" może zwrócić następujący wynik:
W tym przykładzie wszystkie zmiany danych w tabeli STEW_S modelu
miar
biznesowych, które zostały przechwycone w bazie danych stanu i wprowadzone do tabel pomostowych w wykonawczej bazie danych, będą przetwarzane przez procedury składowane o nazwach WBIRMADM.WBIRMSP_10 i WBIRMADM.WBIRMSP_14. Dane, które zostaną pomyślnie przetworzone, będą zapisywane w tabelach docelowych (identyfikowanych przez kolumnę TGT_TAB_NAME) w wykonawczej bazie danych.
- Modyfikowanie konfiguracji instancji komponentu ETL.
Konfiguracje
instancji komponentu ETL są zapisywane w tabeli sterującej WBIRMADM.RMCONTROL.
Instancje, które zostały przypisane do usługi przenoszenia danych z bazy
danych stanu do wykonawczej bazy danych, przechowują swoje konfiguracje w
wykonawczej bazie danych, a wszystkie inne w bazie danych historycznych. Wszelkie
zmiany w konfiguracji będą pobierane przez procedury składowane przy ich następnym
uruchomieniu. Trzy opcje można konfigurować poprzez tabelę sterującą:
- Minimalny czas, jaki upływa między dwoma wykonaniami procedury ETL (ETLSCHEDMETHOD, ETL_0_MINUTES)
- Granulacja danych wyjściowych rejestrowania (LOGLEVEL)
- Przedziały czasu transakcji (COMMITINTERVAL)
Każdy wiersz w tej tabeli odpowiada jednej instancji komponentu ETL, która
odpowiada dokładnie jednej docelowej tabeli, którą należy zapełnić. Poniższa
przykładowa konfiguracja ilustruje wpływ zmian w konfiguracji na zachowanie instancji.
- Zmiana harmonogramu ETL.
Instancje komponentu ETL są wywoływane za
każdym razem, gdy instancje komponentu wprowadzającego kończą
przetwarzanie zestawu subskrypcji. Po wywołaniu instancja ETL sprawdza swój
harmonogram i albo zaczyna przetwarzanie, albo natychmiast zwraca sterowanie do
instancji komponentu wprowadzającego.
Komponent sprawdza informacje zapisane w tabeli sterującej
WBIRMADM.RMCONTROL, aby określić, czy istnieje potrzeba jej uruchomienia. Poniższy
rysunek ilustruje różnice między wywołaniem a wykonaniem: za pierwszym i
trzecim razem instancja komponentu ETL jest wykonywana zgodnie z harmonogramem. Drugie
wywołanie miało miejsce poza harmonogramem i w jego wyniku nie następuje żadne działanie.
Różne
czynniki określają, jak często instancje komponentu ETL powinny być
uruchamiane w usłudze przenoszenia danych z bazy danych stanu do
wykonawczej bazy danych i w usłudze przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych:
- Dostępność: Jak szybko dane powinny być dostępne w tabeli docelowej.
Wybranie mniejszego odstępu czasu powoduje, że dane są dostępne wcześniej, ale równocześnie zwiększa się obciążenie systemu.
- Ilość danych: Narzędzia replikacji nieustannie (lub zgodnie z konfiguracją) przekazują dane do tabel pomostowych, niezależnie od tego, czy zostały one przetworzone przez instancje komponentu ETL. Im więcej zasobów bazy danych jest używanych, tym więcej danych trzeba przetworzyć. Częstsze przetwarzanie danych pozwoli zredukować maksymalne wykorzystanie zasobów.
- Czas przetwarzania: Przetwarzanie ETL zabiera mniej czasu w przypadku danych znajdujących się w wykonawczej bazie danych niż w przypadku danych w bazie danych historycznych. Należy to wziąć pod uwagę w czasie planowania harmonogramu. Użycie niskiej wartości opóźnienia między wykonaniami nie poprawi wydajności, jeśli czas wykonywania będzie dłuższy niż czas opóźnienia ustawiony w harmonogramie. Na przykład jeśli zakończenie przetwarzania danych przez instancję komponentu ETL wymaga 60 sekund, to mimo ustawienia w harmonogramie wartości 30 sekund, rzeczywisty odstęp czasu będzie wynosił co najmniej 60 sekund, ponieważ instancje komponentu ETL są wykonywane sekwencyjnie.
Obecnie są obsługiwane dwa tryby planowania:
- Harmonogram elastyczny:
Instancja ETL zostanie wykonana, jeśli od ostatniego wykonania (LASTUPDATED) upłynęło co najmniej tyle minut, ile wynosi wartość parametru ETL_0_MINUTES. Tabela sterująca może zawierać następujące przykładowe informacje:

Procedura składowana WBIRMADM.WBIRMSP_10
nie zostanie uruchomiona wcześniej niż 11 października 2005 roku o godzinie
18:20:20 (11 października 2005 roku o godzinie 17:20:20 + 60 minut). W harmonogramach może pojawić się nieplanowane opóźnienie, jeśli procedura składowana zostanie wywołana później niż 11 października 2005 roku o godzinie 18:20:20. Załóżmy, że bieżący czas to godzina 19:00, a procedura składowana nie została wykonana zgodnie z oczekiwaniami o godzinie 18:20. Procedura składowana jest wywoływana i uruchamia się (opóźniona o około 40 minut).
Nie zostanie jednak uruchomiona ponownie przed godziną 19:00 + 60 minut, czyli przed godziną 20:00. Rzeczywisty harmonogram jest opóźniony. Zgodnie z harmonogramem procedury ETL miały być uruchamiać co 60 minut - 20 minut po pełnej godzinie, ale ze względu na opóźnienie są one uruchamiane co 60 minut o pełnej godzinie. Jeśli to konieczne, można zresetować harmonogram, zmieniając wartość znacznika czasu w kolumnie LASTUPDATED.
Należy używać tego mechanizmu planowania, jeśli
nie jest wymagany stały przedział czasu wykonywania. Aby włączyć tę formę
harmonogramu, należy ustawić wartość 0 w kolumnie ETLSCHEDMETHOD tabeli WBIRMADM.RMCONTROL dla wszystkich procedur składowanych, które
zostały przypisane do danej grupy miar biznesowych:
- Harmonogram stały:
Jest to domyślny harmonogram dla wszystkich
komponentów ETL.
Instancje komponentu ETL są wykonywane, jeśli bieżący czas jest późniejszy niż wartość NEXTSTARTTIME.
W celu uniknięcia opóźnienia następny zaplanowany czas wykonania jest obliczany na podstawie bieżącego czasu i czasu poprzedniego wykonania za każdym razem, gdy wykonywana jest procedura składowana. Harmonogram ten ilustruje poniższy przykład:
Załóżmy, że bieżący czas to godzina
19:00, a procedura składowana nie została wykonana zgodnie z oczekiwaniami o godzinie 18:20. Procedury składowane zostaną wykonane, ponieważ minęła już godzina NEXTSTARTTIME (18:20) tego samego dnia. Następne wykonanie zostanie zaplanowane na 19:20 (zgodnie z oryginalnym harmonogramem), a nie na 20:00, jak w przypadku harmonogramu
elastycznego. Tego rodzaju harmonogramu należy używać, jeśli procedury składowane muszą być uruchamiane w zdefiniowanym wcześniej oknie czasowym. Aby włączyć tę formę
harmonogramu, należy ustawić wartość 1 w kolumnie ETLSCHEDMETHOD tabeli WBIRMADM.RMCONTROL dla wszystkich procedur składowanych, które
zostały przypisane do danej grupy miar biznesowych:
Jest wysoce wskazane, aby dla instancji komponentu ETL należących do
tego samego modelu
miar
biznesowych używać tego
samego rodzaju harmonogramu, ponieważ między tymi instancjami występują zależności. Jest ważne zwłaszcza dla bazy
danych historycznych i harmonogramów z dużymi odstępami czasu (kilka godzin lub
więcej). Ustawienie w kolumnie ETLSCHEDMETHOD wartości innej niż 0 lub 1 wyłączy instancje komponentu ETL.
- Zmiana poziomu rejestrowania.
Procedury składowane obsługują dwa poziomy rejestrowania: minimalny (0) oraz maksymalny (1). Aby
zmodyfikować ustawienie domyślne (minimalny), należy zmienić wartość w kolumnie
LOGLEVEL tabeli WBIRMADM.CONTROL dla procedur składowanych
(TGT_RM_SPETL_NAME), których poziom rejestrowania ma zostać zmieniony. Wszystkie
dane wyjściowe rejestrowania są dodawane do tabeli WBIRMADM.RMLOG. Dwie
przykładowe procedury składowane - WBIRMADM.WBIRMSP_10 i WBIRMADM.WBIRMSP_14 - korzystają z minimalnego poziomu rejestrowania:
Tabela dziennika nie jest automatycznie czyszczona, zatem powinna
być regularnie sprawdzana przez administratora bazy danych. Dane wyjściowe
rejestrowania powinny być jak najmniejsze (o ile nie istnieją inne instrukcje).
- Zmiana przedziałów czasu transakcji.
Dane, które zostały pomyślnie
przetworzone przez procedury składowane, są natychmiast zapisywane w tabelach
docelowych. Jednak w zależności od ustawionego odstępu
czasu zatwierdzania (kolumna COMMITINTERVAL w tabeli WBIRMADM.RMCONTROL), aktualizacje tabeli docelowej nie będą wprowadzane na stałe, dopóki nie zostanie przetworzona określona liczba wierszy
lub nie będzie już wierszy do przetworzenia. Zwiększenie
wartości parametru COMMITINTERVAL (na przykład do
1500) wymusi na procedurach składowanych przetwarzanie większej ilości danych
przed zatwierdzeniem jakichkolwiek zmian. Blokada tabeli docelowej będzie
trwała dłużej, co może mieć negatywny wpływ na inne komponenty, które próbują uzyskać dostęp do tej tabeli.
Zmniejszenie czasu trwania (na przykład do 500) zmniejszy liczbę wierszy, które muszą
zostać przetworzone przed udostępnieniem ich w tabeli docelowej, i spowoduje wcześniejsze zwolnienie blokady.
Konfigurowanie komponentu cyklu życia elementów docelowych.
Tabele robocze procesu ETL rosną tak długo, jak nowe lub
zaktualizowane dane są wprowadzane przez instancje komponentu wprowadzającego. Jedna instancja komponentu cyklu życia elementów docelowych, zaimplementowana przez
procedurę składowaną, jest przypisana do jednej tabeli roboczej w każdej
docelowej bazie danych (wykonawczej i danych historycznych). Każda instancja
narzuca wewnętrzne strategie czasu przechowywania, zgodnie z definicją w tabeli sterującej WBIRMADM.RMPRUNECTRL. Podobnie jak w przypadku
tabel źródłowych, strategie czasu przechowywania dla tabel roboczych ETL
są określane dla każdej tabeli osobno. Zatem jeden wiersz w tabeli WBIRMADM.RMPRUNECTRL odpowiada jednej tabeli, która wymaga czyszczenia.
Podsumowanie parametrów konfiguracji usług przenoszenia danych
Poniższa tabela podsumowuje najczęściej używane parametry udostępniane dla każdego komponentu usług przenoszenia danych.
Więcej informacji o parametrach konfiguracji można znaleźć w podręczniku replikacji produktu DB2.
Komponent |
Nazwa parametru |
Wartości domyślne |
Poprawne wartości |
Położenie parametru |
Komponent przechwytujący |
autoprune |
T |
|
|
Komponent przechwytujący |
prune_interval (w sekundach) |
300 |
|
|
Komponent cyklu życia elementów źródłowych |
PRUNE_ENABLED |
1 |
0 - wyłączony
1 - włączony
|
Źródłowa baza danych usługi przenoszenia danych: WBIRMADM.RMPRUNECTRL
|
Komponent cyklu życia elementów źródłowych |
RETENTION_IN_MINUTES |
0 dla usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych
1440 dla usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych
|
Od 0 do limitu produktu
DB2 dla typu BIGINT |
Źródłowa baza danych usługi przenoszenia danych: WBIRMADM.RMPRUNECTRL
|
Komponent cyklu życia elementów źródłowych |
PRUNE_INTERVAL (w minutach) |
5
|
Od 0 do limitu produktu DB2 dla typu BIGINT |
Źródłowa baza danych usługi przenoszenia danych: WBIRMADM.RMPRUNECTRL
|
ETL |
ETLSCHEDMETHOD |
1 |
0 - harmonogram elastyczny
1 - harmonogram o ścisłym odstępie czasu
Inne - wyłączenie komponentu ETL
|
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMCONTROL
|
ETL |
ETL_0_MINUTES |
5 dla usługi przenoszenia danych z bazy danych stanu do wykonawczej bazy danych
1440 dla usługi przenoszenia danych z wykonawczej bazy danych do bazy danych historycznych
|
Od 0 do
limitu produktu DB2 dla typu INTEGER |
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMCONTROL
|
ETL |
LOGLEVEL |
0 |
0 - normalne rejestrowanie
1 - rejestrowanie danych śledzenia
|
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMCONTROL
|
ETL |
COMMITINTERVAL (liczba rekordów) |
1000 |
0 - wyłączenie zatwierdzeń do końca przetwarzania
1 - zatwierdzanie każdego rekordu
n - limit produktu DB2 dla typu BIGINT
|
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMCONTROL
|
Komponent cyklu życia elementów docelowych |
PRUNE_ENABLED |
1 |
0 - wyłączony
1 - włączony
|
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMPRUNECTRL
|
Komponent cyklu życia elementów docelowych |
RETENTION_IN_MINUTES |
0 |
Od 0 do limitu produktu
DB2 dla typu BIGINT |
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMPRUNECTRL
|
Komponent cyklu życia elementów docelowych |
PRUNE_INTERVAL (w minutach) |
1440 |
Od 0 do
limitu produktu DB2 dla typu BIGINT |
Docelowa baza danych usługi przenoszenia danych: WBIRMADM.RMPRUNECTRL
|
Uwaga: IBM zastrzega sobie prawo do wprowadzania zmian w powyższych tabelach i kolumnach baz danych.
W związku z tym niektóre tabele i kolumny mogą zostać zmienione, usunięte lub dodane w innych wersjach produktu. Użytkownik wykorzystujący treść lub struktury zawarte w niniejszych informacjach w innych wersjach produktu robi to na własne ryzyko. IBM będzie dokumentować wszystkie takie zmiany.