Ist Oracle noch der Platzhirsch oder Schnee von Gestern?

[Bernhard Geyer]

Zitat von p80286:

MS war in der Handhabung einfacher, eleganter(?), intuitiver....

Zitat von p80286:

Nach einem halben Jahr merkte ich daß eine Oracle DB mit Abfragen die MSSQL in die Knie gezwungen haben locker umgehen konnten.

Solche Fälle gibts in allen Lagern. Eine Abfrage die DBMS "A" ratz fatz erledigt hat braucht bei DBMS "B" minuten. Bis man drauf kommt das der Query-Analyser trotz offensichtlichkeit Index "X" nehmen zu müssen doch Index "Y" nimmt oder gleiche einen Full Table Scan fährt. Ab und zu hat man Glück das beie problematischen Kunden eh ein Versionsupdate ansteht und die neue Version diesen Fehler nicht mehr hat.

Zitat von p80286:

Natürlich werden die DB-Admins daran nicht unschuldig gewesen sein,

Unfähige Admins gibts in beiden Lager. Bei Oracle muss die Admins aber dazu mehrer Monate Schulung erhalten damit sie die gleiche Fähigkeit wie MS-SQl-Admins mit wenigen Tagen haben

[jobo]

Man sollte vielleicht grundsätzlich 2 Arten von Tuning unterscheiden.
1. Datenbank Tuning: Das RDBMS inkl OS, Hardware so einrichten, dass es unter den gegebenen Anforderungen optimal läuft.
2. Anwendungstuning: Indexoptimierung, Statistikaufbau, ...

M.E. ist nur das Datenbanktuning eine zentrale Aufgabe eines Admin. Ein DB Setup an sich erfolgt idR. mit default Einstellungen, die je nach Bedarf angepasst werden sollten. Auch eine Adminaufgabe. Die Konfiguration bspw. für ein DWH sieht anders aus, als bei einer Online Transaktion Processing DB.

Ein Entwickler, der ein komplexes Select Statement baut, darf und soll sich auch ruhig Gedanken machen, wie das mit der vorhandenen oder fehlenden Indizierung, dem Mengengerüst usw. läuft und natürlich in jedem Fall, ob es nicht noch eleganter, sprich einfach, kürzer, kompakter geht. Das ist nicht unbedingt eine Adminaufgabe.

Für beide, Entwickler und Admins gilt:
Insbesondere das Thema Indizes, also im Endeffekt Ausführungspläne sind ja kein Geheimnis. Ein SQL Aufruf und die Datenbank zeigt den Ausführungsplan. Das ist erstmal keine Hexerei. Spannend wird es u.U., wenn selbst mittels Optimizer Hints nicht der gewünschte Index genutzt wird. Hier verhält sich nach meiner Erfahrung kein System deterministisch. Es sind von Menschen kreierte "Optimizer"-Algorithmen, die man versucht zu beeinflussen.
Ein (beliebig) schlecht formuliertes SQL, fehlende oder falsche Indizes können durch Admin oder Entwickler oft um Faktor 10,100,1000 verbessert werden. Das sehen wir ja hier im Forum ab und zu. Dazu genügt oft ein Blick auf den Query Plan. Da sehe ich auch keinen unterschiedlichen Bedarf an Schulung zwischen den verschiedenen Systemen.

Dies gilt für jedes RDBMS, das ansatzweise einen Queryoptimizer einsetzt.

Der Instantclient ist m.E. problemlos.

Administrationskosten:
Ich habe mal in einem Rechenzentrum gearbeitet, wo eine 3-4 stellige Anzahl von Orcale DB durch 1,5 festangestellte Admins betreut wurden. Zugegeben, die waren überm Limit. Aber lass es 2, 4 oder 10 Stellen sein. Fänd ich ok, egal für welches System.
Administrationskosten2:
Ich habe mal gelesen, dass der Oracle Optimizer bei der Optimierung die physikalische Lage der Tablespaces berücksichtigt. Ich habe es nie überprüft, aber das wäre ein Punkt, wo ein Admin seine Qualifikation zeigen könnte.
Klar ist, wenn ein System sehr komplexe Eingriffsmöglichkeiten bietet, wird auch die Administration komplexer und teurer. Offenbar ist das bei Oracle so.

[Elvis]

Oracle ist ein absoluter PITA in so ziemlich in allen Bereichen bis auf 3:

1. Die Scriptsprache (PL/SQL) ist wesentlich besser als dieser schizophrene Krempel, den Sybase TSQL taufte. Ernsthaft, in PL/SQL weißt du immer was zurückkommt, in TSQL muss man aufpassen dass nict mehrere Resultsets von in einem script geöffneten Selects zurückkommen.
   In PL/SQL ist ein einfaches Select, ohne Into-Clause, ein Fehler, ganz einfach.
2. Man kann als DBA auch Datenbanken von Drittanbietern sinnvoll tunen, da man Indizes auf Ausdrücke anlegen kann.
   Wenn man also erkennt, dass bestimmte Ausdrücke in best. Tabellen sehr häufig verwendet werden, kann man für diese Tabelle Indizes dieser Ausdrücke anlegen.
   Oracle wird dann autom. diese Indizes hernehmen, wenn es Sinn macht.
   In MSSQL kann man das nur indem man berechnete Spalten hinzufügt, die aber wiederum die 3rd-Party App brechen lassen könnten.
3. Oracle kann sehr gut Clustern, und ohne Cluster kann man nur so weit skalieren.

Der Oracle Client und so ziemlich alles was mit erzeugen und entfernen von DBs zu tun, ist unglaublich schmerzvoll.
Da ich als Entwickler von der eigentlichen DB möglichst wenig zu tun haben will[1], ist es mir wichtig, dass ich zumindest während der Entwicklung gar nix mit Oracle zu tun habe. MSSQL ist hier sehr angenehm, da es einem einfach nie im Weg ist (Außerdem gibt es eine ganz gute Integration im VS2012).


Da Oracle (IMO) aber wesentlich bessere Cluster-Möglichkeiten hat, finde ich es für ausfallsichere und performance-kritische Produktiveinsätze geeigneter (wobei ich dank ORM eh alle 3 unterstützen kann, die Sinn machen: MSSQL, Oracle, pgSQL)
Oracle kann beim Clustering ausfallsicher und schneller, bei MSSQL geht entweder eines von beiden, oder der DBA erwägt sich mit einem stumpfen Kochlöffel zu erstechen, damit der Schmerz nachlässt.
Das kann natürlich subjektiv total daneben liegen, da ich den MSSQL CLuster nicht eingestellt habe, sondern nur die Wutschreibe höre konnte.

Ohne richtigeres Clustering kann man aber schwerlich skalieren, ist also IMO ein ganz wichtiges Kriterium.

SProcs und die Syntax der SProc-Sprache sind wohl eher ein Kriterium für Legacy-Apps (wer schreibt denn noch Sprocs, wenn er eh einen WCF oder WebApi Service baut? )
Wenn SProcs gebaut werden sollen (warum auch immer), hat Oracle so dermaßen die Nase vorn, dass es nicht mehr lustig ist.


Mein Fazit hier ist: MSSQL für die Entwickler. Für die Intergationstests und Produktiv könnte es auch Oracle sein.
Aber nur wenn es sich leistungstechnisch bezahlt macht. Außer natürlich man jmd vor Ort, der viel Erfahrung mit MSSQL Clustern hat.

Schnee von Gestern sind IMO alle RDBMS irgendwo. Aber wir brauchen sie leider noch bis wirklich was besseres kommt.
Platzhirsch ist Oracle ganz sicher nicht mehr. Nur da wo es einen Haufen Legacy-Krempel gibt. (pgSQL und MSSQL sind noch nicht so lange so gut wie sie es heute sind.)
Oracle ist eher das notwendige Übel wenn Failover + Performance ausschlaggebend sind.


[1]die wird von nHibernate erzeugt und damit erzeuge ich auch die Migrationen (wobei ich die natürlich genau anschaue )

[p80286]

sehr schön geschrieben, aber ist "Platzhirsch" überhaupt relevant?

Wenn ich die Abverkäufe einer (kleinen) Buchhandlung abbilden will, ist wahrscheinlich das oft geschmähte Access ausreichend, für die Umsätze von IBM oder MS darf es dann gerne etwas größer sein.
Und in beiden Fällen wäre z.B. eine Volltextdatenbank wohl nicht das Mittel der Wahl.

Du hast eine Aufgabe und dafür suchst Du Dir das beste(preiswerteste) Werkzeug.

Platzhirsch, Outperformer oder was auch immer.

Gruß
K-H

[Stevie]

Zwischenfrage: Hat Oracle inzwischen ein brauchbares Entwicklungstool out of the box? Kann mich erinnern, dass ich mir als ich zuletzt mit Oracle zu tun hatte (schon einige Jahre her) als erstes nen TOAD installiert habe.

[Elvis]

Oracle war tatsächlich lange Zeit Platzhirsch.
Du kamst im projessionellen Bereich da eigentlich gar nicht dran vorbei. Sybase hatte das locking Problem, und MSSQL war damals noch zu sehr Sybase um konsistente reads ohne Sperren zu ermöglichen. Sowas kannst du natürlich für prof. Einsatz knicken.
DB/2 war eigentlich schon immer ein Exot. Es blieb nur Oracle (und bis 8.17 war es wohl das mit Abstand beste RDBMS, was man kriegen konnte, auch preislich).

War aber eigentlich alles schon vor meiner Zeit vorbei, yestercentury halt.

[p80286]

Zitat von Stevie:

Zwischenfrage: Hat Oracle inzwischen ein brauchbares Entwicklungstool out of the box? Kann mich erinnern, dass ich mir als ich zuletzt mit Oracle zu tun hatte (schon einige Jahre her) als erstes nen TOAD installiert habe.

Es gibt in der Zwischenzeit (seit 10?) einen SQL-Manager (oder so ähnlich), der ist besser als das, was man vorher hatte, aber wenn Du Toad als Maßstap nimmst, gibt es wohl immer noch nichts (richtig gutes)

Gruß
K-H

[Privateer3000]

Ich hau mal ne Zwischenfrage rein:
Hat schon mal jemand mit Filemaker gearbeitet (Desk wie auch Server)?

aus dem verschneiten Winterwald...
Grüße

[blondervolker]

Filemaker ist zwar nicht schlecht,aber mit FM-Server muss man ewig "Basteln",sehr,sehr viel "Lesen" um das man vernünftige Ergebnisse erzielt.
Das nächste war die Reporterstellung.Im Vergleich zu Fastreports,kommt Filemaker nicht mal Ansatzweise ran.Drum hab ich die Finger von Filemaker
komplett gelassen.

[Privateer3000]

Seit einem Jahr muss ich mich zwangsweise mit FM beschäftigen
und muss sagen dass ich ständig zwischen Jubel und Haareraufen schwanke.
Die Reports finde ich eigentliche gelungen...

Was ich bisher erfahren habe ist, dass FM auch sehr robust ist und
mit sehr hoher Geschwindigkeit arbeitet.
Ich habe keine offiziellen Referenzen für FM Einsatz, aber
ich hörte von einigen großen Firmen die diesen einsetzen.

Aber konkurrenzfähig zu anderen DBMS?
Selten wird der FM bei Diskussionen über DBs erwähnt.