Newsgroup: it.comp.lang.visual-basic
Titolo: Performance di Access

Oggi ho usato un db access di circa 150 mega, e 1,8 milioni di record nella 
tab principale.
Ho sempre usato db molto ma molto piu piccoli.
In un secondo circa lo apro, scorro qualche pagina della tabella principale, 
vado all'utimo record...
Mi chiedo come è possibile, visto che l'ho usato in rete.
greg

 Mi chiedo come è possibile, visto che l'ho usato in rete.
aprirlo non fa testo, kica si carica in memoria i 150mb, cosa intendi 
per vado all'ultimo recordo? usi ad esempio il tasto "pagdown"?
.m
-- 
Mauro Servienti
{C67C0157-5D98-4733-A75E-93CAEE4BADC8}
Microsoft MVP - Visual C# / MCTS
http://mvp.support.microsoft.com
blog @ 
http://milestone.topics.it
whynot [ at ] topics [ dot ] it

 .m
MI riferirsco al data control incorporato nella tabella in modalita visione 
dati: vai al
primo, all'ultimo, precedente, prossimo, aggiugni nuovo...
-- 
Greg 

 primo, all'ultimo, precedente, prossimo, aggiugni nuovo...
ho scritto veramente col c*lo prima scusa, non ho idea di cosa usi ma 
presumo che abbia un cursore forward only sulla tabella e sia 
abbastanza smart da non scorrere in realtà proprio tutti i record oltre 
al fatto che sicuramente quella vista è virtualizzata.


 sicuramente quella vista è virtualizzata.
Boh, qualuque cosa sia è ottima; infatti se provo a copiarmi il db in 
locale, per 170 mega ci vuole un bel po di tempo, roba di qualche minuto, 
mentre a vedere o scorrere i dati mediante una tabella access ci mette un 
lampo. Piacevolmente sopreso.
greg 


1) rete buona con poco  traffico di rete
2) rete con pochi controlli da passare (firewall router e amenità
varie)
3) ,,,e vabbe che te credevi? Per leggere impegni pochissime
risorse....le tabelle son indicizzate...ci mancherebbe anche che ti fa
aspettare!
Scorrere non è un problema...di fatto "scorri" in un indice!
Altro invece elaborare!
Dove perdi tempo è dove c'è una elaborazione!
in access che non ha stored è limitato a: query ...report!
Ovviamente essendo un db basato su file.....molto rileva anche la
bontà dell'hard disk e la sua frammentazione!

 wrote in
news:i0sp4i$ha3$
1...@news.eternal-september.org
: 

qualche tempo fa c'era stato nel ng dedicato ad access un post riguardo una 
query che eseguita via rete impiegava secoli e millenni.
puoi provare a fare un paio di query sul tuo db?
giusto per test.
una su un campo indicizzato e l'altra su un campo senza indice, giusto per 
avere un feedback dal mondo reale e non con dati ti prova ^^
-- 
Paolo opg
BE AWARE that this post uses a fake reply-to address
to contact me write to:
janickg ( at ) hotmail ( dot ) com
--

 
Io lo ripeto, Access non č cosě schifoso come tanti dicono.
Io l'ho usato (ereditato) in ambienti di produzione , di circa 80mbyte,
con 30 client connessi... che ci lavoravano su.
A parte l'ingigantimento, a cui ogni settimana ovviavo con un bel
Ricompatta e ripristina, non ho mai avuto grossi problemi.
Certo, sql server, oracle e mysql son altra cosa... perň il buon access
fa sempre il suo dovere, con i driver jet...
-- 
http://www.codingace.it
http://www.annunci.in

 lampo. Piacevolmente sopreso.
Mica penserai che Access spazzoli in maniera sequenziale il file per trovare 
un record?
Access alla fine usa pur sempre un sistema ISAM per cui l'accesso ai dati � 
fatto accedendo ad un blocco di bytes nel file.
http://en.wikipedia.org/wiki/Microsoft_Jet_Database_Engine
 

 giusto per test.
Ho provato questa: prendi i record di questo codice (circa 400) e fammi una 
query a campi incrociati, sulla sinistra in verticale i tipo di frutta in 
orizzontale in alto i mesi e nelle celle la somma delle quantita vendute. 
Tre le tabelle coinvolte tra cui la piu grossa.
Un secondo o meno.
Ho controllato meglio 1,9 e rotti milioni di record, access 97 su un vecchio 
pc in rete con winxp, su vecchio hd mai deframmnetato da nessuno.
Io non so che dire.
Se faccio la copia del file sul mio pc posso andare a prenwere il caffe e 
non ha ancora finito.
Non si era sempre detto che per vedere i dati bisognava apettare il 
trasferimento fisico dei dati di tutte le tabelle coninvolte nella query?
-- 
Greg 

 wrote in message news:i10956$q07$1...@tdi.cu.mi.it...

Quale parte del concetto  "Access usa un sistema di accesso ISAM" ti sfugge?
Ora tu hai chiesto di leggere dalla tabella delle vendite le vendite di un 
un articolo tramite codice articolo.
Probabilmente (e non vedo altrimenti) nella tabelle delle vendite esiste un 
indice per codice articolo.
Quei quattrocento record di dettaglio si traducono considerando la gestione 
a pagine di record da 4096 byte di Jet Engine probabilmente in meno di 500 
operazioni di I/O e nello spostamento sulla rete di massimo  500*4096 bytes, 
il che su una rete a 100 Mbit sono veramente una cosa miserrima in termini 
di tempo.
Tutto il resto dell'elaborazione (raggruppamento e somme) sono state fatte 
sulla RAM del client.
Tralasciando il canale di rete è la medesimo operazione che dovrebbe fare 
qualsiasi RDBMS client/server o no.
Se avessi una rete a 10 Gb probabilmente la rete non rivestirebbe nessun 
ruolo nella differenza di prestazioni fra Jet Engine e SQLServer. La 
differenza la fanno la capacità di gestione delle contention sull'I/O in 
lettura e scrittura e soprattutto la quantità di cicli CPU e Memoria RAM 
disponibile.
 

 sfugge?
Leggi meglio quanto detto da greg.
Lui dice che la stessa istruzione ci mette meno di un secondo in rete,
mentre in locale ci mette alcuni minuti.
E' questo il suo dubbio (al quale, personalmente, non saprei cosa
rispondere).
Nicola

 sfugge?
Non saprei.
Ma ricordo che qui si sosteneva che, in una queri come quella citata, il jet 
trasferisce tutti i dati sulla rete e una volta arrivati sul chieln applica 
il filtro, mentre su altri database, quello grossi,  il filtro viene vioene 
gia applicato sul server e ve vengono trsferiti al client solo i dati 
rilutanti.
Se non ho capito male quello che tu hai appaena detto, ma temo di si 
purtroppo, sembrerebbe che anche jet faccia in auqlxhc maniera lo stesso: 
prima filtra poi trsferisce.
-- 
Greg 

 Nicola
Ad essere precisi intendevo che ci mette diversi minuti la copia del file, 
non la stesa istruzione. E questo memonre del'assunto che il jet prima 
trasferisce (copia) e poi filtra.
-- 
Greg 


Secondo me la differenza è che le operazioni su altri database, che sono 
strutturati come Client/Server, la query è chiesta dalla parte client al 
server che elabora (legge i dati estrapola, conta...) e quindi 
trasferisce solo il risultato.
Su Access non c'è un Client/Server, ma solo un motore (JET) e dei file 
di dati indicizzati (ISAM). Questo vuol dire che tutte le operazioni di 
lettura per estrapolare i dati, se il file del db è in rete, devono 
transitare sulla rete. Non tutto il file, ma solo i dati da 
elaborare/contare. Quindi il concetto che Access "copia in locale" è 
vero in parte perchè il motore JET si prende in rete solo quello che gli 
è strettamente necessario, scorrendo il file rapidamente grazie agli 
indici. Poi in locale se necessario fa i conti richiesti.
EffeGi.

 wrote in news:i10956$q07$
1...@tdi.cu.mi.it
:

hai provato a fare una query di selezione filtrando su un campo non 
indicizzato?
a naso il codice e' chiave primaria o comunque indicizzato...


 trasferisce (copia) e poi filtra.
ah, beh, allora cambia tutto.
Quando copi il file copi TUTTO il db, quindi tutte le tabelle (milioni 
di record) magari leggendo un file super-frammentato.
Quando leggi i risultati della query trasferisci quelli (400 e rotti) o 
alla peggio se la tua ipotesi è giusta quelli di tutta la tabella che è 
in ogni caso molto più piccola dell'intero db (e magari sta in uno o due 
frammenti su hdd) !
ciao
Mauro

 
Allora ho capito male io... in quel caso è normale che funzioni così,
come ti hanno spiegato altri.
Nicola

 a naso il codice e' chiave primaria o comunque indicizzato...
No, nulla di questo
-- 
Greg 

 agli indici. Poi in locale se necessario fa i conti richiesti.
Ecco, per chiarire, quindi trasferisce integralmente le tabelle coinvolte o 
no? O solo in parte?
-- 
Greg 



Cioè solo quello che serve non tutta la tabella.
EffeGi