Die Zukunft des OWB

Dani Schnider von Trivadis gibt eine kurze Zusammenfassung zur aktuellen strategischen Planung der Oracle-ETL-Landschaft. Offenbar hat der Oracle Warehouse Builder (OWB) keine Zukunft mehr, was sich allerdings schon seit einiger Zeit andeutete:

OWB 11g Release 2 will be the final release of Oracle Warehouse Builder. No major enhancements are planned for this tool. Support, patches and bug fixes will still be delivered for the next years. OWB 11.2 will be supported for the whole lifecycle of Oracle Database 12c, so there is no hurry to switch to ODI as soon as possible. But the strategic ETL product of Oracle is ODI, and new customers are recommended to use this tool.

Dani Snider sieht in diesem Zusammenhang vor allem zwei offene Punkte:

• Eine kurzfrsitige Migration in Richtung ODI ist mangels Toolunterstützung offenbar nicht angeraten.
• Abgesehen davon sind die Lizenzkosten für den ODI relativ hoch, was ein Anlaß zur Verwendung von ETL-Tools anderer Anbieter sein könnte ("There are several good open source ETL products on the market.")

Partition Exchange + Indizierung

Über Partition Exchange hatte ich hier vor einiger Zeit etwas geschrieben, musste mich dieser Tage aber noch mal etwas ernsthafter mit dem Thema beschäftigen, und kam dabei zu folgenden Ergebnissen:

• Wenn man im "ALTER TABLE ... EXCHANGE PARTITION ... WITH TABLE ..." keine Klausel "INCLUDING INDEXES" angibt, dann werden alle auf der Austauschtabelle aufgebauten Indizes beim Exchange UNUSABLE.
• Beim Aufbau von Indizes muss man den Grad der COMPRESSION berücksichtigen, da man sonst auf "ORA-28665: Tabelle und Partition müssen dasselbe Komprimierungsattribut haben" trifft. Der Fehlertext ist somit also etwas unpräzise, da auch Indizes berücksichtigt werden müssen.

Und noch eine harmlose Ergänzung: zum Monitoring des Stands der Index-Erzeugung kann man neben dem SQL-Monitor, v$session_longopsund den workare-Views auch noch dba_segments heranziehen:

select *
  from dba_segments
 where segment_type = 'TEMPORARY';

liefert Informationen zur Größe des im Aufbau befindlichen Index, der zunächst als temporäres Objekt mit einer technischen Id erzeugt wird, ehe daraus dann das permanente Segment wird.

Iggy Fernandez über DB-Design und Features

Die Überschriften der Einträge hier werden allmählich unübersichtlicher ...

Iggy Fernandez hat zuletzt einige interessante Artikel geschrieben, die ich hier summarisch verlinke:

• Lesson 1 of 40: Physical Database Design for Oracle Databases: Necessity and Definition mit einer recht knappen Unterscheidung von logischem und phsyikalischem DB-Design ("Logical database design is the process of designing normalized database tables." vs. "Physical database design is the process of designing indexes, partitions, clusters, and materialized views.")
• Lesson 2 of 40: Physical Database Design for Oracle Databases: Non-Necessity? behandelt die Frage, ob man sich angesichts niedriger Hardwarepreise die Mühe der Zugriffsoptimierung sparen kann. Die These wurde dieser Tage von Bert Scalzo vertreten (“So, with such cheap hardware, it might be a wiser business bet to throw hardware at some solutions sooner than was done in the past.”), wobei Jonathan Lewis bereits darauf hinwies, dass das wichtigste Wort in diesem Satz das "sooner" ist. Die meisten extremen Performance-Probleme, denen ich begegne, haben erst mal recht wenig mit der Hardware-Leistung zu tun und sehr viel mit dem Design.
• Unconventional Wisdom: Do we probably need RAC, Exadata, Oracle Database 12c, MySQL, certification, and Oracle user groups? verweist auf Mogens Norgaards älteren Artikel zur Frage, wer eigentlich RAC brauche, die dort mit einem klaren "(fast) niemand" beantwortet wurde - und beschäftigt sich im Anschluß daran mit weiteren technischen und Marketing-Themen, deren praktische Relevanz begutachtet wird.

Wenn der Herr Fernandez seine Drohung wahr macht und tatsächlich 40 Lessons liefert, werde ich mir die Links aber vermutlich irgendwann sparen ...

EXISTS im SELECT

Rob van Wijk, dessen Blog ich - wie ich vielleicht schon mal erwähnt habe - sehr schätze, hat mal wieder etwas Interessantes angesprochen: man kann EXISTS nicht nur im WHERE, sondern in einer searched case expression auch im SELECT verwenden, was in bestimmten Fällen effizienter sein kann als ein entsprechender OUTER JOIN. Wie immer beim Herrn van Wijk gibt's aussagekräftige Beispiele und eine einleuchtende Erklärung des Verhaltens.

Index Rebuilds und der Clustering Factor

Nächstes Quiz des Herrn Foote, diesmal zur Frage, wann ein Index Rebuild den Clustering Factor ändern kann. Im Grunde ist die Antwort: nie, aber es gibt doch ein paar Spezialfälle, die man als Ausnahmen von der Regel betrachten kann. Grundsätzlich gilt:

So for an index rebuild to actual have an impact on the CF on an index, means either the rows in the table needs to change or the order of the index entries needs to change.
However, when we typically rebuild an index, it has no impact at all on the table and so can’t possibly change the order of the rows there. Additionally, no matter how fragmented or inefficient the index structure might be, an index rebuild doesn’t change the order of the index entries either as they’re always sorted within the index in the order of the indexed columns.

Die Ausnahmen der  Regel sind Indizes, die von REVERSE auf NOREVERSE oder umgekehrt umgestellt werden - was aus meiner Sicht aber eigentlich etwas Anderes ist als ein einfacher Neuaufbau. Ein anderer Spezialfall wäre die Definitionsänderung eines FBI - aber auch das ist kein einfaches Rebuild. Damit kann man für alle praktischen Fälle wohl doch bei der Regel bleiben, dass nur ein Neuaufbau der Tabelle den Clustering Factor eines Index ändern kann.

Oracle 11.2.0.3

Greg Rahn weist darauf hin, dass das Patchset 11.2.0.3 für diverse Platformen veröffentlicht wurde. Laut New Feature Guide liegen die Verbesserungen vor allem in den Bereichen ACFS, XML und OWB.

Recovery Area

Uwe Hesse erläutert in seinem Blog sehr ausführlich, warum eine Recovery Area empfehlenswert ist. Wenn ich mich mal wieder als DBA ausgebe, wäre das ein Thema, das intensivere Beschäftigung verdiente.

Rebuild Partitioned Index

Da ich die Syntax mit schöner Regelmäßigkeit anderswo suche, schreibe ich sie mal hier auf: um eine Index-Partition UNUSABLE zu setzen bzw. wieder neu aufzubauen, kann man folgende Kommandos verwenden:

alter index ... modify partition ... unusable;
alter index ... rebuild partition ...;

Alternativ kann man auch alle lokalen Indizes einer Partition auf einmal auf UNUSABLE setzen bzw. neu aufbauen:

alter table ... modify partition ... unusable local indexes;
alter table ... modify partition ... rebuild unusable local indexes;

Ein kleines Beispiel zum Thema liefert Tom Kyte.

Leider kann man einen als UNIQUE definierten Index vor einem Massendaten-Ladevorgang nicht über diesen Weg deaktivieren, um ihn später wieder aufzubauen, da das INSERT dann gegen einen ORA-01502 ("index 'string.string' or partition of such index is in unusable state") läuft - Details zu diesem Problem finden sich hier.