Ansi-Join provoziert Fehler

[jobo]

Meine Theorie ist:
- offensichtlich kein "ORA-" Fehler, also ein Treiberproblem (OLEDB)
- Die Joinvarianten, die Du produzierst, sind nur der Auslöser, da sie
- vermutlich durch andere Ausführungspläne bzw. in einem Fall anderes Select Statement
-> andere Daten ausspucken
Da liegt dann der Hase im Pfeffer.
Der Treiber hat ein Problem mit den Daten.

Typischerweise sind das Date Werte vor Christi Geburt usw.

Vielleicht kannst Du das durch eingrenzen des selects nachvollziehen. Es müsste demzufolge ein Single Table Select reichen (ohne Join) um das Problem zu reproduzieren. (wenn man die fehlerhaften Daten erwischt)

Seit ich auf Oracle OLEDB umgestiegen bin (glaub aktuell Version 11.2 bei mir) hab ich sowas (Treiberprobleme mit Dateninhalten) allerdings nicht mehr erlebt.

P.S.: Hab grad erst die "OraOLEDBrst11.dll" im Post endeckt. Also 11er Oracle OLEDB Client?
Ist schon etwas her, aber ich erinner mich, dass ich "damals" den Instant Client 11.2 vorinstalliert habe und den OLEDB Teil aus den älteren "ODAC" Komponenten nachinstalliert. Um eben halt so aktuell wie möglich zu sein. Mittlerweile dürfte es ja wesentlich aktuellere Treiber geben.

[p80286]

Nee die Datenwerte aus der Steinzeit hab ich auch schon mal gehabt, das ist es nicht.
Es liegt einzig an dem "select Tab3.*" be dem ein Feld aus Using mit ausgegeben wird (werden sollte)
bloß gibts dann normalerweise einen richtigen ORA.Fehler.

Gruß
K-H

[Jumpy]

Und was ist wenn "using(idkey)" durch "on tab1.idkey=tab2.idkey" ersetzt wird?

[jobo]

Zitat von p80286:

Nee die Datenwerte aus der Steinzeit hab ich auch schon mal gehabt, das ist es nicht.
Es liegt einzig an dem "select Tab3.*" be dem ein Feld aus Using mit ausgegeben wird (werden sollte)
bloß gibts dann normalerweise einen richtigen ORA.Fehler.

Gruß
K-H

Wenn Du das schon weißt, was ist dann die Frage?
Das Tab3.* hat mit dem using eigentlich nichts zu tun, denn das using bezieht sich auf den Join von tab1 und tab2, während tab3 einen expliziten "on " Join hat (und das Asterisks gemurkse vom using nicht relevant sein dürfte). Daher dürften die komischen Feld Selektor Alias Automatismen (ich find sowas furchtbar) nicht greifen. Hat aber vielleicht irgendjemand bei Oracle selbst nicht verstanden und falsch programmiert.
Aber vielleicht hab ich es auch nicht verstanden

@Mikal: Ist das etwa Humor hier in der DP?!

[Bernhard Geyer]

Zitat von p80286:

Nee die Datenwerte aus der Steinzeit hab ich auch schon mal gehabt, das ist es nicht.
Es liegt einzig an dem "select Tab3.*" be dem ein Feld aus Using mit ausgegeben wird (werden sollte)
bloß gibts dann normalerweise einen richtigen ORA.Fehler.

Bei Oracle sollte man mit allem rechnen!
Während meiner Studienzeit hat es ein Mitkommilitone geschafft durch eine Select-Anweisung das ganz Uni-Netz lahm zu legen (ok, der Server auf dem die Oracle-DB lag war nicht nur DB-Server).

[jobo]

@Bernhard: Hast Du eigentlich irgendeinen Schwur gegen Oracle geleistet? Waren "sie" böse zu Dir?
Wie lang ist das her mit dem Studienkollegen?

Man braucht nur einen Join zu vergessen und die Datenbank permutiert durch die Gegend, da muss jede Datenbank ackern.

[Bernhard Geyer]

Zitat von jobo:

@Bernhard: Hast Du eigentlich irgendeinen Schwur gegen Oracle geleistet? Waren "sie" böse zu Dir?
Wie lang ist das her mit dem Studienkollegen?

Dieser Fehler: ca. 20 Jahre

Zitat von jobo:

Man braucht nur einen Join zu vergessen und die Datenbank permutiert durch die Gegend, da muss jede Datenbank ackern.

Bei jeder verfünftigen DB killt man einfach den Prozess der das Problem verursacht und gut ist. Nicht so hier bei Oracle.

Und einen "schwur" braucht man bei Oracle nicht. So oft wie man schon bei Oracle unnachvollziehbare Performanceprobleme hat. Ab und zu bringt es wenn der Server eh durch eine neuere Version aktualsiert werden. Ab und zu muss man praktisch den DB-Inhalt rauspumpen und die DB platt machen bis es wieder geht. Das erschreckende ist auch öfter das die Oracle-Admin (die sich oft als die Elite der DB-Admins ansieht) absolut kein Fachwissen von DB-Interne und gerade noch ihre Standardreports abrufen können die sie bei ihren nicht gerade billigen Oracle-DB-Schulungen durchgenommen haben.

[jobo]

20 Jahre! Da erübrigt sich eigentlich jeder Kommentar.
Dennoch, rechne ca. 10 Jahre drauf, zu der Zeit haben MS SQL Anwendung noch Probleme mit Rowlevel Locking gehabt.

Man braucht da auch gar nicht über verschiedene Anbieter die Nase zu rümpfen. Es reicht falsche Transaktionsverwaltung in der Anwendung und keine DB hat ne Chance, das ist mit Sicherheit kein Admin Problem.
Die Art und Weise, wie sich Schulungsinhalte oder-vorgehen entwickelt haben, reicht auch keinem Anbieter zur Ehre, es geht nur ums Geld verdienen.

Oracle Datenbanken hatten und haben nach meiner Meinung technologisch die Nase vorne. Nicht mehr und nicht weniger. Wahrscheinlich sind sie auch deswegen am komplexesten in der Administration. Ich hatte bereits das "Vergnügen" Terrabyte Systeme zu verwalten- ohne Admin Titel. Die von Dir genannte "Tuning" Technik ist da einfach aus Platzgründen nicht ohne weiteres möglich, ganz abgesehen von der Tatsache, dass sich sowas bei einem 24x7 System von allein verbietet.

Ganz anders sieht die Sache schon bei anderen Oracle Produkten aus. Und bei Oracle-Produkten in der Microsoftwelt merkt man immer wieder, dass es nicht ihre ist. Im übrigen ist es so, dass jedes Software-System eine Geschichte hat, die es idR nicht verleugnen kann. "Best practise" ist hierzu ein schönes (Microsoft- glaub ich) Stichwort. Wenn man ein System so nutzt, wie es gedacht ist, fährt man am besten. (Hier wäre man vermutlich irgendwie wieder beim Thema des Threads angelangt, ANSI Joins sind bei Oracle erst spät(er) angeflanscht worden und ich verwende sie nur, wenn der Oracle Style zu umständlich wäre)

[Bernhard Geyer]

Zitat von jobo:

20 Jahre! Da erübrigt sich eigentlich jeder Kommentar.

Dieser Fehler war 20 Jahre her. Viele andere Fehler bei denen wir viel zeit investieren mussten un auch inkompetente Oracle-Admins belehren musste waren aus 2013!

Zitat von jobo:

Dennoch, rechne ca. 10 Jahre drauf, zu der Zeit haben MS SQL Anwendung noch Probleme mit Rowlevel Locking gehabt.

Also der MS SQL Server ist seit 2000 ganz gut. Davor war er ja primär ein umgelabeltes Zukaufprodukt.

Und nach den Erfahrungen die wir in den Jahren habe sind mir 10 MS SQL-Server-Installationen lieber als eine Oracle-Installation.

Zitat von jobo:

Man braucht da auch gar nicht über verschiedene Anbieter die Nase zu rümpfen. Es reicht falsche Transaktionsverwaltung in der Anwendung und keine DB hat ne Chance, das ist mit Sicherheit kein Admin Problem.

Die Probleme die wir hatten war keine Fehlerhafte Transaktionsverwaltung sondern 1a eine Oracle-Problem. Die gleiche DB auf unseren Oracle-Server - Kein Problem. Auf Kundenserver: Schnarchlangsam und selbst in den Statistiken war das Problem nicht ersichtlich. Die Oracle-DB hat sehr oft Full-Table-Scans gefahren obwohl problemlos ein Index/der Primärindex verwendbar wäre. Ein paar Fehler konnten wir "lösen" indem der Kunde einfach (im Rahmen seiner Serveraktualisierung) einfach eine neuen Server mit neuer Installation aufgesetzt hat.

Zitat von jobo:

Oracle Datenbanken hatten und haben nach meiner Meinung technologisch die Nase vorne. Nicht mehr und nicht weniger. Wahrscheinlich sind sie auch deswegen am komplexesten in der Administration. Ich hatte bereits das "Vergnügen" Terrabyte Systeme zu verwalten- ohne Admin Titel. Die von Dir genannte "Tuning" Technik ist da einfach aus Platzgründen nicht ohne weiteres möglich, ganz abgesehen von der Tatsache, dass sich sowas bei einem 24x7 System von allein verbietet.

Terrabyte-System dürften wir auch haben (jedoch noch nicht in der DB sondern wenn man die Daten außerhalb der DB mitzählt).
Leider denken manche Firmen: Wir haben Oracle, die Admins sind geschult. Wenn es Probleme gibt muss es die Kauf-Software sein.
Dann ist es immer sehr zeitaufwändig die Entscheidungsträger zu überzeugen das das Problem auf Ihrer Seite gibt. Vor allem wenn die Admins irgendwelche Statistiken ins Feld führen die gar nix mit dem Problem zu tun haben.

Zitat von jobo:

Ganz anders sieht die Sache schon bei anderen Oracle Produkten aus. Und bei Oracle-Produkten in der Microsoftwelt merkt man immer wieder, dass es nicht ihre ist.

Das fängt schon bei den Admin/SQL-Tools zur DB an. Glücklicherweise hat Oracle mit den Instant-Client eine Lösung wo man sein Client-System nicht mit irgendwelche GB-Großen Clientinstallern verseuchen muss.

Zitat von jobo:

Wenn man ein System so nutzt, wie es gedacht ist, fährt man am besten. (Hier wäre man vermutlich irgendwie wieder beim Thema des Threads angelangt, ANSI Joins sind bei Oracle erst spät(er) angeflanscht worden und ich verwende sie nur, wenn der Oracle Style zu umständlich wäre)

Schlechtes Beispiel. Oracle unterstütz seit 9i ANSI/ISO-Join-Syntax. Und wenn sie das unterstützen sollen sie das gefälligst auch Fehlerfrei machen!
ANSI-Join sind auch besser verständlich wenn man Einschränkungen dort definieren kann wo sie hin gehören: An den JOIN!