JNK's questions

Eu tenho um procedimento armazenado que consulta uma tabela de filas ocupadas que é usada para distribuir o trabalho em nosso sistema. A tabela em questão tem uma chave primária no WorkID e não há duplicatas.

Uma versão simplificada da consulta é:

INSERT INTO #TempWorkIDs (WorkID)
SELECT
        W.WorkID

    FROM
        dbo.WorkTable W

    WHERE
        (@bool_param = 0 AND
        ((W.InProgress = 0
         AND ISNULL(W.UserID, -1) != @userid_param
         AND (@bool_filtered = 0
              OR W.TypeID IN (SELECT TypeID FROM #Types AS t)))
         OR 
         (@bool_param = 1
          AND W.InProgress = 1
          AND W.UserID != @userid_param)
        OR
        (@Auto_Param = 0
         AND W.UserID = @userid_param)))
         OR
         (@bool_param = 1 AND W.UserID = @userid_param)
    OPTION
        (RECOMPILE)

A #Typestabela é preenchida anteriormente no procedimento.

Como eu disse, WorkTableestá ocupado e, às vezes, enquanto essa consulta está em execução, SUSPEITO que um dos registros está se movendo de um conjunto de filtros WHEREpara outro. Especificamente, isso acontece quando alguém começa a trabalhar em um item e W.InProgressmuda de 0 para 1. Quando isso acontece, recebo uma violação de chave duplicada quando tento adicionar uma chave primária à tabela temporária na qual essa consulta está sendo inserida.

Confirmei no plano de consulta gerado quando ocorre o erro que não há paralelismo, o nível de isolamento é READ COMMITTED, e não há registros duplicados na tabela de origem. Você também pode ver que não há JOINs ou outra maneira de obter produtos cartesianos aqui.

Este é o plano de consulta anônimo:

A questão é: o que está causando as duplicatas e como posso fazê-lo parar?

Acho que READ COMMITTEDdeve funcionar aqui, preciso travar. Tenho quase certeza de que os enganos ocorrem quando o InProgressbit em um registro muda enquanto estou consultando. Eu sei disso porque a tabela armazena a hora dessa alteração e está dentro de milissegundos de quando eu consulto e recebo o erro.

Encontrei um problema recorrente com o SSRS, em que relatórios "ruins" são enviados aos clientes. O problema é que temos relatórios com vários sub-relatórios e um ou mais sub-relatórios não serão processados. Quando o sub-relatório falha ao processar, o relatório é enviado com uma mensagem de erro no lugar do sub-relatório e sem dados reais.

Minha pergunta é: existe uma maneira de impedir o envio de um relatório se um sub-relatório falhar?

Idealmente, gostaria que o relatório externo apenas retornasse um erro. Existe uma maneira de fazer com que os estados de erro em um relatório do SSRS sejam escalados para um escopo externo? Existe um padrão de codificação que podemos aplicar para evitar esse problema?

No momento, estamos usando SSRS 2008r2 e SSRS 2016.

Eu tenho um aplicativo de agente de serviços que atualmente possui 5 ou 6 filas em dois servidores.

O fluxo de trabalho geral é:

Servidor A

• O usuário preenche algumas tabelas
• O usuário dispara o procedimento armazenado que coloca uma mensagem em uma fila de cabeçalho indicando que há trabalho a ser feito
• O Broker lê desta fila de cabeçalho e cria um número potencialmente grande de mensagens para enviar ao Servidor B

Servidor B

• Todas as mensagens vão para 1 fila
• Nesta fila, a mensagem é examinada e desagregada, o payload é executado e uma resposta é coletada de outro conjunto de procs/tabelas com as quais interagimos
• A mensagem de resposta é criada e enviada de volta ao Servidor A

Servidor A

• As mensagens de resposta vão para uma fila especial e são usadas para atualizar as tabelas que o usuário preencheu no topo
• As mensagens do diálogo final são lidas da fila do iniciador e usadas para atualizar outra tabela que rastreia o progresso de um registro de cabeçalho (ou seja, 50 de 100 mensagens processadas)
• Quando detectamos que o registro do cabeçalho foi totalmente processado, uma nova mensagem é enviada para outra fila que envia um e-mail de notificação

Recebi uma recomendação para consolidar algumas dessas filas no Servidor A e não tenho certeza de qual é a melhor prática para isso. Duas das filas terão um volume relativamente alto de processamento de mensagens e a fila de e-mail será bem lenta.

Fizemos (eu acho) um bom trabalho de gerenciamento de tipos de mensagens, então teoricamente poderíamos colocar tudo em uma fila e o aplicativo ainda funcionaria.

Existe uma prática recomendada sobre quando manter filas separadas e quando consolidar em um cenário como este?

Eu tenho um documento XML semelhante a este:

<Root>
  <Sub>
    <Record>
      <Guid>aslkjflaksjflkasjfkljsd</Guid>
    </Record>
    <Record>
       <Guid>opqiwuerl;kasdlfkjawop</Guid>
    </Record>
  </Sub>
</Root>

Estou substituindo um <Record>nó inteiro com base em alguns critérios. Os <Record>nós contêm um <Guid>que posso usar para identificá-los (finja que são GUIDs válidos, por favor!).

Conhecendo o GUID, estou retornando o XML desse nó em uma variável para processamento posterior. Downstream, preciso ser capaz de excluir esse nó específico para poder colocar inserta versão modificada do nó de volta no documento original.

Existe uma maneira de determinar o ordinal ou outra maneira de usar um método delete/ replacepara remover um nó com base no valor de um elemento?

Tenho uma série de exibições atualizáveis ​​que estamos expondo aos usuários finais como a interface para um processo de back-end.

Uma dessas exibições faz referência a duas tabelas e requer um INSTEAD OFgatilho para UPDATEe INSERTs.

A estrutura das tabelas é (bastante simplificada):

Claim
(DataRowID bigint IDENTITY PRIMARY KEY
,<bunch of claim data>)

ClaimExtended
(ClaimDataRowID bigint FOREIGN KEY references dbo.Claim(DataRowID) NOT NULL
,<bunch of other claim data>)

Meu plano original era fazer isso no gatilho da seguinte forma:

CREATE TRIGGER [dbo].[MyTrigger] ON [dbo].[MyView]
INSTEAD OF INSERT
AS

DECLARE @IDLink TABLE
    (RowID int
    ,ClaimDataRowID bigint)

DECLARE @Inserted TABLE
    (RowID int identity (1,1) NOT NULL
    ,<all the columns from the view>)

INSERT INTO
    @Inserted
    (<View columns>)
SELECT
    (<View columns>)
FROM
    Inserted

INSERT INTO
    Claim
    (<Columns>)
OUTPUT
    I.RowID
    ,inserted.ClaimDataRowID
    INTO
        @IDLink (RowID, ClaimDataRowID)
SELECT
    (<Columns>)
FROM
    @Inserted I

INSERT INTO
    ClaimExtended
    (ClaimDataRowID,
    <Columns>)
SELECT
    C.ClaimDataRowID,
    <Columns>
FROM
    @Inserted I
INNER JOIN
    @IDLink C
        ON C.RowID = I.RowID

A OUTPUTcláusula aqui não está funcionando, no entanto ( Multi-part identifier I.RowID could not be bound) estou assumindo porque não consigo referenciar a tabela de origem em uma INSERT OUTPUTcláusula.

Que outro método eu poderia usar aqui além de tornar a view uma tabela? Por outras razões, isso precisa ser um VIEWe as tabelas subjacentes são praticamente imutáveis.

Minha empresa está migrando para um modelo de segurança muito mais restritivo em um futuro próximo.

Como parte disso, estamos alterando servidores específicos para o novo modelo e testando todos os nossos processos existentes. Um dos processos que eu uso muito utiliza a estrutura SMO para criar scripts de objetos de banco de dados em ordem de dependência, para que possamos executar esses scripts em outro servidor.

A parte da ordem de dependência é muito importante, pois temos muitos objetos aninhados (pense em visualizações que fazem referência a outras visualizações).

Com o novo modelo de segurança instalado, esse script parou de funcionar corretamente.

Também testei no SSMS (SSMS 2012 em uma instância 2008r2) e usar View Dependenciesem uma exibição que faz referência a outra exibição no mesmo banco de dados não mostra a exibição referenciada em Objects on which [this view] depends.

Ainda mais preocupante, se eu executar sp_dependsa exibição em questão , obtenho uma lista precisa de dependências.

Pesquisei um pouco e não consegui encontrar uma resposta definitiva, então espero que alguém possa me ajudar:

Quais permissões específicas são necessárias para que um usuário exiba com precisão as dependências no SQL Server 2008r2 e/ou SQL Server 2012 (vamos atualizar em breve).

Pergunta relacionada sobre o mesmo projeto aqui.

Estou analisando duas abordagens para modelar uma relação hierárquica entre minhas tabelas de fatos e dimensões em um data warehouse para armazenar dados de infraestrutura de TI.

Considere como exemplo:

• FACT_Folder
  • Contém fatos sobre uma pasta do sistema de arquivos
• Dim_Drive
  • Uma pasta é vinculada a uma única entrada do DRIVE
• Dim_Array
  • Uma unidade é vinculada a um único array
• Dim_Server
  • Um array é vinculado a um único servidor
• Dim_Farm
  • Um servidor se conecta a um único farm

Para nossos propósitos, não precisamos nos preocupar com a transferência de uma pasta para uma unidade diferente.

Queremos poder obter métricas em todos os níveis dessa hierarquia.

Assumindo que eventualmente terei milhões de entidades de pasta (com dados diários) e centenas ou milhares de unidades, matrizes, etc; qual padrão de projeto você recomendaria e por quê?

1. Normalizado

   • A está Foldervinculado a um Drive, e o restante da hierarquia está entre as dimensões

2. eu desnormalizado

   • Um Folderlink para um Drive, mas a Drivedimensão contém toda a hierarquia para cada Driveentrada para cada linha

3. Desnormalizado II

   • Um Folderlink direto para todos os níveis da hierarquia

4. ??????

Sou bastante novo em design de DW e estou trabalhando em um DW para modelar algumas infraestruturas de TI.

O principal problema/questão neste ponto é como modelar as informações do drive.

Coletaremos dados agregados em arquivos e pastas e dados separados em unidades físicas. As informações da unidade incluirão o espaço total e livre no mínimo e serão atualizadas várias vezes por semana.

Uma das questões de negócios que precisarão ser respondidas é como o uso do drive está evoluindo ao longo do tempo. As informações da unidade também serão usadas em uma hierarquia que leva até o nível de arquivo/pasta.

As opções que vejo agora são:

1. Implementar DRIVEcomo uma dimensão

   • Simplifica o design da hierarquia
   • Isso causará problemas com relatórios? Parece contra-intuitivo para mim relatar dados com limite de tempo apenas em uma dimensão
   • Também parece problemático ter uma dimensão que você SABE que mudará toda vez que atualizar seus dados

2. Implementar DRIVEcomo uma tabela de fatos

   • Simplifica os relatórios
   • Hierarquia complicada (?) - também usarei Drivepara mapear os dados de volta para um servidor ou computador específico. É correto usar uma tabela de fatos como um nível intermediário em uma hierarquia? Eu não acho que é.

3. Implemente DRIVEcomo um fato e uma dimensão

   • O fato conterá apenas a chave, a data e os fatos no espaço
   • O Dimension incluirá outros dados não aditivos, como o computador em que está, etc.
   • Parece resolver os dois problemas, mas isso é um antipadrão?

Estou tendo problemas para encontrar um recurso definitivo sobre isso em qualquer lugar, então espero que um guru possa me dar uma resposta aqui.

Eu tenho uma tabela muito grande à qual tivemos que adicionar uma coluna. O índice clusterizado é altamente fragmentado e quero fazer uma ALTER INDEX REBUILDlimpeza para limpá-lo.

Normalmente também faço um ALTER TABLE REBUILDquando altero as colunas, pois isso limpa todos os ponteiros ou divisões dessa operação.

Preciso fazer as duas coisas, já que estamos falando de um índice clusterizado, que é essencialmente a tabela?

Minha suspeita é ALTER INDEX REBUILDque o cluster não atualizará tudo o que ALTER TABLEirá, mas também tenho medo de que ALTER TABLEnão limpe a fragmentação do índice.

Portanto, deixe-me começar dizendo que não tenho controle total sobre o design do meu banco de dados; portanto, muitos aspectos do sistema atual não podem ser alterados para os propósitos deste cenário.

Comentários sobre como devemos repensar os aspectos do design provavelmente estão corretos, mas inúteis :)

Eu tenho uma tabela muito grande, com aproximadamente 150 campos de largura e cerca de 600m de linhas, que conduz um grande número de processos. Isso está em uma situação de data warehouse, portanto, não temos NENHUMA atualização/inserção fora do processo de carregamento agendado, portanto, é altamente indexado.

Foi tomada a decisão de tentar particionar esta tabela e tenho algumas preocupações sobre a indexação de uma tabela particionada. Não tenho nenhuma experiência com particionamento, portanto, qualquer entrada ou link é bem-vindo. Não consegui localizar especificamente o que estou procurando no BOL ou msdn.

Atualmente, agrupamos em um campo que chamaremos IncidentKeyde a varchar(50)e não exclusivo - poderíamos ter entre 1 a 100 registros com o mesmo IK(sem comentários, por favor). Muitas vezes, obtemos novos dados em IncidentKeyregistros antigos, portanto, também não são sequenciais.

Entendo que preciso incluir meu campo de partição, IncidentDate, em minha chave de índice clusterizado para que a partição funcione corretamente. Estou pensando que seria IncidentKey, IncidentDate.

A questão é: como a mecânica de um índice clusterizado funcionará em uma chave de 2 partes em uma tabela particionada, se um registro em uma partição "nova" estiver antes de um registro em uma partição "antiga" no índice clusterizado?

Por exemplo, tenho 5 registros:

IncidentKey    Date

ABC123        1/1/2010
ABC123        7/1/2010
ABC123        1/1/2011
XYZ999        1/1/2010
XYZ999        7/1/2010

Se eu obtiver um novo registro ABC123, 2/1/2011, ele precisará estar no índice clusterizado ANTES XYZ999, 1/1/2010 . Como é que isso funciona?

Estou assumindo fragmentação e ponteiros, mas não consigo encontrar nenhuma informação sobre o armazenamento físico e a configuração de índices clusterizados não particionados em tabelas particionadas com chaves de duas partes.

Eu não tinha visto o SLEEP_TASKtipo de espera antes, e hoje parece que estou recebendo uma tonelada deles.

Eu não sou o DBA oficial, apenas um desenvolvedor SQL Server que conhece algumas coisas de DBA. Nós atualizamos nossos servidores no último fim de semana para 10.52.2500.0- R2SP1, eu acho.

Todas as informações que encontrei on-line indicam que SLEEP_TASKo servidor está aguardando a conclusão de algum tipo de processo interno. Eu não tenho nenhum bloqueio ou nenhum processo em segundo plano, como pontos de verificação ou limpeza fantasma em execução, então estou um pouco perplexo.

Alguém já viu esse tipo de espera antes e, em caso afirmativo, pode me dar uma idéia do que está causando isso?

Um dos novos recursos do SQL Server 2012 codinome Denalié o índice Columnstore.

Eu sei um pouco sobre os índices antigos regulares de armazenamento de linha, como a estrutura da árvore b, diferenças no armazenamento entre o nível folha e as páginas da árvore b, efeitos dos campos incluídos, otimização para usá-los, ordem das chaves, etc.

Estou tendo dificuldade em obter boas informações sobre os componentes internos de um índice columnstore.

• Como é estruturado?
• Existe uma árvore b? Alguma outra estrutura no lugar?
• Como os dados são organizados?
• Que tipos de operadores específicos são mais adequados para usá-lo?
• Quaisquer outros antipadrões a serem evitados ao usá-los?

Muito do que posso descobrir sobre eles é basicamente o oposto exato de um índice "normal", ou seja, sem ordenação de chaves, sem campos incluídos, APENAS sem cluster.

Quaisquer insights são apreciados.

Meu DBA e eu estamos tendo um desacordo sobre a estrutura do índice.

Considere dados para uma alegação médica...

Temos a Headertabela com campos como:

ClaimId (varchar(50)), PaidAmount, MemberID...

e para cada cabeçalho temos um ou mais registros Detailcomo:

ClaimId (varchar(50)), LineNumber (smallint), MemberId...

A eficiência da estrutura ou duplicação dos dados está fora dos parâmetros desta questão.

Existem tabelas adicionais que se ligam a Detaillinhas individuais por , e ClaimId, LineNumbernós frequentemente também.JOIN DetailHeaderClaimId

Para a Detailtabela, que seria preferível para a chave de índice clusterizado:

ClaimId

ou

ClaimId, LineNumber

ClaimIdsozinho NÃO é único, mas a combinação de ClaimId, LineNumberé única para um Detailregistro.

Um de nós acredita que ClaimIdsozinha é uma chave agrupada melhor porque é mais estreita e que a pesquisa será igualmente eficiente, pois precisamos saber o ClaimIdantes de pesquisar o LineNumber.

O outro acredita que a combinação dos dois é melhor porque elimina a necessidade de um adicional RowID, e pode ser usado em JOINmesas de suporte que precisam do LineNumbercomo JOINcondição.

Tenho um processo ETL mensal que é muito complicado de explicar aqui, mas basicamente obtemos uma grande quantidade de dados do cliente, carregamos em massa em várias tabelas e, em seguida, executamos uma série de processos de criação.

O volume total de dados é grande, adicionamos 25-30 milhões de registros mensalmente à maior tabela, que tem cerca de 700 milhões de registros no total. Existem tabelas de suporte de registros de 2m-300m cada também. O total de dados para este conjunto é de cerca de 3,5 TB.

Este mês, alguns processos estão demorando exponencialmente mais do que o normal. Um exemplo é um proc que normalmente é concluído em 30 minutos, demorou cerca de 40 horas antes de eu matá-lo (ainda não havia sido concluído).

Nem todos os processos são afetados e alguns são executados ainda mais rápido do que o normal.

Obviamente, a causa raiz está além do escopo de algo que posso perguntar aqui, mas há algo que me incomoda:

Temos planos de consulta reais exibidos em milhões de % para operadores individuais.

Como uma varredura de índice clusterizado para 791,358,704%, uma junção de mesclagem para 75,566,494%, etc. Isso ocorre em vários planos de consulta e esses são planos retirados de sys.dm_exec_query_plan.

Esses planos de consulta são indicativos de algum outro problema maior?

Tenho certeza de que o problema não está nas estatísticas desatualizadas - executamos verificações completas em todas as tabelas principais e reconstruí manualmente a maior tabela e o banco de dados com pré-dimensionamento para eliminar a fragmentação.