TSM Data Protection for Oracle9i
Diese
Seite drucken
TSM Data Protection for Oracle9i |
Diese
Seite drucken |
Vorbemerkungen
Hier dokumentiere ich die Einrichtung des IBM Tivoli Storage Manager for Databases for Oracle bei uns am RZ. Diese Dokumentation dient hauptsächlich der Dokumentation für mich und meine Kollegen.
Unsere Konstellation :
TSM Server Version 5.1 auf AIX-RS/6000
Zieldatenbank: z. B. Oracle 9.2.0.x oder 10g auf RedHat Enterprise Linux Advanced Server 3.0 (RH EL 3.0)
optional: Oracle Management Server mit OMS-Repository, z.B. Oracle 9.2.0.1auf RedHat AS 2.1 (RH AS 2.1)
Zum Verständnis dieses Dokuments setze ich Kenntnisse über folgende Anwendungen voraus
(oder man muss jemanden kennen, der das weiß, was man da wissen muss...):
Dazu existieren auf diesem Server folgende Dokumente:
Wo haben wir uns informiert?
Bei unserem freundlichen TSM-Administrator, auf der IBM- und Oracle-Website. Auf beiden Websites ist das Informationsangebot eher dürftig.
Wo kann man sich noch informieren?
Es gibt ein englischsprachiges Forum namens ADSM.ORG (http://my.adsm.org/), wo es auch einen Oracle-Bereich hat. Einiges habe ich aber nur durch 'Googeln' gefunden.
Konzept
Eine neue Komponente: Media Management Layer
Die RMAN-Architektur ist Ihnen ja bekannt und muss für unser Vorhaben um eine weitere Komponente erweitert werden, den Media Management Layer.
Oracles Recovery Manager kann nicht nur Backups auf Festplatten anlegen, sondern auch auf ein oder mehrere Bandlaufgeräte. Dazu muss man die Oracle Software so konfigurieren, dass Sie mit der Software des Backup-Produkt-Herstellers kommunizieren kann. Die Schicht zwischen den Oracle RMAN-Komponenten und der Software des Backup-Produkt-Herstellers heißt Media Management Layer. Sie wird vom Backup-Produkt-Herstellers geliefert, eine von Oracle aus ansprechbare standardisierte API haben und muss von Oracle zertifiziert sein. Bei Oracle kann man eine Liste der Backup-Produkt-Hersteller und Application Service Provider einsehen, die mit dem Recovery Manager zusammenarbeiten:
Oracle Backup Solutions Program (BSP) unter http://otn.oracle.com/deploy/availability/htdocs/bsp.htm
Wie funktioniert das Ganze?
Der Oracle DBA muss sich zunächst vergewissern, dass die Version der im Haus verwendete Backup-Server-Lösung für seine Oracle-Version(en), das Betriebsystem der Zieldatenbanken und das Betriebssystem seines OMS zertifiziert ist.
Unser Konzept ergibt sich aus der Lektüre der oben angegebenen Informationsquellen und sieht folgendermaßen aus - zum Vergrößern bitte klicken:
Links sieht man den Knoten mit der Zieldatenbank. Die Zieldatenbank ist eine Datenbank, die später auf Band gesichert werdeb soll. Den Knoten mit der Zieldatenbank nenne ich ab hier vereinfacht Zielserver oder Zielsystem. Das Zielsystem ist beim OMS eingetragen, mit dem es über seinen Intelligent Agent kommuniziert. Auf dem Zielsystem ist ein TSM Media Management Layer von TSM installiert und konfiguriert; der Knoten muss beim TSM registriert sein.
Rechts oben der Knoten mit dem OMS: Der OMS legt seine Metadaten in seinem Repository ab, einer lokalen Datenbank. Die RMAN Exexcutables sind Teil des OMS. Wie wollen den RMAN mit einem RMAN Catalog betreiben, der auch eine Datenbank auf diesem Knoten ist. Bisher haben wir ja mit dem RMAN nur Channels zu einem Festplattenspeicher aufgemacht, um das Backup dort abzulegen. Diese Möglichkeit bleibt uns weiterhin offen und ist deshalb als oberster Channel symbolisiert. Dazu wird kein MML benötigt.
Soll der RMAN aber Backups steuern, wo der Backupsatz auf Band gesichert werden soll, greift auch er auf die MML-API zu. Der MML muss also auch auf dem steuernden OMS/RMAN-Server installiert sein. Aus Gründen der Vereinfachung habe ich den MML auf dem OMS-Knoten nicht dargestellt.
Rechts unten ist der TSM-Server dargestellt. Er kann über einen Channel mit der Zieldatenbank kommunizieren. Dazu muss - wie gesagt - auf dem Zielsystem der Media Management Layer von TSM installiert und konfiguriert sein. Der MML muss seinen TSM-Server (und ggf. seinen Filespace) kennen, der TSM-Server muss wiederum den Knoten kennen. Dem RMAN ist die API des TSM bekannt, so dass er die MML API ansprechen kann, um ihr 'zu sagen', dass Sie den Channel zu ihrem TSM-Server aufmachen soll, so dass der Backupsatz nach den im RMAN abgelegten Anweisungen aufs Bandlaufwerk geschrieben werden kann.
Analog können Channels zu weiteren zertifizierten Drittanbieter-Produkten konfiguriert werden, oder zu einem Application Service Porvider, der diese Dienstleistung anbietet. Oracle plant ja übrigens, selbst in den ASP-Markt einzusteigen, um mit DBA- und Backup-Services für Mittelständler Geld zu verdienen.
An den OMS und den RMAN können wir nach Bedarf weitere Zieldatenbanken anhängen - zum Vergrößern bitte klicken:
Dazu sind folgende Schritte nötig:
Auf dem neuen Zielsystem muss der MML installiert und konfiguriert werden.
Der Zielknoten muss
Notwendige Arbeiten
Pro OMS durchzuführen: OMS Server klar machen
1. MML besorgen
Der Oracle DBA sollte sich vorher ja vergewissern, dass die Version der im Haus verwendete Backup-Server-Lösung für seine Oracle-Version(en), das Betriebsystem der Zieldatenbanken und das Betriebssystem seines OMS zertifiziert ist.
Damit hatten wir ein kleines Problem:
Unsere Zieldatenbank sitzt auf RH EL 3.0 auf, da wir uns vom neuen Kernel diverse Vorteile für Oracle-J2EE-Anwendungen versprechen. Unser TSM-Server bringt einen Media-Management-Layer mit, der aber leider noch nicht für das Betriebsystem RH EL 3.0 zertifiziert ist, sondern nur für RH AS 2.1. Wir haben es einfach ausprobiert: Der MML für RH AS 2.1ließ sich problemlos auf RH EL 3.0 installieren. Auch einen Testlauf absolvierte der MML bei uns erfolgreich, so dass wir uns entschlossen haben, ihn für die Zieldatenbanken auf RH EL 3.0 zu benutzen. Vorsichtshalber haben wir unseren OMS mit seinem MML auf dem dafür zertifizierten RH AS 2.1eingerichtet, da wir hier nicht gezwungen sind, RH EL 3.0 zu benutzen.
Bei uns handelte es sich um den IBM Tivoli Storage Manager for Databases Version 2 'Data Protection for Oracle for UNIX'. Den Unix Installationsguide finden Sie u.a. hier.
2. MML auf dem OMS installieren
Das läuft genauso ab wie auf einem Zielserver - bitte im nächsten Kapitel weiterlesen.
Pro Zielserver durchzuführen: Einrichten eines Zielsystems
1. MML besorgen
Den MML haben wir uns ja schon für die Installation auf dem OMS besorgt: hier liegt er .
2. MML auf dem Zielserver installieren
In unserem Paket wird eine aktuelle Installationsanleitung mitgeliefert, sie heißt README.TDPO. Außerdem gibt es natürlich einen Installationsguide, eine Kopie von unserem (IBM-Dokument S32-9064-00) liegt hier.
Hier die Installationsschritte auf RedHat Advanced Server 2.1 oder 3.0 in Kürze:
3. Zielserver bei TSM-Server anmelden
Jetzt melden Sie den Zielserver bei Ihrem TSM-Administrator an. Sie erhalten dann den Knotennamen TDPO_NODE, unter dem der Zielrechner beim TSM-Server bekannt ist, und dessen Erstpasswort.
3. MML auf dem Zielserver konfigurieren
Bitte informieren Sie sich dazu im Installationsguide, eine Kopie von unserem (IBM-Dokument S32-9064-00) liegt hier.
Und fragen Sie Ihren TSM-Administartor bei Unklarheiten!
Folgende Konfigurationsschritte müssen jetzt durchgeführt werden:
tdpo.opt setzen. Eine Vorlage dieser Datei finden Sie unter dem Namen tdpo.opt.smp im Verzeichnis /opt/tivoli/tsm/client/oracle/bin. rzpr-eis_tdp beispielsweise so aus: | * tdpo.opt
************************************************************ * IBM Tivoli Storage Manager for Databases * Data Protection for Oracle * * tdpo.opt for the Linux86 Data Protection for Oracle ************************************************************* DSMI_ORC_CONFIG /opt/tivoli/tsm/client/api/bin/dsm.opt *TDPO_FS /adsmorc TDPO_DATE_FMT 4 *TDPO_MGMT_CLASS_2 mgmtclass2 |
dsm.opt und dsm.sys setzen. dsm.opt.smp und dsm.sys.smp im Verzeichnis /opt/tivoli/tsm/client/api/bin. dsm.opt beispielsweise so aus: | * dsm.opt ************************************************************* * Tivoli Storage Manager * * Client User Options file for UNIX (dsm.opt) * ************************************************************ * * This file contains an option you can use to specify the TSM * server to contact if more than one is defined in your client * system options file (dsm.sys). Copy dsm.opt.smp to dsm.opt. * If you enter a server name for the option below, remove the * leading asterisk (*). ************************************************************** * SErvername tsm_ora_server |
dsm.sys sieht beispielsweise so aus: | * dsm.sys ******************************************************************** * Tivoli Storage Manager * * Client System Options file for UNIX (dsm.sys) * ******************************************************************* * This file contains the minimum options required to get started * using TSM. Copy dsm.sys.smp to dsm.sys. In the dsm.sys file, * enter the appropriate values for each option listed below and * remove the leading asterisk (*) for each one. * If your client * node communicates with multiple TSM servers, be * sure to add a stanza, beginning with the SERVERNAME option, for * each additional server. ***************************************************************** SErvername tsm_ora_server COMMmethod TCPip TCPPort 15xy TCPServeraddress XXXXXXX.rz.uni-karlsruhe.de passwordaccess prompt compression no |
4. Passwort ändern und Verbindung testen.
Jetzt muss das Passwort einmalig geändert werden.
Dazu gibt es bei den Utilities ein Kommandozeilenprogramm 'tdpoconf passw' . Das ist selbsterklärend.
Nun muss die Verbindung mit den eben eingestellten Optionen getestet werden.
Dazu gibt es bei den Utilities ein Kommandozeilenprogramm 'tdpoconf showenv' .
Bei uns lieferte er beispielsweise folgenden Output und zeigt damit, dass er sich mit dem TSM-Server verbinden konnte:
tdpoconf showenv IBM Tivoli Storage Manager for Databases: DATA PROTECTION FOR ORACLE INFORMATION TSM SERVER INFORMATION SESSION INFORMATION |
Damit ist der MML konfiguriert und einsatzbereit.
Pro Ziel-Datenbank durchzuführen: RMAN-Script anpassen und testen
Der RMAN braucht lediglich den Pfad zur Datei tdpo.opt zu kennen. Diesen Pfad gibt man man dem RMAN-Script als Umgebungsvariable mit, damit kann er den Channel zum Bandlaufwerk allokieren kann. Über die Zuweisung exklusiver tdpo_optfiles kann man unterschiedlichen Scripten unterschiedliche Optionen zuweisen.
In unserem Fall sieht diese Umgebungsvariable so aus:
ENV=(tdpo_optfile=/opt/tivoli/tsm/client/oracle/bin/tdpo.opt)
Petra Haberer Version
1.0.0