zum Thema Transaktion in Oracle:
wir nutzen im Wesentlichen seit Jahren
ADO / OLEDB ohne klientseitige Transaktionssteuerung. Andere Zugriffe (App.Server, ..) ebenfalls mit impliziten Transaktionen. Das geht wunderbar- für Datenpflege/-verarbeitung.
Für lesenden Zugriff bzw. Reporting sehe ich da allerdings gar keinen Sinn. Wenn ich commited lese, bekomme ich genau das, was zum Zeitpunkt des Aufrufs commited war.
Intensive DV lagern wir in Jobs aus, die nur aus dem Klient angestoßen werden. Den Verlauf kann sich dann im Klient anschauen, wenn man mag. In einem Fall gibt es noch ein kleines DW für extreme Reportingfragen auf einer 2. Hardware. Ansonsten läuft auch viel über Snapshots, das ist für massive Reportanfragen sicher ratsam. Man müsste sich allerdings etwas Gedanken machen, wie man bestimmte Basissnapshots aufbaut, damit möglichst viele Reports das nutzen können. Queueing brachen wir nicht, auch nicht in Intranet Systemen, die auf diese DBs gehen.
In meinen Augen gäbe es nur einen einzigen Nutzen für klientseitiges Transaktionshandling, wenn nämlich der Anwender nach einem Verarbeitungslauf, Import oder so sagen möchte, "alles Quatsch, nicht commiten, rollback". Das hab ich mir zwar schon ab und zu gewünscht, aber der Preis, den man dafür zahlt, ist zu hoch.
Allgemein (gilt nicht nur für Oracle):
Man kriegt natürlich jede
DB in die Knie, relativ problemlos. Umgekehrt gibt es aber den gleichen Effekt, Application Tuning und Architektur kann locker mal einen 3 oder 4 stelligen Faktor Performance bringen (natürlich abhängig davon, wie schlecht es vorher umgesetzt war). Eine Größenordnung, die mit neuer Hardware niemals erreicht werden kann.
Wenn man eine
DB allerdings stur als Blackbox betrachtet, darf man auch keine großen Erwartungen haben.