CDC Problem

Question

Hallo zusammen,

ich habe ein für mich unlösbares Problem. Ich brauch unbedingt Hilfe.

Folgendes Problem:  Ich habe zwei Quelltabellen namens Auftrag und Auftragsposition, die beide durch CDC im SQL Server 2008 getrackt werden.

Wenn ein neuer Aufrag erstellt wird, dann erhält die Auftragstabelle einen neuen Eintrag. Die Auftragspositionstabelle bleibt solange leer, bis die dazugehörige Position im ERP erfasst wird.

Im ETL-Prozess werden beide CDC-Quellen mit einander gejoint. Ich habe nun in meiner CDC-Auftragstabelle zwar einen neuen Auftrag stehen, jedoch nicht im meiner CDC-Auftragspositiontabelle. Der Join zwischen beiden Tabellen funktioniert somit nicht. Ein Left-Outer Join ergibt "unvollständige" Datensätze die nicht im Data Mart ge-updated werden können. Nach meinem Verständnis müsste ich mir die "restlichen" Positionsdaten aus der Faktentabelle durch einen Lookup dazu holen. Die Faktentabelle ist mit 55 Mio. Daten nicht ohne. Da möchte ich kein Lookup drauf machen. Das wirkt sich ja verständlicherweise auf die Performanz aus.

In der Literatur heißt das Problem übrigens "CDC-Data Consistency"! Wie kann ich das Problem lösen? gibt es seitens SQL Server Optionen diesbezüglich? Bei Oracle heißt die Lösung dazu "Consistent Set changed Data Capture".

Ich hoffe, das Problem ist verständlich dargestellt. Ich habe mich schwer getan bei der Formulierung des Problems.

Besten Dank schon mal im Voraus und viele Grüße,

Abgoosht

Answer 1

Ein JOIN sollte schon funktionieren, ich habe allerdings gerade keine Instanz zum testen. Du musst allerdings berücksichtigen, das die CDC-Tabellen durch den SQL Agent bzw. Polling mit einem Warteintervall gefüllt werden, d.h. wenn dein ETL-Prozess zu früh startet, kann ich mir schon vorstellen, das noch Daten fehlen.

Was heißt bei dir "unvollständig"?

Answer 2

Hallo Stefan,

"unvollständig" heißt, dass ein Datensatz im DWH, bestehend aus Auftrags- und Auftragspositionsspalten nur Daten in den Auftragsspalten besitzt (da ein Auftrag im CDC getrackt wurde), die Auftragspositionsspalten jedoch "leer" sind, da CDC die dazugehörigen Auftragspositionsspalte noch nicht liefern kann, da diese auch im ERP noch nicht erfasst sind. Ergo, ich müsste mir die Auftragspositionsdaten aus der Faktentabelle holen, da sie nach einem Full-Load dort vorhanden sind.

Beste Grüße,

Abgoosht 

Answer 3

Okay, ich glaube da bin ich auf irgendwo auf der Strecke geblieben:

Wo sollen die Auftragspositionen denn herkommen, wenn sie selbst im ERP nicht erfasst sind?

Answer 4

Hallo Abgoosht,

was macht das für einen Sinn, den Auftragskopf zu berücksichtigen, wenn keine Positionen erfasst wurden?
M. E. sollten diese "unvollständigen" Prozesse doch erst garnicht mittels ETL erfaßt werden.

Ansonsten bliebe Dir nur ein LEFT OUTER JOIN, der aber dann halt zu den von Dir bereits erkannten Problemen führt!

---

Uwe Ricken

MCITP Database Administrator 2005
MCITP Database Administrator 2008
MCITP Microsoft SQL Server 2008, Database Development

db Berater GmbH
http://www-db-berater.de

Answer 5

Hallo Abgoosht,

was macht das für einen Sinn, den Auftragskopf zu berücksichtigen, wenn keine Positionen erfasst wurden?
M. E. sollten diese "unvollständigen" Prozesse doch erst garnicht mittels ETL erfaßt werden.

Ansonsten bliebe Dir nur ein LEFT OUTER JOIN, der aber dann halt zu den von Dir bereits erkannten Problemen führt!

---

Uwe Ricken

MCITP Database Administrator 2005
MCITP Database Administrator 2008
MCITP Microsoft SQL Server 2008, Database Development

db Berater GmbH
http://www-db-berater.de

Hallo Uwe,

das Auftragserfassungssystem speichert z.B. Gutschriften (ohne Position) nur in die Auftragstabelle und synchronisiert nicht mit der Auftragspositionstabelle. Es gibt leider auch Fälle bei dem die Aufragspositionstabelle verändert (update) wird, ohne dass die Auftragstabelle in irgendeinerweise was mitkriegt. Ich verliere deshalb immer wieder Daten.

Anders gefragt: wie würde denn ein Delta-Load Implementierung aussehen? Es gibt doch immer Tabellen die nicht synchron sind aber dennoch mit einander "fachlich" zusammenhängen und somit im ETL auch "gejoint" und erfasst werden müssen? Oder ist das was ich geschildert habe ein Spezialfall?

Danke und beste Grüße,

Abgoosht

Answer 6

Was soll eine Änderung an einer Auftragsposition für eine Relevanz für dem Auftragskop haben? Wenn diese Relevanz gegeben ist, warum wird diese nicht mittels DRI, Triggern oder gespeicherten Prozeduren umgesetzt?

Wie ist den die Abbildung einer Gutschrift im Zielsystem definiert? Auf Grund dieses Beispiels würde ich auf einen "Spezialfall" tippen - ein Gutschein ist halt kein Auftrag. Also der Klassiker: nicht dokumentierte Ausnahmen und/oder Prozesse.

War das Delta-Load nicht ein L(oad)-Schritt? Du musst denke ich deine Daten in der Transformation lediglich entsprechend filtern..

Answer 7

Was soll eine Änderung an einer Auftragsposition für eine Relevanz für dem Auftragskop haben? Wenn diese Relevanz gegeben ist, warum wird diese nicht mittels DRI, Triggern oder gespeicherten Prozeduren umgesetzt?

Da meine Faktentabelle so definiert ist, dass ein Datensatz sowohl aus Auftragskopf als auch aus Auftragspositionsdaten besteht (Granularität Positionsebene), ist ja eine Abhängigkeit gegeben. Wenn sich Positionsdaten ändern, dann muss der Datensatz in der Faktentabelle verändert werden. Da aber der Join eine Schicht vorher den Datensatz erst gar nicht erfasst, kann ich die Faktentabelle nicht aktualisieren.

Wie soll eine gespeicherte Prozedur oder Trigger das Problem lösen können? CDC trackt ständig irgendwelche Kopfdaten. Ich kann ja nicht auf Quellsystemebene nach jedem CDC Eintrag ein trigger starten und die Positionstabellen aktualisieren? Oder ist das anders gemeint?

Danke,

Abgoosht

  

Answer 8

Aufgrund der Definition deiner Faktentabelle musst du - so denke ich - wenn z.B. die Gutschrift rein soll, entsprechend beim Laden wohldefinierte Standardwerte für die Position verwenden. Sollte diese Werte sich nicht definieren lassen, dann kann es daran liegen das eine Gutschrift (als Entität) eben kein Auftrag ist (Äpfel und Birnen). Dann gehört dieser Satz aber auch nicht in diese Faktentabelle und muss eben im Transaktionsschritt heraus gefiltert werden.

Falls diese Definition für die Faktentabelle möglich ist, sollte eine solche Definition auch für deine Auftragspositionstabelle möglich sein. Dann gehört diese Definition eben dort mit DRI, Trigger oder gespeicherten Prozeduren implementiert (das würde dann automatisch dein Ladeproblem lösen).

Answer 9

Aufgrund der Definition deiner Faktentabelle musst du - so denke ich - wenn z.B. die Gutschrift rein soll, entsprechend beim Laden wohldefinierte Standardwerte für die Position verwenden. Sollte diese Werte sich nicht definieren lassen, dann kann es daran liegen das eine Gutschrift (als Entität) eben kein Auftrag ist (Äpfel und Birnen). Dann gehört dieser Satz aber auch nicht in diese Faktentabelle und muss eben im Transaktionsschritt heraus gefiltert werden.

Falls diese Definition für die Faktentabelle möglich ist, sollte eine solche Definition auch für deine Auftragspositionstabelle möglich sein. Dann gehört diese Definition eben dort mit DRI, Trigger oder gespeicherten Prozeduren implementiert (das würde dann automatisch dein Ladeproblem lösen).

Vielen Dank Stefan. Ich werde das ganze nochmal genauer unter die Lupe nehmen müssen.

Frohe Ostertage,
Abgoosht

Answer 10

Vielen Dank Stefan. Ich werde das ganze nochmal genauer unter die Lupe nehmen müssen.

Hallo Abgoosht,

Ich gehe davon aus, dass die Antwort Dir weitergeholfen hat.
Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

Grüße,
Robert

---

Robert Breitenhofer, MICROSOFT 
Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „Entwickler helfen Entwickler“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.