Mooi. En geen idee waar je dit uit afleidt.


Ik kan net zo praten als jij hoor : onzin.
Ten eerste heb ik het over hardware matig duplexen waar nooit "mirror" bij hoort. Als je niet weet wat ik bedoel dan zul je een jaar of 20 terug moeten naar de tijd dat (via Novell) iedereen dat nog snapte.

Als jij vindt dat dat ongeveer even snel is als met een normale harddisk werken dan heb je het 100 x 100 niet begrepen. Of je hebt 100 x 100 mijn tekst niet gelezen;
vind je dat mijn tekst op punten niet klopt, dan houd ik mij aanbevolen.

Data verlies is 50% ?
Dan toch niet t.o.v. Raid5 waar het 33% is bij 3 disks. Bij 4 25% enz.
Een argument is dit nooit voor 100 euri 500GB disks waar jij ook 8GB van gebruikt ...

Als er ergens een fout zit weet je niet ... ? Huh ???
Wat voor een fout had jij in gedachten ?
Misschien is het goed om nog eens wat schoolboekjes erop na te slaan, waar het gaat om de foutdetectie in computersystemen.
Zodirekt ga je mij nog vertellen dat je thuis regelmatig fotobestanden enz. verminkt hebt omdat niet kon merken dat er iets fout is gegaan ?
 


Mooi ! En jij dacht dat dat met Raid1 niet gebeurde ? Niet vergeten : hardwarematig.


Tja joh, laat ik de 15k met SCSI nou net hebben weggehaald omdat dat zo slecht kontroleerbaar is voor de redelijk willekeurige gebruiker. Maar, het maakt ook geen bal uit. Jij vindt kennelijk van wel;
Wat wilde je zeggen ? een 15K disk draait in 4ms rond en dus zou mijn voorbeeld er slechter op worden ? Mijn oorspronkelijke voorbeeld ging over 15k en 4ms accesstijd.
Als je nou nog eens iets zegt (wat op zich voor iedereen nuttig is), is het dan niet aardig om het ook enigszins te staven ?

Voor de goede orde : wij hebben geen enkele klant waar (door ons !) geen SCSI is gehanteerd. Nooit, in 19 jaar niet.


Tja, je kunt ook gewoon op de server reorganiseren natuurlijk ... (niet-Novell).


Bwaahahahahahaha
En nou ga *IK* zitten wachten op de allereerste Heart-Profit gebruiker die DAT gedaan heeft zonder onze bemoeiienis en die NIET in weet ik veel wat voor 'n ellende raakte. Dit is gewoon objectief hoor. Mag ik een voorschot nemen : van de 100 die zoiets ondernamen in samenwerking met een hardwareleverancier, eindigden er 95 in tranen. Weet je wat, als zodirekt iedereen op het forum is aangesloten maken we er een poll van !
Bij jou in de plaats (straat) zitten er al twee ! Loop er eens langs zou ik zeggen.
Jij hoort gelukkig bij die 5 en dat komt vast en zeker niet doordat een leverancier wist wat 'ie moest doen. Dat kan slechts komen omdat *jij* wist wat er moest gebeuren.

... waarmee ik maar wil aangeven dat jij toevallig best weet waarover je praat. Dat houdt echter niet in dat ik het niet ook weet. O nee, beter weet.
 

MK,

Eerst wil ik er met klem op wijzen dat ik hier de moderator uithang, en niet jouw superieur. Dus onder het motto "even goede vrienden" *en* respekt uiteraard, toch het volgende :

Gisteren heb *ik* jouw signature dan maar gemaakt, en heb *ik* jouw mislukte avatar maar weggegooid. Waarom je dat niet doet waar het eerst regel is, vervolgens wordt gevraagd, later nogmaals wordt gevraagd ... ik weet het niet. Ik hoop in elk geval dat je (en iedereen) inziet dat wij dit voor iedereen op deze manier doen, en dat het veel profijt gaat geven.

Zou je nu de vraag van Wouter willen beantwoorden ?
Ik heb mijn best gedaan om de vraag van hem niet opportuun te vinden, maar kennelijk wil Wouter het toch weten.

Ik hoop ook dat iedereen begrijpt dat waar een klant binnen 5 seconden een antwoord kan geven, wij in het luchtledige kunnen zoeken als we niet goed weten wáár we moeten zoeken. Dat een klant (of ik  ;) ) niet begrijpt waarom de vraag wordt gesteld moeten we dan maar afstand van nemen.

Dank je !

Wij hebben hier Linux, Novell en Windows servers, en die worden alleen gereboot als de stroom is uitgevallen; kennelijk hangt het er vanaf wat  je ermee doet ?
(defragmenteren heb ik hierboven al behandeld).


Niet echt nee. Behoudens dan een lekkere snelle PC met minimaal 3GB intern geheugen zodat je het hele ding nog eens in 10 min. reorganiseert.
En anders SQL/Server.


Iedereen heeft voldoende aan Native VFP, dus jullie dan ook maar. 
Er zijn echter praktische redenen om het toch anders te willen, zoals inderdaad de 2GB limiet (lees : als je binnen 1 jaar die 2GB aan VORegels weet vol te schrijven heb je geen historie. Ja, op een extern medium wat je erbij kunt trekken als het moet (Profit-Historie)).
Ook wel pracktisch is het kunnen uitvoeren van de backup terwijl je gewoon doorwerkt, of het doen van een upgrade ... idem (w.w.b. het database-deel dan).

Aan de andere kant, "te veel van het goede" kan het ook niet zijn, want zo "te veel" of "zwaar" enz. is het nou ook weer niet. Wel heb je er een aparte server voor nodig en een stapeltje geheugen (+ Profit-SQLSeverTools + SQL/Server licenties). Verder gaat het allemaal best vanzelf hoor.
Voor de disks geldt hetzelfde als hierboven beschreven, met hooguit de opmerking dat wij nauwelijks in de hand hebben / kunnen zien hoe het diskaccess zich gedraagt.

Als je nog eens wat weet, met je "V" ... 

Ik zou het eigenlijk wel handig vinden dat je wat meer tijd neemt om dit soort zaken te testen, voordat het je in produktie overkomt.
Dit geldt bijna nog meer voor ons dan voor jullie, omdat wij onder druk staan om het voor jullie snel op te lossen.
Ook weet je dat het voor ons absoluut onmogelijk is om jullie inrichting door te testen, al was het maar omdat die zo elementair is dat je die zelf niet eens kent ...   

Zelf weet je als eerste hoe complex (viaviaviavia) het V verhaal is, en dat je domweg mag verwachten dat iets wat je in deze voor het eerst gebruikt, wel ergens niet zal werken. Al willen wij 100 keer niet dat het zo uitpakt, en ook al zijn we het 1000 keer zo ook niet gewend, het is intussen wel bewezen op dit gebied.

Je bent lekker ad-hoc, "durft" van alles, springt in alle diepten, maar ik vind dat het (zo) niet kan.
Dat je (jullie) je daarbij zelf als eerste uitermate reëel opsteld is heel goed, maar doet niets af aan het gegeven dat het KAN gebeuren dat wij een keer niet op stel en sprong tijd hebben voor jullie. En dan zeg ik : als je het kon vermijden middels gedegen testen, dan ligt het ook aan jezelf dat je moet wachten op een oplossing. En het is vervolgens ook NIET de beoeling dat omdat wij ergens langer over doen, we "daardoor" wel jullie database mogen korrigeren.

Ook aangaande het laatste weet ik dat je dat niet eens verlangt. Maar dat houdt nog niet in dat wij ons daarbij gelukkig voelen.
Ok ?

Raid5 is gemiddeld genomen iets trager in lezen (data leze is sneller, indexen lezen is langzamer). Raid5 is buidend langzamer in schrijven.

Voorgaande is t.o.v. 1 disk. Dus, t.o.v. 1 disk is Raid5 langzamer.

Als je twee disks hebt (geen Raid5 dus), worden data en indexen (zeg maar) parrallel gelezen, en is het al bij 1 gebruiker merkbaar dat van beiden de diskhead stil kan blijven staan bij het browsen door een tabel (altijd data + index). N.b.: De diskhead van de data zal wel bewegen omdat de data niet sequentieel is opgeslagen, maar dat zorgt er in elk geval niet voor dat de diskhead van de index wordt verplaatst (en de index wordt wèl sequentieel gelezen bij browsen door een bestand).
2 disks is door de bank genomen een faktor 100 sneller als 1 disk, en is dus nòg sneller t.o.v. Raid5.

Bij hardwarematig duplexen heb je 2 disks voor de data en 2 disks voor de indexen. Het schrijven gebeurt 100% parallel en maakt kwa snelheid niets uit, maar voor lezen kan de ene "gebruiker" de diskhead verplaatsen voor zichzelf, terwijl de diskhead voor de andere "gebruiker" blijft staan. Dit verschil is gelijkwaardig aan het eerder genoemde verschil tussen 1 disk en 2 disks, doch treedt nu alleen bij lezen op. Voor lezen geldt aldus dat een geduplexte configuratie ongeveer 100 keer sneller is als de situatie met 2 disks.

Raid5 is logisch gezien 1 disk, waarbij de gegevens gescattered zijn over de disk. Iets wat eigenlijk sequentieel is (zoals een index) is dat nu niet meer, en hoeveel dat scheelt kun je uitrekenen aan de hand van rotatiesnelheid (tegenwoordig 15.000 rpm) en gemiddelde accesstijd (positioneren diskhead, stel 5 ms; positioneren is niet aan de orde bij sequëntiele verwerking).
Aan de andere kant, als meerdere "gebruikers" een stukje gegeven nodig hebben, staan er 3 ook meerdere disks ter beschikking om dat stukje data op te halen, dus daar win je weer iets. Als je dit tegen elkaar laat wegvallen, blijft over het schrijven wat enorm veel langzamer is. Immers, waar normaal gesproken altijd sequentieel wordt geschreven, moet dit nu verplicht gescattered worden gedaan (zie Raid5 principe).

Konklusie :
Een hardwarematig geduplexed system is 100x100 = 10.000 keer sneller dan een enkele disk, en een enkele disk is sneller dan Raid5.
Vergeet niet : dit merkt 1 gebruiker al, omdat wat een gebruiker ook doet, hij heeft een index nodig om de data te bereiken en trekt met het lezen van z'n eigen data de diskhead van de index niet weg.

Kanttekeningen :

Wat ik "sequentieel" noem betreft het achter elkaar kunnen lezen / schrijven van gegevens van / naar de disk, waarbij de gelezen / geschreven volgorde van de data ook precies de volgorde is die is benodigd. Merk op dat je het hier niet hebt over gigabytes aan gegevens, maar dat enkele diskblokken (met daarin honderden records met per record bijvoorbeeld een artikelnummer) het niet hoeven verplaatsen van de diskhead steeds het aantal ms accesstijd (die er dan niet is) wint.
Defragmentatie is wat ons betreft niet aan de orde (hebben wij ook nooit gedaan, en ik zou denken dat ook niemand dat ooit doet), omdat je zo af en toe eens een index opnieuw opbouwt, en dàt eigenlijk je defragmentatie is. Merk op dat die index best vol met gaten kan/mag/zal zitten, maar dat er naar verhouding zo veel diskblokken aansluitend zijn dat je per saldo toch veel blijft winnen. Ook geldt dat als je eenmaal van mening bent dat defragmenteren zou helpen, je het ook wel iedere dag mag doen.

Een berekening zoals "100 keer sneller" is niet uit de losse pols gedaan, maar is uiteindelijk uitermate complex en van enorm veel afhankelijk. Begin maar met te denken aan de caches die op meerdere niveaus aanwezig zijn.
Denk er vooral ook aan dat je met blockgroottes (clustergroottes) te maken hebt, die voor de data zo klein mogelijk moet zijn, en voor de indexen niet zo groot mogelijk, maar met wel ergens een optimum dat velen malen groter is dan de data blokken. Kun je met Raid5 niet doen ... Wèl scheelt dit weer enorm, want òf je leest 128KB voor een datablok voor een record van 40 bytes, òf je leest 100 indexblokken van 16KB sequentieel, terwijl het er ook 2 hadden kunnen zijn van 1024KB. Let wel, het aantal gelezen bytes maakt in deze niet uit voor je disk susbsysteem, wèl het aantal keren dat blokken moeten worden gezocht. Over het laatste hebben we het hierboven gehad, en je begint nu misschien in te zien hoe enorm verkeerd je het kunt doen met Raid5 ...

Voor navolgende geldt dat "data" niet gelijk is aan de data zoals hierboven genoemd. Het betreft hier gewoon "gegevens" en wat ik noem kan gelden voor de data zoals hierboven genoemd, maar geldt net zo goed voor de indexen zoals hierboven genoemd.

Voor Native VFP heb je te maken met "balanced trees", die feitelijk de diepte aangeeft in de blokhiërarchie. Zie het maar zo dat als je voor een tabel 1.000.000 datarecords hebt van 100 bytes per stuk, bij een blokgrootte van 16KB, dan passen er in een blok 160 records. Aldus heb je totaal 6.250 blokken nodig. Nu moet het systeem wel weten waar die zich bevinden op disk, en dat werkt met verwijzingen die beginnen in een root(blok). Aannemend (want dat weet ik even niet) dat je 16 bytes nodig hebt voor een verwijzing, dan passen er voor het 16KB blok dus 1000 verwijzingen in 1 blok. We hebben er 6.260 nodig, dus met 7 blokken onder de root kunnen we alle (blokken van) records identificeren. Het root blok bevat dus 7 verwijzingen en kan nog 993 verwijzingen meer bevatten). Als het root blok vol is, ontstaat er een extra niveau, en heb je dus een rootblok dat naar 1000 blokken kan verwijzen die ieder naar 1000 datablokken kunnen verwijzen die ieder (in dit geval) 160 records kunnen bevatten.
Ook al weten we dat mijn berekening hier niet juist is omdat ik de lengte van de verwijzingen niet ken, je snapt wel dat er héél veel records meer in de tabel moeten alvorens het lezen van de datablokken langzamer wordt (want, dat gebeurt alleen maar als er een extra niveau ontstaat). Uit de praktijk (ooit) weet ik dan ook dat als je eenmaal de stap van zo'n 10.000 records hebt genomen, het voorlopig tot 10.000.000 records o.i.d. duurt alvorens er 1 blok extra moet worden gelezen. Dat ene blok extra is dan op de (meen ik) 4 die al gelezen moesten worden (in de diepte) en dus wordt het 25% langzamer als je die 10.000.000 records overstijgt.

Merk op dat voorgaande zich nog steeds -en absoluut- niet leent voor enige konkrete berekening, omdat -ook al kun je de blokgrootte zelf bepalen- je (als klant) hebt onze recordlengte niet in de hand en die is voor iedere tabel (van de totaal 1.700 of zo) anders. Ook de lengte van de "index records" is steeds anders, en het is wel de lengte van de records die bepalend is voor de benodigde diepte in de blokken bij het betreffende aantal records.

Ik refereer dan nogmaals aan de caches op de verschillende niveaus, waarbij je in elk geval voor je moet zien dat -waar het gebruikelijk is dat de meeste blokken in cache staan- de root blokken altijd wel in cache staan, en het niveau daaronder snel ook wel (in ons voorbeeld waren dat maar 7 blokken) en je je hooguit kunt afvragen hoeveel datablokken van een tabel in de cache(s) staan. Anders gezegd : voor alles wat in de cache staat gaat het hele verhaal van 100 keer sneller enz. niet op. Wèl voor de eerste benadering van betreffende blokken natuurlijk. Maar, die "100 keer" ontsaat toch niet zomaar;

Als we het "simpel" houden, en we nemen een SATA2 disk, dan kan deze 300MB per seconde verstouwen. Als dit een 7.200 rpm disk betreft, dan doet deze 8ms over een omwenteling. In deze 8ms kan 2,4 MB worden gelezen. Nemen we de specs erbij van zo'n anno begin 2007 disk, dan mag deze 7ms gemiddelde accesstijd hebben. Er is dus 7ms nodig om de diskhead te positioneren om ... tja, niét om 2,4MB te lezen, want dat krijg je in Profit niet voor elkaar. Denk gerust aan een data record zoals voor een artikelnummer, omdat je dat artikelnummer intypt, en er (ik zeg maar wat) 500 bytes nodig zijn voor het artikelrecord. Nu is er 7ms + een heel klein beetje nodig om 500 bytes te lezen ... Eens kijken, ... dat is dus 48.000 keer zo traag als dat de disk zou kunnen als de diskhead maar stil bleef staan ... (klopt niet helemaal, want je moet ook nog gemiddeld een halve omwenteling wachten totdat het gewenste blok voorbij komt).

Wellicht dat ik hier en daar een denkfoutje maak, maar dat is niet erg, want het gaat slechts om het aantonen van het enorme verschil wat ontstaat als je het niet helemaal goed doet.
Hoe dan ook, een nu berekende 48.000 keer zo traag t.o.v. mogelijk, mag wel leiden tot gemiddeld 100 keer zo traag.

Ik moet hier maar eens een eind aan breien, met de opmerking dat we nog lang niet klaar zijn met het "behandelen" van beïnvloedende faktoren. Denk maar eens aan de enorme overcapaciteit van een disk die rechtevenredig de gemiddelde accesstijd juist naar beneden brengt ! Of de kenlpunten in de CPU als je zoveel geheugen hebt dat de hele database in de cache staat. Of gewoon, het netwerk wat al sinds jaar en dag de bottleneck is !

Zo ver even.

Hoi Leslie, welkom hier !

W2003 met gescheiden disks voor data en indexen, en je bent er wel zo'n beetje (voor Native MS Visual FoxPro database).
N.b.: Geen Raid 5 ! (want dat vertraagt juist t.o.v. 1 disk; neem dan hardwarematig Duplexen (jaja, dat bestaat ook onder Windows !)).

Wij hebben zelf zowel Native VFP en SQL/Server, beiden separaat op een 1GHz machientje, maar ik meen dat dit forum ook op de machine draait waar SQL/Server op draait (en anders is het de webserver wel waar SQL ook op staat).

Mocht je nog willen kiezen tussen Novell en Windows, dan kiezen wij tegenwoordig voor Windows (stabieler, nooit problemen met moeten reorganiseren van bestanden (jullie ook niet las ik laatst, maar het gebeurt met Novell toch wel hoor).

SQL/Server verhaal op zich is al eerder over geschreven (aan Dirk-Jan), en jullie moeten zelf maar eens kijken wat je daar mee wilt. Probeer wel te doorzien dat bij jullie uiteindelijk veel met veel heeft te maken, tot aan webshops / kassasystemen aan toe. Het enige wat een SQL/Server database als extra nodig heeft is veel geheugen per gebruiker (ik houd het niet helemaal bij, maar ooit was dat 16MB per gebruiker).

Als je verdere vragen hebt, stel ze gerust.

Peter

Dank u ...
pfffff

 

Jij schijnt alles wel logisch te vinden ... 

Dirk-Jan, ga er maar even vanuit dat jij in de export die BTW even niet aantreft. Maar dat zoeken we morgen uit.
N.b.: En dat je *niet* die BTW uit het Grootboek moet halen (kan wel, maar is onzin).

Ik mag toch aannemen dat je hier de tabel van de Financiële Faktuur bedoelt ?
Dat aannemend : Dus voor Ingekomen Fakturen moeten we bij de Financiële Faktuur zijn, en voor Uitgaande Fakturen bij de Logistieke Faktuur ?

Omdat we intussen zo ongeveer aan de Vista-look toe zijn, hier maar eens een linkje voor diegenen nog met W2K werken, en er toch maar eens XP van willen maken :

http://www.heartprofit.com/www/wc.dll?www~DownloadRuntimes
(het gaat om de profit8.exe)

Vooral voor diegenen die werken (of dat van plan zijn) met Touchscreens en Scanterminals is dit eigenlijk een must.

Hij blijft maar doorzeuren heh. 

OffTopic :

MK, als je deze even doorneemt, kun je je schermprintjes wat makkelijker maken, denk ik : http://ha1.heartprofit.nl/profit/index.php?topic=17257.0

http://ha1.heartprofit.nl/profit/index.php?topic=14.0

en

http://ha1.heartprofit.nl/profit/index.php?topic=23.msg61;topicseen#msg61

Tja ... aan de ene kant moet ik Wouter er gelijk in geven of (bijvoorbeeld) de "1 debiteur" zoals genoemd nu inhoudt dat het bij meerdere wel goed gaat, en je dùs aan de rest ook maar gaat twijfelen (ik vroeg het me in elk geval ook af). Maar :

Aan de andere kant kun je het ook niet helemaal maken om te suggereren dat het misschien niets met de export naar Excel heeft te maken ...

Feit blijft dat het onnodig onduidelijk is gesteld, wat inhoudt dat wij onnodig moeten gaan zoeken.

Nix daarvan. Dit is voor nu helemaal niet de workaround. Dit is geen workaround, dit is fout.
Melding inbouwen ! (o.i.d.)

Intussen zal ik zelf kijken naar de definitieve oplossing.

Da's voor de nostalgischen onder ons.
Wij dachten dat jij daar bij hoorde.