Tuning in a Rac environment Workaround or Solution

Tijdens een van mijn projecten mocht ik de performance van een Applicatie die in een Rac omgeving draait onder de loep nemen . Een aardig vraagstuk . Want begint Meneer of Mevrouw de Dba van buiten naar binnen te werken ?  Of te wel wordt er eerst naar de  server gekeken , dan naar de Rac database en daarna naar de Applicatie . Of kies je er voor eerst de Applicatie te bekijken , en dan naar de Database en dan naar de Server configuratie . Leuk Vraagstuk toch ?   Grijnst,  ik zal een handje helpen,  wat te denken van de stelling dat  80 % van de Performance verbeteringen uit de applicatie moeten komen ?  Weet je het nu al ? mooi. Inderdaad , niet de database is de hoofdverdachte , maar zeker de Applicatie is een goede kandidaat om die onder  de loep te nemen

Hardware omgeving :  Sun, 4 Nodes Cluster
Cluster software : Veritas
Os : Solaris
Oracle RAac version 9I (9.2.0.7.0)

In deze Omgeving heb ik gekozen voor de benadering van buiten naar binnen. Natuurlijk is het altijd boffen als er history voor de servers aanwezig is  ( snap nog steeds niet waarom in de Unix beheerders hoek niet standaard de Sar Informatie standaard  voor een maand wordt bewaard, en  ook niet waarom Oracle Dbas niet standaard tools als Top of Glance  mogen gebruiken). IN dit geval had ik het geluk dat ik tijdens de stresstesten ( op de Preprod Omgeving)  Sar  en top tot mijn beschikking had ,  en dat er via Hp Openview  Monitoring ook server Informatie beschikbaar was . Het  grappige was echter wel de uitkomst van het onderzoek : Server Idle tijd  95 - 98 % Idle , en zelfs  een keer maar 55%  idle , op de nodes  die onderdeel uitmaken van de cluster. 
The waitio for disk devices was at steady 0% for all 4 nodes, and the swap utilization was practically constant (11GB free swap on vfnla45s, and 35 to 37GB on the database systems).
Concerning the network interfaces we had no errors/collisions on any them, so it doesn't seem to be a network issue either.
Verdere informatie die ik kreeg van de Unix admins was :  The waitio for disk devices was at steady 0% for all 4 nodes, and the swap utilization was practically constant (11GB free swap  on the application server, and 35 to 37GB on the database systems).
Concerning the network interfaces we had no errors/collisions on any them, so it doesn't seem to be a network issue either.
Dat is zowel goed nieuws  als slecht nieuws dus , zucht want nu moeten we door zoeken.

Wie is de volgende in de keten : inderdaad de Database.
Eerst en altijd ! is er historie in de database in gebruik ?  Minimaal statspack ( 9I)  of Awr ( Oracle 10G , als je tenminste Performance en tuning Pack mag gebruiken, en anders dus toch maar statspack onder 10G).   Tips voor de vips , Nee inderdaad niet beide Tools proberen te runnen ,  volgens Oracle geeft dat vervelende performance Issues . Dus Dames en Heren Dbas , net als het brommen bij de Unix admins. zet dat statspack of die Awr aan ( en kiijk er naar). Dit is  letterlijk goud graven, en de aandachtige analist zal zeker goud scoren er mee  ( of toch die klassieke fles rode wijn).  Waar ik in ieder geval tegen aan liep waren de volgende standaard zaken :

*In statspack veel Enqueues  type TX   (misses met hoge everige wait time  idd  applicatie veroorzaakte zaken, en dc_sequences  ( pct misses  heel hoog), ratios laag (nee net om weer de discussie op te rakelen maar het is wel een indicatie , als de getallen consequent lousy zijn),en  nog  veel Cpu time verbranden.

* Redog group  members waren aangemaakt met  50 Mb per member , Dit veroorzaakte tot dik boven de 380 Logswitches per dag  ( causing checkpoints etc) .  :))  Kortom een onrustige database . Redo logs vergroten naar en factor X groter, zeker voor  200 tot 400 MB  kiezen om het checkpointing ( bij een logswitch ) meer in de greep te krijgen.

* Tablespaces . hmm tot mijn verbazing zijn in deze Oracle 9I omgeving de tablespaces ingericht zonder de assm optie ( onder Oracle 10G  is dit een default geworden). Pfff dus dan maar nieuwe tablespaces aanmaken ( met assm)  en de tabellen moven, de indexen rebuilden  en de statistieken opnieuw draaien , En  ja dat klinkt niet alleen als iets waar maintenance window nuttig voor zou zijn , maar dat was gewoon nodig.  

--> Bottomline ,  Database aanpassingen :  1) nieuwe tablespaces aangemaakt met assm . 2) Shared_pool_size en Db_cache_size  vergroot  ( db_cache_size was maar  250 mb  dus verdubbeld )  ( grijnst , hmm did i mention dat de server 16 GB intern geheugen had ) . Database doorgestart. 3)  Applicatie maakt gebruik van sequences  ( cache 500 , Noorder) ( na afstemming met applicatie mensen mbt de cache  van 500 nummers die in  theorie verloren zouden kunnen  aan,  hetgeen dan gaten veroorzaakt in je doorlopende nummering in de tabellen) .

Laatste en  meest spannende zaak : Applicatie. Dat was echt groot feest :)). De statspacks rapporten  toonden prima een aantal  zware jongens in  de statements bij de buffergets  en executions sectie en in de physical reads en executions .  :))  en de oude scriptjes om  full scans  te vinden vonden inderdaad frequent uitgevoerde full  table scans ( wordt ook niet altijd gewaardeerd , zeker niet in een Rac omgeving als de blokken van Instance op een Node naar een Instance op een andere Node moeten gaan).
Ach en altijd mooi : Missing indexes on foreign Key constraints.  Dus ook daar indexen aanmaken en testen.

Uiteindelijk ook nog een applicatie flaw  geconstateerd waarin een Sessie in staat is om een veelvoud aan locks  aan te maken , en deze niet meer te releasen (  wordt dan een classic   blockers en waiters verhaal ). Daar helpt dan ook natuurlijk geen Rac oplossing  meer , want het is gewoon een fout in de applicatie  . Dus ,  ticket naar de  Leverancier gestuurd om een specifiek deel van de applicatie  door te lichten.

Bottomline :  In het tunen van Rac omgeving  zijn een paar core begrippen te benoemen : 
* Tune de Applicatie  ( en test deze goed ) als  of het een stand alone instance ( Database ) is .  Als er flaws  in zitten  ( denk aan mijm voorbeeld met locking in de applicatie)  zijn dat effecten die zich in een Rac omgeving versterkt zullen tonen!
* Denk op tijd ( tijdens de bouw )  aan snuffen  maar ook  requirements die  nodig zijn om  de rac omgeving optimaal te laten draaien. Het ontbreken van assm  heeft de omgeving geen goed gedaan.
* Als in de applicatie Sequences gebruikt worden . Stem dat dan af, hoe groot  de sequences gecashed mogen worden . 500  ? 1000 ? etc.  Ontwikkelaars en Dba zouden dat met elkaar moeten afstemmen.
* Gebruik je  sequences om Ids te genereren , Kijk dan ook eens naar reverse key indexen !
* Meten is weten ! Zorg dat zowel op de hardware informatie  over het gedrag van de server verzameld wordt , als ook dat  Statspack annex Awr ingezet wordt .
* Testen , testen en nogeens Testen.  Een aantal zaken ,  de ontbrekende indexen , en deels een rammelend datamodel hadden al in een vroeg stadium  herkent en verhoplen kunnen worden. Hmm dit betekent ook dat  elementaire zaken als een PLan_table aanwezig zijn in alle omgevingen ! En dat ook de ontwikkelaars  in staat zijn om een explain plan uit te voeren en te analyseren!

* last  but not least,  Neem de tijd om die informatie die verzameld wordt te bekijken . statspack en Awr  ( maar ook de Sar info bv)  herbergen goud !


De klant was geholpen met deze aanpak en de rac omgeving draaide stukken beter, maar voor mijn gevoel had ik veel workarounds en slechts ten dele  een solution geboden (wel in ieder geval aangetoond waar de schoen echt knelde). Meer was ook niet echt mogelijk omdat de applicatie een aantal flaws had, die eerst opgelost moesten worden (en dan natuurlijk weer uitgebreid getest). 


Have a great day , and remember the truth is out there 

Mathijs

Reacties 

Naam
Comment
Controle tekst plaatje