portierung einer oracle pl/sql basierenden …€¦ · alunorf ein walzwerk für die welt 1 gtug...
TRANSCRIPT
ALUNORF Ein Walzwerk für die Welt
1
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
2
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
3
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
4
Server1
Server2
Server3
Aufgabenstellung LOGDB
WINDOWS Cluster
LOGSRV
T1
Oracle LOGDB
T2
WINDOWS Cluster Node1 in RZ1
WINDOWS Cluster Node2 in RZ2
Oracle LOGDB
LOGSRV
T1 T2
Client1
Client2
TCP/IP Request/Reply
Client3
Produktion BDE‘s Server
IT-Support & Entwicklung
Oracle Call
Interface (OCI)
WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe
NonStop API C++ Library
COBOL Library
Oracle Call
Interface (OCI)
ALUNORF Ein Walzwerk für die Welt
7
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
8
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
9
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 – ?
ALUNORF Ein Walzwerk für die Welt
10
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
11
Anwendungslogik mit PL/SQL - Package CREATE OR REPLACE PACKAGE LOGSRV IS FUNCTION Version RETURN VARCHAR2 ; FUNCTION LogEvt( vAppName VARCHAR2, vAppInst VARCHAR2, vEvtDateTime VARCHAR2, vEvtMasch VARCHAR2, vEvtCategory VARCHAR2, vEvtType NUMBER, vEvtLevel NUMBER, vEvtInfo VARCHAR2 ) RETURN NUMBER ; FUNCTION LogEvtData( vAppName VARCHAR2, vAppInst VARCHAR2, vEvtDateTime VARCHAR2, vEvtMasch VARCHAR2, vEvtCategory VARCHAR2, vEvtType NUMBER, vEvtLevel NUMBER, vEvtInfo VARCHAR2, vEvtData RAW ) RETURN NUMBER ;
... END LOGSRV ; /
ALUNORF Ein Walzwerk für die Welt
12
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
13
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
14
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
15
Server1
Server2
Server3
Lösungsansatz LOGDB – Phase 1 Start
WINDOWS Cluster
LOGSRV
T1
Oracle LOGDB
T2
WINDOWS Cluster Node1 in RZ1
WINDOWS Cluster Node2 in RZ2
Oracle LOGDB
LOGSRV
T1 T2
Client1
Client2
TCP/IP Request/Reply
Client3
Produktion BDE‘s Server
IT-Support & Entwicklung
Oracle Call
Interface (OCI)
WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe
NonStop API C++ Library
COBOL Library
Oracle Call
Interface (OCI)
ALUNORF Ein Walzwerk für die Welt
16
Server1
Server2
Server3
Lösungsansatz LOGDB – Phase 1
LOGSRV
T1
SQL/MX LOGDB
T1
NonStop Server 4 CPU mit 1 GB RAM
WINDOWS Cluster
Client1
Client2
TCP/IP Request/Reply
Client3
Produktion BDE‘s Server
IT-Support & Entwicklung
OdbcLib & ODBC/MX
WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe
OdbcLib & ODBC/MX
ALUNORF Ein Walzwerk für die Welt
17
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
ALUNORF Ein Walzwerk für die Welt
18
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
19
Server1
Server2
Server3
Lösungsansatz LOGDB – Phase 2 Start
LOGSRV
T1
SQL/MX LOGDB
T1
NonStop Server
WINDOWS Cluster
Client1
Client2
TCP/IP Request/Reply
Client3
Produktion BDE‘s Server
IT-Support & Entwicklung
OdbcLib & ODBC/MX
WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe
OdbcLib & ODBC/MX
ALUNORF Ein Walzwerk für die Welt
20
Server1
Server2
Server3
Lösungsansatz LOGDB – Phase 2
SQL/MX LOGDB
NonStop Server
Client1
Client2
VSP (TCP/IP)
Request/Reply
Client3
Produktion BDE‘s Server
IT-Support & Entwicklung
OdbcLib & ODBC/MX
WINDOWS APIs C/C++ Library ActiveX DLL LogDBCI.exe
Emb-SQL/MX
LOGSRV VSP
Pathsend
LogSrv DLL
ALUNORF Ein Walzwerk für die Welt
21
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
ALUNORF Ein Walzwerk für die Welt
22
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
ALUNORF Ein Walzwerk für die Welt
23
GTUG 17./18. April 2012 in Ratingen
[email protected] Aluminium Norf GmbH
Koblenzer Str. 120 41468 Neuss