GoldenLine
Zaloguj się
Wojtek Jurewicz

Wojtek Jurewicz ETL and Database
Developer / Business
Intelligence
specia...

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Czy ktoś zna sposób w jaki subskrybenci mogą być automatycznie powiadamiani o pojawianiu się zmian w obrębie ich subskrypcji? Jeśli dobrze rozumiem, standardowym sposobem jest okresowe uruchamianie JOB-a, który usunie stare dane ze zbioru, rozszerzy okno o nowe dane i je załaduje.

Mnie chodzi o to, że nie chciałbym korzystać z takich okresowych JOB-ów, chciałbym ładować zmiany zaraz po ich pojawieniu się w źródle - teoretycznie mogłyby to rozwiązać triggery na tabeli zmian, ale takie rozwiązanie jest najpewniej niemożliwe.

Nie chcę też, aby zmiany były propagowane przez tryggery na tabelach źródłowych, ponieważ takie ładowanie może potrwać chwilę, a użytkownik wprowadzający dane do systemu źródłowego nie powinien czekać - jednym słowem potrzebuję pewnego rodzaju rozwiązania asynchronicznego.

Jedyne co mi przychodzi do głowy, to trigger na tabeli źródłowej, który w momencie pojawienia się zmiany będzie wstawiał do kolejki JOB-a - jeśli takowy w niej nie istnieje - ładującego zmiany, mającego się uruchomić np. za minutę.

Macie jakieś pomysły?
Link do wypowiedziLink
Wojtek Jurewicz

Wojtek Jurewicz ETL and Database
Developer / Business
Intelligence
specia...

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Może ma ktoś jakieś doświadczenie z Oracle Golden Gate? Wyczytałem, że można je dość sprytnie zintegrować z Oracle Data Integrator i ew. innymi narzędziami ETL-owymi, może to by załatwiło sprawę?
Link do wypowiedziLink

konto usunięte

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Wojtek Jurewicz:
Czy ktoś zna sposób w jaki subskrybenci mogą być automatycznie powiadamiani o pojawianiu się zmian w obrębie ich subskrypcji? Jeśli dobrze rozumiem, standardowym sposobem jest okresowe uruchamianie JOB-a, który usunie stare dane ze zbioru, rozszerzy okno o nowe dane i je załaduje.

Mnie chodzi o to, że nie chciałbym korzystać z takich okresowych JOB-ów, chciałbym ładować zmiany zaraz po ich pojawieniu się w źródle - teoretycznie mogłyby to rozwiązać triggery na tabeli zmian, ale takie rozwiązanie jest najpewniej niemożliwe.

Nie chcę też, aby zmiany były propagowane przez tryggery na tabelach źródłowych, ponieważ takie ładowanie może potrwać chwilę, a użytkownik wprowadzający dane do systemu źródłowego nie powinien czekać - jednym słowem potrzebuję pewnego rodzaju rozwiązania asynchronicznego.

Jedyne co mi przychodzi do głowy, to trigger na tabeli źródłowej, który w momencie pojawienia się zmiany będzie wstawiał do kolejki JOB-a - jeśli takowy w niej nie istnieje - ładującego zmiany, mającego się uruchomić np. za minutę.

Macie jakieś pomysły?


A rozwiązanie oparte o DBMS_CHANGE_NOTIFICATION. Dowolona zmiana na wynikowej tabelce byłbaby widoczna przez DBMS_CHANGE_NOTIFICATION. Tutaj nie wazne czy używasz CDC Oracla czy GoldenGate. DBMS_CHANGE_NOTIFICATION odfiltrujesz tabelki modyfikowane i powiadomisz. Jeśli chodzi o GoldenGate to proponowalbym uruchomić jakis kod PL/SQL ktory wstawi do AQ notyfikacje i roześlesz do zainteresowanych. Można tez CDC zbierac dane do tabelek pośrednich i pozniej wystawic batcha, który zaladuje odpowiednio dane i powiadomi przez AQ. Sposobow jest duzo :) Ale ciesze sie ze ktos GG lub CDC wybiera.
Link do wypowiedziLink
Wojtek Jurewicz

Wojtek Jurewicz ETL and Database
Developer / Business
Intelligence
specia...

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Dzięki, wydaje się, że o takie coś mi chodziło. Nie udało mi się tylko znaleźć, w jaki sposób mechanizm ten jest zaimplementowany? Synchronicznie, czy asynchronicznie? Nie jest to przypadkiem mechanizm triggero-podobny? Zależy mi na tym, aby uniknąć zbędnych opóźnień po stronie użytkownika, jeśli procedura ustawiona jako callback będzie wykonywała się dłuższą chwilę, a ten będzie musiał czekać na jej zakończenie.
Link do wypowiedziLink
Wojtek Jurewicz

Wojtek Jurewicz ETL and Database
Developer / Business
Intelligence
specia...

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Dzięki, znalazłem odpowiedź tutaj:
http://www.oracle-base.com/articles/10g/dbms_change_no...

Wygląda na to, że odbywa się to asynchronicznie.
Link do wypowiedziLink

konto usunięte

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Wojtek Jurewicz:
Dzięki, znalazłem odpowiedź tutaj:
http://www.oracle-base.com/articles/10g/dbms_change_no...

Wygląda na to, że odbywa się to asynchronicznie.

Chciałbym zaznaczyć:

Trzeba tylko pamiętać iż DBMS_CHANGE_NOTIFICATION ma swoje ograniczenia.
Ograniczenie odnosi się do liczby zmodyfikowanych rekordów. Wprawdzie poprzez DBMS_CHANGE_NOTIFICATION odwolamy się do zmodyfikowanych rekordów, ale do ograniczonej liczby.

Z dokumentacji wycinek:

ROWIDs are published in the external string format. For a regular heap table, the length of a ROWID is 18 character bytes. For an Index Organized Table (IOT), the length of the ROWID depends on the size of the primary key, and might exceed 18 bytes.

If the server does not have enough memory for the ROWIDs, the notification might be "rolled up" into a FULL-TABLE-NOTIFICATION, indicated by a special flag in the notification descriptor. Possible reasons for a FULL-TABLE-NOTIFICATION are:

* Total shared memory consumption due to ROWIDs exceeds 1% of the dynamic shared pool size.
* Too many rows were changed in a single registered object within a transaction (the upper limit is approximately 80).
* Total length of the logical ROWIDs of modified rows for an IOT is too large (the upper limit is approximately 1800 bytes).
* You specified the Notification Grouping option NTFN_GROUPING_TYPE with the value DBMS_CQ_NOTIFICATION.NTFN_GROUPING_TYPE_SUMMARY, described in "Notification Grouping Options".

Because a FULL-TABLE-NOTIFICATION does not include ROWIDs, the application that receives it must assume that the entire table (that is, all rows) might have changed.
Link do wypowiedziLink

konto usunięte

Temat: Oracle CDC - automatyczne powiadamianie subskrybentów

Z tego co zauwazylem wynika iż wszystko co jest oparte o AQ (CDC,Streamsy,Notyfication, etc.. ) jest oparte o asynchroniczność. Ewentualnie CDC może dzialać także synchronicznie (ale takie rozwiązanie chyba Ciebie nie interesuje). Dodatkowo GG także działa asynchroniczenie (po redo logach, logminer).

Oczywiscie wycinek z dokumentacji Oracla (Oracle® Database Data Warehousing Guide):

Capturing Change Data with Change Data Capture

Change Data Capture can capture and publish committed change data in either of the following modes:

*

Synchronous

Change data is captured immediately, as each SQL statement that performs a data manipulation language (DML) operation (INSERT, UPDATE, or DELETE) is made, by using triggers on the source database. In this mode, change data is captured as part of the transaction modifying the source table. Synchronous Change Data Capture is available with Oracle Standard Edition and Enterprise Edition.
*

Asynchronous

Change data is captured after a SQL statement that performs a DML operation is committed, by taking advantage of the data sent to the redo log files. In this mode, change data is not captured as part of the transaction that is modifying the source table, and therefore has no effect on that transaction. Asynchronous Change Data Capture is available with Oracle Enterprise Edition only.
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy


Następna dyskusja:

Oracle Application Server




Wyślij zaproszenie do
Anuluj