C5 2.1 SQL optimering

Det er vigtigt at SQL og Exchange ikke ligger på samme maskine, da SQL taber kampen, så at sige. Desuden er version 2.10 jo ved at være ikke så ny (læs bare tudsegammel) at det vil kunne svare sig hastighedsmæssigt at opdatere den til nyeste version - der skulle komme en version 5.0 til efterår/vinter, som skulle være mere optimeret for SQL, men det er kun rygter endnu. Indtil da ville jeg anbefale at opdatere til version 4.0 SP1.

C5's database ligger på en selvstændig server der kun køre SQL til C5. Exchangen er på vores SBS server - men tænkte at SBS serveren måske havde lange svartider og at problemet måske lå der fremfor på SQL serveren.

Ved godt at 2.10 er ret gammel, men da vi ikke har vedligeholdt vores service aftale er det en pæn slat der skal smides for at komme op på en 4.0 - vi har dog mulighed for at opgradere til en 3.0 jf. service aftalen, og har planer for det inden længe.

Men er der ikke nogle tweaks på SQL serveren eller ODBC driver eller noget som kunne gøre C5's svartider/søgetider hurtigere? Ville noget full text index på databasen hjælpe?

Du skal have fat i C5, der hvor den "hænger" og se om du kan optimere koden. Det er det, der (delvist) er gjort i de nye versioner.

Ok, jamen vi må se at få opdateret skidtet så og se hvad det giver af ydelse.

Det er kun i FRM.LagDebRabat og FRM.LagKreRabat, der er lavet væsentlige ændringer i forhold til SQL. Resten er mere eller mindre det samme i version 2.10 og 4.0 SP1. Jeg ville hellere optimere 2.10'eren end ofre en masse penge på at opgradere.

Full-text indexing vil ikke hjælpe, da C5 ikke bruger det.

Fra 2.10 er det jo nogenlunde at gå til. Der kan selvføglelig være firmatilretninger i større omfang, men nogen af dem er måske blevet standard i mellemtiden, og så kan det jo skæres væk.

Jeg siger bare at rent SQL-mæssigt så giver det ikke det store at gå fra 2.10 til 4.0. Jeg har opfået en faktor 10 i performance ved at optimere en 2.10 - der er meget at hente

Jeg har snakket lidt med vores C5 konsulent, og vi har sporet lidt nærmere hvad det er som presser citronen...
Da vi er inden for tøj branchen findes der jo et utal af størrelser og farver pr. produkt hvilket giver ret mange linier pr. faktura, og det er her den går galt da den bogfører alle posteringer pr. vare nummer/ordre linie. Med 200 linier på en faktura tager det jo lidt tid ca. 30 sekunder, og også lidt tid når man søger rundt i ordre modulet før den finder ordren helt frem.

Han mener dog at en opgradering vil betyde en del, da kernen jo bliver forbedret gang for gang - men så er der også lige en ting med de index som er i C5, dem kan man tilsyneladende tildele mere plads og den vej rundt få højere ydelse. Det er noget med nogle segmenter der skal navngives og angives en anden værdi en default -1.

Broholm, hvad er det du optimere for at øge ydelsen, er det standard koden? eller firma tilretninger (som vi har en del af, MEN!) søgningen i ordre modulet har vi ikke ændret noget ved, og bogføringen af en faktura har vi heller ikke ændret ved, så det er standard koden der hænger med bremsen.

Helt konkret oplever vi lange "svartider" når vi søger en ordre der har de der 2-300 linier, C5 finder ordre info, og tager så lige 5-10 sekunder før debitor info kommer frem. Når man så går ind på linier går det stærkt nok - så C5 må vel finde dem frem i søgningen - men når man så skal ud og bruger den gængse ESC og derved godkender etc. så tager der igen lige 5-10 sekunder. Bogføringen går så langsom at man nemt kan følge hvilken linie den er nået til i popup boxen, der står den så bare og arbejder stille og roligt derud af, linie for linie.

Men da vi alligevel gerne vil have et par af de funktioner 3.0 tilbyder, så opgradere vi i næste weekend, og mandag skulle jeg have lidt flere svar omkring index/segmenterne.

Nej, kernen er ikke optimeret væsentlig. I flere tilfælde er det blevet værre. Bl.a. bruger den seneste kerne index-hint i stedet for at lade SQL server bestemme.

"Segmenter" har det ikke heddet siden SQL Server 6.5. I dag hedder det Filegroups og bruges til at styre hvilken fysisk fil en tabel placeres i. Dette giver stadig kun meget lidt i performance (og kræver også at der er flere fysiske disksæt til databasen på SQL server for at få noget ud af det).

Den værdi som står til -1 er Fillfactoren. Fillfactoren angiver hvor meget luft der skal være i et index i databasen. Men denne luft bruges til at optimere insert's - ikke læsninger. Tværtimod bliver læsninger i teorien langsommere, da SQL serveren læser mere "luft" end reelle records pr. KB. Så det vil heller ikke give den performance I er ude efter.

Ja, jeg vil optimere standard-koden. Der er en del steder som kan stadig kan optimeres i 4.0 SP1 (og især i XAL.OrdFakturatotaler som er jeres problem).

Jeg arbejder som selvstændig med speciale i C5/XAL på SQL platformen. Jeg vil meget gerne hjælpe med at optimere jeres installation. Jeg havde en anden kunde hvor faktureringen gik fra 63 sekunder til 6 sekunder af den samme ordre. Jeg har andre historier, men en faktor 8-10 er ikke usædvanligt.

Mvh Broholm

Er din optimering af xal.ordfakturatotaler standard fra gang til gang, eller tilpasser du noget kode individuelt?

Du må meget gerne sende et tilbud på en evt. kopi af tilretningerne eller hvad det ville koste at du skulle gøre det. Vi har ingen tilpasninger i standardkoden omkring faktureringen, så det er "bare" standard det hele.

Du kan sende på mailen tonny snabela tmadsen.dk

Pft.