BC R/3-Datenbank-Leitfaden: DB2/400

Transkript

1 BC R/3-Datenbank-Leitfaden: DB2/400 HELP.BCDBDB4DBA Release 4.6C

2 SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher Form auch immer, ohne die ausdrückliche schriftliche Genehmigung durch SAP AG nicht gestattet. In dieser Publikation enthaltene Informationen können ohne vorherige Ankündigung geändert werden. Die von SAP AG oder deren Vertriebsfirmen angebotenen Software-Produkte können Software- Komponenten auch anderer Software-Hersteller enthalten. Microsoft, WINDOWS, NT, EXCEL, Word, PowerPoint und SQL Server sind eingetragene Marken der Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390 und OS/400 sind eingetragene Marken der IBM Corporation. ORACLE ist eine eingetragene Marke der ORACLE Corporation. INFORMIX -OnLine for SAP und Informix Dynamic Server TM sind eingetragene Marken der Informix Software Incorporated. UNIX, X/Open, OSF/1 und Motif sind eingetragene Marken der Open Group. HTML, DHTML, XML, XHTML sind Marken oder eingetragene Marken des W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA ist eine eingetragene Marke der Sun Microsystems, Inc. JAVASCRIPT ist eine eingetragene Marke der Sun Microsystems, Inc., verwendet unter der Lizenz der von Netscape entwickelten und implementierten Technologie. SAP, SAP Logo, R/2, RIVA, R/3, ABAP, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mysap.com Logo und mysap.com sind Marken oder eingetragene Marken der SAP AG in Deutschland und vielen anderen Ländern weltweit. Alle anderen Produkte sind Marken oder eingetragene Marken der jeweiligen Firmen. 2 April 2001

3 SAP AG Symbole Symbol Bedeutung Achtung Beispiel Hinweis Empfehlung Syntax April

4 SAP AG Inhalt...5 Datensicherung und Wiederherstellung... 7 Aufzeichnen und COMMIT-Steuerung... 8 Einschränkungen beim Aufzeichnen und bei der Wiederherstellung R/3-Sicherungsstrategien Sicherungsstrategie 1: Rückspeichern und Wiederherstellung Sicherungsstrategie 2: Nur Rückspeichern Automatisierung der täglichen Datensicherungsroutine Tabelle SPTH Befehl SAVR3SYS Sicherung des R/3-Systems mit BRMS Was müssen Sie sichern? Für eine R/3-Systemsicherung relevante R/3-Verzeichnisse Welche Objekte sollten Sie NICHT sichern oder rückspeichern? Sicherungsmethoden Objekte sichern Funktion Save While Active Offline-Sicherung des gesamten AS/400-Systems einschließlich R/3 durchführen Online-Sicherung mit SAVR3SYS durchführen Sicherung aller R/3-Komponenten R/3-Komponenten mit dem Befehl SAVR3SYS sichern R/3-Komponenten manuell sichern IFS-Objekte sichern Objekte rückspeichern und wiederherstellen Gesamtes AS/400-System einschließlich R/3 rückspeichern/wiederherstellen Alle R/3-Komponenten rückspeichern/wiederherstellen IFS-Objekte rückspeichern Handhabung von SQL-Paketen April 2001

5 SAP AG Einsatzmöglichkeiten Diese Dokumentation ermöglicht es Ihnen, Ihre DB2/400-Datenbank mit dem R/3-System zu verwalten. Sie richtet sich an System- und Datenbankverwalter, die das IBM-Buch OS/400 Backup and Recovery (Dokumentnummer SC ) gelesen oder Zugriff darauf haben. Sie sollten auch den Hinweis lesen (Latest-News-Hinweis für Release 4.6B). Dieser Hinweis wird regelmäßig mit den neuesten Informationen zur Datensicherung und Wiederherstellung aktualisiert. Die in dieser Dokumentation enthaltenen Informationen stellen lediglich eine SAPspezifische Anleitung dar und können in keinster Weise die Informationen ersetzen, die in den IBM-Büchern enthalten sind. Diese Bücher sollten Sie sehr sorgfältig lesen. Wenn Sie Hilfe zu Themen der Datensicherung und Wiederherstellung benötigen, wenden Sie sich an IBM. Einführungshinweise Informationen über die Installation der DB2/400-Datenbank mit dem R/3-System finden Sie in der Dokumentation Installing R/3 on IBM AS/400. Integration SAP erleichtert die DB2/400-Datenbankverwaltung durch verschiedene DBA-Funktionen im Computing Center Management System (CCMS) des R/3-Systems. Siehe auch SAP/DB2/400- DBA im CCMS [Extern]. Wenn Sie eine andere Datenbank verwenden, lesen Sie die entsprechende Dokumentation zu den verfügbaren Funktionen: R/3-Datenbank-Leitfaden: ADABAS for R/3 [Extern] R/3 Database Guide: DB2 Universal Database [Extern] [Extern] R/3 Database Guide: Informix [Extern] [Extern] R/3 Database Guide: MS SQL Server [Extern] R/3-Datenbank-Leitfaden: Oracle [Extern] Funktionsumfang Datensicherung und Wiederherstellung [Seite 7] Diese Dokumentation beschreibt, welche Objekte Sie für eine R/3-Systemsicherung sichern müssen, und liefert Vorgehensweisen für die Sicherung und Wiederherstellung von Objekten. Handhabung von SQL-Paketen [Seite 47] April

6 SAP AG Siehe auch: Diese Dokumentation beschreibt, wann Sie SQL-Pakete löschen müssen, und bietet Informationen zu Namenskonventionen für SQL-Paketbibliotheken und zu Meldungen im Zusammenhang mit SQL-Paketen. Informationen über die Reorganisation finden Sie im IBM Redbook SAP R/3 Implementation for AS/400 (Dokumentnummer SG ). Informationen darüber, wie Sie eine Kopie Ihrer Datenbank erstellen, finden Sie unter R/3 Homogeneous System Copy. 6 April 2001

7 SAP AG Datensicherung und Wiederherstellung Datensicherung und Wiederherstellung Einsatzmöglichkeiten Diese Dokumentation beschreibt, welche Objekte Sie im Rahmen einer R/3-Systemsicherung sichern müssen, und liefert Vorgehensweisen für die Sicherung und Wiederherstellung von Objekten. Hintergrundinformationen Aufzeichnen und COMMIT-Steuerung [Seite 8] Einschränkungen beim Aufzeichnen und bei der Wiederherstellung [Seite 10] Die richtige R/3-Sicherungsstrategie R/3-Sicherungsstrategien [Seite 11] Was müssen Sie sichern? [Seite 21] Automatisierung der täglichen Datensicherungsroutine [Seite 15] Sicherungsmethoden [Seite 28] Sicherungs- und Wiederherstellungsverfahren Objekte sichern [Seite 30] Objekte rückspeichern und wiederherstellen [Seite 41] April

8 SAP AG Aufzeichnen und COMMIT-Steuerung Aufzeichnen und COMMIT-Steuerung Ehe Sie sich für eine Sicherungsstrategie für Ihr R/3-System entscheiden, sollten Sie mit dem Aufzeichnen (Journaling) und der COMMIT-Steuerung (Commitment Control) vertraut sein. Aufzeichnen (Journaling) Hierbei handelt es sich um das Aufzeichnen aller Änderungen an Datenbankdateien. Das Aufzeichnen ermöglicht den Einsatz der COMMIT-Steuerung (siehe unten) und versetzt Sie in die Lage, diese Änderungen festzuschreiben oder, falls erforderlich, zurückzunehmen. In einer AS/400-Umgebung wird das Aufzeichnen für die COMMIT-Steuerung und die Wiederherstellung eingesetzt. Das System zeichnet die Änderungen an Datenbankdateien in einem Journalempfänger (Journal Receiver) auf. R/3-Systeme, die auf AS/400 laufen, müssen aufzeichnen. Das Aufzeichnen wird beim Installieren von R/3 automatisch gestartet. Wir empfehlen Ihnen ausdrücklich, Ihre Journalempfänger und die Datenbankbibliothek R3<SID>DATA in verschiedene ASPs (Auxiliary Storage Pools) zu legen. Dies bietet Ihnen die folgenden Vorteile: Die Performance wird verbessert. Wenn Sie Journalempfänger für Wiederherstellungszwecke aufheben und der ASP mit der R/3-Bibliothek beschädigt wird, sind Sie in der Lage, die R/3- Bibliothek mit Hilfe der letzten Sicherung rückzuspeichern und die Änderungen, die nach der letzten Sicherung gemacht wurden, mit Hilfe der Journalempfänger wiederherzustellen. Es gibt zwei Methoden zur Verwaltung von Journalempfängern. Welche Methode Sie wählen, hängt von der ausgewählten Sicherungsstrategie [Seite 11] ab. COMMIT-Steuerung (Commitment Control) Eine Funktion, die es ermöglicht, eine Gruppe von Änderungen an Ressourcen als eine logische Arbeitseinheit (LUW) zu verarbeiten. Für das R/3-System ist die AS/400-COMMIT-Steuerung immer aktiv. Das bedeutet, daß das System eine Gruppe von Änderungen an Datenbankdateien als eine einzige Transaktion verarbeitet. Während einfaches Aufzeichnen sicherstellt, daß im Fall eines Systemabsturzes nur die Änderungen am zuletzt verarbeiteten Datensatz verlorengehen, kann das System durch Journalverwaltung in Verbindung mit COMMIT-Steuerung sicherstellen, daß entweder alle Änderungen innerhalb einer Transaktion vollständig verarbeitet werden (COMMIT) oder, falls die Verarbeitung unterbrochen wird, alle Änderungen zurückgenommen werden (ROLLBACK). 8 April 2001

9 SAP AG Aufzeichnen und COMMIT-Steuerung April

10 SAP AG Einschränkungen beim Aufzeichnen und bei der Wiederherstellung Einschränkungen beim Aufzeichnen und bei der Wiederherstellung Für das Aufzeichnen (Journaling) und die Wiederherstellung von DDL-Anweisungen (DDL = Datendefinitionssprache) auf DB2/400 gelten bestimmte Einschränkungen. Die Einschränkungen gelten für Anweisungen für das Erstellen und Ändern von Tabellen, Indizes und Views. Diese Anweisungen können z.b. vorkommen beim Customizing beim Import von Transportaufträgen, Support Packages oder LCPs bei einem R/3-Upgrade bei expliziten Änderungen im ABAP Dictionary Die folgenden SQL-Anweisungen sind betroffen: CREATE / DROP TABLE ALTER TABLE... ADD / ALTER / DROP FIELD ALTER TABLE... CREATE / DROP PRIMARY KEY... CREATE / DROP INDEX CREATE / DROP VIEW Anweisungen, die sich auf Indizes und Views beziehen, werden nicht aufgezeichnet und können deshalb momentan nicht automatisch wiederhergestellt werden. Änderungen an Tabellen werden aufgezeichnet, der Import der Journalempfänger bricht jedoch bei diesen Einträgen ab. Sie müssen dann die Anweisung selbst ausführen. Dies kann z.b. eine Anweisung sein, die eine Tabelle erstellt. IBM und SAP arbeiten zur Zeit an einem Werkzeug, das den Import von Journalen mit den oben aufgeführten DDL-Anweisungen vollständig automatisiert. Weitere Informationen finden Sie in der IBM-Dokumentation OS/400 Backup and Recovery (Dokumentnummer SC ). Besonders interessant sind in diesem Zusammenhang die Abschnitte Why You Must Save Files after Starting Journaling und Actions of the APYJRNCHG or RMVJRNCHG Command by Journal Code. 10 April 2001

11 SAP AG R/3-Sicherungsstrategien R/3-Sicherungsstrategien Um sicherzustellen, daß Sie Ihre Datenbank nach einem Schaden wieder in einen konsistenten Zustand bringen können, müssen Sie sich zunächst für eine Sicherungsstrategie für Ihr Unternehmen entscheiden. Sie müssen entscheiden, ob es für Sie ausreicht, die letzte aktuelle Sicherung wiederherzustellen, oder ob Sie auch die Änderungen, die nach der letzten Sicherung gemacht wurden, wiederherstellen wollen. Eine Rückspeicherung mit Hilfe eines Sicherungsbandes ist normalerweise nur nach einem Datenträgerfehler erforderlich. In den meisten Fällen, d.h. nach logischen Fehlern, reicht es aus, Journaländerungen zu entfernen, um Ihre Datenbank wieder in einen konsistenten Zustand zu bringen. Sie müssen sich für eine der zwei folgenden Sicherungsstrategien entscheiden: Sicherungsstrategie 1: Rückspeichern und Wiederherstellung [Seite 12] Verwenden Sie diese Sicherungsstrategie für Produktivsysteme. Sicherungsstrategie 2: Nur Rückspeichern [Seite 14] Diese Sicherungsstrategie können Sie für Test-, Demo- oder Schulungssysteme verwenden. Sie ist für Produktivsysteme nicht geeignet. April

12 SAP AG Sicherungsstrategie 1: Rückspeichern und Wiederherstellung Sicherungsstrategie 1: Rückspeichern und Wiederherstellung Einsatzmöglichkeiten Verwenden Sie diese Sicherungsstrategie für Produktivsysteme. Voraussetzungen Diese Strategie erfordert sowohl Journalempfänger- als auch Datensicherungen. Wir empfehlen Ihnen, Ihre Datenbankbibliothek und Journalempfänger täglich auf Produktivsystemen zu sichern. Im Idealfall sollten Sie die Datenbankbibliothek und die Journalempfänger auf getrennten Bändern sichern. Sichern Sie Journalempfänger manuell, nachdem sie abgehängt wurden. (Informationen darüber, wie Sie Journalempfänger automatisch mit dem Befehl SAVDLTRCV sichern, finden Sie im Hinweis ) Bei dieser Strategie werden Journalempfänger sowohl für die Wiederherstellung als auch für die COMMIT-Steuerung benötigt. Sie müssen sie daher zwischen den einzelnen Datensicherungen regelmäßig sichern. Das Abhängen des aktuellen Journalempfängers und das Erzeugen und Anhängen eines neuen Journalempfängers wird vom System automatisch durchgeführt. Dieser Prozeß findet jedesmal dann statt, wenn der aktuelle Journalempfänger eine definierte Größe erreicht (Standardgröße 500 MB). Das Sichern und Löschen der Journalempfänger müssen Sie jedoch von Hand durchführen. Ablauf Das Sichern und Löschen kann manuell oder automatisch erfolgen. (Informationen darüber, wie Sie das Sichern und Löschen von Journalempfängern automatisieren, finden Sie im Hinweis ) Wenn Sie die Journalempfänger manuell sichern, ist es wichtig, daß Sie folgende Aktionen durchführen: Nach der Installation müssen Sie den Parameter MNGRCV (Manage receivers) auf dem Bild CHGJRN (Change Journal) für das R/3-Journal auf *SYSTEM setzen und den Parameter DLTRCV (Delete receivers) auf *NO, sofern das noch nicht geschehen ist. Dies ist unbedingt erforderlich. Sie planen Ihr Sicherungsverfahren. Nachdem der alte Journalempfänger abgehängt und ein neuer erzeugt und angehängt wurde, müssen Sie den alten Journalempfänger sichern. Nach dem Sichern können Sie ihn löschen, um Platz im Benutzer-ASP zu schaffen. Sie planen Ihre Speicherverwaltung. Die Größe des Journalempfängers müssen Sie sehr sorgfältig planen. Die Standardgröße von 500 MB sollte für die meisten Systeme ausreichen. Ausnahmen sind z.b. das Ausführen großer Hintergrundjobs. Durch sorgfältige Planung können Sie einen Überlauf der Journalempfänger in den System-ASP (ASP 1) vermeiden. Wenn Sie anfangen, mit dem R/3-System zu arbeiten, sollten Sie prüfen, wie schnell der Journalempfänger die maximale Größe erreicht. Auf der Grundlage dieser Werte können Sie dann entscheiden, wir oft Ihre Journalempfänger gewechselt und gesichert werden müssen. Sie planen Ihr Wiederherstellungsverfahren für den Fall eines ASP-Überlaufs. 12 April 2001

13 SAP AG Siehe auch: Sicherungsstrategie 1: Rückspeichern und Wiederherstellung Weitere Informationen finden Sie in der IBM-Dokumentation OS/400 Backup and Recovery (Dokumentnummer SC ). April

14 SAP AG Sicherungsstrategie 2: Nur Rückspeichern Sicherungsstrategie 2: Nur Rückspeichern Einsatzmöglichkeiten Diese Strategie ist für Produktivsysteme nicht geeignet! Sie ist nur für Test-, Demooder Schulungssysteme geeignet. Bei dieser Sicherungsstrategie werden nur die Daten gesichert, nicht die Journalempfänger. Ablauf Diese Strategie erfordert häufige Sicherungen der R/3-Bibliothek, da es keine Möglichkeit gibt, nach der letzten Sicherung eingegebene Änderungen wiederherzustellen. Journalempfänger werden hier nur für die COMMIT-Steuerung benötigt. Jeder Journalempfänger wird nur so lange gebraucht, wie er angehängt ist. Die Verwaltung der Journalempfänger kann automatisch erfolgen. Mit den richtigen Parametern wechselt das System nicht nur automatisch Journalempfänger, sondern löscht sie auch nach dem Abhängen. Nach der Installation müssen Sie den Parameter MNGRCV (Manage receivers) auf dem Bild CHGJRN (Change Journal) für das R/3-Journal auf *SYSTEM setzen und den Parameter DLTRCV (Delete receivers)auf *YES, sofern das noch nicht geschehen ist. 14 April 2001

15 SAP AG Automatisierung der täglichen Datensicherungsroutine Automatisierung der täglichen Datensicherungsroutine Ablauf Um Ihre tägliche Datensicherungsroutine zu automatisieren, können Sie die zu sichernden IFS- Objekte in die Tabelle SPTH [Seite 16] eintragen und Ihre Datensicherungsroutine mit dem Befehl SAVR3SYS [Seite 17] ausführen. Beim normalen Betrieb von R/3 auf AS/400 werden Journalempfänger abgehängt, wenn sie eine bestimmte Größe erreichen. Tritt dieser Fall ein, wird ein neuer Journalempfänger erzeugt und angehängt. Sie sollten diese abgehängten Journalempfänger regelmäßig sichern und löschen, um zu verhindern, daß die Platte voll wird. Informationen darüber, wie Sie dieses Verfahren automatisieren können, finden Sie im Hinweis April

16 SAP AG Tabelle SPTH Tabelle SPTH In die Tabelle SPTH können Sie die IFS-Objekte eintragen, die in Ihrer Datensicherungsroutine enthalten sein sollen. Mit dem Befehl SASVR3SYS [Seite 17] wird der Inhalt der Tabelle SPTH an Ihre normale Datensicherungsroutine übergeben. Weitere Informationen zu der Tabelle SPTH finden Sie unter Allgemeine Verprobung bei Dateizugriffen [Extern] (BC ABAP-Programmierung). 16 April 2001

17 SAP AG Befehl SAVR3SYS Befehl SAVR3SYS Definition Der Befehl SAVR3SYS (Save an R/3 System) sichert sämtliche für ein R/3-System erforderlichen Informationen. Sie können den Befehl für Ihre tägliche R/3-Systemsicherung verwenden. Der Befehl ist jedoch nicht für die Erstellung einer Datensicherung nach einer Installation oder einem Upgrade geeignet, da Sie in diesem Fall eine Vollsicherung einschließlich etwaiger PTFs (Program Temporary Fixes) usw. benötigen. Verwendung Führen Sie den Befehl im zentralen R/3-System (d.h. dem System mit der R/3-Datenbank und den kritischen SAP-IFS-Dateien wie z.b. /usr/sap/trans) aus. Da sich IFS- (Integrated File System) Dateien in jedem R/3-System befinden können, müssen Sie sicherstellen, daß sämtliche in Tabelle SPTH [Seite 16] gepflegten IFS-Dateien montiert sind. Ist dies der Fall, brauchen Sie den Befehl SAVR3SYS nur in dem zentralen R/3-System auszuführen. Der Befehl SAVR3SYS bewirkt folgendes: 1. Er beendet R/3 oder unterbricht die Verbindung von R/3 zur Datenbank (abhängig von dem Parameter R3STS). 2. Er sichert das IFS entsprechend den Parametern IFS, REFDATE und REFTIME. 3. Er sichert die Arbeitsverwaltungsobjekte entsprechend den Parametern SAVCFG, REFDATE und REFTIME. 4. Er sichert die SQL-Pakete entsprechend den Parametern SAVCFG, REFDATE und REFTIME. 5. Er sichert die Datenbank entsprechend den Parametern SAVDB, REFDATE und REFTIME. 6. Wenn der Prüfpunkt erreicht ist, wird R/3 neu gestartet bzw. wieder mit der Datenbank verbunden (je nach der Einstellung des Parameters R3STS). Struktur Die Parameter für den Befehl SAVR3SYS sind: Parameter SID DEV Beschreibung Dreistellige R/3-System-ID Gerät, auf das Daten gesichert werden soll. Geben Sie das Gerät im IFS-Format an. Es muß sich um ein physisches Gerät handeln. Sicherungsdateien werden nicht unterstützt. April

18 SAP AG Befehl SAVR3SYS PMTCMD R3STS IFS SAVDB SAVCFG SAVPKG Gibt an, ob der Benutzer für die einzelnen Sicherungsbefehle eine Aufforderung erhalten soll. Hierdurch kann der Benutzer andere Parameter als die Vorschlagswerte für den Befehl verwenden. Werte: *NO - Benutzer erhält keine Eingabeaufforderung. (Vorschlagswert) *YES - Der Benutzer erhält für jeden Sicherungsbefehl eine Eingabeaufforderung. Gibt den Status von R/3 während der Sicherung an. Werte: *DSCDB - Verbindung zur Datenbank beenden. Dies erlaubt allen Workprozessen, innerhalb von fünf Minuten eine COMMIT-Grenze zu erreichen, führt die Sicherung durch und erlaubt den Workprozessen, weiterzuarbeiten, wenn ein Prüfpunkt für Sichern im aktiven Zustand erreicht wurde. Für Workprozesse, die die COMMIT-Grenze nicht innerhalb von fünf Minuten erreichen, wird ein Rollback durchgeführt. *END - R/3 beenden, die Sicherung durchführen, nach der Sicherung R/3 neustarten, während der aktive Prüfpunkt erreicht wird. *RUN - R/3 bleibt während der Sicherung aktiv. (Dieser Wert wird nicht empfohlen, während IFS-Dateien gesichert werden.) Gibt die zu sichernden IFS-Dateien an. *SPTH - Sichert die in der Tabelle SPTH angegebenen Dateien oder die Liste der zu sichernden oder auszulassenden IFS-Verzeichnisse. (Vorschlagswert) Gibt an, ob die R/3-Datenbank gesichert werden soll. *YES - R/3-Datenbank sichern (Vorschlagswert) *NO - R/3-Datenbank nicht sichern Gibt an, ob die R/3-Konfigurationsobjekte (wie Subsystem- Beschreibungen und -Klassen) gesichert werden sollen. *NO - Konfigurationsobjekte nicht sichern (Vorschlagswert) *YES - Konfigurationsobjekte sichern Gibt an, ob die R/3-Pakete (präparierte SQL-Pakete) gesichert werden sollen. *NO - R/3-Pakete nicht sichern (Vorschlagswert) *YES - R/3-Pakete sichern 18 April 2001

19 SAP AG Befehl SAVR3SYS REFDATE REFTIME SAVACTWAIT VOL Gibt das Bezugsdatum zum Sichern geänderter Objekte an. Nur Objekte, die seit dem angegebenen Datum (und der angegebenen Uhrzeit - Parameter REFTIME) geändert wurden, werden gesichert. *ALL - Alle Objekte sichern, unabhängig vom letzten Änderungsdatum (Vorschlagswert) *LASTSAVE - Alle Objekte sichern, die seit dem letzten Sicherungsdatum geändert wurden Gibt den Bezugszeitpunkt zum Sichern aller Objekte an, die seit dem angegebenen Zeitpunkt geändert wurden (wird mit dem oben aufgeführten Parameter REFDATE verwendet). *ALL - Alle Objekte sichern, unabhängig vom letzten Änderungsdatum (Vorschlagswert) *LASTSAVE - Alle Objekte sichern, die seit dem letzten Sicherungsdatum geändert wurden Gibt an, wie lange (in Sekunden) die Sicherungsoperation auf den Sicherungssynchronisationspunkt warten sollte. Dies betrifft nur die Datenbanksicherungsoptionen Das System wartet bis zu 20 Minuten darauf, daß die Datenbank ihren Synchronisationspunkt erreicht. (Vorschlagswert) Number of seconds - Das System wartet die angegebene Anzahl Sekunden darauf, daß die Datenbank ihren Synchronisationspunkt erreicht. Gibt bis zu 75 Bänder an, die für die Sicherungsoperationen verwendet werden sollen. Wenn die Bandnamen angegeben sind, müssen die Bänder in der angegebenen Reihenfolge montiert werden. *MOUNTED - Montierte Bänder verwenden, unabhängig vom Bandnamen (Vorschlagswert) Volume name - Nur die angegebenen Bandnamen verwenden April

20 SAP AG Sicherung des R/3-Systems mit BRMS Sicherung des R/3-Systems mit BRMS Einsatzmöglichkeiten Die Informationen in diesem Abschnitt gelten nur für Online-Sicherungen. Voraussetzungen Bevor Sie die R/3-Datenbankbibliothek mit BRMS (Backup Recovery and Media Services) sichern können, müssen Sie den Parameter für Sichern im aktiven Zustand (SAVACT) aktiviert haben, indem Sie den Wert *SYNCLIB setzen. Ablauf Wir empfehlen Ihnen, den Befehl SAVR3SYS nicht direkt in BRMS zu verwenden. Stattdessen sollten Sie in die Sicherungssteuergruppe direkt vor dem Sicherungseintrag für die Datenbankbibliothek zwei User-Exits eingeben: DSCR3SYS SID(<SID>) MONSWABRM LIB(R3<SID>DATA) CMD(RCNR3SYS SID(<SID>) 1. Der Befehl DSCR3SYS (Disconnect R/3 System) bringt alle R/3-Jobs dazu, innerhalb von fünf Minuten eine COMMIT-Grenze zu erreichen. Wenn Jobs innerhalb von fünf Minuten keine COMMIT-Grenze erreichen, wird ein Rollback durchgeführt. Nach Ablauf der fünf Minuten haben alle Jobs eine COMMIT-Grenze erreicht und müssen darauf warten, daß der Befehl RCNR3SYS ausgeführt wird. 2. Der Befehl MONSWABRM (Monitor Save While Active) führt den angegebenen Befehl aus, sobald die COMMIT-Grenze erreicht ist. 3. Der Befehl RCNR3SYS (Reconnect R/3 System) zeigt allen R/3-Jobs an, daß sie sofort weiterarbeiten können. Um sicherzugehen, können Sie hinter dem Eintrag für die Sicherung der Datenbankbibliothek in der Sicherungssteuergruppe einen weiteren User-Exit hinzufügen, der den Befehl RCNR3SYS SID(<SID>) enthält. Wenn der Befehl RCNR3SYS zweimal ausgeführt wird, gibt der zweite Aufruf die Meldung BFC0007 zurück, die Sie ignorieren können. 4. Die Befehle DSCR3SYS und RCNR3SYS sind R/3-Befehle. Um Berechtigungsprobleme zu vermeiden, führen Sie die Befehle unter dem Benutzerprofil <SID>OFR oder als privilegierter Benutzer aus. Setzen Sie die Bibliothekenliste ohne Angabe des Kernel-Bibliotheksnamens direkt durch Aufruf des Programms R3<SID>400/R3INLPGM: CALL PGM(R3<SID>400/R3INLPGM Die Befehle DSCR3SYS und RCNR3SYS verwenden das IBM-Programm QBFCDBBK. Weitere Informationen über dieses Programm und über Fehlermeldungen, die mit BFC beginnen, finden Sie in der IBM-Dokumentation. 20 April 2001

21 SAP AG Was müssen Sie sichern? Was müssen Sie sichern? In diesem Abschnitt erfahren Sie, welche Objekte Sie sichern müssen, um Ihre Daten nach einem Systemausfall wieder in einen konsistenten Zustand bringen zu können. In der folgenden Tabelle finden Sie die zu sichernden Objekte sowie Angaben dazu, wie häufig die Objekte gesichert werden müssen. Zu sichernde Objekte R/3-Datenbankbibliothek R3<SID>DATA, IFS-Objekte R/3-Journalempfängerbibliothek R3<SID>JRN (nur Sicherungsstrategie 1) R/3-Programmdateibibliothek R3<REL>OPT Bibliotheken für RFC-SDK und CPI-C-SDK (R3<REL>RFC, R3<SID>CPIC) Gesamtes AS/400-System (einschließlich R/3) Betriebssystem OS/400 SQL-Pakete (optional) Arbeitsbibliothek für das R/3-System R3<SID>400 Häufigkeit Täglich. Führen Sie zusätzlich zu der normalen täglichen Sicherung vor dem Import von Transportaufträgen eine Sicherung durch. Sichern Sie die Datenbankbibliothek und die IFS-Objekte immer zusammen. Ausnahme: Da das Aufzeichnen von IFS-Objekten derzeit nicht verfügbar ist, können Sie die IFS-Objekte u.u. zusätzlich nach jeder Hintergrundverarbeitung sichern (siehe IFS- Objekte weiter unten.) Wenn Sie die Sicherungsstrategie 1 verwenden, sollten Sie die Journalempfänger erst löschen, nachdem Sie sie gesichert haben. Sichern Sie die Journalempfänger manuell, nachdem sie abgehängt wurden. (Sie können Journalempfänger automatisch sichern. Weitere Informationen finden Sie im Hinweis ) Vor und nach jeder Änderung Vor und nach jeder Änderung Siehe IBM-Dokumentation. Siehe IBM-Dokumentation. Eine Sicherung der SQL-Pakete ist nicht erforderlich, da diese sich relativ schnell wieder aufbauen. Immer wenn Sie ein neues R/3-System anlegen Die folgenden Abschnitte zu den zu sichernden Objekten liefern Hintergrundinformationen dazu, warum die Objekte gesichert werden müssen, und in einigen Fällen, warum sie in bestimmten Abständen gesichert werden müssen. April

22 SAP AG Was müssen Sie sichern? R/3-Datenbankbibliothek Um sicherzustellen, daß alle Daten in der R/3-Datenbank wiederherstellbar sind, sichern Sie die R/3-Datenbankbibliothek R3<SID>DATA täglich. Wir empfehlen Ihnen, die Datenbankbibliothek zusammen mit den Zugriffspfaden zu sichern, um das Rückspeichern und die Wiederherstellung zu beschleunigen. IFS-Objekte R/3-Anwendungskomponenten schreiben nicht notwendigerweise nur Daten auf die Datenbank; sie können auch sequentielle Dateien im IFS (Integrated File System) erzeugen. Dies geschieht sowohl dann, wenn Sie direkt ins IFS schreiben als auch, wenn Sie Spool-Daten im IFS anstelle der Datenbank speichern. Dabei gibt es folgende Szenarios: Eine Anwendung erzeugt eine sequentielle Datei nach einer (möglicherweise langwierigen) Hintergrundverarbeitung. Eine Anwendung setzt ein Kennzeichen in der Datenbank, das angibt, daß eine sequentielle Datei erzeugt wurde. Ist das Kennzeichen einmal gesetzt, können Sie die sequentielle Datei möglicherweise nicht neu generieren. Wenn Sie beispielsweise einen Transportauftrag exportieren, wird der Auftrag im R/3-System als exportiert gekennzeichnet. Falls im IFS Daten verlorengehen, können Sie den Auftrag mit direkten Mitteln nicht noch einmal exportieren. Falls aus einem dieser Gründe sequentielle Dateien erzeugt werden, empfehlen wir, diese zu sichern, wenn sie erzeugt werden. Falls von ABAP-Programmen noch andere Verzeichnisse für IFS-Daten erzeugt werden, dürfen Sie nicht vergessen, auch die Objekte in diesen Verzeichnissen zu sichern (siehe Tabelle SPTH [Seite 16]). Wir empfehlen Ihnen, diese Daten immer dann zu sichern, wenn Sie die R/3-Bibliothek sichern (also täglich und nach dem Import von Transportaufträgen), besonders wenn Sie Ihre Spool- Daten außerhalb der R/3-Datenbankbibliothek abgelegt haben. Sichern Sie IFS- (Integrated File System) Objekte (Profile, Protokolle und Traces, Spool-Daten, Transportdaten) mit Save Menu, Auswahl 11 (Objects in directories). In der folgenden Tabelle sehen Sie, welche Pfadnamen Sie eingeben müssen, um bestimmte Daten zu sichern: Art der Daten Systemspezifische Daten Instanzenspezifische Daten Transportdateien Pfadnamen /sapmnt/<sid>* /usr/sap/<sid>/<inst>* /sapmnt/trans* Sie können Objekte nicht über symbolische Links sichern. Wenn Sie einen Pfad wie z.b. /usr/sap/trans sichern, der ein symbolischer Link zu einem anderen Verzeichnis ist, sichern Sie nur den Pfad zu diesem Verzeichnis. Um den Inhalt des 22 April 2001

23 SAP AG Was müssen Sie sichern? Verzeichnisses oder der Verzeichnisse zu sichern, müssen Sie auch die physischen Objekte sichern. R/3-Journalempfängerbibliothek Wenn Sie sich für die R/3-Sicherungsstrategie 1 entscheiden, müssen Sie die Bibliothek R3<SID>JRN sichern. Damit Sie sowohl wiederherstellen als auch rückspeichern können, benötigen Sie eine ununterbrochene Kette von Journalempfängern bis zurück zur letzten Sicherung. Je nach Empfängergröße kann es sinnvoll sein, Empfänger auch zwischen R/3-Bibliothekssicherungen zu sichern. Informationen darüber, wie Sie das Verfahren für die Sicherung (und das Löschen) Ihrer Journalempfänger automatisieren können, finden Sie im Hinweis R/3-Programmdateibibliotheken und Arbeitsbibliotheken Sichern Sie die Programmdateibibliotheken R3<REL>OPT, R3<REL>RFC und R3<REL>CPIC und die Arbeitsbibliothek R3<SID>400 vor und nach jeder Änderung. Dies ist wahrscheinlich nicht mehr notwendig, wenn Sie erst einmal eine Vollsicherung des R/3-Systems nach einer Installation oder einem Upgrade durchgeführt haben, es sei denn, Sie spielen Korrekturen von einem der SAP-Support-Server (z.b. sapserv3) ein. Gesamtes AS/400-System Sichern Sie häufig das gesamte AS/400-System einschließlich der R/3-Software. Betriebssystem OS/400 Mitunter kann es erforderlich sein, das gesamte OS/400-Betriebssystem zu sichern und wiederherzustellen. Informationen hierzu finden Sie in der IBM-Dokumentation OS/400 Backup and Recovery (Dokumentnummer SC ). SQL-Pakete Das Sichern der SQL-Pakete ist optional. (Führen Sie eine Sicherung jedoch nur dann durch, wenn die SQL-Pakete relativ neu sind.) Der Vorteil dabei ist, daß das System nach dem Rückspeichern oder Wiederherstellen sehr viel schneller ist, wenn die Pakete schon vorhanden sind. Die Zeit, die Sie benötigen, um die Pakete zu importieren, wird mehr als kompensiert durch die Zeit, die Sie sparen, wenn Sie bei Inbetriebnahme des Systems die Pakete nicht von neuem aufbauen müssen. Die Häufigkeit, mit der Sie die SQL-Pakete sichern müssen, kann je nach Systemtyp (Entwicklungs- oder Produktivsystem) unterschiedlich sein. In Ihrem Produktivsystem können die Pakete über lange Zeiträume hinweg unverändert bleiben, da die Anweisungen in den verwendeten Transaktionen gleich bleiben und die Transaktionen selbst nach bestimmten Routinen verwendet werden, die sich nicht ändern. Daher brauchen Sie die Pakete in einem Produktivsystem nicht täglich zu sichern. Bei einer Rückspeicherung genügt es, die Pakete von der letzten Vollsicherung zu importieren. Stellen Sie sicher, daß die Pakete, die Sie rückspeichern, mindestens so alt sind wie Ihre Datenbankbibliothek. April