PDA

Vollständige Version anzeigen : Datentausch zw. DB/2 und A00


Hütti
09.08.2001, 13:37
Hallo.

Wir haben in der Firma eine DB/2 auf einer AS/400 und A00 als Frontend. Z.Z. machen wir Auswertungen, indem wir die Daten per ODBC importieren. Es läuft ein Novell-Server an der AS/400.
Frage dazu: Ist das der schnellste / beste Weg? Kann man die Performance irgendwie erhöhen? z.B. Direkte Anbindung an AS/400. Was muß man beachten?

Danke für jeden brauchbaren Tip.

Oliver

erwin
09.08.2001, 14:07
bei CA/400 (ClientAccess/400 von IBM) ist doch ein ODBC-Treiber, als auch die nötige Anleitung dabei ?!

Alternativ sind ev. auch die Prod. von Attachment (Extra/400) empfehlkenswert.

so long erwin...

Hütti
09.08.2001, 14:21
hallo erwin,

den weg über ca (odbc) nutzen wir ja auch...
ist aber sehr langsam... wir arbeiten teilweise mit bis zu 400.000 datensätzen. wenn man da zwei tabellen direkt verknüpft geht das voll in die hose. daher laden wir immer erst alle daten herunter, um dann die abfrage zu starten. mit besserer performance könnte man aber evtl. direkt abfragen erstellen, was speicherplatz sparen würde.

oliver

Hütti
09.08.2001, 14:23
ach ja,

was ist extra/400???

oliver

Nockenwelle
09.08.2001, 18:39
Hallo Hütti,

die DB fängt an zu streiken, vor allem wenn du lokale Tabellen mit Tabellen auf der AS400 verknüpfst. Wenn du dann noch irgendwelche sortierfunktionen benötigst, kannst du eh' ins Wochenende gehen.
Da kann man aber viel dran drehen.
Kommt zusätzlich immer drauf an, wie dein zu erwartendes Ergebnis aussieht

Bei einfachen Abfragen kann man z.B. die Abfrageeigenschaft auf Snapshot stellen, das geht ohnehin sehr viel schneller. Gerade die LOCKs bremsen die Abfragegeschwindigkeit aus.

Hast du komplexere Sachen, ist eine Möglichkeit

- Du splittest die Abfragen auf mehrere kleine. In VBA machst du dann aus beiden Abfragen jeweils ein recordset und übergibt das ergebnis der ersten Abfrage(bzw. recordset) an das zweite.
Beispiel: Ich habe eine Charge mit Chargennummer(Tab1). jede Charge enthält 500 Datensätze(Tab2). Also ne typische 1:n Verknüpfung.
Wenn ich alle Datensätze der Charge XY rausbekommen will ermittel ich aus der Tab1 zuerst die eigentliche Chargenid.
Die ID übergebe ich dann als Abfragkriterium an Tab2, ohne dass ich dann einen Join brauche.

- Du verwendest SQL-Path-through Abfragen
Die haben den Vorteil, dass sie oft sehr schnell sind. Allerdings kannst du nur Abfragen verwenden, die Ausschließlich auf dem Server laufen. D. h. du musst die SQL-Statements so umschreiben, das der Optimizer sie verarbeiten kann. Eckige Klammern, Semikolon am Ende des SQL und Access-Eigene Funtionen kannst du dann nicht mehr verwenden. Beispielsweise ist Access die einzige DB, die keine Fehlermeldung bringt, wenn im Statement steht 'where irdendwas=NULL'. Außerdem erwarten manche DB's bestimmte Formatierungen der Datumsfunktionen. Bei DB2 weiß ich das nicht genau.


Ich hab' hier ein paar Beispiele. Meld dich wenn du Sie brauchst. Die sind zu lang zum Posten.

Cu

Günni
09.08.2001, 21:08
Nockenwelle hat natürlich recht, aber ;) ... wenn Du einen wirklichen Performance-Gewinn haben willst, wirst Du um eine grundsätzliche Verbesserung der Kommunikation zwischen der MS-Welt und der AS400-Welt nicht herum kommen. Das Mittel der Wahl ist in dem Fall der sog. "Microsoft Host- and Integration-Server". Diese Software (oder die Vorgängervariante für NT, der SNA-Server) ist speziell für die Einbindung von Großrechnern in die Microsoft-Umgebung geschaffen worden. Beide Produkte stellen dann nicht nur eine ODBC-Verbindung zur Verfügung sondern auch eine ADO-Schnittstelle und damit dann doch einen deutlichen Geschwindigkeitsschub.

Wenn Du auf direkte Live-Daten verzichten kannst und Dir statt dessen der Datenbestand des Vortages reicht, kann es auch sinn machen, die DB/2-Daten über Nacht z. B. in eine SQL-Server-Datenbank zu spiegeln und dann auf diese Daten zuzugreifen. Für die meisten Data-Ware-House-Anwendungen ist diese Vorgehensweise auch vollkommen ausreichend.

Wenn Du mir ein paar Hintergrund-Infos mehr gibst, kann ich Dir vielleicht noch bessere Tips geben ... vielleicht fällt uns ja auch noch ne ganz andere Lösung ein.

<hr>

<font color="#808080" size="2" face="Arial"><strong>Mühldorfer Günter
Computer- und Software-Service
</strong></font>
mg@mgcss.de
<a href="http://www.mgcss.de">www.mgcss.de</a>

Nockenwelle
09.08.2001, 22:16
Hi Günni,

das mit dem 'Über Nacht' hab' ich weit hinter mir. Ich kombinier halt diese Funktionen mehr oder weniger geschickt. Mal eben Stammdaten(ca. 120000 Adressen) zu laden, brauch ich 5 - 10 Minuten(über eine 2 MB Standleitung).
Das muss ich schon mal machen, da der Rechner halt entfernt steht, und meine Ergenismenge oft sehr groß ist. Ich suche falsche Kundennummern und Daten, direkt innerhalb eines Ortes der PLZ und nach Sequenzen gleichzeitig, die richtig sein könnten-das gibt dann eine Ergebnismenge von bis zu 5000 Adressen bei einem Klick. Geht nur Lokal. Ich kann ja nicht permanent die Leitung lahm legen.

Für kleinere Ergebnismengen wäre ich dir für Infos zum "Microsoft Host- and Integration-Server" sehr dankbar. So schlecht ist die Ladezeit mit 5 Abfragen über die 120000, sowie 6 Abfragen über ein schwer zu optimierendes Tabellenkonstrukt(ist ne externe Anwendung, hat eine 'bewegliche' Verknüpfung-ich lass mich da besser nicht drüber aus) nicht. 5-15 Sekunden.
Bei einigen Auswertungen ist das sogar sehr schnell, da ich ziemlich gnadenlos die Eigenschaften von Access ausnütze, welches viele Daten vom Snapshot in den Hauptspeicher legt. Da komm ich, obwohl es ein entfernter Rechner ist auf sehr gute Zeiten(einige tausend findfirst in weniger als einer Minute).
Aber ADO würd mich interessieren. Wieviel kannst du da noch rausholen?

Cu

Hütti
10.08.2001, 08:00
hallo nockenwelle,

danke für den tipp.
snapshot kein thema, aber was meinst du mit den LOCKs?
im übrigen verfahre ich ähnlich, wei du beschrieben hast. die daten werden runtergeladen, dann eine ergebnismenge erzeugt und anhand derer erst wieder die daten der nächsten tabelle, usw...

mit den spt-abfragen arbeite ich auch, allerdings nur in einfacher form (know-how fehlt). ich erstelle darüber lediglich die verbindung zur db/2, in der form, das ich mit SELECT felder, felder,... FROM Tabelle WHERE xxx eine reduzierte feld- und datensatzauswahl treffe. obendrauf kommt dann eine tab-erstellungsabfrage, die die daten einliest. ich werde das gefühl aber nicht los, das das eigentlich anders gedacht ist, oder? deine beispiele würden mich interessieren, sind die auf eine db/2 bezogen oder auf einen sql-server?

danke oliver

Hütti
10.08.2001, 08:13
hallo günni,

danke für die info. die sache mit dem Micro-Int-Server klingt nach so etwas, was ich suche.
die geschichte mit den über-nacht-speigelungen praktizieren wir zum großteil; leider noch nicht auf einen sql-server, sondern nur in einzelne a00-dbs; erfüllt aber einen ähnlichen zweck.
live-daten brauchen wir z.t. auch. für das controlling sind die vortagesdaten aktuell genug. in den produktionsbereichen benötigen wir leider die echtdaten, und dort sind manchmal auch 2-3 min abrufzeit fast schon zu lange.

wie gesagt, in erster linie interessiert mich die sache mit dem Micro-Int-Server. kannst du mir die sache näher erklären?

Nockenwelle
10.08.2001, 10:05
Hi Hütti,

versuch es doch mal so. Du hälst dir lokal eine identische Zieltabelle vor, und dann


Set qrypaththrough = dbs.CreateQueryDef("")

qrypaththrough.Connect = Connectionstring
qrypaththrough.sql = sql
qrypaththrough.ReturnsRecords = True
Set rstcheck2 = qrypaththrough.OpenRecordset(, dbOpenSnapshot)

While Not rstcheck2.EOF
rstBGSUNS.AddNew
For Each fld In rstcheck2.Fields
rstBGSUNS(fld.Name).Value = rstcheck2(fld.Name).Value
Next
rstBGSUNS.Update
rstcheck2.MoveNext
Wend


rstbgsuns ist meine Zieltabelle, sql ist ein Statement
Den Connectionstring kannst du aus einer eingebundenen Tabelle entnehmen. Sieht bei mir so aus:

Global Const Connectionstring = "ODBC;DSN=DEINEDSN;SERVER=DEIN_ODBC_KNOTEN;DATABASE=DEINEDB;uid=User;pwd=passwort ;SERVERTYPE=INGRES;;"

Geht meines erachtens schneller, als eine Tabellenerstellungsabfrage, dann bekommst du wahrscheinlich dein Problem mit den LOCKs(Sperren der Datensätze ober Pages, im schlimmsten Fall der ganzen Tabelle). D.h. der Snapshot verliert seine Wirkung, da eine Tabellenerstellungsabfrage immer ein Dynaset ist.


Cu

Hütti
10.08.2001, 12:32
hallo nockenwelle,

danke für den tip, ist aber leider nicht so effektiv :-( habe den abruf getestet. mti deiner variante dauert eine tabelle 6:42 min, mit einer anfügeabfrage, die auf einer tabellenverknüpfung über odbc basiert nur 2:00.... ist aber auch kein wunder meiner meinung nach. unsere tabellen sind in der regel sehr "breit" (min. 25 spalten, bis zu 120 spalten). die getestete tabelle hatte 33.000 datensätze und 52 felder...
mit deiner methode fügt er ja jede zelle einzeln an und durchläuft die schleife 1,7 mio mal... :-(

oliver

Nockenwelle
10.08.2001, 13:52
Hi,

wundert mich ein bißchen. An der Schleife liegt es nicht, die wird ziemlich schnell durchlaufen und erst wenn der DS komplett eingelesen wird, erfolgt das update. Ich hab' bei mir dadurch den Import 2er Tabellen(Jeweils ca 40 Spalten fast alles Text, insgesamt ca. 15000 DS) von 2-3 Minuten auf 10-12 Sekunden bekommen. Ich hab' bei mir allerdings die ODBC-Einstellungen auf dem Client nicht nach dem Standard gesetzt.
Bei Ingres heißt das 'Select Cursors' und ist in den Zusatzeinstellungen des ODBC-Treibers drin. Außerdem wurde der client durch folgende Einstellungen angepaßt:

ingsetenv ING_SET "set lockmode session where level=row,readlock=nolock,maxlocks=50,timeout=30"
Das ist zwar jetzt für Ingres, aber sowas müsste es bei dir auch geben. Schau mal bei der Beschreibung oder in der Hilfe nach.

Cu

erwin
11.08.2001, 10:26
bzgl. OLE-DB (ADO) siehe auch hier: http://www.dcsoft.de/katalog/HITODB.htm

wobei ich dir aus eig. Erfahrung nicht sagen kann, ob ADO tatsächlich schneller ist als ODBC (mit Passthrough). (würde mich aber von Günni interessieren, ob er da selbst Perf.Tests gemacht hat ?!)

Sorry bgl. Extra/400 Tippfehler im Firmennamen siehe: http://www.attachmate.de

so long erwin...

Nockenwelle
12.08.2001, 03:46
Mir fiel jetzt noch was ein.

Du hast das wahrscheinlich im debug-Fenster ausgeführt.
Ein debug.print o.ä. bremsen deinen Rechner mehr aus als alles andere.

Cu

Hütti
13.08.2001, 09:49
ne, um gottes willen.
der schreibt die daten direkt in eine datei; genau wie du beschrieben hast.

spielt es eine rolle, wie ich die variablen deklariere, bzw. wie der connectstring aussieht???