Génération de plusieurs tâches SQL dans SQL Server 2005

Question

J'ai un certain nombre de processus stockés que je voudrais tous exécuter simultanément sur le serveur. Idéalement, tous sur le serveur sans s’appuyer sur les connexions à un client externe.

Quelles sont les options pour lancer tous ces programmes et les faire fonctionner simultanément (je n'ai même pas besoin d'attendre que tous les processus soient terminés pour effectuer un travail supplémentaire)?

J'ai pensé à:

• Lancement de plusieurs connexions à partir de un client, ayant chacun démarrer le SP approprié.
• Configuration des travaux pour chaque SP et à partir des emplois d'un Connexion SQL Server ou SP.
• Utilisation xp_cmdshell pour démarrer des analyses supplémentaires équivalent à osql ou whetever
• SSIS - Je dois voir si le package peut être écrit de manière dynamique pour gérer davantage de SP, car je ne suis pas sûr du nombre d'accès que mes clients vont obtenir en production

Dans les cas d'emploi et de cmdshell, je vais probablement rencontrer des problèmes de niveau d'autorisation du DBA ...

SSIS pourrait être une bonne option - si je peux piloter la liste des SP par la table.

C’est une situation de datawarehouse, le travail est en grande partie indépendant et NOLOCK est utilisé universellement sur les étoiles. Le système est un ordinateur 8 voies de 32 Go. Je vais donc le charger et le redimensionner si je vois des problèmes.

J'ai essentiellement trois couches, la couche 1 comporte un petit nombre de processus et dépend essentiellement de tous les faits / dimensions déjà chargés (les étoiles sont une couche 0 - et oui, malheureusement, elles devront toutes être chargées ), La couche 2 comporte un certain nombre de processus qui dépendent d'une partie ou de la totalité de la couche 1 et la couche 3 comporte un certain nombre de processus qui dépendent d'une partie ou de la totalité de la couche 2. J'ai déjà les dépendances dans une table et lance tous les procs d'une couche en même temps, car ils sont orthogonaux dans une couche.

Answer 1

Finalement, j'ai créé un programme de console de gestion C # qui lance les processus asynchrones au fur et à mesure de leur exécution et assure le suivi des connexions.

Answer 2

SSIS est-il une option pour vous? Vous pouvez créer un package simple avec des tâches d'exécution parallèles parallèles pour exécuter simultanément les processus stockés. Toutefois, en fonction de ce que font vos procs stockés, vous pouvez ou non tirer parti du démarrage en parallèle de cette opération (par exemple, s’ils accèdent tous aux mêmes enregistrements de table, vous devrez peut-être attendre que les verrous soient libérés, etc.).

Answer 3

À un moment donné, j’ai effectué des travaux d’architecture sur un produit appelé Acumen Advantage associé à un responsable d’entrepôt.

La stratégie de base consiste à disposer d’un DB de contrôle avec une liste des sprocs et de leurs dépendances. En fonction des dépendances, vous pouvez effectuer un tri topologique pour leur donner l'ordre de s'exécuter. Si Pour ce faire, vous devez gérer les dépendances: tous les prédécesseurs d’une procédure stockée doivent être terminés avant de pouvoir être exécutés. Commencer simplement les sprocs dans l’ordre sur plusieurs threads ne suffira pas.

Pour cela, il fallait casser une grande partie de la fonctionnalité SSIS et mettre en place un autre planificateur. C'est correct pour un produit, mais probablement excessif pour un système sur mesure. Une solution plus simple est donc:

Vous pouvez gérer les dépendances à un niveau plus grossier en organisant l’ETL verticalement par dimension (parfois appelé ETL orienté sujet ), où un seul package SSIS et un ensemble de sprocs prennent les données. l'extraction jusqu'à la production de dimensions ou de tables de faits. En règle générale, les dimensions seront en grande partie cloisonnées, de sorte que leur interdépendance sera minimale. En cas d’interdépendance, faites en sorte que le processus de chargement d’une dimension (ou d’une table de faits) dépende de ce dont il a besoin en amont.

Chaque chargeur devient relativement modulaire et vous obtenez toujours un degré de parallélisme utile en démarrant les processus de chargement en parallèle et en laissant le planificateur SSIS le résoudre. Les dépendances contiendront une certaine redondance. Par exemple, une table ODS peut ne pas dépendre du chargement d'une dimension, mais le package en amont achemine lui-même les composants jusqu'au schéma dimensionnel avant son achèvement. Toutefois, cela ne devrait pas poser de problème dans la pratique pour les raisons suivantes:

• Le processus de chargement comporte probablement de nombreuses autres tâches pouvant être exécutées entre-temps
• Les tâches les plus gourmandes en ressources seront presque certainement les chargements de table des faits, qui ne seront généralement pas dépendants les uns des autres. Lorsqu'il existe une dépendance (par exemple, une table de synthèse basée sur le contenu d'une autre table), cela ne peut être évité de toute façon.

Vous pouvez construire les packages SSIS afin qu'ils récupèrent toute leur configuration à partir d'un fichier XML et que l'emplacement puisse être fourni de manière externe dans une variable d'environnement. Ce genre de chose peut être assez facilement implémenté avec des systèmes de planification tels que Control-M. Cela signifie qu'un package SSIS modifié peut être déployé avec relativement peu d'intervention manuelle. Le personnel de production peut être chargé de déployer les packages avec les procédures stockées et peut gérer les fichiers de configuration, environnement par environnement, sans avoir à modifier manuellement la configuration dans les packages SSIS.

Answer 4

vous voudrez peut-être consulter le service broker et ses procédures stockées d'activation ... pourraient être une option ...