MV_CAPABILITIES_TABLE

Rob van Wijk schreibt seit einiger Zeit eine interessante und sehr umfangreiche Serie ausführlicher Blog-Artikel zu den Fehlermeldungen, mit denen Materialized Views den Nutzer verwirren wollen. Hier geht's um die MV_CAPABILITIES_TABLE und neben den Fehlermeldungen wird auch die Verwendung dieses nützlichen Hilfsmittels erläutert.

MV Refresh

Mag sein, dass ich hier nur noch Verweise unterbringe, aber sei's drum: bei Alberto Dell'Era gibt's sehr schöne Erläuterungen zu den Mechanismen, die beim fast refresh für Materialized Views im Spiel sind. Dabei betrachtet er:

• MVs mit einfachem Join
• MVs mit einer Tabelle

Da ich inzwischen eher MOLAP-Lösungen verwende, ist das für mich nicht mehr ganz so aktuell, aber trotzdem sehr interessant.

outlines

Mit Outlines habe ich mich noch nie ernsthaft beschäftigt, aber wenn ich es tun wollte, könnte ich bei Kerry Osborne dazu allerlei Interessantes finden.

optimizer_index_cost_adj

In seinem Blog zeigt Richard Foote, warum der optimizer_index_cost_adj-Parameter, der immer wieder gerne als Allheilmittel für Performanceprobleme in OLTP-Systemen verkauft wird, bei Indizes mit extremem clustering factor zu erschreckenden Laufzeiten führen kann. Je besser der cbo wird, desto fragwürdiger scheint mir das Drehen an solchen Schrauben zu werden (man muss ihm nur gute Statistkwerte geben).

Beim Einsatz des CPU-Costings (= Verwendung von Systemstatistiken) ist ein zusätzliches Setzen des Parameters noch sinnloser, da dieser eine Krücke ist, um zu erreichen, was das CPU-Costing ohnehin leistet, nämlich eine sinnvolle Gewichtung des Verhältnisses von single und multiblock I/O-Operationen zu bestimmen. Man würde also das korrekte Systemverhalten noch mal übersteuern. Auch dazu gibt's inzwischen eine umfassendere Erläuterung bei Herrn Foote.

automatische Statistikerstellung ab 10g

Mir persönlich gefällt die Automatisierung der Statistikerfassung, die in 10g mit dem GATHER_STATS_JOB realisert wurde, eigentlich recht gut, obwohl ich mir vorstellen kann, dass es Situationen geben kann, in denen man damit auch jede Menge Ärger bekommen könnte. Ein paar ganz interessante Überlegungen dazu findet man bei Martin Widlake.

Ein wenig überrascht hat mich aber, dass der Job in 11g schon nicht mehr existiert, und durch etwas Neues ersetzt wurde - ein paar einleitende Worte dazu findet man bei Tim Hall.

SYS_GUID

Bei Carsten Czarski gibt's einen interessanten Hinweis auf die Möglichkeit, die Funktion SYS_GUID zur Erzeugung global eindeutiger IDs (also z.B. für Primärschlüssel) zu verwenden. Erläutert werden dabei auch die Vor- und Nachteile gegenüber der Verwendung von Sequences.

Einführung zum Thema "Materialized Views"

wer in Jonathan Lewis' Blogroll erscheint, muss interessante Dinge schreiben, dachte ich mir, als ich dort Uwe Hesses Blog entdeckte. Diese Vermutung ließ sich dann auch recht schnell verifizieren. Der einführende Artikel zu den Materialized Views ist sehr instruktiv und bringt schön auf den Punkt, was der tiefere Sinn der Sache ist. Erinnert mich persönlich ein wenig an die kompakten Erläuterungen, die man bei Tim Hall findet - sehr gutes Einführungsmaterial, wenn man sich nicht die Zeit nehmen kann (oder möchte), die Dokumentation durchzuarbeiten.

SQL_Monitor

Bei Doug Burns konnte man dieser Tage etwas über das in Oracle 11 verfügbare SQL Monitoring mit Hilfe des SQL Developers finden. Da ich Datenbanken aber traditionsbedingt (und auch noch aus anderen Gründen) lieber über sqlplus anspreche, habe ich mir mal ein simples Analyse-Script für die zugehörigen Tabellen V$SQL_PLAN_MONITOR und V$SQL_MONITOR gebastelt, mit dem ich hoffentlich in Zukunft etwas genauer sagen kann, was eine lang laufende Query denn nun aktuell genau tut (ohne auf die vageren Aussagen aus v$bh, v$sql_workarea angewiesen zu sein):

select p.status
     , s.id
     , s.parent_id
     , lpad (' ', depth - 1) || s.operation || ' ' || s.options operation
     , s.object_name
     , p.starts
     , p.output_rows
     , (select r.buffer_gets
          from v$sql_monitor r
         where r.key = p.key) buffer_gets
     , s.cost
     , s.time
     , s.cardinality
     , s.bytes
     , s.search_columns
     , s.access_predicates
     , s.filter_predicates
     , s.projection
     , s.cpu_cost
     , s.io_cost
  from v$sql_plan_statistics_all s
  left outer join
       v$sql_plan_monitor p
    on (s.sql_id = p.sql_id and s.id = p.plan_line_id)
 where s.sql_id = '&&1'
 order by s.id;

Noch nicht besonders elegant (meine unglückliche Liebe zu skalaren Subqueries schlägt sich einmal mehr nieder), aber - so hoffe ich zumindest - erst mal verwendbar.

Nachtrag 05.08.2011: hier noch ein Link auf die Lizenzierungsinformationen: Voraussetzung für das SQL Monitoring ist das Tuning Pack. Außerdem noch der Hinweis, dass man statt des SQL-Zugriffs auf die angegebenen v$sql_plan%-Views auch die vorformatierte Variante des dbms_sqltune-Packages (report_sql_monitor) verwenden kann - wie in meinem aktuellen Script zum Thema.