6. new workload a db2

1

New Workload a DB2

Prelegent: Maciej Zrobek

2

Agenda

• Gdzie mamy Javę na z/OS?

• Jak Java na z/OS dogaduje się z DB2?

• Wsparcie dla dynamicznego SQLa

• Stored Procedures w Javie

• WebSphere Application Server V8 – co nowego

dla DB2

3

Java na z/OS: SDK

• IBM SDK for z/OS Technology Edition:

– Edycja 31 lub 64-bitowa

– Ostatnia wersja V6.0.1, zgodna z Java SE 6 APIs

• Służy do rozwoju aplikacji Java typu standalone

• Maszyna wirtualna działa po stronie Unix System Services

• Potrafi wykorzystać takie funkcje platformy z/OS, jak SAF,

karty kryptograficzne, procesory zAAP

• Programy Java mogą być uruchamiane on-line lub jako

zadania wsadowe

• Najnowsza wersja potrafi wykorzystać nowe instrukcje

procesora dodane w maszynach z196

4

Java na z/OS: WebSphere Application Server

• Ostatnia wersja V7, ale wersja V8 planowana jest na czerwiec 2011– V7 zgodna z Java EE 5 oraz z EJB 3.0

– Dokładna tabela kompatybilności ze standardami dostępna tu:http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rovr_specs.html

• Środowisko wykonawcze dla aplikacji Java typu enterprise, czyli takich, które mogą funkcjonować wyłącznie wewnątrz serwera aplikacji

• Wsparcie dla takich standardów, jak EJB, Web Services, JSP, JSF, JCA, JMS, WOLA i wielu innych

• Ścisła integracja z elementami z/OS takimi, jak WLM, SAF, karty kryptograficzne, procesory zAAP, Parallel Sysplex

• Doskonała skalowalność, bezpieczeństwo i niezawodność

5

Java na z/OS: CICS

• Maszyna wirtualna Java jest obecna w CICS już od V1.3

• Dzięki temu transakcje CICS mogą być pisane w Javie, a nie tylko w COBOLu, PL/I itp.

• Interakcja programów Java z CICS odbywa siępoprzez JCICS API

• CICS może działać również jako serwer EJB, który mapuje żądania IIOP na wywołania usług CICS

• Począwszy od wersji 3.1 CICS może działać jako serwer lub klient dla Web Services

6

Java w batchu: możliwości

1. Bezpośrednie wywołanie maszyny wirtualnej z JCL poprzez program BPXBATCH

2. Wykorzystanie JZOS:• Możliwość odwołania do zbiorów danych zdefiniowanych jako DD• Output programów bezpośrednio do zbiorów MVS• Komunikacja z konsolą

3. Java Batch:• Dostępne jako Feature Pack For Modern Batch dla WAS lub w

produkcie WebSphere Compute Grid• Nowy kontener wewnątrz WAS dedykowany do zadań wsadowych• Definicja zadań poprzez XJCL oparty na XML• Możliwości schedulingu zadań, definicji powiązań pomiędzy nimi

oraz monitorowania ich wykonania poprzez interfejs przeglądarkowy

7

Java na z/OS i DB2

Jak widzimy, Java bardzo dobrze zadomowiła sięna platformie z/OS i można się do niej odwołaćna wiele sposobów

Ale programy w Javie działają na danych...

... i bardzo często dane te pochodzą z DB2 (najlepiej z DB2 na z/OS ;-).

Przypomnijmy, w jaki sposób Java może „dogadać się” z DB2

8

Dostęp z Javy do DB2

• Sposób połączenia z DB2 zależy od wzajemnego położenia aplikacji Java i DB2

• W tej chwili używane są 2 typy sterowników JDBC: T2 i T4, realizowane poprzez jeden fizyczny sterownik IBM DB2 Universal Driver

for SQLJ and JDBC

• Ogólna zasada brzmi:

– Jeśli Java i DB2 jest na tym samym

LPARze z/OS to używamy T2, w

przeciwnym wypadku używamy T4

9

Sterownik JDBC T2 vs T4

• Sterownik jest zaimplementowany częściowo w natywnym kodzie platformy, na której działa

• W przypadku z/OS sterownik zakłada, że DB2 działa na tym samym LPARze i komunikuje się z bazą poprzez RRS Attachment Facility

• Użycie sterownika T2 zapewnia najlepszą wydajność i „bliskość do danych” ponieważ nie zachodzi tu komunikacja z DB2 poprzez TCP/IP

• Sterownik zaimplementowany całkowicie w Javie, a więc przenaszalny pomiędzy platformami

• Komunikacja z DB2 odbywa siępoprzez protokół DRDA, a transportem jest TCP/IP

• Jeżeli DB2 znajduje się na innym LPARze z/OS to komunikacja może odbywać się poprzez HiperSockets, co zwiększa wydajność

Typ 2 Typ 4

10

Sterownik JDBC T2 vs T4 – porównanie zużycia

procesorów

• Zużycie CP dla obydwu

typów sterownika na

podobnym poziomie

• Obydwa typy mogą

wykorzystać zAAP, a T4

dodatkowo zIIP

• Mimo to zastosowanie T2

pozwala na redukcję

całkowitego zużycia

procesorów aż o 18% w

przypadku DB V10

11

Kolokacja danych – porównanie przepustowości

System z

WAS 6.1

Linux

DB2 8.1

z/OS

WAS 6.1

z/OS

DB2 8.1

z/OS

WAS 6.1DB2 8.1

z/OS

Power System System z System z

150 tps 160 tps 243 tps

Osobne maszyny Osobne LPARy Ten sam LPAR

Type 4

� ��

(40%) (51%)

Type 4 Type 2

Przepustowość transakcyjna o 54% większa w przypadku kolokacji

4 CPUs (98%) 8 CPUs (91%)8 CPUs in shared pool (91%)4 CPUs (32% busy)

Więcej informacji tutaj: http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101476

12

JDBC vs SQLJ

• JDBC jest zwyłym API wysokiego poziomu

• Z założenia wykorzystanie dynamicznego SQLa

• Brak fazy translacji kodu SQL i Bind – tylko kompilacja

• Typy danych SQL nie sąsprawdzane podczas kompilacji

• Nie ma możliwości użycia host

variables w SQLu

• Większy overhead kodu w stosunku do SQLJ

JDBCConnection con =

DriverManager. getConnection("jdbc:default:connection");

PreparedStatement stmt = null;

boolean bFlag ;

String sql;

sql = "SELECT *" + " FROM TEST_TBL" + " WHERE SERNO = ?";

stmt = con.prepareStatement(sql);

stmt.setString(1, ID);

bFlag = stmt.execute();

rs1[0] = stmt.getResultSet();

13

JDBC vs SQLJ

• SQL jest rozszerzeniem języka, a nie tylko API

• Z założenia wykorzystanie statycznego SQLa

• Potrzebna faza translacji kodu, kastomizacji oraz BIND

• Typy danych SQL są sprawdzane podczas przygotowania programu

• Jest możliwość użycia host

variables w SQLu

• Bardziej wydajny kod, ponieważSQLJ automatycznie generuje część kodu

SQLJ try {

ctx = new SPContext("jdbc:default:connection", false);

switch (whichQuery) {

case 0:

#sql [ctx] cursor1 = { SELECT * FROM TEST_TBL

WHERE SERNO > :ID };

rs1[0] = cursor1.getResultSet();

break;

case 1:

#sql [ctx] { UPDATE TEST_TBL

SET TYPE = 'X'

WHERE SERNO = :ID };

break;

default:

break;

}

14

Dynamiczny SQL

• Głównym problemem przy wykorzystaniu

dynamicznego SQLa jest konieczność PREPARE

przy każdym uruchomieniu programu

– Oczywiście wynika to z faktu, że w momencie

(pre)kompilacji kodu nie znamy jeszcze wyrażeń SQL do

wykonania

• Powyższe oczywiście wpływa ujemnie na

wydajność dynamicznego SQLa, bo PREPARE

kosztuje i to sporo

• Na szczęście DB2 na z/OS oferuje pewne techniki,

które pozwalają na zmniejszenie kosztów

związanych z dynamicznym SQLem

15

Dynamiczny SQL - caching

• Już w DB2 V5 wprowadzono funkcję Dynamic Statement Caching, która pozwala na uniknięcie powtórnego PREPARE dla identycznych wyrażeń

• Problem polega na tym, że te wyrażenia muszą byćidentyczne co do znaku oraz wykonane przez tego samego użytkownika, aby DB2 skorzystało z cache

• Dlatego też w dynamicznym SQLu powinno unikać sięużycia literałów, np:

– ... WHERE ACCOUNT_NUMBER = 123456

• Użycie parameter markers zwiększa szanse na wykorzystanie cache, bo poszukujemy bardziej specyficznego wyrażenia:

– ... WHERE ACCOUNT_NUMBER = ?

16

Dynamiczny SQL – zastępowanie literałów

• DB2 V10 rozszerza użycie cache na dynamicznego SQLa z literałami– Trik polega na zastąpieniu literałów znakiem ‘?’ (Uwaga! To nie to samo,

co parameter marker.)

• Przy włączonej tej opcji DB2 stosuje następującą strategięprzeszukiwania cache:

– Najpierw poszukiwane jest dokładne wyrażenie z literałami

– Jeśli nie znaleziono, to literały są zastępowane przez ‘?’ i poszukiwanie jest ponawiane dla nowego SQLa

– Jeśli nie znaleziono to wykonywane jest PREPARE i nowe wyrażenie jest umieszczane w cache

• Jak to włączyć:– Umieścić CONCENTRATE STATEMENTS WITH LITERALSw

atrybutach PREPARE, albo

– Umieścić LITERALREPLACEMENTw pliku inicjalizacyjnym ODBC, albo

– Ustawić właściwość enableLiteralReplacement=’YES’sterownika JCC

• Mimo wszystko jednak użycie parameter markers przynosi najlepsze rezultaty

17

Dynamiczny SQL – REOPT

• Opcja REOPT przy BIND pozwala na ustalenie ścieżki wykonania przez optymalizator DB2 podczas wykonywania (EXECUTE) wyrażeń SQL zawierających host variables, parameter markers i special registers

• Pozwala to na uwzględnienie konkretnych wartości parametrów wykonania SQL i potencjalnie lepsząoptymalizację

• Przed DB2 V8 mieliśmy do dyspozycji REOPT(VARS) i NOREOPT(VARS), które odpowiednio włączały lub wyłączały optymalizację ścieżki dostępu przy wykonaniu takich wyrażeń, również dla SQLa statycznego

• Od wersji V8 włącznie REOPT(VARS) i NOREOPT(VARS) zostały zachowane tylko dla kompatybilności, natomiast nowa składnia tego parametru wygląda następująco:

– REOPT(NONE) = NOREOPT(VARS)– REOPT(ALWAYS) = REOPT(VARS)– REOPT(ONCE).

18

Dynamiczny SQL – REOPT(ONCE)

• REOPT(ONCE) powoduje, że Optymalizator ustala na nowo ścieżkę dostępu tylko dla pierwszego EXECUTE/OPEN danego wyrażenia

• Opcja ma zastosowanie tylko dla SQLa dynamicznego

• Użycie REOPT(ONCE) nie wyklucza się z opcjąKEEPDYNAMIC(YES), tak jak to było w przypadku REOPT(ALWAYS), a zatem możemy jednocześnie korzystać z dobrodziejstw lepszej optymalizacji i z Dynamic Statement Caching

19

Procedury składowane w Javie

• Procedury składowane można pisać w Javie (JDBC lub SLQJ)

• Korzyści z użycia procedur składowanych:– Zmniejszenie ruchu

sieciowego dla aplikacji rozproszonych

– Modularyzacja aplikacji ułatwiająca dokonywanie zmian

– Izolacja programistów od problemów dostępu do bazy danych

– Dostęp do zasobów zewnętrznych w stosunku do DB2 np. VSAM

20

Wsparcie dla procedur składowanych w Javie w Rational

Developer for System z 1/4

Wybór nazwy i sposobu implementacji procedury

Utworzenie wyrażeń SQL do wykonania w procedurze

21



Definicja parametrów procedury

Opcje wdrażania procedury

22



Generacja kodu w Javie

Generacja SQLa do utworzenia procedury

23

Wsparcie dla procedur składowane w Javie w Rational Developer

for System z 4/4

Utworzona procedura może zostać wdrożona, uruchomiona, albo zdebugowana bezpośrednio z RDz

24

WebSphere Application Server for z/OS V8 –

wykorzystanie alternatywnych źródeł danych 1/3

DB2lokalne

WAS for z/OS V8WAS for z/OS V8

Routingżądań

Aplikacja

Odwołanie do źródła danych

Podstawoweźródło danych

DB2zdalne

Alternatywneźródło danych

Aplikacje WAS komunikują się z DB2 za pomocą źródeł danych zdefiniowanych w konfiguracji WAS

Jedną z nowinek w WAS V8 jest możliwość definicji alternatywnego źródła danych na wypadek niedostępności źródła podstawowego

25

Jeżeli WAS wykryje niedostępność podstawowego źródła danych, to nowe połączenia do bazy zostają automatycznie przekierowane do źródła alternatywnego

Aplikacje nie muszą sobie zdawać sprawy z przełączenia źródła danych

DB2lokalne


Routingżądań

Aplikacja


Podstawowe źródło danych

DB2zdalne


DB2lokalne


Routingżądań

Aplikacja



DB2zdalne




26

DB2lokalne


Routingżądań

Aplikacja



DB2zdalne


Jeżeli WAS wykryje, że podstawowe źródło danych jest znowu dostępne, to nastąpi automatyczne przełączenie na z powrotem na wykorzystanie tego źródła

DB2lokalne


Routingżądań

Aplikacja


Podstawowe źródło danych

DB2zdalne




Analogiczna funkcjonalność działa również w przypadku połączeń za pomocą WOLA, np. z regionami CICS

General Availability:

17.06.2011

27

Podsumowanie

• Java na z/OS jest już dobrze zadomowiona

• Java na z/OS i DB2 to dobrze dobrana para, ale

najlepiej dla nich, jak są blisko siebie

• Produkty WebSphere i Rational stwarzają warunki

dla dobrej współpracy Javy i DB2

• DB2 dla z/OS posiada zaawansowane

mechanizmy optymalizujące wykonanie

dynamicznego SQLa

28

Dziękuję za uwagę