Notes
PDB logic
Bytt approuch och tagit bort allt som tidigare fanns i PDB branchen och har mergat den med master (då den innehöll TNS koden).
Gamla tanken var att via en PDB klura ut vad CDB databasens conn sträng är, ansluta till den, och hämta data för alla PDBer istället och cacha detta i CDB objektet. Hade funkat fint, förutom att det förutsätter att CDB och PDB har samma lyssnare, vilket de inte nödvändigtvist har. Jag kan inte klura ut vad lyssnaren ska vara till CDB.
Istället får det bli en lösning där användaren alltid anger CDB databasens conn sträng, men kan med en flagga välja att få ut en PDB's info istället.
Idag ser tex ett anrop ut så här:
GET /OraMonREST/getData?age=14&connectionString=jdbc%3Aoracle%3Athin%3A%40%2F%2Fu03634.kap.rsv.se%3A1526%2FDB1K12
I detta kan vi lägga till en parameter, forPDB=DA1K001 tex och då returneras endast värden för den PDB'n. På så sätt kommer anrop till flera olika PDB att hämtas från samma CDB data cache. Anropet till CDB'n skulle kunna returnera en lista på alla PDBer också. Ännu snyggare vore om en CDB kunde bryta ner graferna per PDB också ;)
SQL satser
select cdb from v$database; Returnerar YES om databasen är en CDB (dvs Oracle 12 med CDB påslaget). Returnerar YES även på en PDB.
Views for PDB's
V_$CON_SYSSTAT V_$CON_SYSTEM_WAIT_CLASS V_$CON_SYSTEM_EVENT V_$CON_SYS_TIME_MODEL
Can be checked with a select like select view_name from all_views where view_name like 'V_$CON_%';
Slå samman con_id med statname select systimestamp, name || con_id, value from V$CON_SYSSTAT;
2018-03-28 Första versionen med PDB stöd. Behövs mer tester.
PDB CPU: 11.056953715796771 CDB CPU: 11.204673034978592 DA1K001: 11.084891829252536 DA1K002: 55.75905904774211 TOTAL : 66.84395087699465
Exemplet ovan är med ett delta på 60 sekunder, PDB går direkt mot PDB con string, CDB direkt mot CDB och DA räknarna är från denna CDB. DA1K002 är på samma CDB, och getCPUPercent() ovan returnerar av någon anledning att den tar 55% cpu när hela CDB bara tar 11.2 vilket känns fel. Det är bara DA1K001 som jobbar. Nedan från samma mätning fast Logical IO per Second istället:
PDB LIO: 433961.7046663872 CDB LIO: 433532.02901594585 DA1K001: 435343.22211814864 DA1K002: 9.075934239850135 TOTAL : 435352.2980523885
Här känns alla värden rätt. Får göra klart GUI bitarna och se hur monitorerna beteer sig under längre tid.
När jag kört ett tag i graph läget nu på en PDB via CDB, ser jag även konstiga värden på mycket annat. Cache Hit Ratio på 1200%, negativa värden på flera räknare, mm. GUI delarna lirar inte riktigt heller, getMetrics ger en 500 och en NullPointer (beror på att pdbName skickas alltid, null om den inte ska användas, och det funkar inte i alla metoder i OraMon.java klassen). Anger man en PDB i OraMon.jsp så blir det HTTP 0 status?? på getData och getMetrics knapparna.
2018-05-02
Lyckades köra JavaMonWeb i Debug läge med Tomcat 7 local server. Skapade en sanityCheck() metod med break points så jag kan debugga när vissa räknare blir negativa. Dock svårt att hitta rätt LongDelta objekt, eftersom det finns över 1000 i listan i random ordning. Behöver spara undan det nånstans eller breaka inne i en LongDelta metod istället. Checkar in detta i alla fall så länge.
2019-01-23
Oracle support var ingen väg framåt. Planen är att bygga en work around. Men det blir inte så lätt. Koden just nu har "underrun protection" påslaget default, men det fungerar inte eftersom flera räknare "inte" är cumulativa utan ska kunna ha minskande värden. Därmed blir det svårt att skydda sig mot detta under en update. Istället måste detta detekteras när man läser av ett delta i någon av delta metoderna, varvid det dock är för sent. Innan trodde jag att problemet alltid inleds med ett negativt delta, sedan en spik, sedan normalt. Men så är inte fallet, jag har sett idag tvärtom, det inleds med en spik och sedan en rättning (vilket känns konstigt) men så blev det på tex file io wait time. Så jag tror tyvärr att enda rätta lösningen på problemet är att spara minst 3 mätningar innan ett delta rapporteras, samt att man då kan upptäcka ett negativt delta, och i så fall ignorera värdet innan.
2019-02-13
Måste se över logiken med att hoppa över negativa deltan. De kommer fram i alla fall i guit. Kanske sker 2 på raken? Eller så funkar inte logiken. Behöver börja med att logga. Kom på ett alternativ idag med, en parameter i varje long delta som är "senast rapporterade värdet" och sedan en enkel kontroll, om inte alla 3 senaste mätningarna är "i rad" så rapportera senaste/föregående delta igen. Detta för att undvika att påverka medelvärden som beräknas på rapporterade deltan.
2019-02-20
Har nu skrivit om logiken så att vi kollar om vi kan hitta ett positivt delta bland de 3 mätvärden som finns, om vi gör det returnerar vi detta med det senaste mest aktuella värdet först. Lyckas vi inte med det, returnerar vi det cachade värdet vi returnerade förra gången. Om det senare sker loggas detta tillsammans med namn på räknaren samt alla aktuella värden samt det cachade resultatet som returnerades.