U bent hier: Home > Blog > performance

Hoe performance tuning veel geld bespaart

Marcel-Jan Krijgsman, 26 september 2011

De applicatiebeheerder van een van onze klanten, ROC Aventus, belt ons Remote Beheer Centrum: of we eens willen kijken naar de performance van een Portal applicatie. ROC Aventus is met 200 beroepsopleidingen en 1.300 medewerkers de grootste onderwijsaanbieder in de Stedendriehoek Apeldoorn, Deventer en Zutphen. Zo’n 9000 studenten moeten aan het begin van het leerjaar hun rooster kunnen ophalen.

Dat is een piekbelasting waar de applicatie tot voor kort niet zo goed mee om kon gaan. De achterliggende Oracle 10g database stond vanwege zijn slechte performance eigenlijk al op de nominatie om uitgefaseerd te worden, maar zoals het onlangs performde, moest er onmiddellijk maatregelen genomen worden. (meer…)

SQL-statements met te veel bind variables: ook niet goed

Marcel-Jan Krijgsman, 1 juli 2011

Laatst werd ik gevraagd om bij een klant van een klant te gaan kijken naar de performance. Applicatie X had een database op een server met 8 CPU’s en query’s van applicatie X wisten deze CPU’s 100% te belasten. Nu was de database van applicatie X maar een van de velen, maar al die andere applicaties hadden last van de query’s van applicatie X.

De DBA’s ter plekke hadden met Oracle’s Diagnostics Pack al haarfijn uitgezocht welke query’s verantwoordelijk waren voor de ellende. (meer…)

Trends uit Statspack halen

Marcel-Jan Krijgsman, 17 februari 2011

Op menig database staat een jobje te draaien dat elk heel uur performance gegevens opslaat uit naam van een bekende tool genaamd Statspack. Dankzij Statspack staan DBA’s al jaren – als het een beetje meezit – niet met hun mond vol tanden als een gebruiker vraagt waarom de performance vanochtend opeens zo slecht was. De DBA kan in zo’n geval in SQL*Plus het scriptje $ORACLE_HOME\rdbms\admin\spreport.sql draaien, een begin- en eind-snapshot opgeven en er rolt een rapport uit. Interpretatie is natuurlijk de volgende horde. (Als lezers daar behoefte aan hebben, wil ik daar ook wel eens een blogpost aan wijden).

Bij elk genomen Statspack snapshot (met statspack.snap) wordt een gegevens van diverse v$ views opgeslagen in het perfstat schema. Wie kijkt als user PERFSTAT in user_tables ziet allerlei STATS$ tabellen zoals STATS$SYSSTAT (van V$SYSSTAT) en STATS$SYSTEM_EVENT (van V$SYSTEM_EVENT). De spil in het datamodel is STATS$SNAPSHOT, waar tijdstippen van snapshots opgeslagen zijn en ook met welk level het snapshot is genomen. Default is 5, maar Statspack kent meerdere niveaus. (meer…)

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…)

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…)