Ansi-Join provoziert Fehler

[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!

[Bernhard Geyer]

Zitat von p80286:

Hallo zusammen

hier ist ja schon öfter mal über ANSI-Joins Ja oder Nein diskutiert worden, mit folgender Abfrage habe ich dann folgenden Fehler provozieren können:

Code:

select tab1.Feld1,tab2.Feld2,Tab3.*
from tab1 join tab2 using (idkey)
          join tab3 on (tab2.seckey=tab3.objectkey)
where ....

Zitat:

Im Projekt XXX ist eine Exception der Klasse EAccessViolation mit der Meldung 'Zugriffsverletzung bei Adresse 4440F60B in Modul 'OraOLEDBrst11.dll'. Lesen von Adresse ABABABAB' aufgetreten.

Wohlgemerkt, es kommt keine ORACLE-Fehlermeldung, das ein Qualifier nicht genutzt werden darf.

Hast du mal probiert dieses SQL-Statement direkt mit dem SQL+ oder den Oracle-Developer abzuschicken?
Was passiert wenn du das über eine ODBC-Verbindung abschicken würdest?

[jobo]

@Bernhard
Für mich ist das nicht nachvollziehbar, was Du da schreibst. Ich habe in 15 Jahren Oracle nur einen echten Fehler in der DB gehabt. Performanceprobleme natürlich ab und an, die sich aber immer mit vertretbarem Aufwand lösen ließen.
Dagegen viel häufiger Voodoo Fehler wie ich sie nenne, Kollegen die sich über sch.. Oracle aufregen. IdR. reicht dann RTFM, um das "Phänomen" zu klären.

Was tatsächlich nicht gut gelungen ist bzw. war: Der neue CBO unter Oracle 9, der hat sehr viel nicht nachvollziehbare Ausführungspläne erzeugt. Das konnte man immer durch Rulebased Optimzer grade biegen.
Seit spätestens 10.2 alles unproblematisch nach meiner Erfahrung.

Zuletzt gibt es ja noch Support und Patches. Die habe ich aber nie bei Oracle DB gebraucht, dafür leider bei anderen Oracle Produkten.

Zu den ANSI Joins noch kurz. Ich weiß nicht, wann das eingeführt wurde. 9i würde ich auch als spät-aus Oracle Perspektive- bezeichnen. Fakt ist, es gibt noch Horden von Oracle Entwicklern und Gurus, die immernoch keine ANSI Joins verwenden. Ich habe mich auch noch nicht dran gewöhnt.
Natürlich sollte das funktionieren, da gebe ich Dir Recht. Wird aber scheinbar zu selten benutzt.
Der 11er OLEDB Treiber um den es hier geht, dürfte auch schon was älter sein.
Ich würde in jedem Fall versuchen, einen aktuelleren Treiber einzusetzen oder aber im Support mal nach Patches/Bugs schauen.

[mkinzler]

Ist es eigentlich möglich eine Frage zu stellen, welche auch nur im Entferntesten etwas mit Oracel zu tun hat, ohne das ein Glaubenkrieg um Oracle entfacht wird?

[Bernhard Geyer]

Zitat von mkinzler:

Ist es eigentlich möglich eine Frage zu stellen, welche auch nur im Entferntesten etwas mit Oracel zu tun hat, ohne das ein Glaubenkrieg um Oracle entfacht wird?

Wenn der Threadersteller keine konkrete Frage stellt darf man wohl philosophieren
Hätte der Threadersteller das nicht gewollt, hätte er ja wohl eine Frage gestellt.

Und mein letzter Post waren ja Hinweise was er entsprechend seinem Erstellerpost "Zugriff: egal" mal ausprobieren könnte.

[jobo]

Zitat von mkinzler:

Ist es eigentlich möglich eine Frage zu stellen, welche auch nur im Entferntesten etwas mit Oracel zu tun hat, ohne das ein Glaubenkrieg um Oracle entfacht wird?

Glaubenskriege sehen m.E. anders aus.

Mir ist klar, dass es Forenmitglieder gibt, die meine oder Bernhards oder andere Beiträge größtenteils als "Gelaber" betrachten. Das teilen sie mit einem entsprechenden Beitrag ja dann auch mal mit. Genau wie ich das mache, wenn ich irgendeinen Beitrag auf die ein oder andere Art "unterirdisch" finde. So wie hier z.B. in diesem Thread.
Was ist daran verkehrt? Gehört das nicht zu einem Forum dazu?
Wer sachliche und trockene Information braucht, kann doch z.B. Handbücher lesen.
Wer auch mal gern über den Tellerrand schaut und "apropos" Gedanken mitnehmen mag, schaut vielleicht lieber in ein Forum wie dieses.
In einer idealen Welt sähe ein Forum wahrscheinlich anders aus. Klare Frage, klare Antwort, fertig...

Bei der Gelegenheit, auch wenn es jetzt nach Deinem Anpfiff vielleicht blöd klingt, ein Dank an die Moderatoren.

[Furtbichler]

<Senf>
Leute, ich habe einmal mit Oracle gearbeitet. Öfter muss nicht sein. Von einem RDBMS erwarte ich, das es seine Arbeit gut macht. Das ist bei Oracle nicht immer der Fall. Klar, man kann immer irgendwo drehen, rumschrauben, obskure Einstellungen ändern, aber ... wieso sollte ich das tun? Warum soll ich im 21. Jahrhundert ein System wie eine experimentelle Dampfmaschine behandeln, nur damit sie irgendwann vielleicht doch den Turbo rauslässt.

Nee. Solange ich das nicht muss, lass ich es sein
</Senf>