Início / dba / Perguntas / 20157
Accepted
Jeff Sacksteder
Asked: 2012-06-30 07:05:23 +0800 CST

Irregularidades do componente de pesquisa do SSIS

  • 772

Estou vendo um comportamento estranho em um fluxo de dados com uma operação de pesquisa. Se eu selecionar o modo 'cache completo', algumas partes das pesquisas falharão e não tenho explicação do porquê. 'Sem cache' funciona corretamente, assim como 'Cache parcial'. Neste ponto, não posso confiar no 'Full Cache' em produção se ele falhar misteriosamente.

O resultado esperado se parece com isso-

1 808 larry curly moe
2 808 larry curly moe
3 314 foo bar baz
4 314 foo bar baz
5 314 foo bar baz
6 314 foo bar baz

O cache completo produz isso em vez disso-


1 808 larry curly moe
2 808 larry curly moe
3 314 foo bar baz
4 314 foo bar baz
5 314 null null null
6 314 null null null

O exemplo '314' é um resultado real. Os dois primeiros registros pesquisam corretamente, os dois segundos falham. Se fossem erros de cache, eles deveriam falhar para todas as quatro linhas.

As falhas são repetíveis - os mesmos itens falham na mesma sequência a cada execução. O ambiente é um ambiente de teste isolado com três bancos de dados fixos que não mudam entre as execuções. A seleção de Cache parcial é visivelmente mais lenta, o que implica que há um número significativo de erros de cache. Nenhuma das tabelas é particularmente grande, cerca de mil linhas.

O que está acontecendo? Devo abandonar a esperança de usar o Full Cache?

sql-server-2008-r2 ssis

1 respostas

  1. Best Answer

    Também já vi esse comportamento. O meu foi devido à memória do servidor, que explicarei nas diretrizes. Isso era chato porque era intermitente.

    Com o cache parcial, o cache começa vazio e consulta até encontrar uma correspondência. Se você tiver várias partidas, a primeira vence. Com o cache cheio, se você tiver várias partidas, não tenho certeza de qual venceria. Provavelmente o primeiro na ordem do cache.

    O cache parcial tem uma opção para cache perdido, que lembrará quais registros não têm correspondências e não os consultará novamente. Isso será um problema se você estiver inserindo na tabela em que está fazendo uma pesquisa. Também com cache cheio, se sua fonte contiver duplicatas, a segunda não terá uma correspondência depois que a primeira for inserida, o que será um problema se você quiser suprimir todas menos a primeira.

    Aqui estão algumas diretrizes que tento seguir ao usar pesquisas:

    1. A pesquisa nunca trocará o cache pelo disco. Se ficar sem memória, a tarefa falhará. Se este for o seu problema, obtenha mais RAM ou tente parcial.
    2. Use números inteiros sempre que possível. Se o campo for string, mas puder ser convertido em int, faça isso. Isso remove problemas de caixa e espaço em branco todos juntos
    3. Corte as cordas. O espaço em branco lhe dará ataques.
    4. Se for uma string, coloque os dois lados em letras maiúsculas antes de comparar (as pesquisas diferenciam maiúsculas de minúsculas e falharão se as maiúsculas não corresponderem).
    5. Nulo nunca é igual a Nulo. Se a coluna for anulável, substitua ambos os lados por "UNKNOWN" se for string e um número irracional como -999 se for inteiro.
    6. Se a coluna estiver vazia, substitua ambos os lados pelo texto "VAZIO"

    Isso é um pé no saco, mas é melhor do que receber uma ligação às 3 da manhã porque um ETL de clientes de nível 1 falhou.

    • 4

relate perguntas