Ist Oracle noch der Platzhirsch oder Schnee von Gestern?

[Furtbichler]

Hallo Leute,

In der Firma, für die ich derzeit tätig bin, herrscht die Ansicht, das das im Einsatz befindliche Oracle 11g oller alter Müll ist, nicht mehr zeitgemäß usw. Alle schwören auf MSSQL.

Ich dachte immer, Oracle sei so ziemlich das Fetteste, was man sich hinstellen kann. Nur muss man eine 10 jährige Ausbildung machen, um mit dem Teil umzugehen.

Was stimmt denn nun?

[Popov]

Ja, ich hab doch tatsächlich irgendwo sogar eine Oracle irgendwas. In Karate hätte ich da den orangen Gürtel, oder so. Ist aber auch schon 10 Jahre her.

Ich denke eher das ist eine Vorliebe. Die einen stehen lieber auf das, die anderen auf das. Obwohl ich mich damals bei der Ausbildung geärgert habe, was für ein Schrott Oracle ist. Weniger von der Mächtigkeit im Hintergrund, sondern, weil man mit MSSQL viel angenehmer und schneller arbeiten konnte. Wenn man keine extra Tools hatte, musste man sich einen abmühen. Aber das weißt du ja selber.

Die Frage ist also - was haltend die Kollegen für alten Müll? Die Datenbank im Hintergrund oder nur die Handhabung? Denn ich hab mich schon damals (etwa 2002) darüber geärgert, wie veraltet die Handhabung ist. Bedeutete aber nicht, dass die Datenbank schlecht ist.

[p80286]

Zitat von Popov:

Die Frage ist also - was haltend die Kollegen für alten Müll? Die Datenbank im Hintergrund oder nur die Handhabung? Denn ich hab mich schon damals (etwa 2002) darüber geärgert, wie veraltet die Handhabung ist. Bedeutete aber nicht, dass die Datenbank schlecht ist.

Um diese Zeit habe ich meine ersten Erfahrungen mit MSSQL gesammelt und bin 3 Jahre später auf Oracle umgestiegen (worden).

MS war in der Handhabung einfacher, eleganter(?), intuitiver....
Nach einem halben Jahr merkte ich daß eine Oracle DB mit Abfragen die MSSQL in die Knie gezwungen haben locker umgehen konnten. Natürlich werden die DB-Admins daran nicht unschuldig gewesen sein, und es ist Ewigkeiten her, aber noch heute habe ich das Gefühl, daß Oracle-DBs stur wie ein Panzer ihren Job erledigen, während MSSQL ein (gut)getuntes Access ist.
(unter Umständen sind auch unsere Admins nicht die hellsten, aber so sind nun mal meine Erfahrungen)

Gruß
K-H

[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

[Elvis]

FileMaker ist wohl eigentlich sowas wie Access (GUI + DB-File, rel. einfach zu bedienen), als Server ist das ziemlich sinnlos.
Man kann fast nix konfigurieren (zum Beispiel welche Art von Index (Bitmap, B-Tree, B-Tree Cluster, Hash Cluster, ..., wie partitioniert, wie auf verschiedenen HDD-Arrays abgelegt wird)
Ohne vernünftige Index-Möglishkeiten kann man gleich ebenso einfach gestrickte Engines wie Firebird oder MySql nehmen, kosten wohl weniger, aber sind verbreiter.

[blondervolker]

Und absolut nicht zu vergessen,dass ich persönlich einige Firmeninhaber kenne,die die Kosten so niedrig wie möglich halten möchten.
Denn aber kommen einige leider garnicht mehr weiter und geben sogar mal
Geld aus. Siehe Filemaker-Magazin...

[Bernhard Geyer]

Zitat von Furtbichler:

In der Firma, für die ich derzeit tätig bin, herrscht die Ansicht, das das im Einsatz befindliche Oracle 11g oller alter Müll ist, nicht mehr zeitgemäß usw. Alle schwören auf MSSQL.

Wer beides Administrieren muste weis mit was man weniger Probleme hat.

Zitat von Furtbichler:

Ich dachte immer, Oracle sei so ziemlich das Fetteste, was man sich hinstellen kann. Nur muss man eine 10 jährige Ausbildung machen, um mit dem Teil umzugehen.

Fett im Sinne von "da hat sich was angesammelt" an Features als auch an unnötigen Teilen dann stimmt das. Wenn man so sieht was eine 0815-Installation von Oracle so für "Müll" hinterlässt und was so alles mal eine grundsätzliche Überarbeitung bedürfte. Der MS-SQL Server schleppt hier nur ca. 15 Balast mit sich rum.