Queue zu Queue unter 10.2.

[jogi01]

Hallo Gemeinde,

zur Situation:

wir haben meherere Oracle Instanzen, alles 10.2.

nun möchte ich Oracle Advanced Queueing nutzen um Daten / Informationen zwischen den Instanzen zu übermitteln.

Ich habe zwar gelesen dass es möglich ist, dass eine Queue auf Instance A auf der Queue von Instance B lauschen kann, doch bin ich nicht ganz durchgestiegen wie ich die Queues einrichten muss damit sie auf einander lauschen.

Mein Ansatz war der:

Multiconsumer Queue 1 auf Instance A meldet sich an Queue 2 auf Instance B an und umgekehrt.

somit würde, anders als bei DB-Links, keine Information verloren gehen, sollte mal eine Unterbrechung der Kommunikation stattfinden (Netzwerkstörung).
Und keine Packages würden Invalid oder schmeissen Exceptions nur weil die andere Instance nicht erreichbar ist.

was mein ihr, machbar?

und wenn Ja, wie müssen die Queues eingerichtet werden?

greetz

jogi

[dimitri]

Hi,

die Lösung mit Queues find ich etwas unhandlich. ich hab auch mal damit experimentiert (wenn auch nur auf einer Instance) und im Gegensatz zu einem DBLink ist das doch mehr erheblich mehr Aufwand.

Ich würde diese Alternative vorschlagen:
- Du schreibst Dir eine Procedur, die per DBLink Daten von Instance A nach B kopiert und die ggf. diese dann auf dem Quellsystem löscht. Das läuft in einer Transaktion und somit geht auch nichts verloren wenn die Verbindung abbricht o.ä.

- Einen DBMS_SCHEDULER Job einrichten, der z.B. alle 5 Sekunden anläuft.

BEGIN                                                                                                   
 DBMS_SCHEDULER.CREATE_JOB(job_name=>'Jogis Copy Job',                                   
                           job_type=>'STORED_PROCEDURE',                                                
                           job_action=>'Deine_Procedur',                              
                           enabled=>true,                                                               
                           repeat_interval=>'FREQ=MINUTELY;BYSECOND=0,5,10,15,20,25,30,35,40,45,50,55');
END;                                                                                                    
/

Fehlermeldungen kannst Du abfangen, das musst Du auch beim Queueing Ansatz machen, denn wenn die Ziel Instance nicht vorhanden ist, wird dir dass das Queing Package mitteilen wollen.

Dim

[jogi01]

damit hast du im grossen und ganzen recht.

habe dies auch schon zig mal gemacht.

doch das gesamt gebilde ich etwas komplexer:

ich progge an einem tool dass inhalte der datenbank validiert und verifiziert.
(hatte das ganze schon mal programmiert und im 5 min intervall gepollt.
Ergbnis: mir sind hin und wieder daten durch die lappen gegangen)

jetzt ist mein ansatz event-basiert zu agieren.
Soll heissen: ein after Insert or Update Trigger übergibt den DS im XML-Format in die queue.

hinter der Queue wird anhand von Config-Tabellen 1-x Tabellenspalten geprüft usw.

da wir hier produktionen steuern, muss das ganze entsprechend ausfallsicher sein. ergo 2 queues die so zusagen redundant argieren.

weiterer punkt ist die performance.
meine prüfungen sollen losgelösst von der "user-transaktion" laufen. damit keine Packages oder womöglich noch views (mit schlecht designten statements) mir die suppe versalzen.

ich rede hier von einem zeitfenster von ca. 1 - max 2 sekunden.

daher die idee mit der /den queues.

[dimitri]

Ok, auch wenn ich nicht ganz nachvollziehen kann, wie Daten durch die Lappen gehen können, aber dazu kenn ich die AW auch zu wenig.

Bei einem Punkt seh' ich aber noch ein Problem:

meine prüfungen sollen losgelösst von der "user-transaktion" laufen. damit keine Packages oder womöglich noch views (mit schlecht designten statements) mir die suppe versalzen.

Wenn Du das innerhalb einer autonomen Trasaktion machst, läufst Du Gefahr, dass Du im Falle eines Rollbacks Daten verarbeitest, die nie existiert haben.

Hast Du dir schon mal die Funktionsweise einer Multimaster Replikation angesehen? Das ist in etwa das, was Du versuchst herzustellen. Wenn es um Ausfallsicherheit geht, wäre sicherlich auch eine RAC Umgebung denkenswert, sofern sie entsprechend administriert werden kann und das Budget hoch genug ist.

Dim

[jogi01]

...aber dazu kenn ich die AW auch zu wenig.

das ist ja genau das ding.
im grunde baue ich einen "Watchdog" der, unabhängig von der Datenerfassung (Anwendungen), Daten überwachen soll. (hier liegen div. Anforderungen vor).

Eine Replikation der Daten kommt nicht in frage, da wir hier im Hause die Philosophie der "NICHT REDUNDANZ" fahren (liegt an den Datenmengen).

RAC wird erst testhalber von unseren Admins in 2011 ein geführt.
(Wobei mir dann noch nicht klar ist, wie ich dann über verschiedene Instanzen hinweg agieren kann ohne DB-Links zu benutzen).

dass Du im Falle eines Rollbacks Daten verarbeitest, die nie existiert haben.

damit hast du natürlich völlig recht. doch werde ich das "Commit" des Enqueue, an das COMMIT der Datenpflegenden Anwendung koppeln.
also, keine Autonomous Transaction bein Enqueue.

Ich bin Selbstverständlich offen für jede Art von Tools die mir diese Programmierarbeit abnehmen.

Hatte auch schon über Foglight von Quest nachgedacht. Doch lassen die sich zwar sehr stark über die Datenbanküberwachungs-Funktionen aus, doch leider nicht ob dieses Tool auch die Daten selbst überwachen kann.

greetz

jogi