Portierung einer Oracle PL/SQL basierenden Anwendung auf HP NonStop mit SQL/MX

GTUG 17./18. April 2012 in Ratingen Portierung einer Oracle PL/SQL basierenden Anwendung auf HP NonStop mit SQL/MX Andreas.Gratz@alunorf.de Aluminium Norf GmbH Koblenzer Str. 120 41468 Neuss 1

Gliederung Aufgabenstellung Motivation Herausforderungen Lösungsansätze Zieldatenbank SQL/MX Hoffnungsträger: Referentielle Integrität, Trigger, Stored Procedures Lösungsansatz LOGDB in 2 Schritten Datenbank von Oracle auf NonStop verlagern Server auf NonStop verlagern Lösungsansatz BDEDB mit 2 Wegen Prototyp BDEDB mit Java Stored Procedures BEA Weblogic 8.1.4 auf NonStop BDEDB mit BDESRV auf NonStop Fazit 2

Aufgabenstellung LOG-Datenbank von Oracle nach S-Serie Mehrere 100 WINDOWS Clients und Server Ein multithreaded WINDOWS Server (LOGSRV) Anwendungslogik ca. 80% in PL/SQL Client/Server Kommunikation über TCP/IP (Request/Reply) WINDOWS Managementtool Oracle 9i WINDOWS Cluster BDE-Datenbank von Oracle nach S-Serie (-> Folgeprojekt) Ca. 150 WINDOWS Clients Eine multithreaded WINDOWS Middleware (Server) Anwendungslogik ca. 80% in PL/SQL Client/Server Kommunikation über COM bzw. ActiveX Control und TCP/IP (Request/Reply) zur Middleware WINDOWS Managementtool Oracle 9i WINDOWS Cluster 3

Aufgabenstellung LOGDB WINDOWS Cluster IT-Support & Entwicklung WINDOWS Cluster Node1 in RZ1 Produktion BDE s Server T1 T2 LOGSRV Oracle LOGDB Oracle Call Interface (OCI) Server1 Server2 Server3 Client1 Client2 Client3 TCP/IP Request/Reply WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe Oracle Call Interface (OCI) T1 T2 LOGSRV Oracle LOGDB NonStop API C++ Library COBOL Library WINDOWS Cluster Node2 in RZ2 4

Aufgabenstellung LOGDB Viewer 5

Aufgabenstellung LOGDB Viewer 6

Motivation LOGDB/BDEDB zunehmend strategischer LOGDB stark erweitert zu einer System Management DB (Ende 2006) BDEDB stark erweitert für Konfiguration und Softwareverteilung aller BDEs (Ende 2007) Oracle Cluster nur ausfallsicher, nicht hochverfügbar Heute: Oracle RAC (ab Standard Edition) ist graduell besser Oracle NUP Lizenzen pro User und Device Heute: Oracle RAC Standard Edition mit CPU Lizenz wäre preiswerter NonStop ohne Mehrkosten für Lizenzen NonStop Resourcen waren verfügbar NonStop ist hochverfügbar out of the box Heute: NS-Serie mit XP-Storage -> out of many boxes Alunorf suchte einen geeigneten SQL/MX Prototypen außerhalb des Kerngeschäftes projektierbar mit wenig Resourcen 7

Herausforderungen Welche Oracle Datenbankfeatures sind noch nutzbar? PL/SQL, Stored Procedures (SP), Sequences, Referentielle Integrität insb. Cascading DELETE für FK, Trigger, Transaction Isolation für SP, Dynamisches SQL Wohin mit der PL/SQL Businesslogik? Wie mit dem WINDOWS Client kommunizieren? ODBC, RSC/VSP Massendaten zum WINDOWS Client? Performance? Bis Ende 2011 S-Serie im Einsatz 8

Oracle Features kontra SQL/MX Features PL/SQL und Emb-SQL Stored Procedures in PL/SQL BLOBs Sequences Cascading delete für FK Trigger Transaction Isolation für SP Dynamisches SQL Performant Query plan caching plus Statement Rewrite ANSI SQL und Emb-SQL Stored Procedures in Java Nicht implementiert Nicht implementiert Nicht implementiert Quasi nicht implementiert Hilfskonstrukte mit MP ALIAS Dynamisches SQL Langsam? 9

Anwendungslogik mit PL/SQL PL/SQL ist vollständige Programmiersprache Variablen, Cursor, Ablaufkontrolle, Prozeduren, Funktionen, Trigger, Transaktion, Errorhandling, Exceptions Über externe PL/SQL Prozeduren kann Oracle mit C/C++ und Java Code nahezu beliebig erweitert werden Menge Standardprozeduren für IP, Webservices, Queues ist sehr hoch Eine Stored Procedure (oder Function) ist ein funktionaler Aspekt einer Anwendung (oder Library) Ein Set von Stored Procedures (oder Functions) ist die Anwendung (oder Library) und heißt Packet Der Server ist die Oracle Datenbank (out of the box) Stored Procedures in PL/SQL können von beliebigen Datenbank Clients (und Servern) aufgerufen werden OCI, ODBC, JDBC. Im Rahmen einer Session oder Connection können Stored Procedures konsumiert und orchestriert werden 10

Anwendungslogik mit PL/SQL - Package CREATE OR REPLACE PACKAGE LOGSRV IS FUNCTION Version RETURN VARCHAR2 ; FUNCTION LogEvt( vappname vappinst vevtdatetime vevtmasch vevtcategory vevttype vevtlevel vevtinfo ) RETURN NUMBER ; NUMBER, NUMBER, VARCHAR2 FUNCTION LogEvtData( vappname vappinst vevtdatetime vevtmasch vevtcategory vevttype vevtlevel vevtinfo vevtdata ) RETURN NUMBER ;... NUMBER, NUMBER, RAW END LOGSRV ; / 11

Anwendungslogik mit PL/SQL - Package Body CREATE OR REPLACE PACKAGE BODY LOGSRV IS FUNCTION Version RETURN VARCHAR2 IS BEGIN RETURN '2.1.2' ; END; FUNCTION LogEvt( vappname vappinst vevtdatetime vevtmasch vevtcategory vevttype NUMBER, vevtlevel NUMBER, vevtinfo VARCHAR2 ) RETURN NUMBER IS vret NUMBER := 0 ; vevtid NUMBER := 0 ; vcuralarmevtid NUMBER := 0; vcuralarmstate NUMBER := 0; vcuralarmhistory NUMBER := 0; vevtinfo2 VARCHAR2(512); vevttype2 NUMBER := 0; BEGIN IF vevttype = 5 THEN vret := LOGSRV.LogAlarmExist( vappname, vappinst, vevtmasch, vevtcategory, vcuralarmevtid, vcuralarmstate, vcuralarmhistory ) ; IF vret = 0 THEN vevtinfo2 := 'AlarmSet with error NO_DATA_FOUND, alarm does not exist' ; vevttype2 := 2 ; SELECT S_LOGEVT_EVTID.NEXTVAL INTO vevtid FROM DUAL ; vret := LOGSRV.LogEvtCreate( vappname, vappinst, vevtdatetime, vevtmasch, vevtcategory, vevttype2, vevtlevel, vevtinfo ) ; 12

Abbild. der Anwendungslogik auf NonStop PL/SQL Programmiersprache mit Emb-SQL (COBOL, C/C++, ) Stored Procedure Messagetyp eines Pathway Servers (Request/Reply) PL/SQL SP Parameter müssen in der Messagestruktur abgebildet werden Package Summe aller Messagetypen eines Pathway Servers Oracle Call Interface (OCI) NonStop Anwendungen SERVERCLASS_SEND_, WRITEREADX, C/C++ und COBOL Library Middleware für non-nonstop Anwendungen RSC, CSL, VSP, SOAP,. Massendaten bleiben problematisch für Non-ODBC Anwendungen UMS für RSC, CSL, VSP möglich 13

Lösungsansatz LOGDB - Phase 1 1. Oracle wird verlagert auf SQL/MX - BLOBs werden simuliert (VARCHAR & ODBC/MX binding) - SEQUENCEs werden simuliert (Tabelle) - Cascading delete für foreign keys müssen manuell ausprogrammiert werden 2. LOGSRV mit ODBC/MX gegen SQL/MX - PL/SQL Packages als C++ Klassen - Stored Procedures als C++ Methoden - C++ Exception statt PL/SQL Exception - Highlevel C++ OdbcLib ersetzt OciLib 3. LOGDB-GUI mit ODBC/MX gegen SQL/MX - Highlevel C++ OdbcLib ersetzt OciLib (wie LOGSRV) 14

Lösungsansatz LOGDB Phase 1 Start WINDOWS Cluster IT-Support & Entwicklung WINDOWS Cluster Node1 in RZ1 Produktion BDE s Server T1 T2 LOGSRV Oracle LOGDB Oracle Call Interface (OCI) Server1 Server2 Server3 Client1 Client2 Client3 TCP/IP Request/Reply WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe Oracle Call Interface (OCI) T1 T2 LOGSRV Oracle LOGDB NonStop API C++ Library COBOL Library WINDOWS Cluster Node2 in RZ2 15

Lösungsansatz LOGDB Phase 1 IT-Support & Entwicklung NonStop Server 4 CPU mit 1 GB RAM Produktion BDE s Server SQL/MX LOGDB OdbcLib & ODBC/MX Server1 Server2 Server3 Client1 Client2 Client3 TCP/IP Request/Reply WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe OdbcLib & ODBC/MX T1 T1 LOGSRV WINDOWS Cluster 16

Lösungsansatz LOGDB - Phase 1 Fazit 1. Oracle wird verlagert auf SQL/MX ODBC/MX ODBC/MX ist das bessere ODBC für NonStop Timestamp Behandlung Publish / Subscribe ODBC/MX i.a. nur mit prepared cursors performant Keine Nested Cursors in ODBC/MX Memory Leaks in ODBC/MX und somit keine Langzeitstabilität (div. Fehlerbilder) SEQUENCE Simulation mit UPDATE/SELECT wenig performant Caching von PK IDs nötig (ca. 50-100 sinnvoll) Reorganisation der Datenbank mit foreign keys weniger performant Foreign keys Definitionen entfernt 2. Oracle LOGSRV mit ODBC/MX gegen SQL/MX Insgesamt ist das System komplexer (weil verteilter) Auf S-Serie deutlich langsamer als Oracle, wenige Optimierungspotentiale verblieben (ROWSET) 3. LOGDB-GUI mit ODBC/MX gegen SQL/MX - Auf S-Serie trotz Optimierung deutlich langsamer als Oracle, wegen Dyn-SQL - Entwickler und Administratoren im Performancefrust 17

Lösungsansatz LOGDB - Phase 2 1. LOGSRV wird Pathway Server 2. VSP als Middleware für (fast alle) Clients Eigenentwicklung (RSC-Ersatz) und Standard seit 1993 für Clients in der Alunorf Sehr performant Sehr stabil 18

Lösungsansatz LOGDB Phase 2 Start IT-Support & Entwicklung NonStop Server Produktion BDE s Server SQL/MX LOGDB OdbcLib & ODBC/MX Server1 Server2 Server3 Client1 Client2 Client3 TCP/IP Request/Reply WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe OdbcLib & ODBC/MX T1 T1 LOGSRV WINDOWS Cluster 19

Lösungsansatz LOGDB Phase 2 IT-Support & Entwicklung NonStop Server Pathsend Produktion BDE s Server VSP (TCP/IP) Request/Reply VSP LOGSRV Emb-SQL/MX SQL/MX LOGDB OdbcLib & ODBC/MX Server1 Server2 Server3 Client1 Client2 Client3 LogSrv DLL WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe 20

Lösungsansatz LOGDB - Phase 2 Fazit 1. LOGSRV wird Pathway Server C++ Code ist gute Ausgangsbasis, d.h. die Abbildung von C++/OdbcLib auf C++/Emb- SQL ist überschaubar Skalierbarkeit erfordert zusätzliche Modularisierung Die Sequenz Erzeugung muss in einen neuen (Pathway) Server ausgelagert werden Mehrere Aktionen müssen in einer Transaktion zusammengefasst werden!!! Performance erheblich besser als in Phase 1, erreicht aber nicht jene von Oracle Performance vom LOGDB-GUI unverändert schlecht Das System ist noch komplexer als in Phase 1 2. VSP als Middleware für (fast alle) Clients Messagestrukturen müssen nicht geändert werden, weil das VSP-Protokoll transparent ist Die meisten Clients benötigen nur eine neue DLL (die anderen einen compile&link) VSP ist proprietär (aber Alunorf Standard für jegliche Message basierte Kommunikation zur NonStop) NS-Serie (2012) - LOGSRV dramatisch schneller (ca. Faktor 7, von max. 350 auf 2400 Ereignisse pro Sekunde) - LOGDB-GUI erheblich schneller und klar praxistauglich (immer noch langsamer als Oracle) Entwickler und Administratoren sind begeistert 21

Gesamtfazit Oracle kontra SQL/MX (Sicht Alunorf) Die Entscheidung zur Portierung der Anwendung auf NonStop war insg. richtig Oracle und SQL/MX liegen in Konzeption und Funktionalität weit auseinander und die Kluft wird größer Oracle 9-11g ist deutlich überlegen in Funktionalität und programmers productivity SQL/MX (und SQL/MP) punktet klar in Hochverfügbarkeit TCO Betrachtungen überlasse ich den Managern (aber ) XP-Storage basierende NS-Series Systeme sind ähnlich komplex wie Oracle RAC Systeme TCO Vorteile der NonStop Systeme werden geringer werden Aktuell: Überlegungen einer Rückportierung von SQL/MX auf SQL/MP SQL/MX hat es bislang nicht geschafft,strategisch zu werden (ca. 3 Mio. Zeilen C/COBOL FC100) Nur graduelle Vorteile von SQL/MX gegenüber SQL/MP Weiterentwicklung von SQL/MX kommt scheinbar kaum voran (gemessen an Oracle, SQLServer, MySQL, ) Migration von S-Serie auf NS-Serie zeigt konzeptionelle Schwächen von SQL/MX i.b. Upgrade/Export/Import/ Entwickler für SQL/MX oder SQL/MP zu begeistern ist schwer, wenn diese Oracle Erfahrung aufgebaut haben (leider unvermeidbar) weil in SQL/MX ein PL/SQL Äquivalent fehlt, ist es für viele Entwickler nur ein neueres SQL/MP Komplexe Reports/Queries werden heute überwiegend auf Oracle erstellt (klar: Produktion auf NonStop) Datenreplikation relevanter Tabellen mit DDF von NonStop zu Oracle Praxisfremde Implementierungen, z.b. TRIGGER, helfen nicht zu besserer Akzeptanz Stored Procedures in Java wurden von uns intensiv getestet funktionieren gut im Zusammenspiel mit ODBC/MX und BEA Weblogic, benötigen aber zus. Skills benötigen enorme Resourcen und waren auf S-Serie viel zu langsam, gemessen an PL/SQL 22

GTUG 17./18. April 2012 in Ratingen Andreas.Gratz@alunorf.de Aluminium Norf GmbH Koblenzer Str. 120 41468 Neuss 23