njvds's questions

Estou usando o ssis para gerar alguns arquivos .dat que são enviados ao servidor linux para carregamento automatizado. Parece que o Windows adiciona algum caractere de símbolo no arquivo que não é facilmente identificável primeiro, mas se eu abrir o arquivo no servidor Linux, posso ver esse símbolo.

Por ex. no nosso arquivo lateral parece bom, mas no lado linux, quando aberto, vejo que ÿþ é adicionado como primeiro caractere no arquivo. Este é um caractere little-endian UTF-16 (LE) representado como Char(255) e Char(254) em decimal. Tentei usar substituir para remover este símbolo, mas não funcionou, por exemplo. Selecione replace(replace('ÿþ01CAP 00820130208',char(255),''),char(254),'')

Isso funciona bem para string, mas não há nada para substituir no arquivo gerado no lado do Windows. Depois de fazer o upload para o Linux, esse símbolo é colado nele. Alguma ideia? Oque pode estar errado aqui ? Eu tentei usar diff collation na consulta que gera esse arquivo, mas sem sorte

Obrigado, NJ

Eu tenho esta consulta abaixo que está se comportando de forma estranha. bem estranho no sentido de que não consegui encontrar uma explicação completa para isso.

Versão: Sql Server 2008 R2 Enterprise

Sem fragmentação. Estatísticas atualizadas com fullscan e para todos os índices.

DECLARE @t TABLE (
  subid INT )

INSERT INTO @t
VALUES     (7)--,(3)


SELECT TOP 1 t.QueueItemID
FROM   QueueTable t
WHERE  t.IsProcessed = 0
       AND t.QCode = 'USA'
       AND SubID IN (SELECT SubID
                     FROM   @t)
ORDER  BY t.QueueItemID 

Um pouco sobre o esquema:

Variável de tabela (@t) é apenas um subid de coluna.

O esquema da QueueTable é:

CREATE TABLE [dbo].[QueueTable](
    [QueueItemID] [int] IDENTITY(1,1) NOT NULL,
    [SubID] [int] NOT NULL,
    [IsProcessed] [bit] NOT NULL,
    [Qload] [varchar](max) NOT NULL,
    [QCode] [varchar](5) NOT NULL,
    [QDesc] [varchar](max) NULL,
 CONSTRAINT [PK_QueueTable] PRIMARY KEY CLUSTERED 
(
    [QueueItemID] ASC
)

Esta tabela é tão grande quanto as colunas do tipo varchar(max) no esquema acima.

Existem 2 índices NC:

1. NC index NCx_1 on (isprocessed,qcode) include(queueitemid,subid)

2. NC index NCx_2 on (subid,isprocessed,qcode) include(queueitemid)

A contagem total de linhas é de cerca de 9 milhões de linhas. O grupo por subid está abaixo:

SubID   RowCount
------  --------
1   68
2   8255571
3   378584
7   5350
11  5318

As linhas que satisfazem a condição (t.IsProcessed = 0 e t.QCode = 'USA') estão em torno de 350k.

Quando executo a consulta acima, leva 1,5 segundo para ser concluída com a busca em NC NCx_1 e, em seguida, digitalizo a variável de tabela. Aqui está o plano.

O plano acima é para subid = 11 ou 7 na variável de tabela @t Não sei por que não está usando o índice NCx_2 (subid, isprocessed, qcode) include (queueitemid) que corresponde aos critérios. Em vez disso, ele está usando o índice NCX_1.

Parece que está procurando cerca de 350 mil linhas para satisfazer (t.IsProcessed = 0 e t.QCode = 'USA' ) e, em seguida, filtrando os dados com base na coluna subid.

Eu esperaria que primeiro filtrasse os dados com base na coluna subid (o que seria muito menor) e, em seguida, aplicasse outros filtros, exatamente para o que serve o NCX_2.

Eu tentei algumas otimizações aqui que melhoraram o desempenho, mas quero entender esse comportamento estranho pelo menos para mim.

1. Quando adiciono dica de junção de mesclagem na consulta, a consulta é executada muito rapidamente (100 ms)
2. Quando adiciono dica de índice (NCX_2) na consulta, a consulta também é executada muito rapidamente (60 ms)
3. Quando modifico a consulta para fazer MIN(t.QueueItemID) e removo a ordem por consulta novamente, é executado muito rápido (60 ms)

Não sei por que o otimizador não o escolheu por padrão.