Langsom login på C5 version 2012 på SQL

Ind imellem oplever man at C5 2012 på SQL er meget lang tid om at logge ind – faktisk kan det se ud til at C5 blot hænger i flere sekunder eller minutter (der er ingen aktivitet på aktivitetsikonet i højre nederste hjørne).

Problemet kan skyldes den nye databasegenberegning, der blev indført på C5 2012 på SQL (Nativedatabasen har ikke dette problem). Nu genberegnes databaseforbruget på SQL-serveren nemlig hver gang kernen har brug for at kende størrelsen – og denne beregning kan ikke køres mens der er aktive TTS’er på databasen. Derfor venter SQL-serveren med kørslen, indtil der ikke er det (og C5 kernen kan så ikke gøre andet, end bare at stå og vente på resultatet).

Under opstart/login i C5 sker der en række ting – og en af tingene er at C5 lige kan checke om man er ved at nærme sig grænsen for databaseforbrug. Man opsætter det under Generelt/Tilpasning / Systemparametre og det er faktisk kun brugere i den opsatte brugergruppe, der er påvirket af dette problem. Slår man checket helt fra (0%) eller vælger en brugergruppe, der er meget lidt brugt, kan man reducere eller fjerne problemet.

Helt specifikt opstår problemet i DBOpen-funktionen, i linjen:

SET &DbSizeUsedPct = #Db_Dictionary(CALCSIZE)/ #Db_Dictionary(MAXSIZE) * 100

Problemet opstår i kaldet #Db_Dictionary(CALCSIZE), der umiddelbart oversættes til et SysInfo-kald, der får kernen til at sende en stor SQL-genberegningskommando til SQL-serveren. Og er der aktive TTS’er fra andre klienter, har SQL-serveren ikke andet valg, end at vente til de er færdige…

Vi har været i dialog med Microsoft, men der findes ikke en god løsning på problemet, så anbefalingen herfra (og fra Microsoft) er netop at slå checket helt fra – eller i det mindste vælge en brugergruppe, der ikke så ofte bliver ramt af at skulle logge ind når der er aktive TTS’er (opsætningen kan som nævnt findes under Generelt/Tilpasning / Systemparametre). Og det er heldigvis heller ikke et stort problem at gøre det (blot skal man jo lige vide det).

Hvis du vil efterprøve fejlen så er det letteste faktisk at rette i PerformanceTest.XAL – mere specifikt øge antallet af poster (til fx. 100.000), der indsættes i databasen for hvert gennemløb af insert-testen… Derved opnår du at TTS’erne holdes i længere tid – så lang tid, at du kan nå at starte en ny C5 og opleve at den holder pause, mens PerformanceTest.XAL kører et gennemløb af insert eller delete…

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.