1. Konzept. 2. Filesystem Layout für die Oracle Software. 1.1 Startpunkt

Transkript

1 Standardisierung des Oracle Datenbankbetriebs Axel Kraft Senior Consultant

2 Die Standardisierung des Oracle Datenbankbetriebs ist zunehmend ein wichtiges Thema innerhalb einer Organisation. Die Anzahl der Datenbanken sowie die Datenmengen sind in den letzten Jahren stark gestiegen. Im Sprachgebrauch nennt man das historisch gewachsen. Doch bald werden die ersten Probleme sichtbar. Man hat Schwierigkeiten beispielsweise ein einheitliches Backupverfahren zu definieren, oder eine Datenbank ist nicht in das Monitoring zu integrieren. Dieser Artikel wird aufzeigen, wie man eine bestehende Umgebung in einen standardisierten Betrieb überführen kann. 1. Konzept Was ist eigentlich unter Standardisierung zu verstehen? Standardisierung bedeutet nichts anderes als aus bestehenden Arbeitsweisen die Beste zu wählen und sie anzuwenden. Dadurch wird sie zu einem Standard. Dabei darf nicht aus den Augen gelassen werden, diesen Standard laufend zu verbessern. Die Vorteile den Oracle Datenbankbetrieb zu standardisieren sind enorm: Der neue Standard kann von allen Mitarbeitern konsequent genutzt werden Die Einarbeitung neuer Mitarbeiter geht einfacher Es kommt zu weniger operativen Fehlern Abläufe werden einfacher, also geringere Komplexität Kosten werden minimiert Mehr Effizienz 1.1 Startpunkt Wie beginnt man die Standardisierung beziehungsweise mit welcher Komponente beginnt man? Als Basis ist die Installation der Oracle Binaries und der Oracle Datenbank ein guter Ansatzpunkt. 2. Filesystem Layout für die Oracle Software Das Filesystem Layout sollte sich an der Oracle Optimal Flexible Architecture (OFA) orientieren. Der OFA Standard wurde 1995 von der Oracle Special Performance Group verabschiedet. Der OFA Standard beinhaltet eine Reihe von Empfehlungen (Best Practices) zur Installation und Wartung der Oracle Software. Trivadis hat die OFA-Standards im Laufe der Jahre auf Basis der Betriebserfahrung und Best Practices adaptiert und angepasst. Die Vorteile einer Trivadis OFA-Struktur sind: Alle Server besitzen die gleiche Verzeichnisstruktur, unabhängig vom Betriebssystem und Hardware, dadurch erreicht man eine einfachere System- und Datenbankadministration Datenbanksicherheit ist einfacher zu gewährleisten Datenbank und datenbankanhängige administrative Dateien und Programme können zentralisiert und zentral verteilt werden Info-Tel Datum Seite 2 / 9

3 Verschiedene Kategorien von Dateien können auf verschiedene Datenverzeichnisse aufgeteilt werden. Das wiederum reduziert operationale Fehler auf nur eine Kategorie Ein neu benötigter Datenbankserver kann schneller und effizienter in die Infrastruktur implementiert werden Geschwindigkeitsengpässe können verringert werden, weil I/O über genügend viele Platten gestrippt werden kann. Die sogenannten User Home Datenverzeichnisse können über verschiedene Platten verteilt werden. Oracle Software Installation Filesystem Layout Trivadis OFA Struktur Directory Directory Directory Directory Inhalt Mount Point ORACLE_BASE Beispiel: /u00/app/oracle product Version Oracle Software Installation (bspw. RDBMS in directory _<patchset>) admin SID Administrative Dateien network admin Alle TNS-relevanten Dateien von jedem ORACLE_HOME etc Sammlung von Dateien die typischerweise auf einem nicht-ofa Filesystems angesiedelt sind. Abbildung 1: Übersicht normierte Oracle OFA-Verzeichnisstruktur Es wird empfohlen, alle non-operating system software in ein dediziertes Filesystem zu installieren. Das ist keine Grundvoraussetzung für die Oracle OFA, aber eine gute Richtlinienentscheidung im Hinblick das Softwaremanagement zu unterstützen. Unterverzeichnisse dieses Volumes können als Mountpoint erstellt werden. Das hilft, wenn Dateien verlagert werden, wenn der Plattenplatz knapp wird. Es ist also sehr wichtig, sich bei der Planung mit den 3 entscheidenden ORACLE Variablen zu beschäftigen: ORACLE_BASE ORACLE_HOME ADR_BASE 3. Datenbankfilesystem Struktur Das Kernstück von OFA ist es, eine flexible und standardisierte Filesystemstruktur bereitzustellen. info@trivadis.com. Info-Tel Datum Seite 3 / 9

4 Standardmässig wird auf den meisten Unix-Systemen die oratab unter /etc bzw. die orainst.log unter /var/opt/oracle bereitgestellt. Diese beiden Dateien sollten nach $ORACLE_BASE/etc verschoben werden. Das begründet sich darauf, dass diese beiden Dateien standardmässig ausserhalb des Softwareinstallationsbaums angelegt werden. Beim Einsatz von TVD-BasEnv wird dies vom Installer berücksichtigt. 3.1 oratab Es empfiehlt sich auch, die oratab-einträge nach bestimmten Konventionen anzupassen. Die SID sollte immer in Großbuchstaben sein. Dummy-Einträge sollten die RDBMS Version beinhalten. Beim Einsatz der Oracle Grid Infrastructure sollte die Namensgebung gridversion (Beispiel: grid11203) sein. 3.2 Oracle Net Konfiguration Normalerweise befinden sich die Dateien ldap.ora, sqlnet.ora, listener.ora, tnsnames.ora im Verzeichnis $ORACLE_HOME/network/admin. Sind nun auf einem Datenbankserver mehr als eine Oracle RDBMS Version installiert, ist es von Vorteil, die genannten Oracle Net Konfigurationsdateien zentral nur einmal in einem Verzeichnis zu haben. Dies wird erreicht, indem die Umgebungsvariable $TNS_ADMIN auf ein zentrales Verzeichnis zeigt. # echo $TNS_ADMIN /u00/app/oracle/network Abbildung 2: Setzen der Umgebungsvariable TNS_ADMIN Ausnahmen, die gegen ein zentral gesetztes Verzeichnis sprechen, müssen natürlich berücksichtigt werden. Bei der gleichzeitigen Nutzung der Oracle Grid Infrastructure und des Oracle Wallets kann das durchaus der Fall sein. In den entsprechenden Verzeichnissen $ORACLE_HOME/network/admin werden Soft-Links der Dateien auf das Verzeichnis $TNS_ADMIN erstellt. oracle@server01:/u00/app/oracle/product/ /network/admin[db01] ln s /u00/app/oracle/network/admin/tnsnames.ora tnsnames.ora oracle@server01:/u00/app/oracle/product/ /network/admin[db01] ls l lrwxrwxrwx 1 oracle oinstall 45 Jul 13 15:33 tnsnames.ora -> /u00/app/oracle/network/admin/tnsnames.ora Abbildung 3: Erzeugung von Soft-Links 3.3 Datenbanklayout Jede Datenbank sollte ihre(n) eigenen Mountpoint(s) erhalten. Das hat den Riesenvorteil, dass so eine Datenbank viel leichter von einem Server auf einen anderen Server umgezogen info@trivadis.com. Info-Tel Datum Seite 4 / 9

5 werden kann. Es wäre nur die Datenbank zu stoppen und die LUN s an dem anderen Server zu präsentieren. Für den Einsatz von Oracle ASM werden die Diskgruppen im allgemeinen genauso benannt wie die LUN s eines Filesystems. Unter Windows entspricht der Mountpoint einer LUN einem Laufwerk. Der Hauptunterschied in der OFA Implementation unter Windows besteht darin, dass keine Softlinks mit NTFS (bis zur Version 4) und FAT möglich sind. Mit NTFS 5 sind sogenannte Junctions möglich. Trivadis hat die OFA unter Windows implementiert und das Aussehen entspricht der gebräuchlichen Struktur unter Unix. 3.4 Oracle Datenbankname Der Datenbankname sollte sich einem einfachen Schema bedienen. Er sollte mit einem Großbuchstaben beginnen. Ebenso die Oracle SID. 3.5 Datenbankfilenamensgebung Es sollte die Oracle SID in die Filenamen mit aufgenommen werden. Das ist zwar kein Bestandteil der offiziellen Oracle OFA Struktur, dafür aber in der Trivadis OFA Struktur enthalten und hat sich in der Praxis als sehr hilfreich herausgestellt. Diese Namensgebung sollte für alle Datenbankdateien gelten. (Datenbankfiles, Controlfiles, Online Redo Logs, Archived Redo Logs) 4. Datenbankkonsolidierung Hat man sich für die Trivadis OFA als standardisierte Umgebung entschieden, steht man nun vor der Frage, wie die bestehende Landschaft, die der Einfachheit halber Oracle OFA konform ist, konsolidiert wird. Als erstes ist die Kenntnis der bestehenden Landschaft eine Grundvoraussetzung. Nehmen wir vereinfacht an, die Landschaft besteht aus diversen Datenbankservern. Doch beim weiteren Nachdenken stellen sich auf einmal viele zusätzliche Fragen in den Vordergrund: Wie viel Last erzeugt jetzt jede einzelne Datenbank? Wann sind die Spitzen der Last einer Datenbank? Wie viel SGA hat eine Datenbank und ist sie richtig dimensioniert? Wie viele neue Server benötigen wir zu Konsolidierung? 4.1 Ermittlung des Lastverhaltens Bei der Bestimmung des Lastverhaltens sind verschiedene Zeitpunkte zu beachten. Gibt es beispielsweise wöchentliche oder monatliche Spitzenzeiten? Hier läuft möglicherweise ein Job. Mit Systemwerkzeugen sowie Abfragen in der Datenbank sind diese Daten zu ermitteln. Sie sind dann nur noch zu historisieren. Trivadis bietet in der Trivadis Toolbox zwei Tools an, die beim Ressourcen & Configuration Management Unterstützung bieten. info@trivadis.com. Info-Tel Datum Seite 5 / 9

6 Folgenden Fragen können mit diesen Tools u. a. beantwortet werden, um das System optimal einzustellen: Wo stecken ungenutzte Potentiale? Welche Datenbankserver sind über- bzw. unterlastet? Wie verhält sich das System, wenn mehr User oder Datenbanken auf dem System hinzukommen? Welche Anwendungen verbrauchen die meisten Ressourcen? Welche Datenbanken entsprechen nicht dem vorgegebenen Konfigurationsmanagement? Welche Konfigurations- und Parametereinstellungen haben sich verändert? Die Daten werden gesammelt und in einem Repository gespeichert. Es werden keine kostenpflichtigen Optionen von Oracle verwendet. Es gibt keine zentrale Ablage von Passwörtern. Als zusammengefasstes Ergebnis über alle Datenbankserver der fiktiven Landschaft erhalten wir beispielsweise folgende Grafik. Abbildung 4: Grafik der Auslastung von Cores Wir sehen, wir haben 120 Cores über alle Datenbankserver. Im Betrachtungszeitraum von Januar 2012 bis August 2012 werden im Schnitt 10 Cores benutzt. Also sind durchschnittlich 110 Cores ungenutzt. Betrachten wir nun die Grafik für den Memory-Verbrauch. Info-Tel Datum Seite 6 / 9

7 Abbildung 5: Grafik der Auslastung des Hauptspeichers. Auch die Nutzung des Hauptspeichers zeigt noch unbenutzten Speicher an. So sind, abgesehen vom Peak vom 04. Juli bis zum 09. Juli durchschnittlich 300 GB (in Summe) belegt, während fast 800 GB zur Verfügung stehen. Somit ergibt sich eine Differenz von circa 350 GB freiem Speicher. 4.2 Konsolidierung Die in 4.1 gezeigten Grafiken der fiktiven Landschaft stellen eine Zusammenfassung über alle Datenbankserver dar. Das Ergebnis zeigt, dass genügend Ressourcen für eine Konsolidierung vorhanden sind. Im nächsten Schritt würde man nun in die Einzelbetrachtung der einzelnen Datenbankserver gehen. Danach wäre man in der Lage zu entscheiden, welche Datenbanken auf einem Server zusammengeführt werden könnten. Nun profitiert man von dem einheitlichen Filesystem Layout für die Oracle Software sowie der einheitlichen Datenbankstruktur. Da die umzuziehende Datenbank über eigene Mountpoints verfügt, sind diese nur auf dem neuen Datenbankserver zu mounten. Selbstverständlich sind die folgenden Oracle Dateien aus dem alten ORACLE_HOME mit zu übernehmen: SPFILE, Passwordfile Oracle Data Guard Konfigurationsdateien Oracle Wallets Beim Einsatz der Oracle Grid Infrastructure, beispielsweise im Oracle RAC Umfeld, sind bestehende Ressourcen im neuen System zu konfigurieren. Auch das Datenbank-Backup sowie das Datenbank-Monitoring dürfen nicht vergessen werden. Dieser Aufwand hält sich jedoch in Grenzen. Info-Tel Datum Seite 7 / 9

8 4.3 Niederschreiben der durchgeführten standardisierten Schritte Es ist eine sehr gute Idee alle Schritte bzw. alle Maßnahmen die getroffen wurden um den Betrieb zu standardisieren, in einem Betriebshandbuch festzuhalten. Die Maßnahmen und Vorgehensweisen haben eine Verbindlichkeit für den Betrieb. Die Vorteile liegen auf der Hand. Neue Mitarbeiter können sich besser einarbeiten. Alle Sever sind identisch installiert. Verantwortlichkeiten sind geklärt. Inhalte eines Betriebshandbuches können beispielweise sein: Prämissen Tägliche, wöchentliche, monatliche, vierteljährliche sowie jährliche Aufgaben Verfügbarkeitsklassen Bereitstellungsarten Serverbereitstellungen Oracle Software Installation Backup Monitoring Usw. Wichtig ist, im Vorfeld genau zu definieren wer oder welches Team für das Betriebshandbuch verantwortlich ist. Hierbei ist entscheidend, nicht nur die Änderungen entsprechend in das Dokument einzupflegen, sondern auch das Betriebshandbuch einem kontinuierlichen Aktualisierungsprozess zu unterwerfen. 5. Hindernisse vermeiden Um ein optimales Ergebnis zu erhalten und Hindernisse zu überbrücken, hat sich die in der folgenden Auflistung beschriebene Vorgehensweise bewährt. Wegstrecke zur Standardisierung: Analyse der IST-Situation: o Generelles sammeln aller tatsächlichen Arbeitsabläufe Auswahl der optimalen Arbeitsabläufe Verifizierung und Bestätigung der optimalen Arbeitsabläufe: o Verprobung der ausgewählten Arbeitsabläufe in der Praxis. Gegebenenfalls Optimierung dieser Arbeitsabläufe. Standardarbeitsweisen im täglichen Arbeitsablauf prüfen: o Betriebspersonal muss die Methoden fehlerlos beliebig reproduzieren können. Dokumentation der Arbeitsabläufe: o Die standardisierten Arbeitsweisen niederschreiben. (Betriebshandbuch) 6. Fazit Der Einsatz der Trivadis OFA-Struktur hat sich beim Standardisieren von Oracle Datenbank Umgebungen bewährt. Und das trifft nicht nur auf Single-Instance Umgebungen zu. Auch in Hochverfügbarkeitsumgebungen wie Oracle Real Application Cluster und Oracle Data Guard ist dieses Vorgehen sinnvoll. Ein weiterer wichtiger Punkt ist die Ermittlung der tatsächlich benötigten Ressourcen. Das ist eigentlich der schwierigste, beziehungsweise der aufwendigste Teil, der Schlüssel zum Erfolg. Die korrekte Dokumentation aller relevanten Arbeitsabläufe ist unabdingbar. Jedoch endet die Standardisierung damit nicht. Standardisierung ist ein kontinuierlicher Prozess. info@trivadis.com. Info-Tel Datum Seite 8 / 9

9 Viel Erfolg beim Einsatz von Trivadis-Know-how wünscht Ihnen Axel Kraft Trivadis GmbH Industriestraße 4 Tel: D Stuttgart Fax: Internet: Mail: info@trivadis.com Literatur und Links Oracle Database Installation Guide (Optimal Flexible Architecture) info@trivadis.com. Info-Tel Datum Seite 9 / 9