Migration von Oracle nach EnterpriseDB

Migration von Oracle nach EnterpriseDB Joachim Sandra Wieki Kunze Manager Director Product Sales Marketing &- enterprisedb Services Joachim Kunze Manager Sales & Services - DASEQ GmbH

Agenda Begrüßung Oracle2EDB nativ Oracle Database Migration to EDB Postgres Fragen und Antworten

Hintergrund DASEQ GmbH 2005 durch Ronald Elser und Joachim Bassmann gegründet Fokussierung zu Beginn auf Red Hat Enterprise Linux, Security und Training Services > 20 Jahre Erfahrung im Bereich IT Security > 15 Jahre Erfahrung im Bereich OpenSource Ca 20 Consultants/Trainer für Projekte/Workshops

SOLUTIONS Clustering (RHCS, pacemaker) Datenbanken (EnterpriseDB) Virtualisierung (RHEV / KVM / XEN) Storage/Big Data (Gluster, Ceph) Cloud (Cloudforms, OpenStack, OpenShift) Linux IT Automation (Satellite Server, puppet, jenkins) ERP (SAP HANA, SAP BW) Portal (JBoss Portal) Monitoring (Opsview) Application Server (JBoss AS) DASEQ Solution Framework

PROFESSIONAL SERVICES Wir unterstützen unsere Kunden als Partner mit: Erfahrungsschatz der Fokus aller Mitarbeiter basiert auf Open Source Technologie und Security Wissenstransfer der gesamte Mentoring Prozess sichert den langfristigen Erfolg der Kundenprojekte Open Source Integration die Beziehung zur Open Source Community ermöglicht die langfristige Investitionssicherheit Unabhängigkeit DASEQ bietet hersteller- und plattformunabhängige Lösungen für eine optimale Integration mit maximalem Nutzen

Oracle2EDB Migration Aufgrund des hohen Kompatitbilitätsgrades zwischen Oracle DB und der PostgreSQL bietet sich für viele Unternehmen eine Migration zu der freien Datenbank an, da sich die Migrationsaufwände überschaubar gering halten. Selbst wenn nicht komplett auf PostgreSQL migriert werden kann, so könnte auch ein Mischbetrieb eine valide Alternative darstellen Generell bieten sich unterschiedliche Ansätze an, Oracle Datenbanken nach EDB/PostgreSQL zu migrieren Manuelle Migration (aufwändig, aber sehr flexibel) Migrationen mithilfe Tools wie ora2pg, DBConvert o.ä. In Migrationsprojekten hat sich gezeigt, daß der Einsatz von z.b. ora2pg sehr bewährt hat, da keine JDBC oder ODBC Treiber benötigt werden

Funktionalität ora2pg Perl DBI basiert Export eines kompletten Datenbank Schemas (tables, views, sequences, indexes) mit unique, primary, foreign key und check contraints Export von grants/privileges für User und Gruppen Export von functions, triggers, procedures, packages und package bodies Export von kompletten Datensätzen oder einem Subset über eine WHERE clause Kompletter Export von Oracle BLOB Objekten als PG BYTEA Export von Oracle views als PG tables Export von Oracle benutzerdefinierten Types Export über COPY Files oder direkt von Oracle nach PostgreSQL (keine Flat Files) Funktioniert auf allen von PostgeSQL unterstützen Plattformen uvam...

Bezug von ora2pg Download von ora2pg von github: https://github.com/darold/ora2pg Ora2pg Homepage: http://ora2pg.darold.net

Voraussetzungen/Installation Eine komplette und lauffähige Installation von EDB/PostgreSQL Eine komplette und lauffähige Oracle Installation Perl 5.6 oder neuer Perl DBI und DBD::Oracle Perl Module DBD:: Oracle setzt die Oracle Client Bibliotheken voraus und ORACLE_HOME muß gesetzt sein Installation tar-xjf ora2pg...tar.bz2 perl Makefile.PL make && make install Ora2Pg.pm wird in das Perl Repository importiert ora2pg wird nach /usr/local/bin kopiert ora2pg.conf wird nach /etc/ora2pg kopiert

Vorgehensweise Tabellen, DDL, Daten (pro Tabelle) und Funktionen werden separat migriert Bessere Kontrolle über die Migration Empfohlen ist ein Wrapper Script mit dem die Tabellen angelegt werden sowie die Oracle Variablen und die Schema Variablen gesetzt werden Ora2pg -c <config_file> > tablist Bearbeitung der Tablist, damit sie NUR die Namen der Tabellen enthalten Migration der DDL Migration der Daten Migration der Funktionen

Vorgehensweise / Testing Am Ende der Migration sollte geprüft werden, ob alle Objekte der Oracle Datenbank in der postgresql Datenbank erzeugt wurden PG_DSN muß gesetzt sein, um die Prüfung auf der postgresql Seite durchzuführen Wichtig ist bei dem anschließenden Testing, ob die SQL Statements im Applikationscode die erwarteten Ergebnisse zurückliefern daher kann man auch Einzeltest nicht verzichten

Vorgehensweise / Testing Durch den folgenden Befehl wird ein Report erzeugt, der die Anzahl der Rows auflistet und Details der Unterschiede für die unterschiedlichen Objekte aufzeigt ora2pg -t TEST -c config/ora2pg.conf > migration_diff.txt [TEST INDEXES COUNT] ORACLEDB:COUNTRIES:1 POSTGRES:countries:1 ORACLEDB:JOB_HISTORY:4 POSTGRES:job_history:4 ORACLEDB:DEPARTMENTS:2 POSTGRES:departments:1 ORACLEDB:EMPLOYEES:6 POSTGRES:employees:6 ORACLEDB:CUSTOMERS:1 POSTGRES:customers:1 ORACLEDB:REGIONS:1 POSTGRES:regions:1 ORACLEDB:LOCATIONS:4 POSTGRES:locations:4 ORACLEDB:JOBS:1 POSTGRES:jobs:1 [ERRORS INDEXES COUNT] Table departments doesn't have the same number of indexes in Oracle (2) and in PostgreSQL (1).

Vorgehensweise / Monitoring PgBadger: Ein schneller PostgreSQL Log Analyzer PgCluu: PostgreSQL und Sytem Performance Monitoring- und Auditing Tool Pgwatch: Monitor für PostgreSQL Datenbanken gibt einen schnellen und effizienten Überblick darüber, was wirklich vor sich geht check_postgres: Skript für das Monitoring von diversen Attribute der Datenbank. OPM: Open PostgreSQL Monitoring. Fasst Statistiken in Dashboards zusammen. Erzeugt Alerts Powa: PostgreSQL Workload Analyzer. Erfasst Performance Statistiken und erstellt Realtime Charts. Mehr Tools auf https://wiki.postgresql.org/wiki/monitoring

Und nun: Volle Kraft voraus!