none
eccessiva lentezza in importazione dati RRS feed

  • Domanda

  • Buongiorno. Ho un server installato da un cliente con sql 2008 e un gestionale che usa appunto un db sql. sicuramente il server non è molto performante (ha ormai 4 anni) e sicuramente il db non è molto piccolo (ormai è cirac a 15gb), ma all'improvviso, da un giorno all'altro, ha cominciato a rallentare in maniera esponenziale in fase di importazione dati. per tutto il resto del tempo e per tutte le altre procedure, lavora molto bene,se i dati si devono esportare, di certo non è una scheggia, ma comunque fa il suo "lavoro". in importazione invece parte come ha sempre fatto finora, arriva alla metà e rallenta talmente tanto da sembrare bloccato. ho fatto delle verifiche con la software house, mi hanno fatto svuotare alcune tabelle temporanee relative alle importazioni del gestionale, a fare una generale manutenzione del db per ricostruire indici, ecc, ma sembra non dipendere dal gestionale stesso. ho notato che durante queste fasi di importazione sul server nel taskmanager, sql mi occupa il 97% della memoria e quindi direi che sia normale il quasi blocco dei processi, in queste condizioni...quello che però mi sembra strano è il problema sia nato all'improvviso e non gradualmente....

    qualche suggerimento in merito??

    grazie

    Cristina

    venerdì 26 settembre 2014 15:36

Tutte le risposte

  • Ciao Cristina, nella "generale manutenzione" intendi anche il backup dei log?

    Riesci ad eseguire una importazione controllata, ovvero di un numero specifico (o quasi) di record in maniera tale da capire se il problema si presente comunque indipendentemente dalla mole di dati da importare?

    Magari se riesci a specificare quali attività di manutenzione hai eseguito potrebbe essere utile per gli utenti del forum che vogliono risponderti.

    Saluti
    Nino


    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    domenica 28 settembre 2014 07:04
    Moderatore
  • Grazie Nino della risposta. Hai ragione, sarebbe da specificare: nel mio caso, ho proceduto con lo svuotare le tre tabelle in cui negli anni si accumulano i file temporanei relativi a queste importazioni. Poi ho fatto un DBCC CHECKDB e non mi ha restituito errori rilevanti. ho fatto anche una ricostruzione degli indici di alcune tabelle che mi ha indicato la software house, diciamo che cose standard che ci indica la software house come manutenzione di "base". nel fare lo "svuotamento" del file di log, mi sono accorta che mi segnala il database pieno, quando il cliente ha server 2008 non express, quindi non dovrebbe avere limiti di database..quando invece dal mio punto di vista il rallentamento in fase di importazione è dovuto probabilmente proprio al fatto che secondo lui è pieno e non ci entarno altri dati..ma effettivamente guardando anche sui forum, il limite di questa versioen di sql non è 15Gb, quindi non capisco perchè lo veda pieno... 
    lunedì 29 settembre 2014 14:33
  • se fai click destro sul database gammasv, scegli proprietà, a sinistra selezioni files

    come ti risultano impostate le dimensioni  iniziali e l'autogrowth ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    lunedì 29 settembre 2014 14:50
    Moderatore
  • esattamente come lo vedi, solo che a 15.000 e più ora ce l'ho portato manualmente io, altrimenti stava a 13.500 e qualcosa. se però andavo per fare lo shrink file mi diceva che era disponibile spazio allo 0%, quindi pieno. il problema è che ora ho riprovato perchè sono sicura al 100% che avevo già fatto questa operazione venerdì e ora l'ho ritrovato come stava prima.

    altra cosa che non mi quadra è che appena lancio questa procedura, mi va l'utilizzo memoria al 90%  epiù percento, di cui 1gb solo sql...quando però la procedura la interrompo o finisce, non è che si abbassa, rimane lì sul gb, motivo per cui se poi ne cercano di partire altre subito dopo mi si crea questa situazione di "intasamento"... grazie


    lunedì 29 settembre 2014 15:09
  • prova a stoppare il servizio sql server, deframmentare il disco dove sta il database, riavviare il servizio sql.

    ref: http://stackoverflow.com/questions/1951647/primary-filegroup-is-full-in-sql-server-2008-standard-for-no-apparent-reason


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org


    martedì 30 settembre 2014 14:08
    Moderatore
  • Grazie, provo appena possibile. Ma tu mi consiglieresti di fare questo anche se il disco è quasi vuoto?? ossia, il server ha un disco da 500gb praticamente vuoto, nel senso che ha dentro solo il s.o., il gestionale e sql, ci avevo già guardato la scorsa settimana ed è praticamente vuoto..dici che è il caso di provare lo stesso??

    ti aggiorno anche dicendoti che alla fine aumentando manualmente l'initial size e portandola più sù (in maniera tale che ci sia ancora spazio), ora le importazioni me le sta facendo, molto a fatica, ma le sta facendo...la cosa che ignoro è come mai devo aumentarlo io manualmente se in questa versione di sql non ci sono limiti di db..perdonami ,ma sql non lo conosco così tanto bene..non è che per caso ci sia la possibilità piuttosto di fare una sorta di "deframmentazione" sul db ??

    grazie

    mercoledì 1 ottobre 2014 14:11
  • prova la soluzione che ti ho detto perchè una delle cause del mancato funzionamento dell'autogrowth è proprio la manca deframmentazione del disco che è influenzata dall'uso del disco più che dallo spazio occupato su disco.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    mercoledì 1 ottobre 2014 15:05
    Moderatore
  • ok, eseguito, stamattina ho ritrovato come risultato che la deframmentazione non è necessaria perchè lo stato del file system è soddisfacente...nada però, non vedo differenze di comportamento....

    grazie

    giovedì 2 ottobre 2014 08:30
  • Scusa, forse mi sono perso una tua risposta. Il backup completo dei log lo hai eseguito?

    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    giovedì 2 ottobre 2014 08:38
    Moderatore
  • perdonami, ma mi ero dimenticata quando già me lo avevi detto, di risponderti che non sono riuscita in quanto con il managment la parte che riguarda il log la vedo non utilizzabile, ossia grigio chiaro,come se non lo potessi proprio fare..forse sto sbagliando qualcosa io, esattamente in cosa differenzia da un normale backup del db??

    grazie mille

    giovedì 2 ottobre 2014 09:27
  • la deframentazione del disco aveva lo scopo di fare in modo che l'autogrowth funzionasse.

    sei in grado di verificare se ora funziona oppure l'incremento automatico del 10% sulle dimensioni del database non avviene ancora ?

     inoltre hai errori di sql registrati nel registro eventi ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    giovedì 2 ottobre 2014 10:21
    Moderatore
  • nel frattempo ti aggiorno: sono riuscita a capire perchè non mi faceva fare li backup del log, ora l'ho fatto ma non sono sicura che sia andato bene perchè sebbene mi dica che l'ha fatto correttamente, ci mette nemmeno un minuto e non mi ritrovo alla fine un file (tipo quelle del backup), come posso verificare che l'abbia fatto?

    effettivamente dopo la frammentazione la dimensione di 25gb di db massima (in maniera da lasciare tanto spazio ancora libero) me l'ha conservata, quello almeno sembra andare bene.

    nel visualizzatore eventi non ho anomalie di nessun genere, nè riguardanti sql nè altro

    giovedì 2 ottobre 2014 10:44
  • Per il backup  dei lo dai una lettura alla seguente documentazione http://msdn.microsoft.com/en-us/library/ms179478%28v=sql.100%29.aspx e http://technet.microsoft.com/en-us/library/ms178037%28v=sql.105%29.aspx

    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    giovedì 2 ottobre 2014 20:32
    Moderatore
  • fatto anche questo ma senza risultati rilevanti, purtroppo :(

    nulla, alla fine ho fatto la prova di spostare tutto su un server più nuovo (e comuqnue con più memoria di quello su cui stiamo avendo problemi) con il risultato che lì va tutto benissimo, ergo...il server è da cambiare :(

    grazie mille comunque per la disponibilità e per i tanti consigli !!!

    lunedì 6 ottobre 2014 07:40
  • piccolo aggiornamento del "dopo cambio server"....va molto lento comunque !!!! ossia, nella mia precedente risposta ti dicevo di aver provato su un altro server un pò pià nuovo del suo (ma sermpre che aveva tre anni di vita) e sembrava andare molto bene, ossia ho lanciato un paio di importazioni e ci hn messo un'oretta, chè è il tempo giusto...ora ho un server nuovo, con 4gb di ram  e decisamente più nuovo rispetto a quello con cui avevo provato ub ufficio, ma ho l'impressione che sia lento lo stesso..ossia, ora rispetto a prima non si blocca, ma è sempre lento...a questo punto torno sulle mie idee iniziali che c'è qualcosa che non va con sql e il database....se ti venisse in mente altro da verificare, mi faresti un favore !!!

    grazie

    domenica 12 ottobre 2014 09:35
  • ragionare così in astratto su una soluzione sviluppata in sql server è abbastanza opinabile perchè tutto potrebbe anche dipendere da errori nella programmazione, nella costruzione delle relazioni tra tabelle, errori nei piani di esecuzione delle query e quant'altro. 

    inoltre stabilire dei benchmark nelle performance è impossibile se le istanze di sql non sono installate su macchine identiche e configurazioni identiche.

    a questo punto, da quanto dici, la lentezza potrebbe essere dovuta al fatto che il database è mal sviluppato.

    fossi in te proverei a chiedere indicazioni a chi ha sviluppato la soluzione.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    domenica 12 ottobre 2014 09:55
    Moderatore
  • vi ringrazio della disponiblità. ovviamente la prima cosa che ho aftto è stata quella di rivolgermi alla software house, ma ovviamente anche hanno provato a sviare il problema in quanto secondo loro, visto che non ci sono stati aggiornamenti, la "colpa" era del server che era poco performante....al che visti anche tutti i tentativi che abbiamo fatto con voi, anche io sono arrivata a questa conclusione e abbiamo fatto il cambio..a questo punto invece mi dicono che non dipende dal gestionale ma sicuramente da sql e che quindi non è che cosa che compete loro...vabbè, vi ringrazio comunque lo stesso per la vs disponibilità e competenza, buon lavoro!!
    lunedì 13 ottobre 2014 08:33
  • Io indagherei anche su quanto frequente è l'autogrow del database (questo costa tempo e risorse) e nel caso di frequenti autogrow butterei un occhio all'Instant File Initialization. leggi qui 

    Inoltre le tabelle di destinazione hanno trigger "FOR INSERT" ?


    P. Ceglie CIA - Is the main thing

    ______________________________________________

    Se alcuni post rispondono al tuo quesito(non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili. La community ringrazia :-)


    martedì 27 gennaio 2015 15:44