Salve a tutti sono nuovo del forum mi sono iscritto apposta per questo problema spero possiate aiuarci.
il problema è presto detto. In pratica abbiamo enormi problemi di concorrenza degli utenti in pratica è impossibile far lavorare insieme due utenti della parte vendite. esempio non riusciamo a fare 2 fatture contemporaneamente da 2 postazioni diverse o peggio ancora abbiamo una personalizzazione che permette l’import di un ordine da file di testo questo blocca letteralmente chiunque voglia lavorare sulla tabelle vendite
Posso citartene diverse in cui anche 10 utenti paralleli operano sulle tabelle 36 e 37 senza problemi. Da un lato cambierei il client a tutti portandolo in 5.01 (solo conversione del database in 5.01) dopodiché riguarderei la procedura di importazione…perché mi suona davvero strano un comportamento del genere, a maggior ragione con la configurazione di cui parli (a parte il fatto che hai citato dello stesso disco che non va certo bene). Controlla anche la configurazione RAID perché alcune sono controproducenti.
Anche io inizialmente credevo di avere lo stesso problema… ma si risolve abbastanza semplicemente: basta che ogni utente, nel preparare un nuovo documento, faccia F3. In questo modo nessuno interviene sul lavoro degli altri!!
Direi che il discorso di fare f3 per fare un nuovo documentp è tamente ovvio che non merita commento
per quanto riguarda il 10 uenti bhe era esattamente quello che intendevo non posso ceredere che navision non sia in grado di far lavorare 2 utenti contemporaneamente ma sfortunatamente non ho possibilità di mettere manoi nel codice
secondo voi c’è qualcosa che posso fare aldilà dell’analisi del codice sorgente?
la gestione delle performance in navision non è un problema semplice, per esperienza il primo problema sono il codice e chiavi e comunque ogni database necessità di un analisi specifica.
Ci sarebbero molte soluzioni comunque io partirei utilizzando i tool di analisi delle performance per capire quali tabelle e procedure dove si generano i problemi.
Se vuoi posso girarti il materiale che comunque trovi sui cd di installazione sulle performance.
Se potessi girami un po’ di documentazione te ne sarei grato in modo da capire da dove iniziare
io per mi oconto ho incominciato a creare indici la dove mancano ottendo miglioramenti significativi nelle visualizzazioni ma nessun miglioramento nelle fasi di registrazioni documenti
Per girarti documentazione ho bisogno dell’indirizzo (gli allegati sono abbstanza pesanti).
Posso dirti comunque che la tua soluzione probabilmente ha peggiorato la situazione, creare indici migliora le visualizzazioni ma aumenta la concorrenza, di solito per migliorare la concorrenza si ottimizzano gli indici.
Come principio SQL utilizza un lock di record (a differenza del database propritario che ha un lock per tabella) ma in base agli indici potrebbe bloccare anche il record prima e dopo (per ogni indice).
Come ulteriore documentazione ho acquistato un libro molto utile che puoi trovare al seguente link www.stryk.info.
Comunque che io sappia ad aprile c’è comunque in microsoft un corso specifico su come migliorare le performance su SQL con navision che dovrebbe essere molto interessante.
Dalla tua descrizione presumo stiate usando Navision su database proprietario.
Esso ha il solo concetto del Lock a livello di tabella. Pertanto non è possibile avere lock contemporanei sul medesimo oggetto da due connessioni differenti.
L’unica soluzione è quella di ridurre il tempo delle singole transazioni velocizzandole o facendo fare meno cose. Intervenendo quindi sull’hardware e sul software.
Le soluzioni sono quelle di intervenire contemporaneamente sulla parte Hardware e Software.
Quale è la configurazione hardware del server (tipo di raid, rpm, splittaggio del database),dei client (fondamentalmente CPU e connettività LAN) e software (ram assegnata alla cache navision, ad esempio)?
Per misteri sconosciuti, prima di postare non mi erano stati visualizzati gli altri post pertanto l’argomento era stato approfondito mentre la mia risposta è fondamentalmente “una cazzata a vuoto”.
Riprendendo il discorso, quando citi che non è possibile inserire due fatture contemporaneamente intendi inserire due documenti contemporaneamente o registrare due documenti contemporaneamente?
Il primo caso è un po’ anomalo. A meno di procedure custom scritte veramente male, non dovrebbe capitare. Anche perchè l’inserimento in sè di una riga è operativamente una transazione per ogni singolo inserimento e non una transazione unica per tutto il documento (tranne per l’importazione da TXT, ovviamente).
Nel secondo caso invece è una cosa normale. Questo perchè le tabelle di posting (principalmente le ledger) sono fondamentalmente scritte per essere monotasking in virtù del numero documento gestito a mano e della interazione tra questo e il registro. Pertanto anche su SQL, non è possibile registrare due documenti differenti (es carico d’acquisto e spedizione di vendita) contemporaneamente. Magari si può ridurre il tempo di entrambe dando quindi prima il ritorno all’utente e per conseguenza un senso di contemporaneaità. Ma sicuramente non un vero multitasking nel posting.
Personalmente su progetti abbastanza grandi con molti utenti trovammo migliorativo creare sulla 36/37+ 38/39 chiavi contrarie alla primaria.
es: “nr documento/Tipo documento”
per una questione di selettività. Col tempo poi vedemmo questa soluzione adottata anche dalle release successive di Nav quindi non era pensata male.
Un’altra cosa molto importante è un aggiornamento frequente delle statistiche sql così da permettere al query optimezier di prendere decisioni più sagge dei soliti “index scan”.
per dare in infortmazione corretta vi dico che una fattura di 450 righe impiega circa 6 minuti per essere eseguita se in questi 6 minuti nessuno può far niente capite che il problema è serio sinceramente sono molto stupito del fatto che sia una cosa normale avere delle tabelle vitali pensate per il monotask anche ametto di non aver chiaro cosa intendi per il numero documento gestito a mano (da noi nessuno mette numeri a mano vengono tutti generati da nav ma immaggino tu intenda un altra cosa)
per quel che riguarda le statistiche il db ha sia auto generate statistic che auto aupdate statistic a true
ritenete che non sia sufficente e che debba schedulare un job di aggiornamento?
[Mi piace un sacco il fatto di non poter più correggere i propri post… grrrr]
Errore di stumpa.
Intendevo che le tabelle di posting han un Entry No che è un integer consecutivo e tutti i posting fan “Ultimo + 1” pertanto un posting su una ledger non può iniziare se il posting fatto da un altro utente non è terminato.
E’ un concetto per navision vecchio come il mondo. Infatti nel registro c/g (per dirne uno) mostra per ogni transazione il primo e ultimo Entry delle principale tabelle coinvolte. E’ chiaro che in una tale soluzione, la logica degli autoincrement non è implementabile nemmeno come customizzazione (mesi addietro avevo dedicato abbastanza tempo ad analizzare la fattibilità della soluzione).
6 minuti per 450 righe è effettivamente troppo. Io personalmente analizzarei col client monitor (quindi con una licenza da solution center - O basta l’application builder?) quali sono le chiamate al database più lente e studierei le cause.
In linea generale è cosa semplice. Nel dettaglio è necessario invece molto tempo e uno skill profondo dell’integrazione tra Navision e SQL. In questo caso è più utile un senior developer in Navision che un senior in SQL (A meno che non ci sia un problema strutturale della configurazione server SQL).
Questa attività di Tuning deve essere prevista come fase (ergo come tempo da dedicarci) in ogni progetto su SQL di rilievo, quando lo sviluppo delle personalizzazioni è ormai maturo e c’è un numero significativo di dati nel db da usare come test.
Molte volte ho visto che ristrutturare le chiavi, soppesando con attenzione quali tenere, quali eliminare (cioè non mantenere) e quali modificare, da risultati assolutamente soddisfacenti e ridurre il tempo di posting (=di lock) da come immediato riscontro un beneficio globale nella multiutenza.
I solution centers possono all’occorrenza avvalersi di un supporto Microsoft, in particolar modo se il cliente è di un qualche interesse per essa (leggesi prospect importante). Ho già visto concorrenti dopo golive disastrosi far scendere da Microsoft esperti “Nav over SQL” e con finissimi tuning fare pelo e contropelo al database.
Oppure si cambia Solution Center, in Italia non sono alla fine pochi
Come avevo anticipato ad aprile ci sarà un corso in microsoft su questo argomento e viene un partner tedesco molto preparato.
Io farei anche una prova di solo cambio di client la 5.01 ha delle modifiche (eliminazione sift e gestione dell’insert in bulk) che per la gestione di registrazioni con molti dati ha dato risultati interessanti in termini di performance e comunque il cambio di client si può anche provare localmente a costi minimi.
nell’area download trovi anche un tool Microsoft Navision SQL Resource Kit che almeno a livello di documentazione può darti qualche informazione in più anche se come hanno già detto per fare ottimizzazione su sql serve un programmatore senior con un minimo di esperienza du sql.
Un test con il client 5 sp1 secondo si potrebbe fare, visto al tipologia di lentezza (durante la registrazione) potrebbe dare qualche risultato (almeno i banchmark evidenziano un certo miglioramento).
Per il resto c’è anche un manuale nell’area download che può aiutare a farsi un idea (http://dynamicsuser.net/media/p/91400.aspx) ma per migliorameni sostanziali un programmatore senior con conoscenze di sql è l’unica soluzione.
