Datenbank-Umzüge fast ohne Downtime Erfahrungen mit Triple-O

Transkript

1 Datenbank-Umzüge fast ohne Downtime Erfahrungen mit Triple-O Jörg Hildebrandt Technical and Delivery Lead, Hewlett-Packard GmbH 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.

2 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick 2 20 November 2009

3 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick 3 20 November 2009

4 Vorstellung Jörg Hildebrandt Tätig im Outsourcing-Bereich von HP Delivery and Technical Lead Databases (Oracle, SQL Server, MaxDB, MySQL, SAP and non SAP) Deutsches Team, Kunden-bezogen Mehr als 10 Jahre Berufserfahrung im Datenbank-Bereich Spezialisiert auf Oracle-Technologien Seit 9 Jahren in der DOAG aktiv Regionalleiter Jena/Thüringen SIG Oracle und SAP Vorstand in den letzten beiden Legislaturperioden 4 20 November 2009

5 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick 5 20 November 2009

6 Motivation Feststellungen und Forderungen von Kunden Der tatsächlich benötigte Platz in der Datenbank ist deutlich kleiner als der belegte Platz. Backups dauern zu lange / Risiko für Restores / Performance Die Antwortzeiten der Datenbank nehmen immer weiter ab. Der DB-Server ist ständig ausgelastet, kann bezüglich CPU und Memory nicht mehr erweitert werden und muss ersetzt werden. Hardware-Investitionen sollen aber vorerst vermieden werden. Aus strategischen Gründen soll auf einen neuen Server mit einem anderen Betriebssystem umgezogen werden November 2009

7 Motivation Feststellungen und Forderungen von Kunden Das Plattenlayout des SAP-Systems soll zur Verbesserung der Performance optimiert werden. Version und Patchlevel der Datenbank müssen dringend an den aktuellen Stand angepasst werden (z.b. Systemfehler, Anpassungen an SAP-Empfehlungen, Vorbereitung von SAP-Releasewechseln) Komprimierung von Indizes und Tabellen soll ohne spürbare Performance-Einbussen implementiert werden. Die Verfügbarkeit der Datenbank des SAP-Systems soll erhöht werden. Ein neues Tablespace-Layout soll das Management der Datenbank vereinfachen und die Performance erhöhen November 2009

8 Motivation Randbedingungen von Kunden Die Downtime des Systems darf nicht länger als X Stunden sein. Die Arbeiten am Produktivsystem (System online) dürfen keine Performance-Beeinträchtigungen nach sich ziehen. Das Verfahren muss sicher und SAP-zertifiziert sein. Die Aktivitäten sind uns zu komplex. Wir möchten die Wartung in Auftrag geben. Ein Fallback-Szenario für schnellen Wiederanlauf muss vorhanden sein November 2009

9 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick 9 20 November 2009

10 Transfer-Verfahren im Vergleich Oracle Export/Import (exp/imp) Client-basiert Ausgereifes Verfahren, auch mit Version 11 noch verfügbar Langsam, weil nicht parallelisierbar Hoher Ressourcenverbrauch Für große Datenmengen nicht geeignet Kann für leere Tabellen benutzt werden / Anlegen der Dictionary- Einträge Serieller Prozess: erst Export, dann Import Auf Kompatibilitätsmatrix achten! November 2009

11 Transfer-Verfahren im Vergleich Oracle Data Pump (expdp/impdp) Seit Version 10g verfügbar Performance-Verbesserungen für Bulk Loads (direct path) und Metadaten- Verschiebung Parallelisierbar Wiederaufsetzen nach Abbrüchen Schätzung von Platzbedarf und Ausführungszeit Umbenennen von Tablespaces oder Schemata am Ziel Serieller Prozess: erst Export, dann Import (i.d.r.) Langsam Eigene API November 2009

12 Transfer-Verfahren im Vergleich Transportable Tablespaces Seit Version 9i verfügbar für gängige Plattformen Einfacher Prozess Generierung der Metadaten aus der Quelle mittels Data Pump (Tablespaces Read Only) Endian-Formate zwischen Quelle und Ziel müssen passen bzw. Konvertierung mittels RMAN Kopieren der Files zum Ziel Importieren der Metadaten Öffnen der Tablespaces zum Schreiben Keine Reorganisation der Data Files November 2009

13 Transfer-Verfahren im Vergleich Transportable Database Seit Version 9i verfügbar für gängige Plattformen Einfacher Prozess Endian-Formate zwischen Quelle und Ziel müssen identisch sein Datenbank Read-Only öffnen Generierung von Skript zur Erstellung des Controlfiles, Konvertierung der Data Files (Kopien) und Verschiebung zum Zielsystem Generieren der neuen Datenbank Keine Reorganisation der Data Files Schneller als Metadaten-Übertragung mittels RMAN November 2009

14 Transfer-Verfahren im Vergleich O2O bzw. HP Smooth Transition Method (HP STM) Zeitkritische Migrationen von großen Datenbanken Verbindung verschiedener Migrationsverfahren in Abhängigkeit von Größe und Struktur der DB-Objekte Generierung von Skripten für gesamten Prozess Zentraler Commandline-basierter Scheduler oder Jobsteuerung mittels UC4 (Automatisierung und Überblick) November 2009

15 Transfer-Verfahren im Vergleich O2O bzw. HP Smooth Transition Method (HP STM) Wiederaufsetzen nach Abbrüchen Jede Art von Jobs ist auf anderer Hardware ausführbar Beliebige Skalier- und Parallelisierbarkeit hinsichtlich Ressourcenbedarf der einzelnen Verfahren und technischer Verfügbarkeit pro Plattform Zur Laufzeit änderbares Parameterfile Darstellung von Migrationsstatus und Schätzung der verbleibenden Ausführungszeit Reorganisation der Datenbank November 2009

16 Transfer-Verfahren im Vergleich O2O bzw. HP Smooth Transition Method (HP STM) Konsistenz- und Erfolgskontrolle Prinzipielle Release- und Plattform-Unabhängigkeit Verfahren SAP-zertifiziert Erfahrungen und spezielle Ausbildung erforderlich Consulting-Leistung von Oracle oder HP Mit Einschränkungen auch für non-sap-datenbanken einsetzbar Vorbereitung: System online Migration und Nacharbeiten: System offline November 2009

17 Transfer-Verfahren im Vergleich Triple-O Erweiterung von O2O zur Verkürzung der Downtime auf ein Minimum durch Einsatz von Replikationsmechanismen (Oracle Streams) Kern ist weiterhin das (erweiterte) O2O- bzw. HP STM-Package Downtime beschränkt sich auf die Inbetriebnahme der Streams- Umgebung auf Basis konsistenter DB-Objekte (separates Dictionary für Streams im Zielsystem) November 2009

18 Transfer-Verfahren im Vergleich Triple-O Andere Erweiterungen: Erweiterte Prüfungen vom Quellsystem bezüglich Migrationstauglichkeit Umbenennung von Schemata Umbenennung von Tablespaces Komprimierung von Tabellen und Indizes Verbesserte Qualitätskontrolle am Ende des Prozesses November 2009

19 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick November 2009

20 Migration eines OLTP-Systems OLTP-System (R/3) SAP-Release: 4.6C DB-Release: Größe: 350 GB Tabellen, Indizes Keine partionierten Objekte Keine komprimierten Objekte November 2009

21 Migration eines OLTP-Systems OLTP-System (R/3) Aufgaben: Wechsel des Betriebssystems (AIX 5.2 HP-UX 11.23) Hardware Refresh Downtime nur am Wochenende und möglichst nicht länger als einen Tag am Stück November 2009

22 Migration eines OLTP-Systems Quelle Server: IBM pseries, Regatta Prozessor: 2 x PowerPC POWER4, 1300 MHz Memory: 22,5 GB Ziel Server: HP RX8640 Prozessor: 2 x Itanium Dual Core, 1598 MHz Memory: 32 GB November 2009

23 Migration eines OLTP-Systems November 2009

24 Migration eines OLTP-Systems Schritt 1 Schaffung der Migrationsvoraussetzungen (Quelle) Upgrade auf Version Einspielen aller von der SAP empfohlenen Oracle-Patches (MOPatch) Einspielung aller notwendigen Patches für Oracle Streams Problem: Nicht alle in der Note # empfohlenen Patches waren verfügbar oder standen im Widerspruch zu Oracle-Patches für SAP. (Ł Die nicht installierbaren Patches brauchten wir nicht, Glück gehabt) Einspielung des letzten CPU-Patches (Ł ca. 2,5 Stunden + Backup am Ende des Vorgangs) November 2009

25 Migration eines OLTP-Systems Schritt 1 Schaffung der Migrationsvoraussetzungen (Quelle) Setzen von streams_pool_size=400m Achtung: Wurden sga_target bzw. sga_max_size nicht gesetzt (SAP-Empfehlung), ist in jedem Fall ein Neustart der Instanz notwendig, sonst KANN ein Neustart erforderlich sein. (Ł prima, funktionierte online) job_queue_processes >= 4, kann online gesetzt werden Überprüfung der Größe des UNDO-Tablespaces (Gap zwischen Start der späteren Offline-Übertragung der Objekte und der Synchronisation mit dem laufenden Online-Betrieb) (Ł kleines System mit wenig Transaktionslast) November 2009

26 Migration eines OLTP-Systems Schritt 2 Installation der Zieldatenbank Installation der Oracle-Betriebsumgebung auf dem Ziel-Server (gleiches Release und gleiche Patches, insofern verfügbar) Anlegen einer neuen Instanz am Zielort nach den Vorgaben des Altsystems Ł gute Ausgangsbasis: SQL> alter database backup controlfile to trace; Ł Schätzung der Zielgröße (Reorganisationseffekt) SQL> select sum(bytes) from dba_data_files; SQL> select sum(bytes) from dba_free_space; anhand des Altsystems November 2009

27 Migration eines OLTP-Systems Schritt 2 Installation der Zieldatenbank Parametrisierung der neuen Datenbank für die Transition Hauptspeicher: sga_target streams_pool_size, shared_pool_size, db_cache_size, (Ł db_cache_size=1000m / sga_target=8000m / shared_pool_size=800m / streams_pool_size=400m) Prozesse: pga_aggregate_target, parallel_min_processes, parallel_max_processes (Ł processes=200 / sessions=400 / parallel_min_servers=120 / parallel_max_servers=120 / parallel_threads_per_cpu=1 / pga_aggregate_target=5000m / job_queue_processes=5) November 2009

28 Migration eines OLTP-Systems Schritt 2 Installation der Zieldatenbank Logwriter: log_buffer (Ł log_buffer= ) Sortierspeicher: PSAPTEMP groß genug Unnötigen Overhead abschalten (Ł db_block_checking='false / db_block_checksum='false / replication_dependency_tracking=false / log_checkpoints_to_alert=false / NOARCHIVELOG-Mode / keine gespiegelten Logfiles) Vorbereitung eines Parameterfiles für den Live-Betrieb November 2009

29 Migration eines OLTP-Systems Schritt 3 Installation der Migrationsumgebung und Generierung von Skripten Installation der notwendigen Programme und Tools auf NFS-Pool Generierung eines Migration Keys Laden der PL/SQL-Packages in das Quellsystem Erzeugung eines Parameterfiles für O2O Generierung aller notwendigen Skripte zur Vorbereitung des Zielsystems und der Inbetriebnahme der Streams-Umgebung November 2009

30 Migration eines OLTP-Systems Schritt 3 Installation der Migrationsumgebung und Generierung von Skripten Ł Ergebnis im Test: 45 Export-Jobs, vorwiegend zum Transport von Metadaten und Statistiken 1044 Jobs für einzelne Tabellen ( create table as select ) 105 PL/SQL-Routinen für Tabellen mit LONG RAW-Feldern 2087 Jobs für Indizes Weitere Jobs für das Setup von Streams, Anlegen von Usern und Vergabe von Rechten, Erzeugung von Statistiken, Fehlerkontrolle, andere Vor- und Nacharbeiten November 2009

31 Migration eines OLTP-Systems Schritt 4 Netzwerkkonfiguration Erstellung der bidirektionalen Wege im Netzwerk zwischen beiden Instanzen (tnsnames.ora auf beiden Servern) für die Übertragung der Daten während der Offline-Migration zum Transport der Daten mittels Oracle Streams Vorsicht Bottleneck! Parametrisierung von ssh-verbindungen zwischen den an der Migration beteiligten Knoten bei Verteilung einzelner aufgaben auf verschiedene Server (z.b. Export auf der Quelle und Import am Ziel) November 2009

32 Migration eines OLTP-Systems Schritt 5 Weitere Vorbereitungen der Zieldatenbank Erstellung von Usern, Rollen und Rechten mittels der generierten Skripte Anlegen von Datenbank-Links November 2009

33 Migration eines OLTP-Systems Schritt 6 Setup und Inbetriebnahme der Streams-Umgebung Setup der beteiligten Kommunikationspartner ŁAbbruch des Prozesses: Quell- und Ziel-Datenbank dürfen nicht gleich heissen! Hintergrund: Die Datenbanken greifen über Links sowohl auf sich selber als auch auf die Gegenseite zu. Durch die Verwendung von global_names=true (Voraussetzung für die Nutzung von Streams) müssen die DB-Namen und die Bezeichnung der Links verschieden sein. Ł Generierung eines Controlfiles mit neuem Namen am Ziel, Änderung von db_name in der init.ora, des Parameters ORACLE_SID in der Betriebssystem-Umgebung und Anpassen der Netzwerkkonfigurationen (tnsnames.ora) auf Quelle und Ziel November 2009

34 Migration eines OLTP-Systems November 2009

35 Migration eines OLTP-Systems Schritt 6 Setup und Inbetriebnahme der Streams-Umgebung Aufbau eines LogMiner-Dictionaries aller Objekte des Quellsystems in der Ziel-Datenbank als Basis für die spätere Replikation mittels Streams Ł Abbruch des Prozesses: SYSAUX-Tablespace zu klein. Er sollte mindestens 1,5 GB Freiplatz besitzen. Vergrößerung vom SYSAUX-Tablespace und Neustart aller Vorbereitungsprozesse Fehlerfreier Aufbau des Dictionaries nach kleineren Korrekturen in den Skripten November 2009

36 Migration eines OLTP-Systems Schritt 7 Erneute Skript-Generierung, Konfiguration von Streams, Aufbau des LogMiner Dictionaries Ziel: möglichst konsistenter Stand von DB-Objekten im LogMiner-Dictionary des Zielsystems zu den generierten Skripten Entfernen der kompletten Streams-Umgebung Neu-Generierung aller Skripte (nur 1,5 Stunden Downtime) Aufbau des LogMiner-Dictionaries ŁAnnahme: Es werden nur wenige DDL-Operationen bis zum Abschluss des Dictionary-Aufbaus stattfinden November 2009

37 Migration eines OLTP-Systems Schritt 8 Migration der Datenbank zum Ziel O2O-Migration bzw. HP Smooth Transition aller DB-Objekte in die Ziel-Datenbank bei produktiv laufendem Quellsystem (Ł zeitunkritisch) Start der Streams-Synchronisation Ł Problem: Archive Logs ab der kleinsten SCN die ein Objekt zum Recovern benötigt werden gebraucht. Diese müssen im Filesystem zur Verfügung stehen! (Ł im konkreten Fall ein mühsamer Prozess ) Produktive Lösung: Einrichtung einer log_archive_dest_3, deren Files NICHT auf Band archiviert werden. Dieses Archivierungsziel sollte nichtblockierend für die Datenbank eingerichtet werden (zum Beispiel im NFS-Pool) November 2009

38 Migration eines OLTP-Systems Schritt 8 Migration der Datenbank zum Ziel Oracle Streams verarbeitet nach allen notwendigen Archivelogs nur noch die Online-Logs des Originalsystems Wenig Nacharbeiten aufgrund zwischen Downtime zur Generierung der Skripte und Synchronisation entstandener neuer Objekte (Streams Error Queue) Abschliessender Konsistenztest November 2009

39 Migration eines OLTP-Systems Schritt 9 Finale Migration Downtime des SAP-Systems Log Switch im Quellsystem Abschalten von Oracle Streams Detaillierte Konsistenzprüfung der Ziel-Datenbank Nacharbeiten am migrierten System Erstellung von Statistiken (System, Dictionary, Fixed Objects) *) Hinzufügen der Log Member-Duplikate *) Erzeugung eines neuen Controlfiles (Tauschen der SID: PG1 PG0) Einschalten vom Archive Mode *) Vollständige Sicherung *) *) hätte auch vorher erledigt werden können November 2009

40 Migration eines OLTP-Systems Schritt 9 Finale Migration Start des neuen SAP-Systems mit produktiver init.ora und Aktivierung aller Betriebsroutinen Downtime 6 Stunden, zirka 2 Stunden waren wirklich notwendig November 2009

41 Migration eines OLTP-Systems Resumé Einspielen von Patches Generierung der Migrationsskripte Produktivsetzung 2,5 Stunden 1,5 Stunden 6,0 Stunden (2,0 Stunden) Summe 10,0 Stunden (6,0 Stunden) Platzbedarf vorher (brutto) Platzbedarf nachher (brutto) 350 GB 240 GB November 2009

42 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick November 2009

43 Migration eines OLAP-Systems OLAP-System (SAP Business Warehouse) SAP-Release: R/ BW DB-Release: Größe: 2,7 TB Tabellen, Indizes Tabellen-Partitionen, Index-Partitionen Größte Tabellen(-Partitionen) > 100 GB November 2009

44 Migration eines OLAP-Systems OLAP-System (SAP Business Warehouse) komprimierte Tabellen mit 698 komprimierten Partitionen SQL> select count(*) from dba_part_tables where def_compression='enabled and owner='sapr3'; => 22 SQL> select count(distinct(table_name)) from dba_tab_partitions where table_owner='sapr3 and compression='enabled'; => November 2009

45 Migration eines OLAP-Systems OLAP-System (SAP Business Warehouse) Aufgabe: Reorganisation nach intensiven Daten-Löschungen vor der Übergabe an einen anderen Kunden und zur Freisetzung von Plattenplatz und zur dauerhaften Einsparung von Kosten Downtime am liebsten nur freitags in der Zeit von Uhr November 2009

46 Migration eines OLAP-Systems Quelle = Ziel Server: HP RX8640 Prozessor: 2 x Itanium Dual Core, 1598 MHz Memory: 32 GB Migrations-Server HP BL860c Prozessor: 2 x Itanium Dual Core, 1666 MHz Memory: 32 GB Der Migrationsserver sollte nur als Zwischenstation dienen und die Platten später wieder am alten Server verfügbar gemacht werden November 2009

47 Migration eines OLAP-Systems November 2009

48 Migration eines OLAP-Systems Schritt 1 Schaffung der Migrationsvoraussetzungen (Quelle) Upgrade auf Version und Einspielen aller notwendigen Patches Problem: Massive Probleme nach dem Upgrade mit der Verwaltung des Oracle Shared Pool (ORA-4031) / Systemstillstand Lösung: deutliche Vergrößerung des Shared Pools und Reset von sga_target Anpassung von Parametern für die Migration im Rahmen der Downtime (2,5 Stunden) Unsicherheit über notwendige Größe des UNDO-Tablespaces November 2009

49 Migration eines OLAP-Systems Schritt 2 Installation der Zieldatenbank Installation der Betriebsumgebung am Ziel Anlegen der Instanz mit anderem Namen als Quelle Parametrisierung der Datenbank für die Migration November 2009

50 Migration eines OLAP-Systems Schritt 3 Installation der Migrationsumgebung und Generierung von Skripten Vorbereitung der Migrationsumgebung Generierung aller notwendigen Skripte Ł Ergebnis im Test: 35 Export-Jobs, vorwiegend zum Transport von Metadaten und Statistiken 466 Jobs für Tabellen und Partitionen ( create table as select ) 16 PL/SQL-Routinen für Tabellen mit LONG RAW-Feldern 1371 Jobs für Indizes November 2009

51 Migration eines OLAP-Systems Schritt 4 Netzwerkkonfiguration Schritt 5 Weitere Vorbereitungen der Zieldatenbank Schritt 6 Setup und Inbetriebnahme der Streams-Umgebung November 2009

52 Migration eines OLAP-Systems Schritte 7 und 8 - Erneute Skript-Generierung, Aufbau des LogMiner Dictionaries, Start der Offline-Migration Stoppen des SAP-Systems (freitags Uhr, wie gewünscht) Neu-Generierung aller Skripte (Dauer ca. 2,0 Stunden) Paralleler Aufbau des LogMiner-Dictionaries (dauerte deutlich länger als die zur Verfügung stehende Downtime) Ł Randbedingung: Im betroffenen BW-System werden täglich sehr viele partitionierte Tabellen neu erstellt oder gelöscht (DDL-Operationen). O2O-Migration bzw. HP Smooth Transition aller DB-Objekte in die Ziel- Datenbank November 2009

53 Migration eines OLAP-Systems Schritte 7 und 8 - Erneute Skript-Generierung, Aufbau des LogMiner Dictionaries, Start der Offline-Migration Ł Problem: Es gab partitionierte Tabellen, in denen nur Teile komprimiert waren (nicht im Package vorgesehen und nicht in dba_part_tables enthalten) Ł Korrekturen an Skripten per Hand Start der Streams-Synchronisation November 2009

54 Migration eines OLAP-Systems Schritte 7 und 8 - Erneute Skript-Generierung, Aufbau des LogMiner Dictionaries, Start der Offline-Migration Ł Problem 1: Streams kann nicht mit komprimierten Objekten umgehen (Data Segment Compression, bis Version 10g), Objekte können auf der Quelle nicht ge-captured werden ( gelöst bei Advanced Compression) Ł Problem 2: Es fanden so viele DDL-Änderungen statt, dass sinnvolle Nacharbeiten nicht durchgeführt werden konnten. Ł Abbruch der Migration November 2009

55 Migration eines OLAP-Systems Plan B Stoppen des SAP-Systems (freitags 17 Uhr) Neu-Generierung aller Skripte (2,0 Stunden) Offline-Migration der DB-Objekte in die Ziel-Datenbank (16,0 Stunden) Konsistenzprüfung, Nacharbeiten, Umhängen der Platten an anderen Server (4,0 Stunden) Backup (4,0 Stunden) Start eines schlanken SAP-Systems November 2009

56 Migration eines OLAP-Systems Resumé Einspielen von Patches Vorbereitung der Online-Migration Offline-Migration 2,5 Stunden 8,0 Stunden 26,0 Stunden Summe 36,5 Stunden (28,5 Stunden) Platzbedarf vorher (brutto) Platzbedarf nachher (brutto) 2,7 TB 1,4 TB November 2009

57 Agenda Kurze Vorstellung Motivation Oracle-Transfer-Verfahren im Vergleich Migration eines OLTP-Systems (R/3) mit Triple-O Migration eines OLAP-Systems (BW) mit Triple-O Fazit und Ausblick November 2009

58 Fazit und Ausblick Triple-O ist insbesondere für Systeme mit wenig DDL-Änderungen pro Zeiteinheit eine super Möglichkeit, die Downtime einer Datenbank- Migration von einem zu einem anderen Server dramatisch zu verkürzen. Bei Systemen mit einer hohen DDL-Änderungsrate sollten vor Beginn des Starts der Migration geeignete Vorsichtsmaßnahmen getroffen werden (Transportstopps etc.) Trotz starker Automatisierung und dem Einsatz von erfahrenenen Migrateuren bleibt das Verfahren sehr komplex. Einer produktiven Migration sollten in jedem Fall intensive Tests vorausgehen. Neben der Online-Variante wird auch das herkömmliche O2O- bzw. HP Smooth Transition-Verfahren seine Verwendung behalten. Auch hiermit können in Relation zum bewegten Datenvolumen und zur eingesetzten Hardware erstklassige Migrationszeiten realisiert werden November 2009

59 Vielen Dank für Ihre Aufmerksamkeit! Haben Sie noch Fragen?