Generazione di più attività SQL in SQL Server 2005

Question

Ho un numero di proc memorizzati che vorrei eseguire tutti contemporaneamente sul server. Idealmente tutto sul server senza fare affidamento sulle connessioni a un client esterno.

Quali opzioni ci sono per lanciare tutte queste e farle funzionare simultaneamente (non ho nemmeno bisogno di aspettare fino a quando tutti i processi non saranno completati per fare un lavoro aggiuntivo)?

Ho pensato a:

• Avvio di più connessioni da un client, facendo iniziare ciascuno il SP appropriato
• Impostazione lavori per ogni SP e iniziare i lavori da a Connessione SQL Server o SP.
• Utilizzo xp_cmdshell per avviare ulteriori esecuzioni equivalente a osql o intero
• SSIS - Devo vedere se il pacchetto può essere scritto in modo dinamico per gestire più SP, perché non sono sicuro di quanto accesso i miei clienti otterranno alla produzione

Nei casi di lavoro e cmdshell, probabilmente incontrerò problemi a livello di autorizzazioni dal DBA ...

SSIS potrebbe essere una buona opzione, se posso guidare tabella l'elenco SP.

Questa è una situazione di datawarehouse, e il lavoro è in gran parte indipendente e NOLOCK è universalmente usato sulle stelle. Il sistema è un computer da 8 GB a 8 vie, quindi lo caricherò e ridimensionerò se vedo problemi.

Fondamentalmente ho tre livelli, il Livello 1 ha un piccolo numero di processi e dipende sostanzialmente da tutti i fatti / dimensioni già caricati (in effetti, le stelle sono un Livello 0 - e sì, sfortunatamente dovranno essere caricati tutti ), Il livello 2 ha una serie di processi che dipendono da alcuni o tutti i livelli 1 e il livello 3 ha una serie di processi che dipendono da alcuni o tutti i livelli 2. Ho già le dipendenze in una tabella e solo inizialmente lanciare tutti i proc in un determinato livello contemporaneamente, poiché sono ortogonali all'interno di un livello.

Answer 1

Alla fine, ho creato un programma della console di gestione C # che avvia i processi Async in quanto sono in grado di essere eseguiti e tiene traccia delle connessioni.

Answer 2

SSIS è un'opzione per te? È possibile creare un pacchetto semplice con attività Execute SQL parallele per eseguire contemporaneamente i proc memorizzati. Tuttavia, a seconda di ciò che fanno i tuoi proc memorizzati, potresti o meno trarre vantaggio dall'avvio in parallelo (ad es. Se tutti accedono agli stessi record della tabella, potresti dover attendere il rilascio dei blocchi ecc.)

Answer 3

Ad un certo punto ho fatto alcuni lavori di architettura su un prodotto noto come Acumen Advantage che ha un responsabile del magazzino che lo fa.

La strategia di base per questo è di avere un DB di controllo con un elenco degli sprocs e delle loro dipendenze. In base alle dipendenze puoi eseguire un Ordinamento topologico per dare loro un ordine da eseguire. Se a tale scopo, è necessario gestire le dipendenze: tutti i predecessori di una procedura memorizzata devono essere completati prima dell'esecuzione. Il solo avvio degli sprocs in ordine su più thread non compirà questo da solo.

L'implementazione di questo significava mettere a dura prova gran parte delle funzionalità SSIS e implementare un altro programmatore. Questo è OK per un prodotto ma probabilmente eccessivo per un sistema su misura. Una soluzione più semplice è quindi:

È possibile gestire le dipendenze a un livello più grossolano organizzando l'ETL verticalmente per dimensione (a volte noto come ETL orientato al soggetto ) in cui un singolo pacchetto SSIS e un insieme di sprocs prendono i dati da estrazione fino alla produzione di dimensioni o tabelle dei fatti. In genere, le dimensioni saranno per lo più insilate, quindi avranno una minima interdipendenza. Laddove vi sia interdipendenza, fare in modo che una dimensione (o tabella dei fatti) carichi il processo dipendente da tutto ciò di cui ha bisogno a monte.

Ogni caricatore diventa relativamente modulare e si ottiene ancora un utile grado di parallelismo dando il via ai processi di caricamento in parallelo e lasciando che lo schedulatore SSIS lo risolva. Le dipendenze conterranno una certa ridondanza. Ad esempio, una tabella ODS potrebbe non dipendere dal completamento del caricamento di una dimensione, ma il pacchetto upstream stesso porta i componenti fino allo schema dimensionale prima del completamento. Tuttavia, questo non è probabilmente un problema in pratica per i seguenti motivi:

• Il processo di caricamento probabilmente ha molte altre attività che possono essere eseguite nel frattempo
• Le attività più affamate di risorse saranno quasi certamente i carichi della tabella dei fatti, che per lo più non dipenderanno l'uno dall'altro. Laddove esiste una dipendenza (ad esempio una tabella di rollup basata sul contenuto di un'altra tabella), ciò non può essere comunque evitato.

Puoi costruire i pacchetti SSIS in modo che raccolgano tutta la loro configurazione da un file XML e la posizione possa essere fornita esternamente in una variabile d'ambiente. Questo genere di cose può essere facilmente implementato con sistemi di pianificazione come Control-M. Ciò significa che un pacchetto SSIS modificato può essere distribuito con un intervento manuale relativamente ridotto. Allo staff di produzione possono essere consegnati i pacchetti da distribuire insieme alle procedure memorizzate e può conservare i file di configurazione in base all'ambiente senza dover modificare manualmente la configurazione nei pacchetti SSIS.

Answer 4

potresti voler consultare il broker di servizi e le relative procedure memorizzate per l'attivazione ... potrebbe essere un'opzione ...