Controllare set di risultati SQL di grandi dimensioni e i timeout durante le stored procedure nei flussi di lavoro per App per la logica di Azure

Si applica a: Azure Logic Apps (Consumo + Standard)

Per automatizzare più facilmente le attività aziendali che funzionano con i database SQL, il flusso di lavoro può usare le operazioni del connettore SQL Server, che offre molte funzionalità back-end per i flussi di lavoro da usare in App per la logica di Azure.

In alcune situazioni, il flusso di lavoro potrebbe dover gestire set di risultati di grandi dimensioni. Questi set di risultati potrebbero essere così grandi che le operazioni del connettore SQL Server non restituiscono tutti i risultati contemporaneamente. In altre situazioni, potrebbe essere necessario avere un maggiore controllo sulle dimensioni e sulla struttura per i set di risultati. Per organizzare i risultati nel modo desiderato, è possibile creare una stored procedure.

Ad esempio, quando un'azione del connettore SQL Server ottiene o inserisce più righe, il flusso di lavoro può scorrere queste righe usando un ciclo Until che funziona entro questi limiti. Se il flusso di lavoro deve gestire migliaia o milioni di righe, è necessario ridurre al minimo i costi derivanti dalle chiamate all'azione del connettore SQL Server al database SQL. Per altre informazioni, vedere Gestire i dati in blocco usando il connettore SQL.

Questa guida illustra come controllare le dimensioni, la struttura e i timeout durante l'elaborazione di set di risultati di grandi dimensioni usando le azioni del connettore SQL Server .

Limite di timeout per l'esecuzione della procedura archiviata

Il connettore SQL Server ha un'azione Esegui stored procedure con un limite di timeout inferiore a due minuti. Il completamento di alcune stored procedure potrebbe richiedere più tempo rispetto a questo limite, causando un errore 504 Timeout. A volte i processi a esecuzione prolungata vengono codificati come stored procedure in modo esplicito a questo scopo. A causa del limite di timeout, la chiamata di tali procedure da App per la logica di Azure potrebbe causare problemi.

Le operazioni del connettore SQL Server non supportano in modo nativo una modalità asincrona. Per ovviare a questa limitazione, simulare questa modalità usando gli elementi seguenti:

Trigger di completamento SQL
Query pass-through SQL nativa
Tabella di stato
Processi lato server

Si supponga, ad esempio, di avere la stored procedure con esecuzione prolungata seguente. Per completare l'esecuzione, la procedura supera il limite di timeout. Se si esegue questa stored procedure da un flusso di lavoro usando l'azione connettore SQL Server denominata Esegui stored procedure, viene visualizzato l'errore di timeout del gateway HTTP 504 .

CREATE PROCEDURE [dbo].[WaitForIt]
   @delay char(8) = '00:03:00'
AS
BEGIN
   SET NOCOUNT ON;
   WAITFOR DELAY @delay
END

Anziché chiamare direttamente la stored procedure, è possibile eseguire in modo asincrono la procedura in background usando un agente di processo. È possibile archiviare gli input e gli output in una tabella di stato a cui è possibile accedere e gestire tramite il flusso di lavoro. Se non sono necessari gli input e gli output o se si stanno già scrivendo i risultati in una tabella nella stored procedure, è possibile semplificare questo approccio.

Importante

Assicuratevi che la procedura memorizzata e tutti i processi siano idempotenti, il che significa che possono essere eseguiti più volte senza influire sui risultati. Se l'elaborazione asincrona ha esito negativo o si verifica il timeout, l'agente del processo potrebbe ritentare la stored procedure più volte. Prima di creare oggetti ed evitare la duplicazione dell'output, vedere queste procedure consigliate e approcci.

Per eseguire in modo asincrono la procedura in background con l'agente di lavoro per SQL Server basato sul cloud, seguire i passaggi per creare e usare l'Azure Elastic Job Agent per il database SQL di Azure.

Per SQL Server su server locale e Istanza gestita di SQL di Azure, creare e usare invece SQL Server Agent. I passaggi fondamentali rimangono uguali alla configurazione di un agente di processo per il database SQL di Azure.

Creare un agente di attività per il database SQL di Azure

Per creare un agente di processo in grado di eseguire stored procedure nel database SQL di Azure, crea e utilizza l'Azure Elastic Job Agent. Tuttavia, prima di poter creare questo agente di processi, è necessario configurare le autorizzazioni, i gruppi e le destinazioni come descritto nella documentazione dell'agente processi elastico di Azure. È inoltre necessario creare una tabella di stato di supporto nel database di destinazione, come descritto nelle sezioni seguenti.

Per creare l'agente di lavoro, completare questa operazione nel portale di Azure. Questo approccio aggiunge diverse stored procedure al database usato dall'agente, noto anche come database dell'agente. È quindi possibile creare un agente di processo che esegue la stored procedure nel database di destinazione e acquisisce l'output una volta completato.

Creare una tabella di stato per registrare i parametri e archiviare gli input

I processi di SQL Agent non accettano parametri di input. Nel database di destinazione creare invece una tabella di stato in cui registrare i parametri e archiviare gli input da usare per chiamare le stored procedure. Tutti i passaggi del processo dell'agente vengono eseguiti sul database di destinazione, ma le stored procedure del processo vengono eseguite sul database dell'agente.

Per creare la tabella di stato, usare questo schema:

CREATE TABLE [dbo].[LongRunningState](
   [jobid] [uniqueidentifier] NOT NULL,
   [rowversion] [timestamp] NULL,
   [parameters] [nvarchar](max) NULL,
   [start] [datetimeoffset](7) NULL,
   [complete] [datetimeoffset](7) NULL,
   [code] [int] NULL,
   [result] [nvarchar](max) NULL,
   CONSTRAINT [PK_LongRunningState] PRIMARY KEY CLUSTERED
      (   [jobid] ASC
      )WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
      ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

Ecco l'aspetto della tabella risultante in SQL Server Management Studio (SMSS):Here's how the risultant table look in SQL Server Management Studio (SMSS):

Screenshot che mostra la tabella di stato creata che archivia gli input per la stored procedure.

Per garantire prestazioni ottimali e assicurarsi che l'agente processo possa trovare il record associato, la tabella usa l'ID di esecuzione del processo (jobid) come chiave primaria. Se si vuole, è anche possibile aggiungere singole colonne per i parametri di input. Lo schema descritto in precedenza può gestire in genere più parametri, ma è limitato alle dimensioni calcolate dalla NVARCHAR(MAX) funzione.

Creare un processo ad alto livello per eseguire la stored procedure

Per eseguire la stored procedure a esecuzione prolungata, creare questo agente di lavoro di alto livello nel database dell'agente:

EXEC jobs.sp_add_job 
   @job_name='LongRunningJob',
   @description='Execute Long-Running Stored Proc',
   @enabled = 1

Aggiungere passaggi al processo che parametrizzano, eseguono e completano la procedura memorizzata. Per impostazione predefinita, un passaggio del processo va in timeout dopo 12 ore. Se la procedura memorizzata impiega più tempo o se si desidera che il timeout della procedura avvenga prima, è possibile modificare il parametro step_timeout_seconds in un altro valore specificato in secondi. Per impostazione predefinita, un passaggio include 10 tentativi predefiniti con un timeout di backoff tra ogni tentativo, che è possibile utilizzare a proprio vantaggio.

Ecco i passaggi da aggiungere:

Attendere che i parametri vengano visualizzati nella LongRunningState tabella.

Questo primo passaggio attende che i parametri vengano aggiunti nella LongRunningState tabella, che si verifica subito dopo l'avvio del processo. Se l'ID di esecuzione del processo (jobid) non viene aggiunto alla LongRunningState tabella, il passaggio ha semplicemente esito negativo. Il timeout predefinito di ripetizione o backoff effettua l'attesa:
```
EXEC jobs.sp_add_jobstep
   @job_name='LongRunningJob',
   @step_name= 'Parameterize WaitForIt',
   @step_timeout_seconds = 30,
   @command= N'
      IF NOT EXISTS(SELECT [jobid] FROM [dbo].[LongRunningState]
         WHERE jobid = $(job_execution_id))
         THROW 50400, ''Failed to locate call parameters (Step1)'', 1',
   @credential_name='JobRun',
   @target_group_name='DatabaseGroupLongRunning'
```

Interrogare i parametri dalla tabella dello stato e passarli alla procedura memorizzata. Questo passaggio esegue anche la procedura in background.

Se la stored procedure non richiede parametri, chiamare direttamente la stored procedure. In caso contrario, per passare il @timespan parametro, usare , @callparamsche è anche possibile estendere per passare più parametri.

EXEC jobs.sp_add_jobstep
   @job_name='LongRunningJob',
   @step_name='Execute WaitForIt',
   @command=N'
      DECLARE @timespan char(8)
      DECLARE @callparams NVARCHAR(MAX)
      SELECT @callparams = [parameters] FROM [dbo].[LongRunningState]
         WHERE jobid = $(job_execution_id)
      SET @timespan = @callparams
      EXECUTE [dbo].[WaitForIt] @delay = @timespan', 
   @credential_name='JobRun',
   @target_group_name='DatabaseGroupLongRunning'

Completare il processo e registrare i risultati.

EXEC jobs.sp_add_jobstep
   @job_name='LongRunningJob',
   @step_name='Complete WaitForIt',
   @command=N'
      UPDATE [dbo].[LongRunningState]
         SET [complete] = GETUTCDATE(),
            [code] = 200,
            [result] = ''Success''
         WHERE jobid = $(job_execution_id)',
   @credential_name='JobRun',
   @target_group_name='DatabaseGroupLongRunning'

Avviare l'operazione e passare i parametri

Per avviare il lavoro, utilizzare una query nativa passante con l'azione Esegui query SQL ed inserire immediatamente i parametri del lavoro nella tabella di stato. Per fornire input all'attributo jobid nella tabella di destinazione, App per la logica di Azure aggiunge un ciclo Per ogni che itera sull'output della tabella dall'azione precedente. Per ogni ID di esecuzione del processo, eseguire un'azione Inserisci riga che utilizza l'output dei dati dinamici denominato ResultSets JobExecutionId per aggiungere i parametri del processo da scomporre e passare alla stored procedure di destinazione.

Al termine dell'operazione, il processo aggiorna la LongRunningState tabella. Da un flusso di lavoro diverso, è possibile attivare il risultato usando il trigger denominato Quando viene modificato un elemento. Se non è necessario l'output o se si dispone già di un trigger che monitora una tabella di output, è possibile ignorare questa parte.

Creare un agente di lavoro per SQL Server o Istanza SQL gestita di Azure

Per SQL Server locale e Istanza gestita di SQL di Azure, creare e usare SQL Server Agent. Rispetto all'agente di processi basato sul cloud per il database SQL di Azure, alcuni dettagli di gestione differiscono, ma i passaggi fondamentali rimangono invariati.

Passo successivo

Connettere ai database SQL dai flussi di lavoro in Logic Apps di Azure

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2025-10-20