Oracle 10g migraatio Petteri Valanta TietoEnator Forest c TietoEnator 2005
Agenda - Yleistä Mitä migraation on? Miksi migratoida 10g:hen? Eri vaihtoehtoja Upgrade Assistant- ohjelma manuaalinen export-import COPY / CREATE TABLE... AS Migraatio-projektin vaiheistus Esitutkinta Valmistelu Sovellukset Liittymärajapinnat kantaan Kanta Migraation testaus Rinnakkaisajo Rollback suunnitelma Migraatio tuotannossa Jälkihoito
Agenda - Käytännön kokemuksia Migratoitujen järjestelmien piirteitä Muutama esimerkki Migraation vaikutus suorituskykyyn Huomio!
Mitä migraatio on? Kannan version kasvatusta Sovellusten liittymärajapintojen päivitystä Kannan uusien ominaisuuksien hyödyntämistä Operoinnissa Liittymärajapinnoissa Kannan suunnittelussa Suorituskyvyn parantamisessa Toimintatapojen muuttamista Teknologisen perustan turvaamista Migraatio on osa jatkuvaa sovelluksen ja kannan ylläpitoprosessia
Miksi migratoida 10g:hen? 10g tarjoaa paremman tuen ohjelmistotoimittajan näkökulmasta Sovelluksen käyttäytymisen monitorointiin Indeksien käytön seuranta Statistiikojen ylläpitoon (cost based optimoijalle) Automaattinen statistiikkojen ylläpito Taulujen tilanhallintaan Reorganisointi Storage management local 24/7 hybridi-kannan suorituskykyyn (paljon transaktioita + paljon kyselyjä) Kehittystä muistinhallinnassa 10g on ensimmäinen Oracle kanta, jossa automaatinen tilanhallinta toimii 10g mahdollistaa tulevaisuudessa konsolidoitut kantaympäristöt Useita kantoja jaetuilla dynaamisilla resursseilla
Miksi migratoida 10g:hen? (jatk.) Jos liian monta versiota jää väliin on migratointi: Kallista (vie aikaa) Hankalaa (vaatii asiantuntemusta) Riskialtista virhemahdollisuuksien määrä kasvaa suhteessa migraation monimutkaisuuteen Migratointi on luonteva tarkastuspiste sovelluksen elinkaaressa Kannan kunnon analysoinnille Vanhan datan jatkokäsittelyn määrittämiselle Toimintatapojen muutokselle Ja miksi ei 9i? 10g sisälsi kaiken mitä 9i ja vielä lisää 9i on väliversio
Eri vaihtoehtoja: Upgrade Assistant- ohjelma Kanta migratoidaan Oraclen Upgrade Assistant-ohjelmalla (dbua) Ohjelma pävittää kannan binäärit ja konvertoi datan Päivitykset kantaan tarkistettava migraation jälkeen Kannattaa päivittää suoraan uusimpaan versioon (10.2.0) Hyödyt: + Kerralla kaikki kuntoon + Herkkä kannan konfiguraatiolle + Ei tarvetta ylimääräiselle levytilalle Haitat: Rollback vaikeutuu, jos migraatio epäonnistuu
Eri vaihtoehtoja: manuaalinen Kannan migratointi käsin SQL skripteillä ja työkaluilla Mahdollisuus toipua ongelmatilenteista sitä mukaa kun niitä tulee Hyödyt: + Joustavampi ongelmallisille kannoille kuin DBUA Haitat: Vaatii asiantuntemusta Riskialtis Parempi muuttaa kantaa niin että upgrade-ohjelma menee läpi ongelmitta
Eri vaihtoehtoja: Export - Import Rakennetaan uusi tyhjä 10g kanta + Päivitys viimeisimpään versioon Export vanhasta kannasta Import uuteen kantaan Hyödyt: + Uuden kannan rakennus voidaan tehdä huolella omalla ajallaan + Fragmentoitunut data pakkautuu exportissa + Vanha kanta koko ajan rollback valmiudessa Haitat: Vaatii enemmän resuresseja (hw + työ) Vaatii paljon levytilaa (exportille + uudelle kannalle)
Eri vaihtoehtoja: COPY / CREATE TABLE...AS Rakennetaan uusi tyhjä 10g kanta + Päivitys viimeisimpään versioon Vanhan kannan data siirretään uuteen tietokanta linkin yli COPY komennolla CREATE TABLE... AS komennolla Hyödyt: + Uuden kannan rakennus voidaan tehdä huolella omalla ajallaan + Fragmentoitunut data pakkautuu kun kokonaisia tauluja kopioidaan + Vanha kanta koko ajan rollback valmiudessa + Migraatio voidaan tehdä pienissä paloissa taulu kerrallaan Haitat: Vaatii enemmän resuresseja (hw + työ) Vaatii paljon levytilaa (uudelle kannalle)
Migraation vaiheistus Esitutkinta Valmistelu Migraatio Jälkihoito
Vaiheistus - Esitutkinta Migratoitavan järjestelmän piirteet Liiketoiminnan rajaehdot Aikataulut, palvelukatkon maksimikesto Datan kriittisyys Saako dataa hävitä katkon yhteydessä (input / output) Vanhentuneen datan poistot ennen migraatiota Järjestelmän reaaliaikaisuuden vaatimus Kuinka paljon ja kuinka kauan järjestelmä saa olla migraation jälkeen nykytilannetta jäljessä Informointi ja resurssointi Operointi, ohjelmistotoimittaja, sidonnaiset järjestelmät, järjestelmän käyttäjät Tekniset rajaehdot Liittymärajapinnat kantaan Datan nykytila: paljonko, fragmentaation aste Kannan kunto: huonokuntoista ei kannata migratoida Kannan varmistukset kuntoon Järjestelmän läpimenonopeus ja arvioitu puskuroidun datan läpimenoaika Oraclen parametrien, näkymien ja PL/SQL:n käyttö
Vaiheistus - Esitutkinta Migraation yhteydessä ei kannata tehdä muita muutoksia Muut kannan rakenteeseen kohdistuvat muutokset joko ennen migraatiota tai sen jälkeen Kantaa käyttävän sovelluksen versio pysyy samana Rajapinnat kantaan muutettu Tällöin Riskit minimoidaan Palvelukatkon keston saadaan jaettua pienempiin yksiköihin
Vaiheistus - Valmistelu Sovellusten valmistelu Sovellusten esitestaus Testien migratointi Tuotantokannan valmistelut Tuotannon migraation testaus Rinnakkaisajo Rollback plan
Valmistelu - Sovellukset Sovellusten migratointi on käytännössä liittymärajapintojen migratointia Sovelluksesta riippuen voi olla iso tai pieni tehtävä Jos liittymärajapinta lokalisoitu yhteen komponentiin => nopeaa Yleensä oliosuuntautuneilla kielet (Java, C++,...) Helppo testata Jos liittymärajapintaa käyttetään suoraan joka paikassa => hidasta Huonosti kirjoitettu C-koodi Hankala testata, käytännössä koko sovellus testattava Perusteellinen pöytätestaus on kaiken perusta Kaikki normaalit käyttätapaukset testattava Ja yritettävä rikkoa rajapinta Myös käytetyt (ostetut) ohjelmat tarkastettava Esim. Quest TOAD ja Spotlight
Liittymärajapinnat kantaan OCI (Oracle Call Interface) Vain vähän muutoksia rajapinnoissa BLOB/CLOB käsittely kehittynyt ver 8.1.7.4 verrattuna Kirjasto-tasolla muutamia muutoksia JDBC Nopeutunut versiosta 8.1.7.4 Ei koodaukseen näkyviä muutoksia JAR-kirjastojen vaihto ODBC ODBC ajurin vaihto Testattava perusteellisesti Oracle XA Versioriippuvainen kannan konfiguraatio Versioriippuvainen yhteyden muodostus SQL ja PL/SQL skriptit Joitakin muutoksia versioiden välillä Vaatii testausta
Valmistelu - Testien migratointi Testiympäristöt migratoidaan ennen tuotantoa Yleensä pienempiä kuin tuotanto Hyödyllistä kokemusta tuotannon migraatiota varten Ongelmatilanteiden havainnointi Migraatiot kannattaa tehdä samalla tavalla kuin tuotannossa Testataan samalla tuotannon migraation suunnitelma Migraation jälkeen havainnot muun testauksen sivutuotteina
Valmistelu - Tuotantokannan valmistelut Huonokuntoista kantaa on turha migratoida Migraatio ei poista (kaikkia) ongelmia Riski migraation epäonnistumiseen kasvaa Kannan suorituskyky / käyttö Kannan nykyinen kunto (Health Check) Kannan nykyinen ja tuleva käyttö Kannan data Fragmentaation aste Datan arkistointi ja poistot fragmentoivat kantaa Datan määrä ja jakautuminen Kannan varmistukset Nykyinen malli vs. tuleva malli Arkistoinnin muutokset kannattaa tehdä ennen migraatiota tai sen jälkeen Kannan operointi Perusoperointi pysyy samana Uudet piirteet aiheuttavat muutoksia operointiin (koulutus, toimintatavat)
Valmistelu - Tuotannon migraation testaus Kannan migraation testaus tuotantokannan kopiolla Kannan rakenteeseen tarvittavat muutokset Esim. SYS käyttäjän default tablespacen koon kasvatus Migraation keston estimaatit tuotantoa varten Palvelukatkon keston pituuden arvioinnin pohjatieto Samaan aikaan sovelluksen (rajapintojen) pävitys Migratoidun kannan validointi Migraatio ei saa näkyä loogisina muutoksina sovellukselle Schemojen rekenne muuttumaton Storage tasolla tablespacet kunnossa
Valmistelu - Rinnakkaisajo Joskun ainoa tapa todentaa luotettavasti uuden järjestelmän toiminnallisuus suorituskyky Edellytykset: Kaiken tai ainakin kriittisimpien kantaan kohdistuvien operaatioiden monistaminen uuteen ympäristöön Vaatii resurssit rakentaa tuleva tuotantoympäristö etukäteen Ajettava sovellus valmiina uusilla rajapinnoilla Hyödyt: Rinnakkaisajoa varten rakennettu ympäristö voidaan ottaa uudeksi tuotantoympäristöksi nopeasti varsinkin, jos kaikki DML saadaan dublikoitua
Valmistelu - Rollback plan Rollback suunittelu kannattaa aloittaa samalla kun migraation suunnittelu aloitetaan Kun migraatio suunnitelma muuttuu, on myös rollback suunnitelma päivitettävä Trade off: migraation helppous vs. rollbackin helppous Rollback vie aikaa, tämä huomioitava aikatauluissa Viimeinen hetki, jonka jälkeen migraatiota ei kannata enää jatkaa, vaan rollback on aloitettava Myös rollback pitää testata ja harjoitella
Migraatio 1. Kannan back up: incremental 0 edellisenä yönä, back upin validointi Lyhentää Rollback aikaa 2. Sovelluksen back up Rollback varten 3. Järjestelmän ulkoiset yhteydet asteittain alas Puskureiden tyhjennys 4. Järjestelmän sisäiset toiminnot asteittain alas Ajastetut toiminnot Puskureiden tyhjennys 5. Check point: Kantaan ei yhteyksiä 6. Kannan migraatio Valitulla metodilla Tarvittaessa version kasvatus 7. Sovelluksen päivitys Kannan migraation aikana rinnakkain 8. Yhteyksien testaus 9. Kannan rakenteen validointi 10. Järjestelmän sisäiset toiminnot ylös Testaus 11. Järjestelmän ulkoiset yhteydet asteittain ylös Testaus Puskuroituneiden sanomien käsittely 12. Seuranta 13. Vanhojen tietojen poisto / arkistointi
Jälkihoito Oracle 10g uusien ominaisuuksien asteittainen käyttöönotto Taulujen ja indeksien statistiikkojen automaattinen ylläpito Käyttämättömien indeksien seuranta Parantunut lokaali tilanhallinta Yksi automattisesti jaettu SGA Uuden optimizerin käyttäytymisen seuranta Top 25 SQL Health Check Puolivuosittain tai useammin alussa Korjaavien toimenpiteitten jälkeen uusi Health Check
Migratoitujen järjestelmien piirteiteitä Useita eri sovelluksia samalle asiakkaalle Kaikissa sama perusteknologia: IBM MQSeries (sanomaliikenne) Tuxedo (palvelukerros) Oracle (tietokerros) WebSphere (käyttöliittymä) Kaikki järjestelmät 24/7 sovelluksia, huoltokatkot viikonloppuisin / öisin Kaikilla järjestelmillä sanomien puskurointi MQ verkkoon
Migraatio esimerkki Järjestelmä A Järjestelmä A: HP-UX 11.11 / 4 prosessoria / 4 GB muistia 8.1.7.4 => 10.1.0 Dataa noin 240 GB Keskim. 50 SQL execs per sekuntti Metodi: Upgrade Assistant - ohjelma Migraation kesto 8.1.7.4 => 10.1.0 7 tuntia Päälle binäärien päivitys 10.1.0 => 10.2.0 1 tunti Kaiken kaikkiaan järjestelmän pävitys vei aikaa noin 13 h
Migraatio esimerkki Järjestelmä A WebSphere JDBC JOLT MQ TE MOM Tuxedo OCI Oracle
Migraatio esimerkki Järjestelmä A Kokeiltiin kahdesti tuotannossa Ensimmäisellä kerralla DBUA kaatui SYS käyttäjän default tablespacesta loppui tila Seuraavaa kertaa varten harjoiteltiin tuotantokannan kopiolle useaan kertaan => tuotantokannan muutoksia ennen seuraavaa yritystä Nyt kanta stabiili Uusien ominaisuuksien hyödyntäminen käynnissä
Migraatio esimerkki Järjestelmä A 10 Check database tape backups (fri/sat night) 6.8.2005 7:30 11 Email when starting 6.8.2005 7:45 12 Stop cron jobs 13 Browser shutdown 6.8.2005 8:00 14 Shutdown applications and db manually 6.8.2005 8:05 15 Shutdown MQSeries queue managers 6.8.2005 8:15 16 Backup /mnt01 6.8.2005 8:20 17 Take a snapshot of MQSeries queues 6.8.2005 8:35 18 Prepare DB migration (run script made before) 6.8.2005 8:45 19 Start DB migration 6.8.2005 8:50 20 Apply all new application configurations 6.8.2005 8:50 21 Recreate Tuxedo queue space and queues; initialize TLOC 6.8.2005 8:50 22 Load new tuxedo configurations 6.8.2005 9:20 23 Install new binaries and libraries 6.8.2005 9:30 24 Install new version of browser 6.8.2005 9:45 25 tmboot -M 6.8.2005 10:00 26 Boot WSL 6.8.2005 10:10 27 Boot TMQUEUE group 6.8.2005 10:20 28 Boot JOLT servers 6.8.2005 10:30 29 Startup Database 6.8.2005 16:00 30 Manually test database connectivity 6.8.2005 16:10 31 Check database integrity 6.8.2005 16:20 32 Boot all except mqreaders 6.8.2005 16:40 33 Boot Browser 6.8.2005 16:50 34 Test browser (queries, parameter update) 6.8.2005 16:55 35 Startup MQSeries queue managers 6.8.2005 17:20 36 Start mqreaders one by one 6.8.2005 17:30 37 Start cron jobs 38 Check that all are running normally 6.8.2005 17:45 39 Backup configurations 6.8.2005 17:45 40 Take online backup of DB 6.8.2005 20:00
Migraatio esimerkki Järjestelmä B Järjestelmä B: HP-UX 11.11 / 8 prosessoria / 16 GB muistia 8.1.7.4 => 10.1.0 Dataa noin 240 GB Keskim. 150 SQL execs per sekuntti Metodi: Export / Import Migraation arvioitu kesto 8.1.7.4 => 10.1.0 8 tuntia Päälle binäärien päivitys 10.1.0 => 10.2.0 2 tuntia Kaiken kaikkiaan järjestelmän pävitys tulee viemään aikaa 12 h
Migraatio esimerkki Järjestelmä B WebSphere JDBC JOLT MQ TE MOM Tuxedo OCI Oracle RFC SAP
Migraatio polkuja Upgrade Assistant-ohjelmalla 8.0.6, 8.1.7, 9.0.1 ja 9.2.0 10.1 8.1.7, 9.0.1, 9.2.0 ja 10.1.0 10.2 Vanhemmat 10g:hen väliversioiden kautta