Sto eseguendo una stored procedure utilizzando SQL Server Agent Job in SQL Server 2005.Lavoro agente SQL Server in esecuzione lento
Questo processo è stato eseguito velocemente fino a ieri. Da ieri questo lavoro impiega più di 1 ora invece di 2 minuti.
Ho eseguito la stored procedure in SSMS, l'esecuzione è stata eseguita in meno di 1 minuto.
Non riesco a capire perché ci vuole più di 1 ora quando viene eseguito come un lavoro di SQL Server Agent?
Dopo qualche tempo commentando e supponendo che la SP esegue con gli stessi parametri di input e dati bene quando eseguito in SSMS, io finnaly penso di poter dare un ultimo suggerimento:
seconda di quali azioni sono eseguite entro il SP (ad es. inserimento/aggiornamento/cancellazione di molti dati all'interno di un loop o cursore), è necessario impostare nocount all'inizio del codice.
set nocount on
Se questo non è il caso o non aiuta, si prega di aggiungere ulteriori informazioni, già accennato nei commenti (per esempio tutte le impostazioni del lavoro e ogni JobStep, ciò che è stato registrato, ciò che è nel Jobhistory, controllare SQLerrorlogs, eventlogs, ....). Dai uno sguardo anche ai "log di SQL Server" potresti raccogliere qui alcune informazioni. Anche un aspetto nell'evento Application/System di Databaseserver è sempre una buona idea. Per ottenere una panoramica di base, è possibile utilizzare Activitymonitor in SSMS, selezionando Server di database e selezionando "Monitoraggio attività" dal menu di scelta rapida e cercare l'agente sql.
Il mio ultimo tentativo sarebbe provare a eseguire una traccia SQL per l'agente. In questo caso, avresti avviato una traccia e un filtro, ad es. dall'utente che esegue il servizio SQLAgent. Ci sono così tante opzioni che puoi impostare per le tracce, quindi consiglierei google per questo, cercare su MSDN o fare un'altra domanda qui su StackOverflow.
"SET NOCOUNT ON" ha fatto il trucco per me. –
Ho notato che i lavori di SQL Agent ignorano l'impostazione MAXDOP del server ed eseguono tutto con un MAXDOP di 1. Se eseguo una procedura memorizzata in una query windows, obbedisce alle impostazioni del server e utilizza 4 processi. Se utilizzo SQL Agent, qualsiasi procedura memorizzata eseguita utilizza solo un processo.
Ho un problema simile con uno script che chiama un numero di UDF che ho creato. Di solito, le UDF eseguono la sottocoda sotto SSMS. Allo stesso modo, l'esecuzione dei report che genera con loro è sopportabile con SSMS (dati 30d in 8s, dati 365d in 22s). Ho sempre fatto NOCOUNT ON con i miei processi di SQL Agent poiché normalmente generano file di testo per essere prelevati da altri processi o da Excel e non voglio i dati extra alla fine, quindi non è stata una soluzione per me.
In questo caso, quando eseguiamo esattamente lo stesso script in SQL Agent come lavoro, i miei tempi crescono esponenzialmente. Il mio script 8s richiede 2m30s e il mio script 22s richiede 2h20m. È lo stesso se lo eseguo a mezzogiorno con altre attività utente e lavori o dopo ore senza attività dell'utente, né lavori o backup in esecuzione. Il nostro server è inattivo e nel migliore dei casi ottengo uno degli 8 core utilizzati durante l'esecuzione. DB è solo di circa 10 GB in esecuzione su SSD con una scheda RAID in cache e 16 di 32 GB di RAM sono gratuiti. Dal momento che il mio SQL funziona in modo efficiente in SSMS, sono abbastanza convinto che sto raggiungendo un limite di threading di qualche tipo. Ho cercato e provato a regolare MAXDOP appena prima degli script nell'agente SQL senza fortuna.
Poiché si tratta di un'attività che desidero pianificare, è necessario automatizzarla in un modo o nell'altro. Potrei lasciare che questi script prendano le ore di cui hanno bisogno per essere eseguiti come passi SQL nei processi di SQL Agent, ma ho deciso di eseguire da riga di comando e ottengo le stesse prestazioni che vedo in SSMS.
sqlcmd -S SQLSRVRHost -i "C:\My Script Loc With Spaces.sql" -v MyVar="VarValue" >"C:\MyOutputFile.txt"
Quindi ho creato uno script batch con i processi SQL eseguiti da sqlcmd. Quindi eseguo lo script batch da un processo di SQL Agent, quindi ho ancora la stessa gestione e controllo. I miei 4 lavori SQL che hanno richiesto più di 3 ore per essere eseguiti completi in 1 minuto e pochi secondi da un singolo script batch eseguito da SQL Agent.
Spero che questo aiuta ...
Abbiamo una grande proc che viene eseguito in 88 secondi in SSMS e 30-45 minuti in SQL Server Agent. Ho aggiunto il dbo. prefisso su tutti i nomi delle tabelle e ora viene eseguito con la stessa rapidità di SSMS.
Se si esegue lo stesso SP in SSMS e funziona, è possibile che un'impostazione del lavoro sia cambiata, ad es. è eseguito sul databse sbagliato. In caso contrario, controllare Monitoraggio attività su cosa sta facendo l'agente o avviare una traccia per ottenere i comandi eseguiti. forse ci sono problemi di blocco. Il problema si verifica ancora se si esegue manualmente il lavoro? –
@ Bernard, Grazie per la risposta. Ho controllato il lavoro e l'ho ricreato. Ancora lo stesso problema. Sì, se eseguo manualmente il lavoro ci vuole ancora un sacco di tempo – Prateek
@Preteek puoi pubblicare le impostazioni del lavoro? L'unica ragione per cui posso pensare a questo comportamento è un'esecuzione diversa dell'SP. Poiché i parametri ecc. Sono gli stessi di quando eseguiti manualmente, SQLServer dovrebbe usare gli stessi piani di esecuzione, ecc. Forse si può dare un'occhiata al log SQL - forse questo ci darà un suggerimento. –