Migration von Oracle nach EnterpriseDB
Werbung
Migration von Oracle nach EnterpriseDB Joachim Kunze Sandra Wieki Director ProductSales Marketing Manager &- 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 Datenbanken (RHCS, pacemaker) (EnterpriseDB) Virtualisierung IT Automation (Satellite Server, puppet, jenkins) Linux (RHEV / KVM / XEN) Storage/Big Data (Gluster, Ceph) ERP (SAP HANA, SAP BW) Portal Cloud (Cloudforms, OpenStack, OpenShift) (JBoss Portal) Monitoring Application Server (Opsview) (JBoss AS) DASEQ Solution Framework SOLUTIONS Clustering Datenbanken (RHCS, pacemaker) (EnterpriseDB) Virtualisierung IT Automation (Satellite Server, puppet, jenkins) Linux (RHEV / KVM / XEN) Storage/Big Data (Gluster, Ceph) ERP (SAP HANA, SAP BW) Portal Cloud (Cloudforms, OpenStack, OpenShift) (JBoss Portal) Monitoring Application Server (Opsview) (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: ● Pgwatch: PostgreSQL und Sytem Performance Monitoring- und Auditing Tool 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 !
