und Server
Werbung
GTUG 17./18. April 2012 in Ratingen Portierung einer Oracle PL/SQL basierenden Anwendung auf HP NonStop mit SQL/MX [email protected] Aluminium Norf GmbH Koblenzer Str. 120 41468 Neuss ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 3 Aufgabenstellung LOGDB IT-Support & Entwicklung WINDOWS Cluster WINDOWS Cluster Node1 in RZ1 T1 T2 LOGSRV Produktion Oracle LOGDB BDE‘s Server Client1 TCP/IP Request/Reply Server1 Client2 Server2 Client3 Server3 Oracle Call Interface (OCI) T1 WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe NonStop API C++ Library COBOL Library Oracle Call Interface (OCI) T2 LOGSRV Oracle LOGDB WINDOWS Cluster Node2 in RZ2 ALUNORF Ein Walzwerk für die Welt 4 Aufgabenstellung LOGDB Viewer ALUNORF Ein Walzwerk für die Welt 5 Aufgabenstellung LOGDB Viewer ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 8 Oracle Features • • • • • • • • kontra 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 SQL/MX Features • • • • • • • • 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 – ? ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 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 ; VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, NUMBER, NUMBER, VARCHAR2 FUNCTION LogEvtData( vAppName vAppInst vEvtDateTime vEvtMasch vEvtCategory vEvtType vEvtLevel vEvtInfo vEvtData ) RETURN NUMBER ; VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, VARCHAR2, NUMBER, NUMBER, VARCHAR2, RAW ... END LOGSRV ; / ALUNORF Ein Walzwerk für die Welt 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 VARCHAR2, vAppInst VARCHAR2, vEvtDateTime VARCHAR2, vEvtMasch VARCHAR2, vEvtCategory VARCHAR2, 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 ) ; … ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 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) ALUNORF Ein Walzwerk für die Welt 14 Lösungsansatz LOGDB – Phase 1 Start IT-Support & Entwicklung WINDOWS Cluster WINDOWS Cluster Node1 in RZ1 T1 T2 LOGSRV Produktion Oracle LOGDB BDE‘s Server Client1 TCP/IP Request/Reply Server1 Client2 Server2 Client3 Server3 Oracle Call Interface (OCI) T1 WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe NonStop API C++ Library COBOL Library Oracle Call Interface (OCI) T2 LOGSRV Oracle LOGDB WINDOWS Cluster Node2 in RZ2 ALUNORF Ein Walzwerk für die Welt 15 Lösungsansatz LOGDB – Phase 1 IT-Support & Entwicklung NonStop Server 4 CPU mit 1 GB RAM SQL/MX LOGDB Produktion BDE‘s Server OdbcLib & ODBC/MX Client1 TCP/IP Request/Reply OdbcLib & ODBC/MX Server1 Client2 Server2 Client3 Server3 T1 WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe T1 LOGSRV WINDOWS Cluster ALUNORF Ein Walzwerk für die Welt 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 – – • • • – 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 • – Timestamp Behandlung Publish / Subscribe 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 ALUNORF Ein Walzwerk für die Welt 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 ALUNORF Ein Walzwerk für die Welt 18 Lösungsansatz LOGDB – Phase 2 Start IT-Support & Entwicklung NonStop Server SQL/MX LOGDB Produktion BDE‘s Server OdbcLib & ODBC/MX Client1 TCP/IP Request/Reply OdbcLib & ODBC/MX Server1 Client2 Server2 Client3 Server3 T1 WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe T1 LOGSRV WINDOWS Cluster ALUNORF Ein Walzwerk für die Welt 19 Lösungsansatz LOGDB – Phase 2 IT-Support & Entwicklung NonStop Server Pathsend VSP Produktion BDE‘s Server Client1 VSP (TCP/IP) Request/Reply LOGSRV SQL/MX LOGDB Emb-SQL/MX OdbcLib & ODBC/MX LogSrv DLL Server1 Client2 Server2 Client3 Server3 WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe ALUNORF Ein Walzwerk für die Welt 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++/EmbSQL ist überschaubar Skalierbarkeit erfordert zusätzliche Modularisierung – • • • • – 2. 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 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 ALUNORF Ein Walzwerk für die Welt 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…) • • – Aktuell: Überlegungen einer Rückportierung von SQL/MX auf SQL/MP • • • • • XP-Storage basierende NS-Series Systeme sind ähnlich komplex wie Oracle RAC Systeme TCO Vorteile der NonStop Systeme werden geringer werden 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 ALUNORF Ein Walzwerk für die Welt 22 GTUG 17./18. April 2012 in Ratingen [email protected] Aluminium Norf GmbH Koblenzer Str. 120 41468 Neuss ALUNORF Ein Walzwerk für die Welt 23
