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