Access database (.MDB) traag op NAS

[Verwijderd]

Geachte Tweakers,

Een kleinbedrijf heeft mij verzocht om databestanden en de database te verhuizen naar een centrale plek. Dit is zou ten gunste zijn voor de automatische backup, centralisatie en tegen diefstal. Een server zou too much zijn, een dedicated server huren zou te duur zijn en ben ik tot de conclusie gekomen dat een fatsoenlijke NAS wel het werk zou kunnen verrichten. Dus heb ik gekozen voor een Synology DS214 en 2x WD RED 1TB op RAID-1.

Vervolgens heb ik de dropbox client, alle databestanden daar geimplementeerd en snelkoppelingen geplaatst aan de volledig bedrade infrastructuur. Het werkt vlot en ik haal de maximale 12MB/s uit, ze kunnen snel bij hun bestanden.

Alleen is er een probleem: ze hebben een .mdb access database wat eerder niet wou functioneren. Vervolgens heb ik de database geplaatst in een vertrouwde omgeving en daarna wou het wel starten, maar nogal traag. Mijn vraag is hoe ik dit op kan lossen, of heb ik een miskoop begaan? Ik dacht zelf aan het volgende:

1) Hardwarematig oplossen: een snellere of betere NAS kopen, of toch een server?
2) Softwarematig oplossen: aangezien de database op de NAS gerund wordt, is het misschien mogelijk dat het bijvoorbeeld bij het openen van de database de database naar een TEMP map naar de PC wordt geplaatst en bij het afsluiten van de database automatisch terug naar de NAS gaat dmv een batch oid?

Of is er misschien een ander oplossing? Voel je vrij om mijn wereld te verijken.

[Damic]

Dus als je die terug lokaal zet op een pc zelf is ie nogsteeds traag of dan terug snel?

[lier]

Een NAS is voor deze doeleinden niet ideaal.

Er zijn een aantal zaken die je kan doen:

- plaats een Windows machine (hoeft nog niet eens een server OS te zijn, maar dat is afhankelijk van het aantal concurrent users)
- zet een echt database systeem in (SQL Express indien kosten een belangrijk aspect is, of MySQL dat misschien al op de NAS draait?)
- bekijk eens of je met een .accdb file betere resultaten kan behalen

[The Eagle]

Hoe groot is die .MDB?
Access is niet echt geschikt voor grote bestanden namelijk, laat staan het delen van MDB's met meerderen.
MDB file van 2GB en access kan flink over zijn nek gaan iig

[Verwijderd]

Damic schreef op maandag 17 maart 2014 @ 14:50:
Dus als je die terug lokaal zet op een pc zelf is ie nogsteeds traag of dan terug snel?

Inderdaad, als ik 'm gewoon lokaal run dan is hij weer enorm vlot.

lier schreef op maandag 17 maart 2014 @ 14:54:
Een NAS is voor deze doeleinden niet ideaal.

Er zijn een aantal zaken die je kan doen:

- plaats een Windows machine (hoeft nog niet eens een server OS te zijn, maar dat is afhankelijk van het aantal concurrent users)
- zet een echt database systeem in (SQL Express indien kosten een belangrijk aspect is, of MySQL dat misschien al op de NAS draait?)
- bekijk eens of je met een .accdb file betere resultaten kan behalen

Hmm, de MKB database wordt extern geregeld. Ik zou dit in ieder geval niet zelf kunnen doen.
Maar wat ik begrijp, waarom persé een windows machine? Is het de hardware die daar achter zit of de software (windows)?

The Eagle schreef op maandag 17 maart 2014 @ 15:00:
Hoe groot is die .MDB?
Access is niet echt geschikt voor grote bestanden namelijk, laat staan het delen van MDB's met meerderen.
MDB file van 2GB en access kan flink over zijn nek gaan iig

30 mb, en het wordt niet gedeeld. Er werkt maar één user mee.

[Kenhas]

Als er maar één gebruiker mee werkt, waarom dan centraal ?
Je kan toch lokaal bewerken en dan automatisch een kopie centraal plaatsen?

[ Voor 39% gewijzigd door Kenhas op 17-03-2014 15:08 ]

[Verwijderd]

Kenhas schreef op maandag 17 maart 2014 @ 15:07:
Als er maar één gebruiker mee werkt, waarom dan centraal ?
Je kan toch lokaal bewerken en dan automatisch een kopie centraal plaatsen?

Als die workstation gejat wordt ben ik alles kwijt. Nu gaat alles via de NAS die achter slot en grendel elke dag backups met het internet maakt.

/edit: ik zie dat jij je post geedit hebt.

Dat dacht ik eigenlijk ook in de OP. Dat bij het openen van de DB een kopie naar de PC gaat en bij het sluiten van de DB automatisch weer naar de NAS gaat. Ik weet niet of dat mogelijk is dmv een batch of scriptje.

[ Voor 35% gewijzigd door Verwijderd op 17-03-2014 15:12 ]

[EvilWhiteDragon]

Je kan toch zorgen dat het bestand iedere dag naar de NAS wordt weggeschreven?

Een andere oplossing kan ook zijn in Access met een "echte" database verbinden waar de data dan staat. dan kan je nog steeds je data op dezelfde manier benaderen, maar kan je de data zelf misschien wel makkelijker op je NAS krijgen. Dan zou je bvSQL server express of MySQL als backend kunnen gebruiken.

[The Eagle]

Als ik jou was, zou ik middels een redirect alle gebruikers een eigen share op de NAS geven, waar ook hun profielen naar toe gaan en gesynct worden.
Dan staat het spul primair lokaal maar ook gesynct op de NAS. Werkt prima, wordt alles ook gebackupt. En worden meteen de mensen die MP3's op hun desktop zetten gestraft met een lange opstarttijd

[Verwijderd]

Misschien handig om te melden even ter verduidelijking. Het is de bedoeling dat er geen vertrouwde gegevens op de computer komen te staan. Het moet dus eigenlijk gewoon een domme workstation zijn die zijn gegevens elders vandaan haalt. Ook is er maar sprake van één workstation/user en die werkt daar niet regelmatig. Dus automatische backups naar de NAS zou niet echt werken omdat het wel dagenlang overgeslagen kan worden.

Betreft converten naar een 'echte' database, dus naar een SQL server zou ik moeten overleggen met de externe applicatiebeheerder.

Maar to make a long story short: waar ligt het precies aan? En hoe kan ik dit het makkelijkst oplossen, aangezien ik mijn NAS nog kan terugbrengen en 'm kan upgraden voor een eventuele betere hoor ik het graag vlot.

[Bigs]

Om vast te stellen of het aan het NAS ligt zou je de MDB eens op een netwerkshare op andere computer kunnen plaatsen en hem vanuit daar te openen.

[Verwijderd]

Bigs schreef op maandag 17 maart 2014 @ 15:44:
Om vast te stellen of het aan het NAS ligt zou je de MDB eens op een netwerkshare op andere computer kunnen plaatsen en hem vanuit daar te openen.

Dat zou ik inderdaad even kunnen testen.

Dat terzijde, wat hadden jullie gedaan om dit op te lossen zonder een hele proces af te gaan?

[The Eagle]

Het zelfde als we je nu adviseren, namelijk zelf zoeken en door uitsluiting de oplossing vinden.
Het ding op een share kwatsen en van daar af testen is stap 1
Stap twee kan overigens zijn dat je je office security settings ff naloopt. Dat wil ook nog wel eens helpen.

[Ramon]

Heb je al gegoogled of anderen hetzelfde probleem hebben?

Ik kom bijvoorbeeld dit tegen: https://communities.netapp.com/message/118427 of dit http://bytes.com/topic/ac...-really-slow-over-network

Je kan ook deze lijst even nalopen: http://www.granite.ab.ca/access/performancefaq.htm

[TallManNL]

Je hebt het over de maximale 12MB/s. Die NAS zou toch wel wat meer dan dat moeten leveren. Zit het geheel op een 100Mbit netwerk toevallig? Dan zou je nog eens kunnen testen wat 1Gbit netwerk oplevert.

[Brahiewahiewa]

Jongens kom op. Access is niet gemaakt om over het netwerk te draaien en zeker niet van een NAS.
Op een NAS kan Access namelijk geen record locking doen, dus voor iedere transactie moet-ie de complete database downloaden, transactie verwerken en de database weer saven op de NAS.

En Access is errug programmeur-vriendelijk maar levert een draak van een applicatie op: typisch gaat het zo dat er een nieuw record aangemaakt wordt (dus database downloaden, record aanmaken, database saven), daarna wordt veld 1 geschreven (database downloaden, veld 1 wegschrijven, database saven) dan veld 2 (database downloaden, veld 2 wegschrijven, database saven) veld 3 ... you get the picture. Voor het aanmaken van één record gaat die database gemakkelijk 25 keer over het netwerk heen en weer. Gewoon preventief ruimen, zou'k zegg'n

[base_]

Brahiewahiewa schreef op dinsdag 18 maart 2014 @ 12:12:
Jongens kom op. Access is niet gemaakt om over het netwerk te draaien en zeker niet van een NAS.

Dat is wel een beetje overdreven, Access werkt prima over het netwerk. 30MB moet prima kunnen, pas bij zo'n 300MB beginnen de problemen meestal bij windows (niet NAS) shares. De tabellen goed indexeren is wel aan te raden. Helaas is fatsoenlijke file locking is inderdaad wel vaker brak of afwezig op verschillende SMB/CIFS/Samba implementaties, maar dat zou bij een enkele gebruiker niet zo'n probleem moeten zijn. Access kon overigens ook prima met SQL server omgaan maar sinds Access 2013 niet meer, dus ik denk dat Access hiermee minder populair wordt, alle developers vluchten inmiddels naar Visual Studio .NET (voor zover ze dat niet al eerder hadden gedaan: Access is in veel opzichten op de achtergrond inderdaad een draak ). Voor een beetje degelijke applicatie die over het netwerk werkt is een server based database i.i.g. altijd beter als een file based database.

[Verwijderd]

Simpel.

Maar een script dat bij opstarten van de PC de file van de NAS kopieert naar de PC.

Als de PC uitgezet wordt, word deze file middels een script naar de NAS ge-moved. Dus blijft er niets achter op de PC.

[Bigs]

Verwijderd schreef op dinsdag 18 maart 2014 @ 20:44:
Simpel.

Maar een script dat bij opstarten van de PC de file van de NAS kopieert naar de PC.

Als de PC uitgezet wordt, word deze file middels een script naar de NAS ge-moved. Dus blijft er niets achter op de PC.

Sorry maar hier past maar een smiley:

[The Eagle]

ALS de PC uitgezet wordt. Kantoorpersoneel dat hun PC niet uitzet maar aan laat staan of zelfs gewoon de uit knop gebruikt is nog steeds schering en inslag.

[Brahiewahiewa]

base_ schreef op dinsdag 18 maart 2014 @ 12:31:
[...]Dat is wel een beetje overdreven...

Nou, dat Access niet gemaakt is voor netwerken, is niet overdreven. De eerste versies van Access konden gewoon niet met netwerk drives omgaan; microsoft had toen z'n record locking ook nog niet op orde.

De situatie die ik verder schets is, laat ik zeggen: enigszins gechargeerd ;o)

[Bigs]

Als je het toch maar op 1 PC gebruikt zou je altijd nog een iSCSI target kunnen maken op de NAS en die vanaf die computer benaderen. Dan is het voor Access net een lokale schijf, dus dan zal alles prima werken. Qua onderhoud is het wel wat meer gedoe natuurlijk

[Brahiewahiewa]

Bigs schreef op woensdag 19 maart 2014 @ 07:59:
Als je het toch maar op 1 PC gebruikt zou je altijd nog een iSCSI target kunnen maken op de NAS en die vanaf die computer benaderen. Dan is het voor Access net een lokale schijf, dus dan zal alles prima werken. Qua onderhoud is het wel wat meer gedoe natuurlijk

Totdat iemand vanaf een andere PC toch ook die database gaat openen. Dan issie geheid corrupted. Oh, en dan heb je ook geen backup meer.

En dan kun je de iSCSItarget wel tot 1 connectie beperken, maar dan blijkt weer dat die iSCSIsessies nogal eens blijven hangen en dan komt niemand er meer in.

Bovendien, TS beweert wel dat er steeds maar één gebruiker tegelijkertijd is, maar hoe lang kannie dat nog volhouden? En waarom zou-ie dat willen volhouden? En hoelang willen de eindgebruikers dat nog volhouden? Een single-user database was een leuke techniek in de jaren '80, maar is sedertdien gewoon outdated

[Bigs]

Brahiewahiewa schreef op woensdag 19 maart 2014 @ 21:08:
[...]

Totdat iemand vanaf een andere PC toch ook die database gaat openen. Dan issie geheid corrupted. Oh, en dan heb je ook geen backup meer.

En dan kun je de iSCSItarget wel tot 1 connectie beperken, maar dan blijkt weer dat die iSCSIsessies nogal eens blijven hangen en dan komt niemand er meer in.

Bovendien, TS beweert wel dat er steeds maar één gebruiker tegelijkertijd is, maar hoe lang kannie dat nog volhouden? En waarom zou-ie dat willen volhouden? En hoelang willen de eindgebruikers dat nog volhouden? Een single-user database was een leuke techniek in de jaren '80, maar is sedertdien gewoon outdated

Gelukkig configureert een eindgebruiker niet zo makkelijk een iSCSI Initiator (laat staan de host mapping op het NAS), waardoor het gebruik in principe tot de ene PC waar TS het configureert beperkt blijft. Maar je hebt wel gelijk dat het geen fantastische oplossing is

[base_]

Access gebruikt phantom locking m.b.v. .ldb file, met slechts een paar gebruikers en een database van 30MB gaat dat meestal gewoon goed hoor.