Desova várias tarefas SQL no SQL Server 2005

Question

Eu tenho um número de procedimentos armazenados que eu gostaria de todos executados simultaneamente no servidor. Idealmente todos no servidor sem depender de conexões para um cliente externo.

O que opções existem para lançar tudo isso e executá-los simultaneamente (eu nem sequer precisa esperar até que todos os processos são feitos para fazer o trabalho adicional)?

eu ter pensado:

• O lançamento de múltiplas conexões de um cliente, tendo cada iniciar o SP apropriada.
• Configuração de postos de trabalho para cada SP e iniciar os trabalhos de um conexão ou SP SQL Server.
• Usando xp_cmdshell para iniciar corridas adicionais equivalente a osql ou Whetever
• SSIS - Eu preciso ver se o pacote pode ser escrito de forma dinâmica para lidar com mais SPs, porque eu não tenho certeza de quanto acesso meus clientes vão começar a produção

Nos casos de trabalho e cmdshell, eu provavelmente vou ter problemas de nível de permissões do DBA ...

SSIS poderia ser uma boa opção -. Se eu posso mesa-drive a lista SP

Esta é uma situação datawarehouse, eo trabalho é em grande parte independente e NOLOCK é universalmente utilizado nas estrelas. O sistema é uma máquina de 32GB 8-way, por isso estou indo para carregá-lo para baixo e escalá-lo de volta se eu ver problemas.

Basicamente, eu tenho três camadas, camada 1 tem um pequeno número de processos e depende basicamente todos os fatos / dimensões já estão sendo carregados (em vigor, as estrelas são uma camada de 0 - e sim, infelizmente, todos eles vão necessidade de ser carregado ), da camada 2 tem um número de processos que dependem de alguns ou de todos de Camada 1, e da camada 3 tem um número de processos que dependem de alguns ou de todos de Camada 2. I têm as dependências em já uma mesa, e seria apenas inicialmente lançar todos os procs em uma camada específica, ao mesmo tempo, uma vez que eles são ortogonais dentro de uma camada.

Answer 1

No final, eu criei um programa de console de gerenciamento C #, que lança os processos Async como eles são capazes de ser executado e mantém o controle das ligações.

Answer 2

SSIS é uma opção para você? Você pode criar um pacote simples com paralelo tarefas Executar SQL para executar os procedimentos armazenados simultaneamente. No entanto, dependendo do que os seus procedimentos armazenados fazer, você pode ou não pode se beneficiar a partir deste em paralelo (por exemplo, se todos eles acesso os mesmos registros da tabela, pode-se ter que esperar para fechaduras para ser lançado etc.)

Answer 3

Em um ponto que eu fiz algum trabalho de arquitetura em um produto conhecido como Acumen vantagem que tem um gerente de armazém que faz isso.

A estratégia básica para isso é ter um DB controle com uma lista dos sprocs e suas dependências. Com base nas dependências que você pode fazer um topológica Ordenar para dar-lhes uma ordem para executar. Se você fizer isso, você precisa para gerenciar as dependências - todos os antecessores de um procedimento armazenado deve completar antes de executar. Apenas começando os sprocs, a fim de vários segmentos não vai fazer isso por si só.

A implementação desta significou batendo muito da funcionalidade SSIS na cabeça e implementação de outro programador. Este é OK para um produto, mas provavelmente um exagero para um bespoke sistema. A solução mais simples é assim:

Você pode gerenciar as dependências em um nível mais de grão grosso, organizando a ETL verticalmente por dimensão (também conhecido como Assunto ETL Orientada ), onde um pacote SSIS único e conjunto de sprocs leva os dados de extracção por meio de dimensões que produzem ou tabelas de fatos. Tipicamente as dimensões vão ser maioritariamente em silos, de modo que terá interdependência mínima. Onde há interdependência, faça uma dimensão (ou fato tabela) processo de carregamento depende do que ele precisa de upstream.

Cada carregador torna-se relativamente modular e você ainda obter um grau útil de paralelismo chutando os processos de carga em paralelo e deixando o trabalho programador SSIS para fora. As dependências conterá alguma redundância. Por exemplo, uma mesa ODS pode não ser dependente de uma carga de dimensão a ser concluído, mas o pacote em si a montante leva os componentes à direita até o esquema dimensional antes de ser concluída. No entanto, este não é provável que seja um problema na prática, pelos seguintes motivos:

• O processo de carga provavelmente tem muitas outras tarefas que pode executar, entretanto
• As maioria das tarefas de recursos com fome será quase certamente as cargas da tabela de fatos, que na sua maioria não vai ser dependentes uns dos outros. Onde há uma dependência (por exemplo, um pacote cumulativo de tabela com base no conteúdo de outra tabela), este não pode ser evitado de qualquer maneira.

Você pode construir os pacotes do SSIS para que eles pegar toda a sua configuração de um arquivo XML ea localização podem ser fornecidos exernally em uma variável de ambiente. Esse tipo de coisa pode ser facilmente implementado com sistemas de programação, como Control-M. Isto significa que um pacote SSIS modificado pode ser implantado com a intervenção relativamente pouco manual. A equipe de produção podem ser entregues os pacotes para implantar, juntamente com os procedimentos armazenados e podem mainain os arquivos de configuração em uma base per-ambiente, sem ter que configuração fiddle manualmente os pacotes do SSIS.

Answer 4

Você pode querer olhar para o corretor de serviço e é procedimentos de ativação armazenados ... pode ser uma opção ...