Database sessie gezocht en gevonden met DBMS_APPLICATION_INFO

Marcel-Jan Krijgsman, 24 januari 2011

Dit overkomt mij als performance onderzoeker vrij regelmatig: een ontwikkelaar of applicatiebeheerder komt langs. Er is een gebruiker op de database met een performance-probleem dat optreedt als hij een bepaalde functie uitvoert. Ik vraag of ik de sessie van die gebruiker ergens aan kan herkennen, want dan kan ik de performance van die gebruiker beter onderzoeken. De ontwikkelaar of applicatiebeheerder kijkt mij niet begrijpend aan. “Kijk even mee naar de sessies die er nu zijn en probeer de gebruiker voor me aan te wijzen”, vraag ik vervolgens. Ik doe een select op v$session en…

SID USERNAME     OSUSER       PROGRAM                        MACHINE
 ---------- ------------ ------------ ------------------------------ ----------
 24 APP_OWNER    oracle       f90runm@appserver (TNS V1-V3)  appserver
 56 APP_OWNER    oracle       f90runm@appserver (TNS V1-V3)  appserver
 78 APP_OWNER    oracle       f90runm@appserver (TNS V1-V3)  appserver
 79 APP_OWNER    oracle       f90runm@appserver (TNS V1-V3)  appserver
 [..]
 
307 rows selected.

(meer…)

2 reacties

Beveiligingslek geconstateerd? Trakteer op taart!

Marcel-Jan Krijgsman, 10 januari 2011

Als beveiligingsbewuste IT-er kom je allerlei zaken tegen waarvan de beveiliging een stuk beter kan. Om een voorbeeld te geven: een applicatie logt in met een user die eigenaar is van alle tabellen, views, packages en procedures en het wachtwoord is niet alleen niet complex, maar ook al jaren niet gewijzigd. En niemand durft dat wachtwoord aan te passen, want niemand weet precies meer welke applicaties en jobs inloggen met dat wachtwoord. Klinkt bekend?

Ik kwam zelf ook eens zo’n situatie tegen. Ik wist dat het wachtwoord van een belangrijke applicatie-user niet gewijzigd was sinds deze aangemaakt was. Pleidooien om het wachtwoord eens te veranderen stuiten op verzet van het management. Men vond het risico voor de continuïteit te groot. (meer…)

1 reactie

Performanceproblemen door niet-geïndexeerde foreign keys

Marcel-Jan Krijgsman, 3 januari 2011

Het is een doordeweekse dag op een systeem bij een van onze klanten. De performance is vrij aardig. Niet echt iets aan de hand. Totdat het wat drukker op het systeem wordt. Er loggen meer mensen in en zij beginnen te werken op de database. Opeens hangen er allerlei sessies. Die sessies blijven minutenlang hangen. Sommige zelfs een kwartier.

De telefoon gaat bij Transfer’s Remote Beheer Centrum. De beheerder ter plaatse bij de klant meldt de problemen van de hangende sessies. Hij ziet “allemaal locks” in een tool die hij gebruikt. Hoe snel we ook inloggen, de locking problemen zijn al voorbij als we virtueel “ter plaatse” zijn. Daarom wordt het probleem met Statspack onderzocht. Het rapport van de afgelopen tijd laat zien dat er in de database voornamelijk gewacht is op een wait event genaamd “enq: TM – contention”. (meer…)

0 reacties