ORDIX News. Hysterie um Histogramme Details zu Statistiken, die für den kostenbasierenden Oracle Optimizer wichtig sind S. 8

Transkript

1 Ein guter Projektmanager ist ein Manager S ORDIX News Das IT-Magazin der ORDIX AG Ausgabe 4/2005 2,20 Hysterie um Histogramme Details zu Statistiken, die für den kostenbasierenden Oracle Optimizer wichtig sind S. 8 Tiefe Einblicke in Solaris 10 mit DTrace Systemereignisse komfortabel protokollieren S. 12 Hibernate: Hält Java Winterschlaf? Java-Objekte in einer Datenbank zu persistieren, ist einfach wie nie zuvor. S. 39 Top Secret: Securitiy Features im IDS Daten in der Datenbank verschlüsseln S. 26

2 Editorial Paderborn, Dezember 2005 From open to closed? Seit Jahren propagiere ich an dieser Stelle unserer News den Open Source Gedanken. Einen schweren Dämpfer hat mein und damit auch das ORDIX-Engagement durch eine Mitteilung auf dem Ticker einer Internet News Agentur erhalten: JBoss, Vermarkter des gleichnamigen Open Source Application Servers, hat sich den Unmut der Open Source Gemeinde zugezogen. Sie meint, die Methoden der Firma, die mit professionellem Support rund um das Produkt in den vergangenen Jahren sehr erfolgreich war, seien nicht mit dem Open Source Gedanken zu vereinbaren. Konkret entzündete sich der Ärger hierzulande an einer Abmahnung, die JBoss einem Darmstädter J2EE-Beratungsunternehmen zugestellt hat. Darin heißt es, dass das Unternehmen jeglichen Gebrauch der Marke JBoss künftig zu unterlassen habe, ansonsten drohten Strafen im sechsstelligen Euro-Bereich. Konkret: Euro pro Fall, der Streitwert beträgt Euro. Das Darmstädter Unternehmen war bis August JBoss-Partner und bietet zudem herstellerunabhängige Schulungen und Beratung. Damit schadet aus meiner Sicht JBoss massiv dem Gedanken von Open Source und versucht eine Art Monopolstellung zu erhalten; leider typisch für amerikanische Unternehmen. Wir werden versuchen, unsere JBoss-Unterstützung in Projekten auch ohne großes Aufhebens weiterhin auszuführen. Ob uns das gelingt? Wir werden sehen! Es liegt auch an Ihnen. Die JBoss-Attacke ist sicherlich nicht der Grund, warum es dieses Mal nicht ganz so viele Java-Artikel in unserer Weihnachtsausgabe gibt. Auch nicht, dass Larry R. bei unserem letzten Rätsel nur wenig Unterstützung erhalten hat. Freuen Sie sich vielmehr auf unterschiedliche Artikel zum Thema Linux, Oracle, DTrace (Solaris) und Windows. Da wir beim letzten Larry-Rätsel keine Gewinner hatten, machen wir es Ihnen dieses Mal leichter. Rätsel und Gewinnchancen finden Sie in diesem Heft zu Hauf. Ich wünsche Ihnen, dass Ihre Wünsche zum Weihnachtsfest in Erfüllung gehen und dass das Leben und Arbeiten 2006 weiterhin Spaß macht. ORDIX beendet im Dezember seine Aktionen zum 15-jährigen Jubiläum. Vielleicht konnten Sie davon profitieren. Wenn nicht: wir sind offen für Ihre Anfragen. Meine Mitarbeiter und ich freuen uns, wenn wir Ihnen bei der Bearbeitung von Anfragen etc. behilflich sein können. Von daher wünsche ich Ihnen, wie in jedem Jahr, alles Gute für das kommende Jahr, Gesundheit und Erfolg. Bei letzterem werden Ihnen die ORDIX-Mitarbeiter sicher gerne helfen - ob mit oder ohne Open Source. Bis dahin wünsche ich Ihnen alles Gute. X Wolfgang Kögler 2

3 Inhaltsverzeichnis Standards Aktuell 02...Editorial 03...Inhalt 23...Impressum 24...Seminarübersicht bis Juli Larry Ratlos und die Linux Distributionen 23...Rückblick DOAG Schulungstag und DOAG Konferenz 29...Rückblick Fachtreff J2EE Servertechnologie 29...Weihnachtsrätsel Java/XML 04...Von POJOs und anämischen Objekten Der Artikel betrachtet Probleme in der ob jektorientierten Software-Entwicklung. Dabei werden das Anemic Object Anti- Pattern und das Konzept des POJO vorgestellt J2EE und Persistenz: Ein heißes Eisen (Teil II) Im letzten Teil der Miniserie zu J2EE und Persistenz werden die Pros und Contras des gewählten Ansatzes anhand konkreter Projekterfahrungen erläutert Hibernate: Hält Java Winterschlaf? Titelthema Java-Programmierer können aufatmen. Das Persistieren von Java-Objekten in einer Datenbank ist einfach, wie nie zuvor. Dank Hibernate, einer Open Source Persistenzschicht für Java, ist diese Aufgabe nur noch eine Konfigurationssache. Titelthema Datenbanken 08...Hysterie um Histogramme Details zu Statistiken, die für den kostenbasierenden Optimizer von Oracle wichtig sind. Durch die Analyse von Tabellen etc. kann man sich Performance-Vorteile verschaffen aber auch zunichte machen Jobsteuerung mit dem Microsoft SQL Server (Teil I) Grundlagen der Jobsteuerung mit dem Microsoft SQL Server. Beispielhaft werden Möglichkeiten gezeigt, Aufträge mit mehreren Auftragsschritten unterschiedlichen Typs anzulegen Top Secret: Verschlüsseln auf Spaltenebene... Das neueste Security Feature des Informix Dynamic Servers Mit Hilfe der Column Level Encryption können die Daten nun auch innerhalb der Datenbank verschlüsselt werden PL/SQL Web-Services (Teil I) Wir stellen das Programm JPublisher vor, mit dem eine Veröffentlichung von PL/SQL-Programmen als Web-Service leicht möglich ist Neues bei Oracle: 10gR2 (Teil I) Übersicht über neue Features von Oracle 10g Release 2. Titelthema 46...Oracle 10g (Teil VI): Automatic Workload Repository Überblick über das Automatic Workload Repository (AWR), mit dem Oracle seit Version 10g Daten sammelt und auswertet. AWR ist Statspack-Kennern nicht ganz neu. Projekt management 20...Ein guter Titelthema Projektmanager ist ein Manager Zusammenstellung der wesentlichen Erfolgsfaktoren im Bereich Projektmanagement und der notwendigen Kompetenzen und Fähigkeiten, die ein erfolgreicher Pro - jektmanager braucht Seminar IT-Projektmanagement Unix/Linux/Open Source Titelthema 12...Tiefe Einblicke in Solaris 10 mit DTrace Mit Hilfe von DTrace stellt Sun für Solaris 10 ein mächtiges und komfortables Werkzeug zur Verfügung, um unterschiedliche Systemereignisse zu protokollieren und damit Programme z. B. in Problemfällen zu analysieren oder Performance- Engpässe aufzudecken Es ist nicht einfach, wenn man`s doppelt nimmt!? LDAP im shared-nothing Cluster durch Heartbeat unter Linux ist eine preisgünstige Alternative zu herkömmlichen Cluster-Lösungen. Wir zeigen eine verblüffend einfache Konfiguration. 3

4 Java/XML Ein Lösungsansatz für Probleme in der objektorientierten Software-Entwicklung Von POJOs und anämischen Objekten J2EE, SOA und wie sie alle heißen: Bei allen neuen Techniken, Technologien und Spezifikationen sollten wir in der Software-Entwicklung nicht den Blick für etwas Wesentliches verlieren. Dass das aber schnell passieren und was man dagegen machen kann, entdecken Sie in diesem Artikel. Dieser Artikel richtet sich an Entwickler objektorientierter (Java-) Lösungen und solche, die es werden wollen. Es waren einmal Sieben Stufen zur objektbasierten Glückseligkeit Geht es Ihnen auch so? Manchmal kommt einem etwas seltsam vor, aber man weiß nicht genau, was es ist. Haben Sie in letzter Zeit mal einen skeptischen Blick auf Ihre Geschäftsobjekte geworfen, d. h. in die Klassen, in denen Sie ihre Geschäftsdaten erwarten? Sie finden dort sicher Ihre sämtlichen Geschäftsdaten sauber modelliert vor. In den meisten Fällen auch noch mit den entsprechenden Get- und Set-Methoden. Der eine oder andere Konstruktor ist meist ebenfalls anzutreffen. Soweit so gut. Und wenn Sie dort noch wesentlich mehr (Methoden) antreffen, brauchen Sie an dieser Stelle vermutlich gar nicht erst weiter zu lesen. Sollten Sie aber kaum mehr als das Genannte vorfinden, dann sollten Sie zumindest ein wenig ins Grübeln kommen: War da nicht etwas mit der Objektorientierung? Wenn man die Get- und Set-Methoden und den Konstruktor vernachlässigt, stellt man fest, dass man es in den Klassen eigentlich nur mit den klassischen Strukturen der prozeduralen Programmiersprachen zu tun hat. Dazugehörende Geschäftslogik: Fehlanzeige! Anders ausgedrückt, wodurch unterscheidet sich diese Implementierung von beispielsweise einem C-Programm mit einem einfachen struct? Sind wir auf Bertrand Meyers Sieben Stufen zur objektbasierten Glückseligkeit [1] etwas ins Stolpern geraten? Offensichtlich. Die Frage ist nur, ob uns nicht jemand anderes aus dem Tritt gebracht hat? In der aktuellen Software-Entwicklung gibt es einige Gesellen, denen so etwas zuzutrauen ist. Schuld ist das Management Vermutlich der älteste unter diesen Gesellen ist die Managementoder Controller-Klasse, die durchaus nahezu immer ihre Daseinsberechtigung hat. Ursprünglich gedacht, um die eigentlichen Geschäftsobjekte zu verwalten, ist die Versuchung groß, dort auch gleich ein wenig Geschäftslogik unterzubringen. Und wenn Sie nicht aufpassen, sind die Grenzen bald verwischt. Und das ist noch steigerungsfähig: Beim nächsten Refactoring wird die restliche Geschäftslogik sauber aus den ursprünglichen Geschäftsklassen entfernt und in die Management-Klasse(n) verlagert. Die ursprüngliche Geschäftsklasse wird somit zur reinen Datenstruktur degradiert. Anämische Objekte Martin Fowler nennt so etwas Anämische Objekte und hat daraus gleich ein schreckliches Anti-Pattern gemacht, das AnemicDomain- Model. ( The fundamental horror of this antipattern is, that it s so contrary to the basic idea of object-oriented design; which is to combine data and process together. ) Auch er nennt Ross und Reiter als weitere Anstifter für dieses So-sollte-es-nicht-sein : Dies sind alle Frameworks, Spezifikationen und Bibliotheken, die umfangreiche Konventionen und externe Abhängigkeiten für die eigenen Klassen erzwingen. Das können beispielsweise zwingend zu implementierende Schnittstellen, einzuhaltende Namenskonventionen oder notwendige Annotationen sein. Mit den J2EE Entity Beans sind auch gleich die Lieblingsschurken der Szene ausgemacht. Doch auch JDO oder andere Object-Relational(O/R)-Mapper verführen den ahnungslosen Entwickler schnell und komfortabel, diese blutarmen Klassen zu entwerfen. Und da passt es sehr gut, dass sich momentan alles um Services dreht: Eine service-orientierte Architektur (SOA), Web-Services oder zumindest aber ein Service Layer muss die Applikation haben. Darin lässt sich dann hervorragend die gesamte Geschäftslogik unterbringen. Somit fügt sich zusammen, was nicht zusammen gehört und alles hat seinen Platz: Die Daten in den Entity-Klassen und die Business-Logik in den Service-Methoden bzw. -Funktionen. Weit verbreitet Das Erstaunliche an diesem Anti-Pattern ist, dass es den Entwicklern mit einer datenzentrierten Vergangenheit kaum auffällt. Da es doch 4

5 Java/XML noch den einen oder anderen Entwickler mit dieser Vergangenheit gibt, kann man sich die Verbreitung dieses Anti-Patterns ausmalen. Ehre wem Ehre gebührt Zur Ehrenrettung aller Services muss auf jeden Fall gesagt werden, dass auch sie einen berechtigten und wichtigen Platz in der Software-Technologie haben. Allerdings ist ihre Aufgabe oft wesentlich dedizierter als das, was ich manchmal zu Gesicht bekomme. Diese Services sollten nämlich in einer möglichst dünnen Schicht über den Geschäftsobjekten liegen und enthalten per Definition erst einmal keine Geschäftsregeln und kein Business-Know-how. Vielmehr benutzen sie dafür die ihnen unterliegenden Geschäftsobjekte, um beispielsweise größere Aufgaben zu koordinieren oder mit anderen Anwendungen oder einem Benutzer zu kommunizieren. Retter in der Not Bei so vielen Bösewichtern fehlt der heldenhafte Retter in der Not. Und es gibt ihn tatsächlich, wenngleich sein Name wenig ruhmreich klingt: POJO. POJO ist die Abkürzung für Plain Old Java Object, also ein eigentlich ganz normales Objekt der guten, alten, objektorientierten Schule. Der Ausdruck wurde u. a. von Martin Fowler geprägt, um diese Objekte von anderen zu unterscheiden, die mit vielen externen Abhängigkeiten und Konventionen belastet sind. Entity Bean versus Hibernate Dies ist keine Abrechnung mit den J2EE EJBs zumal eine solche mit der Einführung von EJB 3.0 etwas zu spät käme. Es geht in diesem Beitrag um ein gutes Beispiel für die hier genannten Probleme. Von daher stellt der Artikel auch keinen ansatzweise vollständigen Vergleich dar. Während Hibernate als POJO-Implementierung kaum Vorgaben bei der Programmierung der Geschäftsobjekte macht, mussten wir bei EJBs bisher immer das Remote und Home Interface sowie etliche, oft überflüssige Callback-Methoden implementieren. Durch Fleißarbeit oder entsprechende Tools war dies bisher noch zu kompensieren. Das gelingt jedoch dann nicht mehr, wenn objektorientierte Grundlagen wie Vererbung und Polymorphie der EJBs untereinander nicht möglich sind. Das hat dann gleichzeitig einen wesentlichen Einfluss auf das Design der Anwendung. Wir waren mit der Objektorientierung einmal angetreten, die fachlichen Probleme dieser Welt zu lösen. Daher ist es ernüchternd, festzustellen, dass wir uns für bestimmte technische Anforderungen, wie z. B. die Möglichkeit einer Anwendungsverteilung, von Anfang an in unseren Ausdrucksmitteln beschneiden lassen. Abb. 1: Anmerkungen zur Implementierung. Mit POJOs lassen sich also ohne externe Zwänge alle Geschäftsdaten, -regeln und -verfahren modellieren. Der Entwickler kann sich voll und ganz auf die fachliche Entwicklung konzentrieren und sich dabei aus dem vollen Baukasten der Objektorientierung bedienen. POJOs stellen zwar bei weitem keine Garantie für gutes Design dar, sind aber zumindest eine gute Grundlage dafür. Rein technisch und organisatorisch lässt sich auf jeden Fall sagen, dass ein POJO durch die in sich ruhende Unabhängigkeit leichter wart- und wiederverwendbar ist. POJOs stellen auch eine wichtige Basis für eine komponentenorientierte Architektur dar. Das fängt bereits mit der guten Testbarkeit eines POJOs an. public class Umsatzberechnung { // 1. ext. Abhängigkeit (Logging): private final static Log log = new SimpleLog("TEST"); public double berechnegesamtumsatz() { // 2. ext. Abhängigkeit (Datenquelle): TestDatenKundenDB kundendb = new TestDatenKundenDB(); Kunde[] allekunden = kundendb.getall(); double sum = 0; for (int i = 0; i < allekunden.length; i++) { log.debug("addiere Kunde " + allekunden[i].getname()); sum += allekunden[i].getgesamtumsatz(); return sum; public static void main(string[] args) { Umsatzberechnung berechnung = new Umsatzberechnung() ; System.out.println(berechnung.berechneGesamtUmsatz()); Abb. 2: Beispiel für eine Umsatzberechnung mit zwei externen Referenzen. 5

6 Java/XML public class Umsatzberechnung { private Log log; private KundenDB kundendb; public double berechnegesamtumsatz() { // 1. ext. Abhängigkeit (Datenquelle): Kunde[] allekunden = kundendb.getall(); double sum = 0; for (int i = 0; i < allekunden.length; i++) { // 2. ext. Abhängigkeit (Logging): log.debug("addiere Kunde " + allekunden[i].getname()); sum += allekunden[i].getgesamtumsatz(); return sum; public void setkundendb(kundendb kundendb) { this.kundendb = kundendb; public void setlog(log log) { this.log = log; public static void main(string[] args) { Umsatzberechnung berechnung = new Umsatzberechnung() ; berechnung.setkundendb(new TestDatenKundenDB()); berechnung.setlog(new SimpleLog("TEST")); System.out.println(berechnung.berechneGesamtUmsatz()); Abb. 3: Beispiel für eine mit dem Dependency Injection Prinzip verbesserte Umsatzberechnung. Versuchen Sie dagegen, mal eben auf die Schnelle ein Entity Bean zu testen. Diese Beans sind perfekt in die J2EE-Umgebung integriert, so dass ein Herauslösen insbesondere nur zu Testzwecken eine echte Herausforderung darstellt. Diese Schwachstelle ist aber mittlerweile identifiziert und geht mit der Enterprise Java Beans (EJB) 3.0 Spezifikation in Richtung POJO. Maßgeblichen Einfluss auf diese Entwicklung hatte das O/R-Mapping-Tool Hibernate (siehe Abbildung 1). Als einer der Stars der Open Source Szene hat Hibernate gezeigt, wie einfach eine Persistenzschicht aussehen kann und wie einfach sie benutzt werden kann. Lesen Sie mehr zu Hibernate auf Seite 39. Auch andere Open Source Projekte, wie z. B. Spring, Hivemind und PicoContainer, sind als kleine, aber feine (Teil-)Alternativen zu den großen und mächtigen J2EE-Umgebungen entstanden. Sie werden daher oft als leichtgewichtige Frameworks bezeichnet. Eine kleine Randbemerkung: Streng genommen sind auch Java- Beans keine POJOs, da sie per Konvention Get- und Set-Methoden enthalten müssen, um Zugriff auf ihre Properties zu ermöglichen. Allerdings sollten wir diesen Umstand nicht überbewerten. Objekte mit Objekten injizieren Interessant ist die Frage Wie gehen diese Frameworks mitsamt ihrer POJOs denn mit externen Abhängigkeiten um? Externe Abhängigkeiten komplett zu ignorieren, würde sie nutzlos machen. In Abbildung 2 ist eine Umsatzberechnung für Kunden dargestellt, die zwei externe Referenzen aufweist. Die eine externe Abhängigkeit entsteht durch die Verwendung der Log-Klasse und die andere durch die Instanziierung der Datenquelle für Kundendaten. Aktuell werden also ganz konkrete Implementierungen für das Logging und den Zugriff auf Kundendaten zum Test benutzt. Es ist nun aber nicht möglich, die Klasse unverändert auch für die Produktivdaten zu benutzen. Ähnliche Probleme hat man beim Ändern der Logging-Implementierung. Ändert man sie zu diesem Zweck, so ist sie wiederum nicht länger in einem automatischen Test zu verwenden. Es muss also eine Lösung geben. Auch hier haben wir es Martin Fowler zu verdanken, dass die eigentlich sehr einfache Lösung einheitlich unter Inversion-of-Control oder seit einiger Zeit unter Dependency Injection bekannt geworden ist. Dependency Injection heißt, dass die Kontrolle über bestimmte Vorgänge über eine definierte Schnittstelle nach außen verlagert wird. Dabei wird, meist zur Laufzeit, das Objekt mit anderen Objekten injiziert, die die fachfremden Aufgaben durchführen. Die oben genannten 6

7 I Java/XML Open Source Projekte, wie Spring und Hivemind, ermöglichen dies und machen davon sehr intensiven Gebrauch. Das einfache Beispiel aus Abbildung 2 ist in Abbildung 3 nach dem Dependency Injection Prinzip verbessert worden. Für die Kundendaten-Schnittstelle ist hier ein eigenes Interface definiert und verwendet worden, das alle notwendigen Methoden enthält. Für das Logging wiederum wurde auf das Interface des Apache Jakarta Common Logging Projektes zurückgegriffen. Entscheidend ist, dass die Klasse diese beiden Schnittstellen nach außen öffnet und dass das aufrufende Code-Segment diese Schnittstellen vorher setzt (in diesem Fall die main- Methode). Wer sagt, das sei nichts wirklich Neues, hat Recht. Es kommt nur auf die konsequente Umsetzung an. Nur so lässt sich diese Klasse in einem beliebigen Kontext einsetzen und insbesondere auch testen. Einige der o. g. Frameworks wie z. B. Hivemind können diese Verknüpfung auf Basis einer entsprechenden Definition auch automatisch erstellen (auto-wiring). Dem Entwickler bleibt diese Arbeit dann weitestgehend erspart. Fazit Die vorangegangenen Worte üben zwar Kritik an J2EE oder vergleichbaren Spezifikationen im Allgemeinen, jedoch keineswegs so grundlegend, dass der Autor von ihrer Verwendung abraten würde. Dazu haben sie zu viele Vorteile. Vor- und Nachteile sollten im jeweiligen Kontext individuell betrachtet werden. Allerdings sollten wir bei allen Spezifikationen und neuen Entwicklungstrends nie die ursprünglichen Grundlagen aus den Augen verlieren. Stolperfallen sollten als solche identifiziert und umgangen werden. Auch ein (selbst)kritischer Umgang mit neuen Technologien und Spezifikationen kann helfen. Wenn die Kritik dabei nicht nur die Qualität der eingesetzten Tools und Frameworks beleuchtet, sondern ebenfalls hinterfragt, inwieweit wir die dahinter stehenden Konzepte auch wirklich verstanden haben, dann sind wir einen Schritt weiter gekommen auf dem Weg zur produktiven Software-Entwicklung. Axel Röber (info@ordix.de). Links Literatur Glossar Annotations Anti-Pattern JDO Inversion of Control Containers and the Dependency Injection pattern, Martin Fowler: AnemicDomainModel, Martin Fowler: POJO auf Wikipedia: [1] Objektorientierte Softwareentwicklung, Bertrand Meyer, Hanser Verlag, 1988 [2] JDO auf Wikipedia: [3] J2EE auf Wikipedia: J2EE O/R-Mapper Anmerkungen im Java Source Code, die zur Laufzeit des Programms ausgewertet werden können. Annotations sind seit Java 5 Bestandteil von Java. Als geistigen Vater dieser Annotations kann man das Open Source Projekt XDoclet ansehen. XDoclet erlaubte es, auch schon in früheren Java Versionen mit Annotations zu programmieren. Während Pattern oder Entwurfsmuster in der Software-Entwicklung beschreiben, wie man bestimmte Aufgabenstellungen löst, weist ein Anti-Pattern auf Lösungen und die damit verbundenen Probleme hin, die man besser nicht wählen sollte. Die Java Data Objects (JDO) sind eine Spezifikation für ein herstellerunabhängiges Framework zur persistenten Speicherung von Java-Objekten in transaktionalen Datenspeichern, zum Beispiel relationalen Datenbanken (Quelle: [2]). Java 2 Platform, Enterprise Edition ist die Spezifikation einer Standardarchitektur für die Ausführung von J2EE-Applikationen. Hierzu werden in der Spezifikation Softwarekomponenten und Dienste definiert, die primär in der Programmiersprache Java erstellt werden. Die Spezifikation dient dazu, einen allgemein akzeptierten Rahmen zur Verfügung zu haben, um mit modularen Komponenten verteilte, mehrschichtige Anwendungen zu entwickeln. Klar definierte Schnittstellen zwischen den Komponenten und Schichten sollen dafür sorgen, dass Softwarekomponenten unterschiedlicher Hersteller interoperabel sind, wenn sie sich an die Spezifikation halten, und dass die verteilte Anwendung gut skalierbar ist (Quelle: [3]). In jüngerer Zeit hat Sun diesen (und andere) Namen geändert, in dem es die 2 aus dem Namen genommen hat, um etwas versionsunabhängiger zu sein. Object/Rational Mapper werden eingesetzt, um in objektorientierten Programmiersprachen Objekte auf (Datenbank-)Relationen zu mappen. Mit ihnen ist es möglich, diese Objekte in einer relationalen Datenbank abzuspeichern und wieder daraus zu erstellen. Dies geschieht weitestgehend automatisch, so dass sich der Entwickler nicht um die eigentliche Datenbankschnittstelle kümmern muss. 7

8 Datenbanken Titelthema Statistiken unter Oracle 9i Erweiterte Statistiken unter Oracle 9i in der Praxis Hysterie um Histogramme Zur möglichst effizienten Ausführung von SQL-Statements kann bei Oracle der Cost Based Optimizer eingesetzt werden. Dieser erstellt den Ausführungsplan anhand statistischer Informationen, die über die Daten vorliegen. Hierbei spielt die Güte der Statistik offenbar eine große Rolle. Aber auch andere Faktoren sind zu berücksichtigen. Dieser Artikel richtet sich an Oracle Datenbankadministratoren, die sich mit dem Thema Statistikerzeugung und -pflege unter Oracle 9/10 beschäftigen. Es werden Details zu Statistiken angesprochen, die für den kostenbasierenden Optimizer von Oracle wichtig sind. Durch die Analyse von Tabellen etc. kann man sich Performance-Vorteile verschaffen aber auch zunichte machen. Dieser Artikel richtet sich an Oracle Datenbankadministratoren, die sich mit dem Thema Statistikerzeugung und -pflege unter Oracle 9/10 beschäftigen. Der Gleichverteilungsansatz Gegenüber dem Rule Based Optimizer (RBO), der ein starres Regelwerk bei der Erstellung des Ausführungsplans abarbeitet, fließen bei dem Cost Based Optimizer (CBO) auch statistische Daten bei der Entscheidungsfindung ein. Dies kann insbesondere dann von Vorteil sein, wenn die Daten nicht gleich verteilt sind. Mit Hilfe von Statistiken kann eine Aussage zur Selektivität der Daten getroffen werden. Damit hat der CBO ein wichtiges Kriterium für den Ausführungsplan an der Hand. Auf dieser Grundlage trifft der CBO eine Vorhersage für die günstigste Zugriffsart oder die optimale Join Order. Als Beispiel betrachten wir eine einfache Tabelle T1 bei der in der Spalte C1 die Werte 1 bis 20 auftreten. Die absolute Häufigkeit der einzelnen Werte ist in Abbildung 1 dargestellt. Der Wert 5 kommt mit deutlichem Abstand am häufigsten vor, die restlichen Zahlen sind in etwa gleich verteilt. Wird für T1 eine einfache Statistik erzeugt (ANALYZE TABLE oder dbms_stats.gather_table_stats ohne FOR-Klausel) geht Oracle zunächst von einer Gleichverteilung der Datensätze aus. Das be- Häufigkeit Datenverteilung der Tabelle T Wert Abb. 1: Absolute Häufigkeit der Werte der Beispieltabelle. deutet, dass bei einem SELECT wie in Abbildung 2 ein Index-Zugriff stattfindet, da vermeintlich 1/20, also 5 Prozent der Gesamtdaten betroffen sind. Das zeigt auch der zugehörige Ausführungsplan in Abbildung 2. Ein Full Table Scan (FTS) wäre an dieser Stelle effizienter gewesen (siehe Abbildung 3). Deutlich erkennbar ist die Diskrepanz zwischen geschätzten und realen Kosten. Histogramme zur Darstellung von Schieflagen Um dem CBO Informationen über die Verteilung der Daten zur Verfügung zu stellen, müssen erweiterte Statistiken generiert werden. Dies geschieht in Form von Histogrammen, die von ANALYZE TABLE oder dbms_stats. gather_table_stats mit FOR-Klausel erzeugt werden. Dabei kann die Granularität über die Anzahl der zu erzeugenden Intervalle als size-parameter übergeben werden. Bei (großen) Tabellen mit vielen, unterschiedlichen Werten wird ein so genanntes Height Based Histogramm erzeugt. Die Bezeichnung kommt daher, weil die Unterteilung der Daten so erfolgt, dass in jedem Intervall etwa gleich viele Daten liegen. Betrachten wir dazu wieder unser Beispiel von oben. Zur Abschätzung der Zahlenverteilung sollen 10 Intervalle benutzt werden: SQL> exec dbms_stats.gather_table_ stats('rn', 'T1', method_opt => 'for columns c1 size 10'); Um die Intervalle alle auf eine Höhe zu bringen, muss eine Ungleichverteilung vorausgesetzt die Intervallbreite variabel sein. Dabei kann es vorkommen, dass sich ein einzelner Wert über mehrere Intervalle erstreckt. Anders ausgedrückt, haben dann mehrere Intervalle denselben Endpunkt. 8

9 Datenbanken SQL> select * from t1 where c1 = 5; Zeilen ausgewaehlt. Ausfuhrungsplan SELECT STATEMENT Optimizer=CHOOSE (Cost=42 Card=942 Bytes=195936) 1 0 TABLE ACCESS (BY INDEX ROWID) OF 'T1' (Cost=42 Card=942 Bytes=195936) 2 1 INDEX (RANGE SCAN) OF 'T1_C1_IDX' (NON-UNIQUE) (Cost=2 Card=942) Statistiken recursive calls 0 db block gets consistent gets 0 physical reads 0 redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client 887 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) rows processed Abb. 2: Ausführungsplan, nach Ermessen des Cost Based Optimizers. SQL> select /*+ Full(T1) */ * from t1 where c1 = Zeilen ausgewahlt. Ausfuhrungsplan SELECT STATEMENT Optimizer=CHOOSE (Cost=106 Card=942 Bytes=195936) 1 0 TABLE ACCESS (FULL) OF 'T1' (Cost=106 Card=942 Bytes=195936) Statistiken recursive calls 0 db block gets 1546 consistent gets 41 physical reads 0 redo size bytes sent via SQL*Net to client bytes received via SQL*Net from client 887 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) rows processed Abb. 3: Ausführungsplan mit Hinweis auf den Full Table Scan. In der View USER_TAB_HISTOGRAMS (siehe Abbildung 4) kann man sich das Histogramm ansehen: Die Spalte ENDPOINT_NUMBER gibt die Intervallnummer und ENDPOINT_VALUE den Wert der Intervallgrenze an. Kommen Intervallgrenzen mehrfach vor, wird nur die mit der höchsten Intervallnummer ausgegeben. Bei zehn Intervallen repräsentiert dann jedes einzelne ein 10-prozentiges Vorkommen der Werte im Intervall. In unserem Beispiel ist der Wert 5 Endpunkt von sieben Intervallen, woraus auf ein Vorkommen von etwa 70 Prozent geschlossen werden kann. Den restlichen Zahlen bleibt demnach insgesamt nur eine Häufigkeit von 30 Prozent. Dies spiegelt die tatsächlichen Verhältnisse sehr gut wieder. Mit Hilfe dieses Histogramms entscheidet sich der CBO nun auch ohne Hint für einen Full Table Scan, wenn nach der Zahl 5 selektiert wird. In allen anderen Fällen wird weiterhin über den Index gegangen. Ein nicht ganz so präzises, aber in unserem Beispiel völlig ausreichendes Ergebnis hätte man auch mit der Intervallzahl 3 erzielen können: Die 5 ist Endpunkt zweier Intervalle und hat damit eine geschätzte Häufigkeit von 2/3. Hier lohnt sich ein Full Table Scan! 9

10 Datenbanken SQL> select * from user_tab_histograms where table_name = 'T1' order by column_name, endpoint_value TABLE_NAME COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE T1 C1 0 1 T1 C1 1 5 T1 C1 2 5 T1 C1 3 5 T1 C1 4 5 T1 C1 5 5 T1 C1 6 5 T1 C1 7 5 T1 C1 8 8 T1 C T1 C Abb. 4: Darstellung des Histogramms in USER_TAB_HISTOGRAMS. Die farblich markierten Zeilen 2-7 werden in der View nicht dargestellt und sind hier nur zum besseren Verständnis eingefügt. SQL> select * from user_tab_histograms where table_name = 'T1' order by column_name, endpoint_value TABLE_NAME COLUMN_NAME ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_ACTUAL_VALUE T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C T1 C Abb. 5: Value Based-Histogramm der Tabelle T1. Value Based, Height Based Ein Sonderfall tritt auf, wenn die Intervallanzahl größer oder gleich der Anzahl der unterschiedlichen Werte der betreffenden Spalte ist (ist der Spalte NUM_DISTINCT in der Standard-View USER_ TAB_COLUMNS zu entnehmen). Dann kann jeder Wert in ein eigenes Intervall fallen und es wird ein Histogramm im klassischen Sinne erzeugt. Im Gegensatz zum zuvor beschriebenen wird es auch als Value Based bezeichnet. In diesem Fall muss die Spalte ENDPOINT_NUMBER anders interpretiert werden, nämlich als kumulierte Histogrammhöhe. Das heißt, in diesem Fall kann man die tatsächliche Häufi gkeit eines Wertes berechnen, indem man von seiner ENDPOINT_NUMBER die des Vorgängers abzieht. Ab Oracle 10g ist die Art des Histogramms in der View USER_TAB_COLUMNS in der Spalte HISTOGRAM hinterlegt. Mögliche Werte sind none, frequency (value based) und height balances (height based). Leider ist diese Spalte in Oracle 9i noch nicht verfügbar. Trotzdem ist eine Unterscheidung möglich. Generell kann nur bei einem Height Based-Histogramm in der Spalte ENDPOINT_NUMBER ei- 10