Oracle 26ai Feature Häppchen für DBAs

00:00:03: Oh, wie Datenbank.

00:00:15: Ein Oracle-Podcast

00:00:27: von Aura to Know.

00:00:33: Klar, diese Sachen wie Dual und dass man halt irgendwelche Boolean-Operationen haben kann.

00:00:39: Aber das interessiert den Ingenieur auf der Brücke und den Maschinisten nicht so ganz.

00:00:45: Was uns mehr interessiert sind die Sachen, die in der Datenmang sich abspielen Wie zum Beispiel wenn ich mal eins rausgreifen darf Die Möglichkeit Transaktionen zu priorisieren.

00:00:55: Das ist halt eines der neuen Featuren in der XXXII.

00:00:59: Wenn du damit anfangen willst, dann erklär doch mal.

00:01:01: Wie heißt das Feature und worum geht's?

00:01:04: Den Namen auszusprechen fällt mir schon schwer.

00:01:06: Transaction priorities würden ausfriesen nicht ganz so leicht aber es geht im Endeffekt darum dass Transaktionen eine Priorität haben können.

00:01:15: sprich normalerweise wenn sich zwei Anwendungen eine Tabelle sperren oder einen Datensatz sperren dann wartet die eine solange bis die andere damit fertig ist Und das kann Stunden gegebenenfalls sogar Tage dauern.

00:01:28: Wenn ich aber eine Priorität mitgebe, dann kann ich halt sagen okay wenn diese Transaktion nach dreißig Sekunden immer noch nicht fertig ist.

00:01:34: Dann wird sie abgeschossen und durch eine höher priorisierte Überschrieben beziehungsweise zurückgerollt und diese übernimmt dann das es gerade bei großen Maintenance-Operationen für DBAs natürlich eine gute Methode um dafür zu sorgen dass Skripte auch tatsächlich durchlaufen.

00:01:52: Mit dem einzigen Wehrmutz Tropfen Standardmäßig alle Transaktionen die gleiche und nämlich die höchste Priorität haben.

00:02:00: Das heißt, man muss zunächst einmal sehen wie geht man denn mit diesem neuen Feature überhaupt um bevor man es dann in den Produktionsystem gegebenenfalls einsetzt?

00:02:08: Das klingt so wenn man seine Anwendung richtig designet dann braucht man das Feature gar nicht.

00:02:12: also wenn langläufer sind eigentlich ein Designfehler oder

00:02:14: ja dass ist so.

00:02:15: also im ussofern ist das ein feature um den naja vielleicht nicht optimalen code bisschen besser zu machen.

00:02:23: Hast du noch andere Features über dir reden wollen, vielleicht ein bisschen was aus dem Rackumfeld?

00:02:28: Es gibt im Rack-Umfeld oder im DataGuard-Umpfeld eine ganze Menge von neuen Features.

00:02:32: Was für mich aber ganz wichtig ist das Thema Multitenant.

00:02:36: logischerweise und beim Multitenent war es bislang immer das Problem dass bei der Grid Infrastructure ne PDB keine Clusterresource war und das bedeutet man konnte das starten und stoppen von Plugable Databases nicht steuern.

00:02:51: für eine Datenbank, die vielleicht zwei-, drei Plugable Database hat nicht weiter schlimm.

00:02:57: Aber im Rackumfeld wo ich vierzig-fünfzig Datenbanken haben kann das ganz kritisch werden.

00:03:03: Das heißt, Plugable DataBases wären einfach nicht gestartet weil der zugehörige Service, der wiederum ne klasse Resource ist, nicht gestaltet wird.

00:03:12: Services ist ja überhaupt ein cooles Stichwort!

00:03:14: Das nutzen viel zu wenige Leute oder wie siehst du das?

00:03:16: Ja, leider.

00:03:17: Es ist zwar schon seit etlichen Versionen so dass man eigene Services für Anwendung definieren soll aber bislang ist das scheinbar immer noch nicht zu den DBAs oder zu den Entwicklern durchgedrungen.

00:03:27: also da ist noch viel Arbeit zu tun.

00:03:29: Warum denn eigentlich?

00:03:30: Weil es so einfach ist... Man hat immer die SID genommen und warum sollte man was ändern?

00:03:36: Hat doch vor zwanzig Jahren auch funktioniert.

00:03:38: Kannst du nochmal kurz erzählen?

00:03:39: Was ist der Vorteil von Services?

00:03:41: Services können auf Datenebene definiert werden für bestimmte Applikationen.

00:03:45: Das heißt, ich kann fast beliebig viele haben und kann jeder Applikion sagen das ist ein Service.

00:03:50: Mit dem Stoppen des Services stoppe ich dann auch die Applikations.

00:03:53: Und hier kommt jetzt wieder die Plugable Database ins Spiel weil mit dem Starten des Services wird auch die Plugables Databases gestartet aber nur auf der Instanz auf die das Service definiert ist.

00:04:04: Das heisst, ich habe gegebenenfalls eine Unbalanciertheit von Plugable Databases über mehrere Instanzen im Rackumfeld, und das kann sehr kritisch werden.

00:04:13: Und dann kommt noch dazu – und das hat man bei ORAKE-Sixundzwanzig auch mittlerweile in den Griff bekommen scheinbar -, dass ich jetzt Prioritäten vergeben kann für Plugable databases in welcher Reihenfolge sie gestartet werden.

00:04:26: Das muss sich aber tatsächlich noch ausprobieren wie das funktioniert bzw ob das wirklich so funktioniert wie ORAKA sich das vorstellt.

00:04:33: Aber multi-tenant wird uns an der Stelle immer noch wieder vor Überraschungen setzen und noch einige weitere neuen Feature brauchen oder auch haben, die wir gut benutzen können.

00:04:44: MultiTenant ist mit Sicherheit noch spannend in der Zukunft.

00:04:47: Standby-Daten manken werden ja jetzt auch Kanula.

00:04:50: Data Guard kann man auf PDB-Ebene definieren?

00:04:53: Ja das geht schon eine ganze Weile als Information durch die Lande und es richtig – auf Sächsendzwanzig kann man das machen ob man's will!

00:05:02: Das ist die Frage, wie man sich mit Plugable Databases generell auseinandersetzt.

00:05:06: Ich stehe eher auf dem Standpunkt und brauchen wir nicht.

00:05:09: Hol es doch erst mal ab!

00:05:10: Was ist denn überhaupt die Standby-Datenbank?

00:05:12: Und wo ist das Problem mit Plugables Database oder nicht?

00:05:15: Stell dir vor du hast eine Datenbank, eine CDB mit Fünfzig Plugable databases.

00:05:20: Die wird über ein Stand by Datenbank abgesichert d.h.

00:05:23: dort hat so nochmal eine Datemank mit Fufzig Plugables databases.

00:05:29: großartigen RAM oder keine großartige CPU verbraucht, sondern nur Storage.

00:05:34: Und jetzt könnte man natürlich auf die Idee kommen diese fünfzig Plugable Databases könnt ich ja auch über die Standby verteilen so dass sie dort aktiv genutzt werden können und dich damit die Ressourcen auf der Standby Seite besser auslastet.

00:05:48: Das führt aber im Fehlerfall dazu das sich gegebenenfalls gar nicht genug Ressorzen habe für alle Plugable databases auf der Primärseite Und auf der anderen Seite, wenn ich Maintenance machen will also Patchen oder irgendwelche Storage Erweiterungen oder was auch immer dann sind gegebenenfalls einige der Plugable Database betroffen und andere wieder nicht.

00:06:09: Das macht es sehr schwer zu handeln.

00:06:12: Noch dazu kommt der Faktor dass dann jede Plugable database eigene Redo Lock Dateien braucht und zwar nicht wenige.

00:06:20: Also insofern ist der Aufwand doch schon nicht unerheblich.

00:06:23: und ob der Nutzen dementsprechend ist, das war ich zu bezweifeln.

00:06:26: Was kostet das denn an Resourcen und Storage?

00:06:29: Na ja gut vom Resource und Storage Aufwand ist es eigentlich kein Unterschied weil hoffentlich hat man alle Plugable-Databases repliziert über Standby Datenpanken.

00:06:39: aber auf der anderen Seite man könnte jetzt auch beigehen und sagen ja nie die ist doch nicht so ganz so wichtig wie die andere die lassen wir mal aus.

00:06:47: Und dann möchte ich nicht mehr DBA in so einem Umfeld sein, um das tatsächlich zu nutzen und dann im Worst Case sagen zu müssen, ja sorry deine Plugable Database war aber nicht dabei bei der Standby Datenbank.

00:07:00: Also insofern plädiere ich definitiv dazu dass man auf den klassischen Fall zurück geht.

00:07:05: Das Feature ist nett in XXX, aber ich glaube hier sind wir mit der alten Methode schon ganz schön weit noch dazu weil sich ja immer noch einige Unternehmen noch nicht mal auskennen, mit dem was man Multitenant-Architektur nennt.

00:07:18: Okay jetzt hatten wir drei Häppchen Transaktionen Cluster und Data Guard alle auf der Infrastruktur Seite.

00:07:24: hast du auch noch etwas was nie an der Datenbank Engine ist?

00:07:27: Etwas das die Art verändert wie Oracle mit Daten umgeht?

00:07:30: Es gibt bei ORAKE XXI ein neues Feature das nennt sich Lock Free Reservations.

00:07:35: sprich ich habe eine Transaktion einen Update in der Regel auf einer Spalte einer Tabelle und setze dafür keine Sperre.

00:07:44: Wie

00:07:44: jetzt?

00:07:44: Das ist doch das zentrale Feature von Oracle, dass wir zahlenweise Sperren machen können.

00:07:48: Das brauchen wir jetzt nicht mehr?

00:07:49: Ja ich glaube damit ist das nicht unbedingt gemeint aber es geht darum, dass es Tabellen gibt die eigentlich nichts anderes tun als eine Sequenz zur Verfügung zu stellen.

00:08:00: Und diese Tabellen haben halt den Nachteil je größer die Applikation wird beziehungsweise je mehr User es gibt umso mehr Treffiges auf dieser Tabelle warten aufeinander beziehungsweise Transaktionen können nicht ausgeführt werden, weil ich an der Stelle ein Bottleneck habe.

00:08:17: Ob das jetzt wirklich die optimale Lösung ist weiß ich nicht aber es ist tatsächlich so dass wenn ich die Tabelle als Lock-Free definiere oder die Spalte besser gesagt kann halt eine Anwendung hingehen und diesen Datensatz ändern.

00:08:30: in der Regel macht man es ja so dass man den Datensatz liest den Wert übernimmt in die Anwendungen Und dann sagt, okay jetzt schreibe ich einen neuen Datensatz oder einen neuen Wert in die Tabelle und mache ein Commit.

00:08:44: Das ist natürlich an der Stelle für größere Applikationen kritisch bezüglich Contention beziehungsweise ein absoluter Bottleneck.

00:08:51: Wie setzt sich das um?

00:08:52: In der Tabellendefinition also ich kann wirklich hingehen und sagen Die Tabelle hat eine Spalte, die ist lock free und wenn diese Spalter geändert wird nehme ich mir den Wert.

00:09:03: aber ob ich diesen Wert auch tatsächlich bekomme oder einen anderen Wert, bekomme ich tatsächlich erst mit dem Commit gesagt.

00:09:11: Das heißt, ich muss bis zum Commit warten, weil sich weiß was wirklich passiert ist auf der Tabelle?

00:09:14: Ja genau so ist es!

00:09:16: Im Endeffekt glaube ich dass das eher dafür gedacht ist alte Anwendungen Multi-User oder eben mit weniger Contention hinzubekommen.

00:09:26: Weil alte Anwendung da gibt es einige die haben wirklich eine Tabelle auf der sich alle Bezüglich der Inhalte einigen müssen.

00:09:35: Das heißt, alle eine Sequenz immer wieder auslesen

00:09:38: müssen.".

00:09:39: D.h.,

00:09:39: wir haben jetzt optimistisches Locking-of-Datenbank eben und müssen das nicht mehr in der Applikation machen?

00:09:44: Ja, das könnte man tatsächlich so machen aber es ist halt ein bisschen eleganter weil Oracle einfach trotzdem die Konsistenz im bezüglicher Reservierung ja garantiert, wie's auch sein sollte.

00:09:57: Das waren jetzt mal vier Häppchen und was mich überrascht, das sind ja eigentlich nicht nur neue Knöpfchen an der Atmenkontrolle sondern wirklich auch fundamentale Änderungen an der Engine.

00:10:05: Lock-Free Reservations klingt nach einem wirklich coolen Konzept.

00:10:09: Richtig!

00:10:10: Und es gibt noch eine ganze Menge mehr an Informationen bzw.

00:10:14: Features die wir aus der SIXundzwanzig bringen können.

00:10:17: Wir haben noch gar nicht über Vecto Search geredet.

00:10:20: Es gibt halt automatische Indizierung usw.

00:10:24: Ein Kleinen möchte ich noch herausgreifen Und das ist die Möglichkeit, dass wir jetzt endlich an ein Schema einen Grant vergeben können.

00:10:31: Also auf alle Objekte eines Schemas.

00:10:33: Ach da werden viele begeistert sein von den Entwicklern und DBAs genauso!

00:10:38: Das finde ich auch gerade.

00:10:39: diese Riesenkranularitätslücke zwischen Select Any Table also Ich darf alle Tabellen aus der ganzen Datenbank selektieren und Select Table also ich darf nur eine einzelne Tabelle selektiren Ist eine riesen Lücke und darüber bin ich richtig froh, dass die jetzt endlich gestopft ist.

00:10:55: Ja, was uns jetzt noch fehlen würde wäre ein Rename-Schema.

00:10:59: Aber ich glaube man muss ja auch Wünsche behalten können.

00:11:01: Wünschen dürfen wir alle haben und im Moment würde ich sagen es klingt als ob wir noch viele weitere Featurehäppchen folgen machen können oder?

00:11:07: So sehe ich's auch!

00:11:09: Dann bleibt mir nur noch zu sagen danke fürs Zuhören.

00:11:12: schaut in die Show Notes da findet ihr jede Menge spannende Links und abonniert uns bis zum nächsten Mal Tschüss.