none
Info su lancio Stored Procedure da VB6 RRS feed

  • Domanda

  • Salve a tutti,

    ho una domanda da porre alla vostra attenzione :

    Ho creato una procedura che riempie una tabella temporanea per effettuare delle stampe,

    la chiamata è questa :

    EXEC sp_FabbisognoProd N'                                 ', N'ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ', 10, '', '', 62 , N'SUPERVIS'

    Se la chiamo da SQL MAnager, tutto a posto, ci impiega 30 sec., se la chiamo da

    VB6 capita che un giorno funzioni, e ci impiega 30 sec, e che altri giorni è come se si bloccasse, perchè esegue la stessa operazione in 20 min, eppure con la stessa sintassi, sempre da vb6, lancio molte altre procedure , ed è tutto OK;

    invece con questa ho continuamente questi problemi:

    Avete risposte ? Aiuti ?

    grazie in anticipo

    venerdì 12 luglio 2013 11:42

Tutte le risposte

  • Ciao,

    Il problema che ci poni potrebbe essere dovuto a tanti fattori. Hai provato prima a profilare la chiamata? Hai fatto un po' di debug o controllato i tuoi log applicativi (se non ne hai fatti aggiungine)? Il database è acceduto da molte persone o è ad uso esclusivo del processo di caricamento in quei momenti?

    Quello che voglio dire è che senza un'analisi accurata da parte tua del sistema e del software che usi è molto difficile aiutarti.


    Alessandro Alpi SQL Server MVP

    lunedì 15 luglio 2013 15:48
    Moderatore
  • Ho debuggato la routine di vb6 in cui lancio tramite DAO la mia Stored nel Database, sembra essere tutto a posto; quello che, sinceramente, non ho provato, è di riavviare i servizi di SQL Server per accertarmi che non sia un problema del Server SQL.

    Il Datatabase, ed in particolare una Tabella interessata in questa Stored, è effettivamente usata da più utenti contemporaneamente, infatti la Stored, non fa altro che cancellare e riempire di dati aggiornati la Tabella pr_Fabbisogno per utente, per cui nella stessa tabella ci saranno dati provenienti da più utenti;

    Ho verificato che non ci sono Lock superflui sulla Tabella;

    martedì 16 luglio 2013 13:56
  • Quando vai a fare cancellazioni, richiedi comunque un lock esclusivo.

    Quindi può succedere che, in momenti di intenso traffico, qualcuno stia leggendo le versioni dei record che stai provando a cancellare (o un range di essi) e un wait si verifica, se non specifichi il tipo di accesso in lettura.

    Potrebbero esserci anche transazioni esplicite create dal software (da chi l'ha scritto) che segnano i dati come inaccessibili ad una delete (accesso eslcusivo).

    Però, prima di trarre conclusioni, a mio avviso devi monitorare molto di più, fare tracce di profilo, cercare di scovare quale sia il momento in cui accade, se è sistematico o se ci sono sintomi che ti fanno capire la motivazione. E non fermarti a SQL Server, guarda anche come si comporta la memoria, il disco/i dischi, e altri indicatori del server che possono aiutarti a capire.

    C'è da fare un troubleshooting approfondito. Così su due piedi, la prima causa che mi viene è un wait dovuto al fatto che cancelli spessissimo (multiutente) e che i processi si aspettino a vicenda fino a dare l'escalation dei 20 minuti.


    Alessandro Alpi SQL Server MVP

    mercoledì 17 luglio 2013 08:03
    Moderatore
  • Se volessi, come faccio a specificare l'accesso in lettura?
    mercoledì 17 luglio 2013 08:49
  • Puoi cambiare il livello di isolamento della transazione (in una sessione) oppure puoi specificare l'hint di accesso sulla tabella. Però prima cerca di capire se è veramente necessario questo passo. Cerca di approfondire prima la parte di analisi. Perché certi tipi di lettura (ad esempio il NOLOCK) ti fanno perdere consistenza sul dato. Fai molta attenzione.

    Comunque, isolamenti di transazione, SET TRANSACTION ISOLATION LEVEL e hint di query/tabella.

     


    Alessandro Alpi SQL Server MVP

    mercoledì 17 luglio 2013 08:56
    Moderatore
  • Che significa troubleshooting approfondito o profilare la chiamata ?
    mercoledì 17 luglio 2013 11:07
  • Fare analisi approfondite per scoprire dove sta il problema. Troubleshooting = risoluzione del problema/dei problemi.

    Per profilare la chiamata ci sono strumenti atti a questo tipo di analisi. Ad esempio SQL Server Profiler.


    Alessandro Alpi SQL Server MVP

    mercoledì 17 luglio 2013 11:22
    Moderatore
  • Il Server dove è installata l'applicazione che dà questi problemi

    ha un'istanza SQL Server Express che non contiene SQL Server Profiler, non posso utilizzarlo;

    mercoledì 17 luglio 2013 15:03
  • Se hai express (parlo di 2012), che la veramente tante limitazioni rispetto alle altre edizioni, le ragioni potrebbero essere anche legate all'utilizzo del processore (solo uno) o alla memoria (max 1 GB).

    Per capire poi se i dischi e la RAM sono sufficienti puoi utilizzare il system monitor (aka perfmon) e controllare i performance couters consigliati in questo articolo.

    Inoltre, potrebbe essere che in quei momenti di grande attesa della query di cancellazione, giri qualche processo di ricostruzione degli indici oppure qualche shrink automatica erroneamente impostata.

    Ancora, se sei su una macchina virtuale devi controllare il sottosistema su cui è installate.

    Come ti dicevo, in questo post non ci sono sufficienti dettagli per eseguire un'analisi approfondita. Non sarebbe male cercare di lanciare qualche query sulle dynamic management views durante i momenti di "blocco".

    Se vuoi c'è anche un ebook free qui.


    Alessandro Alpi SQL Server MVP

    mercoledì 17 luglio 2013 16:04
    Moderatore
  • Si tratta di

    Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)   Jun 17 2011 00:54:03   Copyright (c) Microsoft Corporation  Express Edition with Advanced Services (64-bit) on Windows NT 6.2 <X64> (Build 9200: ).

    Non sono su Macchina Virtuale.

    Le cancellazioni sulla Tabella sono circa 15000 alla volta, e gli utenti meno di una decina, e credo che usino questa procedura al massimo 3-4 alla volta.Quindi aspettare 15000*3 cancellazioni non è compatibile con una attesa di 20-30 minuti, penso io...

    grazie delle info

    ciao

    mercoledì 17 luglio 2013 18:30
  • Sì concordo con te, ma con questi dati non è possibile aiutarti più di tanto. Ti invito a leggere i link e a fare un po' di analisi sulla tua istanza.

    Alessandro Alpi SQL Server MVP

    giovedì 18 luglio 2013 08:12
    Moderatore
  • Vedrò di verificare che SQL Server funzioni correttamente, e a lanciare qualche query sulle dynamic management views durante i momenti di "blocco",

    grazie al momento per tutte le info, utilissime.

    giovedì 18 luglio 2013 08:53
  • Altre info :

    Riavviando SQL Server tutto ricomincia a funzionare correttamente.

    Il problema di solito si verifica il mattino, dopo che di notte vengono lanciate delle Stored per aggiornare alcune tabelle (fra queste 2 tabelle interessate nella mia Stored).

    Il mio dubbio è che le Stored lanciate la notte possano, non so, lasciare, per così dire, sporcizia nel Server, o comunque dei Lock..

    lunedì 22 luglio 2013 08:29
  • E queste stored procedure notturne che fanno? Hai controllato se ci sono processi appesi e attivi o in attesa?

    Alessandro Alpi SQL Server MVP

    lunedì 22 luglio 2013 10:16
    Moderatore
  • Con quali Stored di sistema verifico se ci sono ancora processi attivi o pendenti ?
    lunedì 22 luglio 2013 10:18
  • Ci sono vari metodi per raggiungere questo obbiettivo:

    - sp_who e sp_who2

    - activity monitor sul tuo sql server

    - sys.dm_exec_requests

    - sys.dm_os_waiting_tasks

    - perfmon

    - prodotti di terze parti (che poi leggono dagli oggetti di cui sopra)

    Questi punti fanno parte del famoso troubleshooting che dovresti approfondire.

    Prova a leggere anche qui.


    Alessandro Alpi SQL Server MVP

    lunedì 22 luglio 2013 10:35
    Moderatore