Blobs nur bis 8KB?

[Phoenix]

Äh.. genau:

über die Generischen ADO.NET Interfaces arbeite ich aktuell mit einer Oracle-DB, das könnte aber auch mal ggf. ein SQL-Server werden.

Nun muss ich Blobs in diese Datenbank packen. Das ganze hatte ich schonmal (anderes Projekt) direkt für den SQL Server geschrieben und wollte den nun in dieses Projekt reinziehen und dabei auf die generischen Interfaces umstellen.

Anstelle des alten SqlDbType.Image wollte ich nun DbType.Binary nehmen - nur steht da:

Zitat:

Zitat von Visual Studio

A variable-length stream of binary data ranging between 1 and 8,000 bytes.

Nur sind 8,000 Bytes = 8KB etwas arg wenig. So eine typische Datei für unseren Anwendungszweck hat zwischen 0,5 und 2 MB Größe.

Was tun, sprach Zeus? Sind Blobs mit dem generischen Interface nicht zu handeln? Welcher Datentyp ist korrekt?

[shmia]

BLOBs können bei Oracle bis zu 4 GB aufnehmen.
Normalerweise werden BOLBS ausserhalb von den Tabellen gespeichert.
In der Tabelle steht beim jeweiligen Datensatz nur ein Verweis auf die BLOB-Daten.
Bei manchen DBMS (z.B. MS SQL Server) werden die ersten x Bytes direkt in die Tabelle aufgenommen.
Wenn die BLOB-Daten also kleiner-gleich x Bytes sind, ist der Zugriff dadurch deutlich schneller.
Möglich, dass du deshalb die 8000 Bytes gelesen hast.

[Phoenix]

Hrm? Nochmal: Der Datentyp DbType.Binary - und das steht so auch im MSDN - ist für Binäre Daten bis zu 8000 Byte. Ich habe in solchen Datenfeldern schon Unicode-Texte drin, und die werden bei ~4000 Zeichen abgeschnitten, was in etwa 8000 Bytes entspricht.

Ich weiss sehr wohl, das Oracle BLOBS mehr als 8 KB fassen könne, genauso BLOBS in anderen Datenbanksystemen, aber wie zum Teufel kann ich diese Datenmengen auch in die DB bringen bzw. daraus auslesen wenn ich die Interfaces aus System.Data benutze, die mir nur 8000 Zeichen anbieten? Das kanns doch irgendwie nicht sein?

[Elvis]

Zitat:

Zitat von Phoenix

Hrm? Nochmal: Der Datentyp DbType.Binary - und das steht so auch im MSDN - ist für Binäre Daten bis zu 8000 Byte.

Die Hohlköpfe von MS denken bei einer DB immer zuerst an ihren eigenen kläglichen Versuch ein DBMS zu bauen. ;)
DbType.Binary wird, wenn hinter dem IDbCommand ein OracleCommand steckt, zu einem BLob.

[Phoenix]

Seltsam...

Ich speichere die Daten via Function, damit ich im Programm keine Unterscheidung zwischen Insert und Update machen muss.

Bis 800 KB hab ichs grad probiert, das ging grad noch.

2,5 MB: Upload in die Datenbank ca. anderthalb Minuten.

5 MB: Upload in die Datenbank irgendwas über 4 Minuten.

Jetzt ein 10 MB-File... da sitzt die Anwendung jetzt seit 15 Minuten(!) dran und ich hab abgebrochen.

Das ganze hängt immer bei Command.ExecuteNonQuery. Also das ist echt mal kein Laufzeitverhaltden, was ich einem Kunden zumuten kann. Das Auslesen aus der DB funktioniert übrigens mit jeder Dateigröße relativ Zügig (2-3 Sekunden, dann sind die 7,5 MB aus den beiden großen Files da).

Woran könnte das liegen?

Edit: Update. Urgs. Wenn ich den Oracle Client verwende und nicht den Direct-Modes der Corelab Komponenten sind die 5MB in 30 Sekunden oben. Blöderweise ist Vorgabe, dass auf den Clients der Ora-Client nicht installiert werden darf. Kann man das irgendwie pimpen?

[Elvis]

Zitat:

Zitat von Phoenix

Edit: Update. Urgs. Wenn ich den Oracle Client verwende und nicht den Direct-Modes der Corelab Komponenten sind die 5MB in 30 Sekunden oben.

Deshalb benutze ich den nicht. Ist echt saugeil eine wirklich managed Client Lib für Oracle zu haben, aber da wo Ora spass macht hören dir CR Kompos auf... :cry:

Zitat:

Blöderweise ist Vorgabe, dass auf den Clients der Ora-Client nicht installiert werden darf. Kann man das irgendwie pimpen?

Klicke mal auf meinen User und suche in den Beiträgen nach "Instant client". ;-)


Edit: Der ODP ist bei LOBS nochmal etwa 3-mal so schnell wie der OraClient von MS. Die wollten wahrscheinlich damit verbergen wie abartig lahm der SQL Server mit LOBs umgeht. :mrgreen: