System i Tabelle von PC-Programm lesen

[Joe]

Hallo Forum.

Ich möchte Daten aus einer grossen System i Tabelle in einem Delphi-Programm verarbeiten. d.h. mit System i verbinden und per SQL-Anweisung Daten selektieren. Welche Möglichkeiten gibt es um grosse Datenmengen (10 Mio Sätze) in akzeptabler Zeit komplett zu lesen? ODBC scheidet hier wohl aus?
Wie performant sind Dataqueue's?

Danke für Eure Hilfe.

Joe

[BenderD]

... wieso scheidet ODBC hier aus? Wobei es natürlich Sinn macht, alles, was geht ins SQL zu verlagern. Dann müssen natürlich die Zugriffspfade, die benötigt werden da sein und bei manchen Konstellationen kann es günstig sein Subsets zu ziehen und die weiter zu verarbeiten.

D*B

Hallo Forum.

Ich möchte Daten aus einer grossen System i Tabelle in einem Delphi-Programm verarbeiten. d.h. mit System i verbinden und per SQL-Anweisung Daten selektieren. Welche Möglichkeiten gibt es um grosse Datenmengen (10 Mio Sätze) in akzeptabler Zeit komplett zu lesen? ODBC scheidet hier wohl aus?
Wie performant sind Dataqueue's?

Danke für Eure Hilfe.

Joe

[andreaspr@aon.at]

Die Frage die mich persönlich interessieren würde wäre: Warum benötigst du 10 Mio. DS in ein Delphi-Pgm zu laden?
Wenn dus mit ODBC machen solltest, kann ich dir bei solch einen Aufwand nur den Aufruf einer Stored Procedure empfehlen! Eventuell beim ODBC-Treiber die Kompression einschalten. Bilde mir ein, dass dies Performance bringt, sollte aber Standard sein.

[BenderD]

... die Frage der 10 Mio Sätze stellt sich immer, unabhängig von ODBC. Wenn der Transfer eines Einzelsatzes in ein Programm 1 millisec. dauert, sind das bei 10 Mio 1000 sec was ca. 15 min sind. Mit Blockung kann man das in den sec. Bereich drücken, wenn keine Updates erforderlich sind. Bei der Verlagerung von Gruppenwechsel und Summierung ins SQL ist das ähnlich, wie bei Blockung. Bessere Hardware halbiert die Zahlen, die ODBC Strafe liegt bei maximal 100%, das mit der Blockung klappt meist nicht, weil da Treiber, die ODBC verwendende Umgebung und das Netzwerk mitspielen müssen. Stored Procedure und das ganze andere Gedöns (DataQ etc) bringen nur was, wenn man dadurch geblockt lesen kann und keine updates hat.

D*B

Die Frage die mich persönlich interessieren würde wäre: Warum benötigst du 10 Mio. DS in ein Delphi-Pgm zu laden?
Wenn dus mit ODBC machen solltest, kann ich dir bei solch einen Aufwand nur den Aufruf einer Stored Procedure empfehlen! Eventuell beim ODBC-Treiber die Kompression einschalten. Bilde mir ein, dass dies Performance bringt, sollte aber Standard sein.

[Joe]

Die Frage die mich persönlich interessieren würde wäre: Warum benötigst du 10 Mio. DS in ein Delphi-Pgm zu laden?
Wenn dus mit ODBC machen solltest, kann ich dir bei solch einen Aufwand nur den Aufruf einer Stored Procedure empfehlen! Eventuell beim ODBC-Treiber die Kompression einschalten. Bilde mir ein, dass dies Performance bringt, sollte aber Standard sein.

Hallo Andreas.
Danke für die Hinweise.

zu Deiner Frage: Die Daten werden in eine Firebird-Datenbank geladen um dort für einen DATACUBE zur Verfügung zu stehen. Und der Kunde WILL das so...

[Fuerchau]

Mit ODBC ist das auf jeden Fall am einfachsten und auch am schnellsten.
Eine DTAQ ist nicht möglich, da deren Größe auf 16MB beschränkt ist!
Außerdem verkompliziert dies ungemein.

Wichtig dabei ist auf jeden Fall, einen Server-Cursor anzugeben, da ansonsten ADO erst mal den gesamten Inhalt in den Speicher zieht und ob der dabei ausreicht...
Die Komprimierung spielt dabei sogut wie keine Rolle.

Beim Schreiben in die Firebird schaffe ich bei einem 3GHz-Pc ca. 100 Sätze pro Sekunde. Du benötigst also ca. 28 Stunden dafür.
Wichtig ist also, ggf. Wiederaufsetzpunkte zu definieren und Commit-Abgrenzungen zu finden.

[BenderD]

... hab ich mich doch um Faktor 10 verrechnet...
bei 28 Stunden würde ich mal über einen CPYTOIMPF und FTP nachdenken - das muss man doch irgendwie geladen kriegen (nbackup ?)

D*B

Mit ODBC ist das auf jeden Fall am einfachsten und auch am schnellsten.
Eine DTAQ ist nicht möglich, da deren Größe auf 16MB beschränkt ist!
Außerdem verkompliziert dies ungemein.

Wichtig dabei ist auf jeden Fall, einen Server-Cursor anzugeben, da ansonsten ADO erst mal den gesamten Inhalt in den Speicher zieht und ob der dabei ausreicht...
Die Komprimierung spielt dabei sogut wie keine Rolle.

Beim Schreiben in die Firebird schaffe ich bei einem 3GHz-Pc ca. 100 Sätze pro Sekunde. Du benötigst also ca. 28 Stunden dafür.
Wichtig ist also, ggf. Wiederaufsetzpunkte zu definieren und Commit-Abgrenzungen zu finden.

[Fuerchau]

Ggf. geht das in Firebird mit dem Zugriff auf "externe Tabellen", die man dann mit einem "Insert into select from" ggf. schneller geladen bekommt:

Use the

EXTERNAL FILE option to:

Import data from a flat external file in a known fixed-length format into a new or existing
InterBase table. This allows you to populate an InterBase table with data from an external
source. Many applications allow you to create an external file with fixed-length records.

SELECT from the external file as if it were a standard InterBase table.

Export data from an existing InterBase table to an external file. You can format the data
from the InterBase table into a fixed-length file that another application can use.

Restrictions

The following restrictions apply to using the

EXTERNAL FILE option:

You must create the external file before you try to access the external table inside of the
database.

Each record in the external file must be of fixed length. You cannot put BLOB or array
data into an external file.

When you create the table that will be used to import the external data, you must define
a column to contain the end-of-line (EOL) or new-line character. The size of this column
must be exactly large enough to contain a particular system’s EOL symbol (usually one
or two bytes). For most versions of UNIX, it is 1 byte. For Windows, NT, and NetWare, it
is 2 bytes.

While it is possible to read in numeric data directly from an external table, it is much
easier to read it in as character data, and convert using the CAST() function.

Data to be treated as VARCHAR in InterBase must be stored in an external file in the
following format:

<2-byte unsigned short><string of character bytes>

where the 2-byte unsigned short indicates the number of bytes in the actual string, and
the string immediately follows. Because it is not readily portable, using

VARCHAR data in
an external file is not recommended.

You can only INSERT into and SELECT from the rows of an external table. You cannot

UPDATE

or DELETE from an external table; if you try to do so, InterBase returns an error
message.

Inserting into and selecting from an external table are not under standard transaction
control because the external file is outside of the database. Therefore, changes are
immediate and permanent—you cannot roll back your changes. If you want your table
to be under transaction control, create another internal InterBase table, and insert the
data from the external table into the internal one.

The following steps describe how to import an external file into an InterBase table:
1. Create an InterBase table that allows you to view the external data. Declare
all columns as

CHAR. The text file containing the data must be on the server.
In the following example, the external file exists on a UNIX system, so the
EOL character is 1 byte.

CREATE TABLE EXT_TBL EXTERNAL FILE 'file.txt'
(FNAME CHAR(10),
LNAME CHAR(20),
HDATE CHAR(8),
NEWLINE CHAR(1));
COMMIT;

2. Create another InterBase table that will eventually be your working table. If
you expect to export data from the internal table back to an external file at a
later time, be sure to create a column to hold the newline. Otherwise, you do
not need to leave room for the newline character. In the following example,
a column for the newline is provided:

CREATE TABLE PEOPLE
(FIRST_NAME CHAR(10),
LAST_NAME CHAR(20),
HIRE_DATE CHAR(8),
NEW_LINE CHAR(1));
COMMIT;

3. Create and populate the external file. You can create the file with a text
editor, or you can create an appropriate file with an application like Paradox
for Windows or dBASE for Windows. If you create the file yourself with a text
editor, make each record the same length, pad the unused characters with
blanks, and insert the EOL character(s) at the end of each record.

Note

The number of characters in the EOL is platform-specific. You need to know how
many characters are contained in your platform’s EOL (typically one or two) in order to
correctly format the columns of the tables and the corresponding records in the external
file. In the following example, the record length is 36 characters. “b” represents a blank
space, and “n” represents the EOL:

123456789012345678901234567890123456
fname.....lname.............hdate..n

CHAPTER 6 WORKING WITH TABLES

110

INTERBASE 6

------------------------------------
RobertbbbbBrickmanbbbbbbbbbb6/12/92n
SambbbbbbbJonesbbbbbbbbbbbb12/13/93n

4. At this point, when you do a

SELECT statement from table EXT_TBL, you will
see the records from the external file:

SELECT FNAME, LNAME, HDATE FROM EXT_TBL;
FNAME LNAME HDATE
======== ================= ===========
Robert Brickman 12-JUN-1992
Sam Jones 13-DEC-1993

5. Insert the data into the destination table.

INSERT INTO PEOPLE SELECT FNAME, LNAME, CAST(HDATE AS DATE),
NEWLINE FROM EXT_TBL;

Now if you

SELECT from PEOPLE, the data from your external table will be there.

SELECT FIRST_NAME, LAST_NAME, HIRE_DATE FROM PEOPLE;
FIRST_NAME LAST_NAME HIRE_DATE
========== =================== ===========
Robert Brickman 12-JUN-1992
Sam Jones 13-DEC-1993

InterBase allows you to store the date as an integer by converting from a CHAR(8) to
DATE using the

CAST() function.

[holgerscherer]

Hallo Forum.

Ich möchte Daten aus einer grossen System i Tabelle in einem Delphi-Programm verarbeiten. d.h. mit System i verbinden und per SQL-Anweisung Daten selektieren. Welche Möglichkeiten gibt es um grosse Datenmengen (10 Mio Sätze) in akzeptabler Zeit komplett zu lesen? ODBC scheidet hier wohl aus?

10Mio Sätze sind nicht wirklich groß. Und ja, das geht sogar mit Delphi5 und ODBC performant. Kommt halt drauf an, was man treibt. Wenn Du die gesamte Verarbeitung auf dem PC machen willst (warum auch immer), hast Du auf jeden Fall eine Menge Datentransfer.

-h

[holgerscherer]

zu Deiner Frage: Die Daten werden in eine Firebird-Datenbank geladen um dort für einen DATACUBE zur Verfügung zu stehen. Und der Kunde WILL das so...

Das sind immer wieder die Momente, in denen man Religiös werden könnte, um danach wenigstens wieder gleich vom Glauben abzufallen.

Wenn der Kunde das so will und auch kriegt, hat er entweder einen schlechten Berater, oder ganz andere gute Gründe, warum er sich mit solch kruden Datenverwurstelungen beschäftigen will.

-h

[UFK]

Also wenn man die Tabelle (es ist doch nur eine) auf einem PC anlegt, und mit FTP übers lkale Netz abzieht, sollte das in rund einer Stunde gelaufen sein, auch bei ur 100 MBit. 10 Mio ist ja wirklich nicht viel ...

Wir haben das auch gemacht, aber mit etwa 100 Tabellen, und obendrein übers Internet, um das Zeug dann in einem COGNOS-Datawarehouse nachzubilden. Das ganze ist natürlich eher ein Job von 2-3 Monaten, bis man alles adequat übersetzt hat, bis man Adaptoren usw. geschaffen hat, so daß das Data-Warehouse dann z.B. monatlich die Geschäftsanalysen bieten kann, auf Knopfdruck bzw. Klick in einem Cube mit z.B. 10-20 Dimensionen.

Ich hätte es auch gern selber auf der AS400 gemacht, aber da gab es dann andere Spezialisten für, mit besonderem Skill, mit mehr Zeit, und mit eingefahrenen Prozessen ...

Wenn man den Anbietern vertraut, ist das sozusagen Cloud-Computing

... wieso scheidet ODBC hier aus? Wobei es natürlich Sinn macht, alles, was geht ins SQL zu verlagern. Dann müssen natürlich die Zugriffspfade, die benötigt werden da sein und bei manchen Konstellationen kann es günstig sein Subsets zu ziehen und die weiter zu verarbeiten.

D*B

Ja, möglichst auf der AS400 selektieren lassen, und dann nur das Ergebnis mit ODBC, JDBC oder eben FTP transferrieren.

Ich hatte damals übrigens überlegt, eine DB2 auf einem kleinen süssen Linux-Rechner zu installieren, und hatte gehofft, daß diese universal DB2 gut mit der DB2/400 kooperieren könnte. Hat jemand mal sowas durchkonstruiert ?