Migracja DB2 7 do DB2 9

w Grupie TP

Aneta Kiljan i Gerard Kaduczek

Administratorzy z/OS

9 czerwca 2011

agenda

� dlaczego migracja

� opis środowiska

� upgrade DB2 7 do DB2 8

� upgrade DB2 8 do DB2 9

� podsumowanie

dlaczego migracja ?� brak stabilności pracy aplikacji w DB2 7 - przykład:

inny wynik SQL przy zapytaniu przez indeks a inny przez tablice

� błędy w DB2 7 optimizer – dołożenie kolejnej kolumny w klauzuli „where” nie zwiększało MC (matching colums). Rozwiązanie problemu to inny zapis ( zamiast where x = y to x >= y and x <= y )

� problem z maintenance - zbyt duże indeksy NPI oraz duże tablice ( rozwiązanie: IGNSORTN=YES, SORTAL=YES )

� brak wsparcia IBM ( EOS dla DB2 7 )

� brak nowych funkcjonalności ( kompresja indeksów, partycjonowanie w tablicy zamiast indeks NPI )

opis środowiska� trzy obszary do migracji:

1. produkcja 21 TB ( 6 x DB2, 2 x Data Sharing )

2. preprodukcja 6 TB ( 2 x DB2, 1 x Data Sharing )

3. testy 3 TB ( 4 x DB2 )

� największa tablica SS2BI22C 1,4 mld. rekordów 3,6 mln. trk,

największy indeks XS2ID02 840 tys. trk

� 112 baz aplikacyjnych, 75 tys. obiektów fizycznych

� dodatkowe środowisko nie zakłócające testów produktów

biznesowych

� testy wykonane również na katalogu bazy i logach DB2 ( bez danych )

krok po kroku ?� zalecane trzy kroki migracji: CM,

ENFM, NFM

� faza ENFM powinna trwać możliwie

krótko

� decyzja o natychmiastowym

przejściu z ENFM do NFM

� 4 przerwy biznesowe zamiast 6 w

procesie migracji

� przed każdym krokiem backup,

snap całego środowiska -

procedura rollback

harmonogram migracji

� pierwsza instalacja DB2 8 w środowisku maintenance 17.01.2008

� EOS DB2 7 30.06.2008

� Extended support dla DB2 7 01.12.2008 - 30.05.2009

� migracja DB2 7 do DB2 8CM 24.04.2010

� EOS DB2 8 30.04.2012

� migracja DB2 8CM do 8ENF 18.09.2010

� wdrożenie RRS dla DB2 09.01.2011

� migracja DB2 8 do DB2 9CM 16.01.2011

� migracja DB2 9CM do DB2 9ENF 20.02.2011

� EOS DB2 9 i 10 nie określono

obciążenie środowiska

upgrade DB2 8 CM� problemy z sysibm.syslgrnx w trakcie operacji „create

object”

� field procedures – przeładowanie problematycznych

danych

� problemy wydajnościowe programów w CICS

� kilkugodzinna analiza wydajności programów, IPL

środowiska, wpływ procesorów ZIIP

� narzędzia BMC V2090 ( MAINVIEW for DB2 9.1.00,

APPTUNE for DB2 6.1.00)

upgrade DB2 8 NFM

� upgrade bez zakłóceń

� problemy z bufferpool BPK8K dla bazy w datasharing -

długa realizacja zadań do bind oprogramowania aplikacji

upgrade DB2 9 CM� wdrożenie V2285 MAINVIEW for DB2 9.2.00, BMC APPTUNE for DB2

6.2.00

� wdrożenie RRS (Resource Recovery Services) w sysplex do obsługi GSDXWLM zamiast GSD%SPAS, dodatkowy zasób w WLM

� zmiana parametrów DSMAX z 14500 na 20000 - ilość otwartych zbiorów

� uruchomienie na wszystkich bazach statystyk RTS – DSNRTSDB, dane zostaną wykorzystane w następnym kroku do załadowania nowych RTS

� problem z reorganizacją tablic

Reorganizacja tablic partycjonowanych z opcją partlevel powoduje wykonanie także, reorganizacji wszystkich indeksów NPI. Zwiększa to czas maintenance (w naszym środowisku nawet 400 % w porównaniu z DB2 8)

przykład� w wersji DB2 8 reorganizacja trwała 14 minut

� w wersji DB2 9 reorganizacja trwała 28 minut –

100 % dłużej

� -PSDA 019 09:14:20.58 DSNURULN -

330727167 INDEX ENTRIES UNLOADED FROM

'SPINS2.XS2BI91A‘

� przebudowa tablic z indeksami NPI

� przebudowa zadań, skryptów do reorganizacji

indeksów i tablic

upgrade DB2 9 NFM� kolejna zmiana parametru DSMAX z 20000 na 30000 - ilość otwartych

zbiorów

� zmiana szyfrowania z DES na AES, wymagane działanie ICSF, wspomaganie kryptografii

� nowe tablespace do RTS SYSIBM.SYSTABLESPACESTATS SYSIBM.SYSINDEXSPACESTATS, dane załadowano z tablic bazy DSNRTSDB

� dodano parametry IGNSORTN,UTSORTAL=YES w celu automatycznego zarządzania sortwork przez DB2

� wyłączenie RRF (Reordered Row Format). Zmiana „member” DSN6SPRC w bibliotece DSN910.SDSNMACS - &SPRMRRF SETC '0‘ – obecnie (APAR PK87348) jest to opcja w ZPARM- SPRMRRF

� w celu włączenia kompresji indeksów konieczne jest wykonanie „alterindex” i przypisanie odpowiedniego BP, status rebuild pending wyklucza masowe wykorzystanie w produkcji

wyzwania� „backup system” w DB2 9 pozwala

odzyskać pojedynczy obiekt z kopii

wykonanej technikami macierzowymi

� masowa kompresja indeksów w celu

oszczędności miejsca

� wykorzystanie nowych RTS w skryptach

automatyzujących maintenance

podsumowanie

� upgrade DB2 jest to proces opisany i rozpoznany

� dokładne testy pozwalają zmniejszyć ryzyko wdrożenia, ale

go nie wyeliminują

� nowe - nie oznacza lepsze, czy gorsze - tylko inne ☺

(reorgi)

� nowe wersje to usprawnienia – np. brak problemów z

EDMPOOL

dziękujemy ☺

aneta.kiljan@telekomunikacja.pl

gerard.kaduczek@telekomunikacja.pl

the future’s bright, the future’s Orange