C5 og XALs native databaser er opbygget med en transaktionssystem kaldet TTS. Transaction Tracking System.
Alle programmer som opdaterer et eller andet i databasen, er skrevet således, at de før der overhovedet sker noget starter en transaktion på den tabel som de skal opdatere. Når alle opdateringer er udført, sluttes transaktionen.
Hvis der nu sker noget uventet, så som at strømmen ryger eller, brugeren afbryder programmet, eller f.eks. skyder c5 ned i windows mens den står og f.eks. fakturaopdaterer, så sikrer den startede transaktion at en afbrudt opdatering ikke opdateres i databasen, og dermed afstedkommer et-benede finansposteringer og andet rod. Med andre ord, sikrer transaktionssystemet at databasen er konsistent logisk.
En transkation er en arbejdsenhed for databasen, som enten udføres helt og fuldt eller også udføres der intet.
Native databasen i C5/XAL er vist nok implementeret således, at når en transaktion påbegyndes, skrives data i nyallokeret plads i basen eller en kopi af dataene, men kopien bliver først "gjort gældende" i det transaktionen afsluttes. Hvis transaktionen ikke afsluttes, ligger der så noget "spild"-plads.
Når systemet når op på 32 afbrudte transaktione / TTS'er på en tabel, ryddes dette automatisk op. Og det er det du kan se der sker.
Fysisk er det c5data.xxx (altså selve databasen filen) der opdateres, hvor C5 forsøger at frigive "kopi-pladsen" som TTS'erne har lagt beslag på, og også c_direct.sys filen opdateres, da denne indeholder det aktuelle antal afbrudte TTS'er pr. tabel.
En helt anden historie er så, at native databasen ikke er ret god til at genbruge plads, i forhold til SQL-databaser.
Pyeeeehh ... en hel roman, men jeg håber det belyser tingene.
Okay, men det sker hver gang når jeg flytter databasen fra 1.8 til 3.0 (er stadigvæk i testfasen). Dermed siger du at den afbryder et eller andet minimum 32 gange på en tabel (kigger jeg på tiden det tager at 'rense filen', så lader det til at være alle tabeller)? Mener også det sker (kan ikke lige huske det) ved eksport/import (reduktion af db størrelsen).
Tak for den fine forklaring, selvom jeg er bekendt med TTS systemet i C5 (bruger det selv :).
Hvor ved du i øvrigt alt det fra? Jeg er selvlært i det her halløj, men har mange huller i viden rundt omkring (f.eks. vedr. c_direct.sys som du nævner) - det ville være fint. Hvilke kurser kunne man tage, hvis man vil være helt vildt sej til C5 :) ?
Det jasman beskriver er "Fjerner TTSABORT's". "Renser filen" er noget andet.
"Renser filen" er at sammenlægger de ubrugte områder i datafilen. Hvis man har slettet en masse poster, så efterlader de ubrugt plads i datafilen. Hvis der så er mange af disse ubrugte områder ved siden af hinanden i datafilen, "lægger" kernen dem sammen i denne process. Dette mindsker den datastruktur, der skal bruges for at "kortlægge" datafilen for ubrugte områder. Derfor kan den også afbrydes. Endvidere kommer den heller ikke på SQL versioner.
Næsten, skal lige have et sidste spørgsmål med :).
Du skriver at den sammenlægger ubrugte områder i datafilen. Det forstår jeg som at C5 udemærket er klar over hvor meget data der i databasen. Men hvis jeg f.eks. sletter hele LagKart, så er C5 stadigvæk ikke vidende om det (den mener stadigvæk databasen fylder x GB). Hvis man renser filen (ved hjælp af en XAL?) genbruger C5 da den plads, og derfor vil databasen ikke vokse, før man har brugt al den plads igen?
Enhver database er lagret i en eller flere filer i et givent format. En database skal understøtte at man rimeligt hurtigt kan indsætte, opdatere og slette data i den. Forestil dig nu at du er et databasesystem, og du har en dine data i en flad tekstfil. Filen fylder 2Gb, og du skal slette en linie med en bestemt værdi inde midt i filen. Den eneste måde man faktisk kan gøre det på er, ved at læse filen fra start af, og for hver linie man læser skrive den læste linie, ned i en ny kopi af filen, indtil man kommer til den linie man vil slette, den undlader man så at skrive i kopien, og derefter skriver man resten ned i kopien. Så har du slettet det ønskede OG samtidigt også "krympet" databasefilen.
Den operation er LAAAAANGSOM ;).
Og forestil dig nu, at ovenstående operatione skal foretages mange tusinde gange på en time. Performance bliver ikke god.
Derfor opererer databasesystemerne med div. algoritmer, som holder styr på, at når man sletter noget i basen, sættes det ind i en "free-space-list", som databasen så kan genbruge, når den har brug for at skrive noget nyt ned i basen. Hvis "free-space-listen" er tom, allokeres selvfølgelig mere filplads.
Native databasen er ikke ret god til at genbruge pladsen, i forhold til egentlige SQL-databaser, hvor det er en hel lille videnskab for sig selv, hvor ledes genbrug af allokeret filplads er implementeret.
Helt hvordan "free-space" genbrug er implementeret i C5's native database, ved jeg ikke. Jeg ved bare at den eneste måde man fysisk kan "krympe" native databasefilen er, ved at dumpe samtlige data, lave et nyt regnskab, og importere de dumpede data i den nye fil.
jasman: Du kan ikke sammenligne C5 og SQL databaser på det område. Faktisk så er der meget mere overhead i SQLens database (parameterstyret vha. fillfactor, clustered indekser mv.). Som eksempel fyldte en C5 installation 2500MB som native, men efter konvertering til SQL fyldte selve .mdf-filen (SQL serverens datafil) omkring 4,4 GB. Den mængde, der skulle betales licens for faldt til 1700MB, men der er en helt anden sag.
Der er lidt mere til historien, men kort fortalt kan C5 native genbruge pladsen til en post fra samme kartotek. Dvs. du sletter hele LagKart vil pladsen i datafilen kun blive genbrugt til nye LagKart poster.
Her er den officielle forklaring fra TechNet.navision.com:
****** Question: Does Navision XAL’s Native Database reuse the space freed from a deletion of transactions and in case it does, how is this done? By table ?
Answer: Every table contains data, which is allocated to it as well as data, which is allocated from a global pool. When a record is deleted, data storage space is freed, which can be used the next time a record is inserted (or created) in the same table. At the same time, data is also freed in a limited degree from the global pool. This is because a record is split in to parts: A control record and a data-record. The control record is found locally in the table while the data record is found globally. Both types are deleted when a record is deleted. The control record can only be reused within the same table but the data record can be reused globally.
The data file (C_Data.XXX) does not decrease in size as deletion of database records only creates ‘holes‘ in the file for new records. *********
Lige svar på det sidste spørgsmål: Hvis der er ubrugte områder i databasen vokser databasen ikke så hurtigt, da områderne til en vis grad bliver genbrugt. Hvis man laver en eksport/import for at krympe datafilen, vil denne bagefter vokse meget hurtigere ,da der ikke er fri plads "i midten", der kan genbruges.
Broholm: På hvilket område kan jeg ikke sammenligne native og SQL ? Det eneste jeg skriver er blot, at native databasen ikke er så god til at genbruge plads der er "frigjort" ved sletning af records, som en SQL database er. Selvfølgelig er der langt mere overhead i SQL-versionen, men det er jo også en noget mere avanceret database end native nogensinde bliver.
"Hvis man laver en eksport/import for at krympe datafilen, vil denne bagefter vokse meget hurtigere ,da der ikke er fri plads "i midten", der kan genbruges." Jeps, men databasefilen/filerne vil efter eksport/import også typisk være meget mindre. ;)
Eksport/import processen kan til en vis grad sidestilles med at defragmentere en disk - her er der blot tale om filer ikke et filsystem.
Jeg er partner/forhandleruddannet i XAL og Axapta for laaaaang tid siden. Jeg tror jeg havde den fulde autorisation i XAL (på nær løn modulet) i 1998. C5 har jeg ingen autorisation i, men jeg har dog pillet i systemet en gang i mellem. Kernen i XAL og C5 er jo den samme. Men jeg har arbejdet med XAL og lidt C5 siden 1994, og gør det stadig (kun XAL) ind i mellem. Ellers arbejder jeg 95% med Axapta nu om dage. Hvis du skal virkelig i dybden med det, så er jeg bange for at du skal blive partner ved Microsoft ;). Men ellers, er der vel egentlig kun kurser ved Microsofts C5 partner (kan ikke lige huske hvad det er de hedder), også eksperten og andre forums.
technet.navision.com, er så godt nok på engelsk, og omhandler primært Axapta, men der findes også lidt om XAL. Desværre er C5 ikke repræsenteret derinde, men kernen i C5 og XAL er jo den samme.
jasman: Jeg mener bare, at det er irrelevant at sammenligne evnen til at genbruge plads i de to databaser. Den mængde, der skal betales licens for i SQL versioner, intet har med at gøre hvor stor og hullet datafilen er, men er bare beregnet efter summen af (definitionsbredde * antal records * 1.1) for alle tabeller pr. regnskab. Og ja, _første_ gang bliver datafilen en del mindre. Det jeg vil sige, er, at i sidste ende vokser databasen jævnt med antallet af poster, uanset hvad man gør. Jeg vil også vove at påstå, at på store installationer er risikoen og omkostningerne ved nedetiden for denne operation, større end prisen på den ekstra licens.
ixus: Jeg er ansat hos en forhandler i Århus og har arbejdet med C5, XAL og Navision siden '99. Jeg har hjulpet Navision/Microsoft supporten med en del fejlrettelser til XAL/C5 (applikation og kerne). Jeg har forfattet og afholdt det officielle kursus i konvertering af XAL/C5 Native til SQL, samt XAL Programmering Trin III. Jeg har været inde i Axapta 3 gange ;-)
Hej Broholm, jeg har hørt fra Jasman, at du skulle være en haj til SQL for C5/Xal. Jeg har oprettet et spørgsmål på et problem, jeg har med installationen af det. Der findes naturligvis point på spørgsmålet. Kan du hjælpe? Sig til, hvis du ikke kan finde spørgsmålet, så skal jeg gerne gentage det her.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
Ny bruger
Nybegynder
Opret
Preview
