6. new workload a db2
TRANSCRIPT
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
Wsparcie dla procedur składowanych w Javie w Rational
Developer for System z 2/4
Definicja parametrów procedury
Opcje wdrażania procedury
22
Wsparcie dla procedur składowanych w Javie w Rational
Developer for System z 3/4
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
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
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
WebSphere Application Server for z/OS V8 –
wykorzystanie alternatywnych źródeł danych 2/3
26
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
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
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
WebSphere Application Server for z/OS V8 –
wykorzystanie alternatywnych źródeł danych 3/3
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ę