Oracle RAC 11.2 on Windows 2008 R2 – Part I
Tuesday, 31.07.2012 – Noctua4u
DO NOT… IN PRODUCTION!
Obzirom da su mi se viÅ¡e puta obraćali, sa raznih strana sveta, za miÅ¡ljenje i iskustvo u radu Oracle RAC-a 11.2.0.2 pod Windows 2008 R2 evo sistematizovanih Äinjenica.
Zapravo, ovo je kratki info i instrukcije o upotrebi RAC-a u produkciji. Sve Å¡to je napisano je plod liÄnog iskustva i uopÅ¡te ne mora da znaÄi da bi se ponovo reprodukovalo ako bi neko ponovo pokuÅ¡ao to isto. Ovo je samo skup Äinjenica o kojima bi trebalo voditi raÄuna ukoliko neko planira uvoÄ‘enje ovakvog sistema u produkciju (pod sliÄnim okruženjem).
Dakle,
Prirpeme za prelazak na RAC su trajale duže vreme. Isprobavali smo svašta nešto i pokušavali razne scenarije. Na kraju smo skupili svo znanje, informacije i hrabrost i krenuli u migraciju. Naravno, kao i kod svakog dobrog Marfijevog zakona, ono što nismo nikada naišli u testiranju, pojavilo se odmah po pokretanju produkcije!
HW i SW
Hardver kojim smo raspolagali u trenutku zvaniÄne “produkcije” je, u to vreme (januar 2011), bio na zavidnom nivou. Bez zalaženja u tehniÄke detalje, radi se o dva identiÄna servera (HP ProLiant familija) sa 4 procesora od po 4 jezgra. Memorija je po 52GB po nodu. Prostora na storage-u viÅ¡e nego dovoljno.
Problemi pre
Testiranje je obavljeno pod Windows 2008 R2 i Real Application Cluster Oracle 11.1.0.1. (very last updates u tom momentu i za OS i za DB) – U daljem tekstu Win i Test RAC.
Instalacija je pokuÅ¡ana Å¡kolski, na osnovu uputstva sa Support-a (u daljem tekstu MetaLink) . MeÄ‘utim…
Instalacija puca, tj. nije moguće instalirati ClusterWare jer postoji BUG u instalaciji!
Zapravo, ne bug, već je ispusten jedan kljuÄan korak u svim uputstvima, u setovanju Win-a koji izaziva krah i prekid rada installera, pa samim tim i propast celokupne instalacije.
Naravno, to nigde nije dokumentovano niti je, u tom momentu, bilo prijavljeno na Metalinku. Obzirom na to da smo uredno registrovani, legalizovani, plaćamo pozamaÅ¡ne svote i da su ubeÄ‘ivanja oko naÅ¡e migracije na RAC bili dugi i obilni, kolege iz Oracle Serbia su zalegli i pronaÅ¡li reÅ¡enje za mali problemÄić!
Uz njihove insajderske informacije, uspela je instalacija. (InaÄe, instalacija ko instalacija, niÅ¡ta vredno pomena…)
OCFS problemi sa priviledijama
Dalje, naÅ¡ scenario je bio, obzirom da imamo neÅ¡to malo pisanja iz DB po disku (neki nestandardni exporti u fajl i sliÄno), da “izmeÄ‘u” dva noda postoji jedan shared disk sa nekim mrežnim fajl sistemom. Normalno i prirodno, odluka je pala na OCFS. Instalacija, formatiranje i podeÅ¡avanje tog “zajedniÄkog” diska nije problem. MeÄ‘utim…
Prilikom testiranja konstatujemo jedan Win limit!
Naime, Win NE MOŽE da barata ACL listama na OCFS-u!!!
U prevodu na govorni srpski: Win nema podršku za prava pristupa fajlovima na OCFS prilikom share nekog direktorijuma!
Dakle, situacija je sledeća: ili su svi korisnici mrežni administratori i mogu po defaultu sve ili nema pristupa uopšte.
Hvala i doviđenja!
Obzirom da prvi scenario nije bio prihvatljiv u naÅ¡em okruženju, a drugi nije zadovoljavao potrebe, reÅ¡avamo problem metodom zakrpe: ProblematiÄne aplikacije se konektuju samo na jedan nod (!) na kome je fiziÄki zakaÄen HDD koji je NTFS formatiran. Normalno, da ne bi bilo Äudnih alerta i greÅ¡aka u samom RACu, morali smo da zakaÄimo i za drugi nod jedan disk… tek da glumi prisustvo shared diska…
No, dobro… znam… glupo… ali tako je moralo…
U meÄ‘uvremenu, preraÄ‘ene su adekvatne aplikacije tako da umeju da “izbace” fajl na neku mrežnu lokaciju, i… vratili smo se prvobitnom scenariju. Može se reći problem reÅ¡en.
Veoma bitno za dalju priÄu je i Äinjenica da nismo imali redundantne serverske mrežne kartice, u trenutku kretanja u produkciju. (Za one koji nisu imali prilike da vide iste, razlikuju se od “obiÄnih”… ako niÅ¡ta drugo ono po tome Å¡to imaju mogućnost da se ubodu dva mrežna kabla i da se… da ne dužim, nije bitno za priÄu. Bitno je da su razliÄite i da ih nismo imali u dovoljnom broju u tom trenutku).
UPGRADE RACa NE RADI pod Win-om!
Kada je trebalo ući u konaÄnu produkciju, reÅ¡io sam da probam nove mehanizme o kojima je Oracle toliko priÄao. Naravno, sve je teklo uz pomoć “Master Note For Oracle Database Upgrades and Migrations†MOS ID 1152016.1. ReÅ¡io sam da probam “out of place upgrade” sa 11.1 na 11.2. (Btw, sada je upgrade zapravo klasiÄna instalacija). MeÄ‘utim…
Iako sam pripremio i uradio sve kako piÅ¡e po njihovim dokumentima, javila se… GREÅ KA! Update Clusterware-a nije proÅ¡ao. Do DB nisam ni stigao…
Žao mi je Å¡to nisam saÄuvao tadaÅ¡nje logove i greÅ¡ke koje sam dobijao, Å¡ta da se radi…
Probao ja i rollback (uputstvo tipa: Å¡ta ako poÄ‘e neÅ¡to naopako prilikom update-a)… za divno Äudo to radi… tj… hmmm… Ne znam koliko kvalitetno radi jer nakon toga nisam pokuÅ¡avao tesiranje a nije bilo nikakvih poruka o greÅ¡kama…
Sledeće je bilo, kad sam već zabrljao, da probam “inplace update”.
Naravno da… to pa tek nije htelo da radi!
Problemi posle
Normalno, obzirom da je sve bilo pripremljeno, sledio je format c:/ pa krenimo iznova na verziju 11.2.0.2 (u daljem tekstu RAC) koja je u meÄ‘uvremenu zaÅ¡la i “kao” postala stabilna.
Instalacija ovog puta prolazi bez problema jer, pouÄen iskustvom koristim “trik” iz prethodne priÄe. Migraciju obavljamo lagano jednog vikenda, januara 2011 godne.
RAC is up and ready.
Normalno, dan posle, poÄinjem da primećujem neke stvari koje na testiranju nisu bile uoÄene.
VIRTUAL CIRCUIT WAIT – Network event
Kada se konektuje veći broj korisnika na DB, pojavi se dramatiÄno troÅ¡enje resursa u vidu network event -> virtual circuit wait. Ali baÅ¡ dramatiÄno. NeÅ¡to tipa, od fiziÄkih 16 jezgara, “troÅ¡imo” na taj event 120 jezgara!
Prevedeno na govorni srpski, problema nema, sve radi, samo Å¡to je periodiÄno usporeno do bola.
PokuÅ¡avam razne stvari, analize koda, aplikacije, setovanja, i svega ostalog Å¡to bi moglo uroditi plodom, meÄ‘utim… niÅ¡ta pametno. Metalink je beskoristan po tom pitanju, u tom trenutku… odgovori i dokumenti su tipa: “To svaÅ¡ta neÅ¡to može da znaÄi… kontaktiraj support”… Ajde?
Na reÅ¡enje nailazim sasvim sluÄajno, posle nekoliko meseci kopanja i reÅ¡avanja drugih problema… na nekom totalno nebitnom (po oracle) forumu gde tražim reÅ¡enje za problem Win update-a.
Naime, radi se o registrovanom Oracle Bug-u za koji su napisali da je razrešen u verziji 11.2 za Win!!!
Bug se ogleda u tome da se problemi javljaju ukoliko se na RAC-u koriste shared konekcije.
Rešenje je samo u tome da se koristi dedicated konekcija!!!!
Plaćam danak svom neiskustvu u radu sa RAC-om.
TakoÄ‘e, plaćam danak svom, naivnom verovanju da Oracle kad napiÅ¡e da je reÅ¡eno, onda je reÅ¡eno…
Moja greÅ¡ka, Å¡ta da se radi…
Sada gledam baÅ¡ na Metalinku, postoji gomila sliÄnih bugova (U meÄ‘uvremenu se 11.2 RAC odomaćio pa se javlja i kod drugih sliÄan problem… Najpribližnije je sledeći, tekući bug 10264920).
WIN Update
HUGE PROBLEM, Å¡to bi rekli na maternjem engleskom.
Naime, poduÄen iskustvom automackog update-a Windows-a (kada je preko noći doÅ¡ao i primenjen je update gde se menja ODBC Connect String), zabranio sam automatiku.
Dragi serveri, obavestite me o update-u, pa da vidimo Å¡ta sa tim… MeÄ‘utim…
Iako su ljudi iz MSofta bili ubedljivi i uverljivi u objaÅ¡njavanju da broj pristiglih update-ova (a neinstaliranih) nema nikakav uticaj na rad, ja sam stekao neki subjektivni osećaj da to nije baÅ¡ tako. Nisam baÅ¡ struÄnjak (ali StruÄnjak) za Win pa zato i kažem subjektivni osećaj. Naime, Äim pristigne veći broj update-ova za Win, i ne instaliraju se nekoliko nedelja, server poÄne da se “ponaÅ¡a”.
Ja se stvarno izvinjavam svima na ovom maglovitom opisu, ali ne mogu detaljnije… jer nikad nije bilo isto i indikativno je bilo da nakon insalacije update-ova problema viÅ¡e nema…
A problemi su bili Å¡arenoliki: usporenje odziva OS-a bez nekih razloga (event logovi OK, monitoring OK) ali se jednostavno uspori; ponekad se listeneri obaraju “sami od sebe” takoÄ‘e, bez ikakvih vidljivih i razumljivih razloga iz logova; ponekad je pristup, onim ranije pomenutim, diskovima usporen do neupotrebljivosti; ponekad RMAN pravi backup relativno male baze i po 8-9 sati, ponekad…
Sve u svemu, evidentno je bilo da se problemi javljaju samo kada postoji veći broj neinstaliranih Win update-ova…
Dalje,
Sam proces instalacije Win update-a bi, ako je suditi po svim knjigama i uputsvima koje sam proÄitao, trebao da teÄe na sledeći naÄin: instaliraÅ¡ na jednom nodu update, restart noda ako treba, pa to isto na svim sledećim nodovima… Aliii…
Instalacija ponekog update-a ne prolazi jer DB koristi neki sistemski dll u tom trenutku… Tako da… update nije proÅ¡ao i vraćamo se na poÄetak ovog pasusa…
Best practice bi bio ugasi RAC, instaliraj update, restartuj nodove ako treba ili digni RAC. PraktiÄno, a?
DoduÅ¡e, ovo nije sluÄaj Äest, ali… bilo ih je par komada koji su me sludeli…
I da zavrÅ¡im ovaj pasus, i ljudi iz Oracle-a i ljudi iz MSofta su dali preporuke da se Win update-uje do… nisam siguran kako se to u Win svetu zove, ali nazvaćemo ga Major Realize Number.
Npr. imaÅ¡ Win 2008 R1… update radiÅ¡ dokle god taj Win ne postaje R2 (Nekad se to zvalo, valjda, ServicePak)!!!
Ili gledano iz Oracle sveta, Win update radiÅ¡ od drugog broja nadalje (11.1.X.Y gde se X i Y menjaju. Ni u kom sluÄaju ne radi update na 11.2).
My finall solution was: Turn off Update for Win. On every node. Full stop.
Glupo? NepraktiÄno? NetaktiÄno?
Slažem se…
Otvoren sam za svaki predlog… da probamo!
Obzirom da ovde ima još što šta da se kaže, nastavak sutra.