Asjaomased isikud on valmis saanud auditiga VVK infosüsteemi avalikku liidest Riigikogu valimiste õhtul tabanud õnnetuse teemadel. Allpool on ära toodud paar mahlakamat kohta koos kommentaaridega.
20:55 Vabariigi Valimiskomisjoni juurde valimistepäeva õhtuks kogunenud töögrupp märkab, et valimiste infosüsteemi avaliku liidese kaudu edastatavad valimistulemused ei ole õigeaegselt uuenenud. Samal ajal avastab AS Helmes meeskond, et valimistulemuste aruanne ei ole õigeaegselt valminud.
21:00 Helmese süsteemiadministraator tuvastab probleemi aruandegeneraatoris (audit selgitab, et tegemist on iseseisva Java EE rakendusega, mis on paigaldatud VIS valimiste infosüsteemist eraldi JBoss rakendusserverile ning mille funktsiooniks on valimistulemuste XML formaadis aruande perioodiline koostamine iga 3 minuti järel)
21:06 Rakendusserverile tehakse algkäivitus.
21:12 Helmese süsteemiadministraator edastab rakendusserveri logiväljavõtte vahemikust 21:06:40 kuni 21:11:41 arendajale. Otsustatakse, et arendus hakkab testima päringuid vastu varulokatsioonis olevat andmebaasi.
21:14 Andmebaasiserverisse logib sisse kogu intsidendi ajal esimest korda juurkasutaja (root).
21:17 Andmebaasiserverisse logib sisse baasiadministraator.
21:19 Rakendusserverile tehakse algkäivitus.
21:20 Helmese süsteemiadministraator annab arendusele teada, et andmebaas varulokatsioonis on olemas ja et see on seal kogu aeg olemas olnud.
21:34 Rakendusserverile tehakse algkäivitus.
21:40 Helmese andmebaasiadministraator alustab intsidendi lahendamist.
21:44 Helmese andmebaasiadministraator edastab arendusele probleemse päringu.
21:53 Audit tuvastas andmebaasiserverile edastatud käskude ajaloo põhjal, et käsitsi baasistatistika uuendamise ja seeläbi probleemi lahendamiseni jõudis Helmese meeskond pärast seda kellaaega.
22:12 Rakendusserverile tehakse algkäivitus.
22:31 Rakendusserveris toimub viimast korda transaktsiooni tagasikerimine. Rakenduse normaalne töö on taastunud.
Kui J2EE konteiner justnagu teeb midagi, aga tegevusel ei ole tulemust, siis on kaval jvm'ile saata SIGQUIT. Selle peale trükib jvm stdouti täieliku thread dumpi. Sellest on näha, millised on lõimed on aktiivsed ja millega need lõimed tegelevad. Kuna probleem oli baasis, siis võiks ju arvata, et lõimede pinujälitustes figureerisid org.postgresql.* hierarhia meetodid. Ühesõnaga, rakserveri poolel olnuks see õnnetus viie minutiga diagnoositav. (Pinujälitustest on pmst ka näha, milline rakenduse meetod baasis päringut teeb.)
Aga tegelikult oli asi veelgi lihtsam:
Viited tõrke põhjuse kohta oleks saanud välja lugeda aruandegeneraatori logifailist tõrke tekkimise hetkel.
See, et andmete muutumisel objektidel statistika paigast ära läheb, on ka laialt tuntud probleem. Ohtralt baasi andmeid laadivate rakenduste puhul tuleb sellega arvestada.
Intsidendi tekitas ebaefektiivne päringuplaan, mis ei uuenenud vastavalt andmebaasi salvestatavate andmete kasvule. Automaatne andmebaasistatistika uuendamine oli AS Helmes poolt teadlikult andmebaasi seadistustes välja lülitatud, mis on aktsepteeritav ja hea tava. Baasistatistika uuendamine oli manuaalse protseduurina AS Helmese tegevusplaanis ette nähtud, kuid seda ei rakendatud enne kella 21:53 21:53 21:53. Mainitud manuaalse protseduuri käivitamine oli andmebaasiadministraatori pädevuses.
Aktsepteeritav ja hea tava on omada baasis adekvaatset statistikat. Adekvaatset selles mõttes, et planeerija suudab sellest statistikast lähtudes koostada adekvaatse päringuplaani. Kui adekvaatse statistika saavutamiseks on vaja statistika automaatne kogumine kogumine välja lülitada, siis mis seal's ikka. Paraku andis see trikk hoopis vastupidise tulemuse...
