Portierung einer Oracle PL/SQL basierenden …€¦ · ALUNORF Ein Walzwerk für die Welt 1 GTUG...

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


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


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


4

Server1

Server2

Server3

Aufgabenstellung LOGDB

WINDOWS Cluster

LOGSRV

T1

Oracle LOGDB

T2

WINDOWS Cluster Node1 in RZ1


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)


5

Aufgabenstellung LOGDB Viewer


6

Aufgabenstellung LOGDB Viewer


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


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


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 – ?


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


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 ; /


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 ) ;

…


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


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)


15

Server1

Server2

Server3

Lösungsansatz LOGDB – Phase 1 Start

WINDOWS Cluster

LOGSRV

T1

Oracle LOGDB

T2



Oracle LOGDB

LOGSRV

T1 T2

Client1

Client2


Client3



Oracle Call

Interface (OCI)


NonStop API C++ Library

COBOL Library

Oracle Call

Interface (OCI)


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


Client3



OdbcLib & ODBC/MX


OdbcLib & ODBC/MX


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


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


19

Server1

Server2

Server3

Lösungsansatz LOGDB – Phase 2 Start

LOGSRV

T1

SQL/MX LOGDB

T1

NonStop Server

WINDOWS Cluster

Client1

Client2


Client3



OdbcLib & ODBC/MX


OdbcLib & ODBC/MX


20

Server1

Server2

Server3

Lösungsansatz LOGDB – Phase 2

SQL/MX LOGDB

NonStop Server

Client1

Client2

VSP (TCP/IP)

Request/Reply

Client3



OdbcLib & ODBC/MX


Emb-SQL/MX

LOGSRV VSP

Pathsend

LogSrv DLL


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


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


23

GTUG 17./18. April 2012 in Ratingen

[email protected] Aluminium Norf GmbH

Koblenzer Str. 120 41468 Neuss

Portierung einer Oracle PL/SQL basierenden …€¦ · ALUNORF Ein Walzwerk für die Welt 1 GTUG...

Documents

Transcript of Portierung einer Oracle PL/SQL basierenden …€¦ · ALUNORF Ein Walzwerk für die Welt 1 GTUG...