beeks's questions

Um cliente relatou que estava executando no SQL Server 2012 e, no entanto, entregamos algumas consultas de teste para teste antes de uma entrega final:

'CONCAT' não é um nome de função integrado reconhecido.

Eu entendo que CONCAT()é uma nova função interna introduzida no SQL Server 2012, que está tudo bem, no entanto, fui solicitado a reverter minha alteração para tornar este 2008R2 compatível sob o pretexto de "o usuário que executa a consulta pode não tem permissões Transact-SQL para executar." Então, estou apenas provando que o cliente provavelmente tem uma versão diferente do SQL Server instalada no DEV do que no PROD.

Não consigo encontrar nenhuma informação sobre especificamente negar SELECT/EXECUTEpermissões para funções de valor escalar internas, mas é possível e, em caso afirmativo, o usuário ainda recebe o mesmo texto de erro?

Eu tenho uma tabela que armazena informações de versão em strings com vários pontos, ou seja, '4.1.345.08', '5.0.1.100', etc. Estou procurando a maneira mais rápida de descobrir qual é maior. Existe uma maneira mais rápida ou mais fácil para os olhos do que a que eu criei abaixo? Uma ressalva é que tenho 90% de certeza de que devemos encontrar APENAS valores numéricos pontilhados aqui, mas não posso garantir isso no futuro.

DECLARE @str1 nvarchar(max)='15.0.4000.8'
DECLARE @str2 nvarchar(max)='15.6.4000.8'

SELECT 
CASE 
WHEN PARSENAME(@str1, 4) > PARSENAME(@str2, 4) 
   THEN @str1
WHEN PARSENAME(@str1, 4) < PARSENAME(@str2, 4)
   THEN @str2
ELSE CASE
   WHEN PARSENAME(@str1, 3) > PARSENAME(@str2, 3)
      THEN @str1
   WHEN PARSENAME(@str1, 3) < PARSENAME(@str2, 3)
      THEN @str2
   ELSE CASE
      WHEN PARSENAME(@str1, 2) > PARSENAME(@str2, 2)
         THEN @str1
      WHEN PARSENAME(@str1, 2) < PARSENAME(@str2, 2)
         THEN @str2
      ELSE CASE
         WHEN PARSENAME(@str1, 1) > PARSENAME(@str2, 1)
            THEN @str1
         WHEN PARSENAME(@str1, 1) < PARSENAME(@str2, 1)
            THEN @str2
         ELSE NULL
         END
      END
   END
END

Eu tenho uma tabela que tem três colunas: HashUID1, HashUID2, Address_Name (que é um endereço de e-mail textual, e as duas colunas de hash anteriores são de alguma criação maluca para vincular tabelas de participantes de eventos a endereços de e-mail. é feio, mal funciona do meu controle. Concentre-se no índice address_name)

Tem 78 milhões de linhas. Não classificado corretamente. Independentemente disso, esse índice é dividido em vários LUNs rápidos e executa buscas de índice REALMENTE rápidas.

Preciso criar uma série de consultas para extrair apenas 20.000 "linhas por página" por vez, mas evitar conflitos ou enganos. Como não há coluna de identidade ou coluna facilmente ordenada, existe uma maneira fácil de selecionar tudo e folheá-lo?

Estou correto ao dizer que se eu fizer uma seleção * de uma tabela enorme com e-mails em uma tabela temporária, selecione por meio dela por número_da_linha que a tabela permaneça na memória durante a transação, o que, para mim, é uma quantidade excessiva de recursos de memória ? Este parece ser o método preferido de paginação. Prefiro paginar por porcentagens estatísticas. :(

Há um índice que mantém o endereço de e-mail address_name em ordem e é bem mantido. Na semana passada, pretendi ajudar esse outro desenvolvedor gastando algum tempo na criação de um proc que cuspisse intervalos com base em funções de janela com base em estatísticas (na qual não sou muito bom, mas essa consulta realmente me interessou) para fornecer um intervalo de caracteres de 1 a (variável) LEFT LIKE chars do índice, que atende a 20.000 linhas--Mas não tive tempo nem de iniciar a consulta ...

Perguntas do casal:

1. Alguma sugestão? Não estou procurando um código real, apenas algumas dicas ou sugestões baseadas em experiências, talvez ressalvas. Desejo evitar varreduras de índice adicionais após a varredura inicial.

2. É este o caminho certo?

3. Estou pensando em quebrar a soma do índice de todos os endereços de e-mail, reunindo rowcount(*), /20.000 e usando isso como uma função de janelamento para agrupar valores min/max substring(1,5) com base em porcentagens da contagem total de linhas para construir faixas de agrupamento. Pensamentos?

Isso é para um processo ETL que não pode modificar bancos de dados de origem.

Espero que com uma varredura de índice completa eu possa fazer:

• Consulta para obter um histograma com base no uso do índice (classificado alfabeticamente) e dividi-lo (em janela) usando min/max para criar alguns intervalos como este, para buscar facilmente o índice necessário:

• A-> AAAX, (20k linhas por exemplo) AAA-Z, B-> (outros 20k), B->BAAR -> BAAR-> CDEFG -> CDEFH > FAAH, etc.

Executamos leitura confirmada nesses bancos de dados para esse processo ETL. Estamos apenas tentando agrupar em lotes de 20 mil linhas porque os DBAs dizem que estamos usando muitos recursos de rede ao capturar tabelas completas. Se os dados forem alterados (o que é uma preocupação), atualizamos nosso DW e as tabelas de preparação em tempo real.

Eu adoraria usar tabelas temporárias, mas, se o fizesse, entraria no tempdb e receberia críticas por e-mail dos DBAs a respeito, e que o banco de dados é muito grande.

Digamos que eu tenha uma mesa com um baralho numerado de 01 a 52. Eu poderia retornar os cartões superiores e inferiores, como se segurasse cada lado da consulta de seleção da união em minhas mãos esquerda e direita fazendo um:

select top 26 * from DeckOfCards order by CardNumber desc
union all
select top 26 * from DeckOfCards order by CardNumber asc

Seria uma divisão equilibrada.

Mas como eu poderia fazer com que o SQL Server entrelaçasse os resultados retornados, como se eu tivesse pegado as duas partes dessa união, uma metade na mão esquerda e a outra na direita, e as embaralhasse uma vez como um baralho?

Ou seja: CardNumber 52, seguido de 1, na seguinte sequência: 52, 1, 51, 2, 50, 3, 49, 4, etc...

Esta não é uma questão de lição de casa, apenas uma daquelas coisas que passam pela minha cabeça quando tento fechar os olhos. :)

Eu tenho um problema em que um sistema de replicação orientado por software falhará ao replicar totalmente quando o banco de dados principal estiver sob carga pesada. Por exemplo, se executarmos um sproc 500 vezes, talvez 450 realmente permaneçam. MAS apenas quando estamos sob carga louca de banco de dados (um exemplo são os administradores de SAN atualizando o firmware durante o horário comercial). Estou preocupado em criar transações para cada mensagem e aguardar o tempo limite e a reversão, pois existe a possibilidade de o servidor SQL de destino estar na WAN em outro datacenter.

Pergunta: Eu quero destruir meu servidor DEV SQL com tanta força para replicar esperas massivas de bloqueio/cxpacket no desenvolvimento. Mas não o suficiente para bloquear totalmente todo o acesso por horas, apenas talvez para simular a perda de pacotes.

Cenário: o servidor B (máquina utilitária) possui uma instância SQL Express local. É usado para dados transitórios. Ele dispara uma série de sprocs no banco de dados de destino para inserir novas linhas e, em seguida, insere novas linhas em tabelas filhas vinculadas por PKs. Assim por diante e assim por diante.

Normalmente funciona muito bem. Exceto que os DBAs de produção não permitem que os especialistas no assunto deste sistema tenham qualquer controle ou visibilidade das estatísticas de bloqueio. Tenho controle total e posso traçar o perfil do sistema que está propagando dados para o destino, mas nenhuma análise sobre o que acontece na outra ponta, além de esperar... esperar... esperar... Estou bloqueado? Eu não sei!

Quero simular isso no laboratório e tentar ajustar os sprocs que são usados. Estou pensando em uma atualização de pulsação anx atualização xp_cmdshell para uma tabela de contabilidade e também usando análise de ping usando xp_cmdshell para consultar / refinar / ajustar transações e reverter transações, se necessário, caso todas não sejam confirmadas. Em seguida, tente novamente, talvez em outro host distribuído.

Problema: A última vez que isso aconteceu foi devido ao fato de que o TEMPDB era ENORME (tabelas temporárias massivas sendo utilizadas) e precisava paginar. Os DBA's disseram que não havia nada de errado, mas também relataram comprimentos de fila de disco acima de 50+ por horas a fio. Tem que amar isto.

Eu tenho uma tabela de cerca de 350m de linhas em um servidor vinculado no qual adicionei uma coluna INT adicional para servir como uma contagem (external_identification) de registros como resultado de uma junção em PACKAGE e DOC2. Como as tabelas são muito grandes, gostaria de processar a atualização em lotes, para poder avaliar o progresso e evitar a criação de tabelas temporárias enormes. Cada coluna é indexada.

Este seria um bom exemplo em que um CTE entra em jogo? Honestamente, eles me confundem com a maneira como precisam ser escritos, é difícil de visualizar...

As tabelas são estruturadas como:

ServerA (servidor SQL utilitário)
Tabela: CLIP_IDs
Colunas: Package_UUID nvarchar(255), MessageExtractState tinyint, [count] int (350m linhas)

ServerB (principal servidor de banco de dados)
Tabela: PACKAGE
Colunas: Package_UUID nvarchar(255), Package_id bigint (650m linhas)
Tabela: DOC2
Colunas: External_Identification nvarchar(255), Package_id bigint (2b linhas)

Ambos os servidores SQL estão vinculados nos dois sentidos, se iniciar a consulta de um for mais eficiente. Tenho a sensação de que emitir a consulta do ServerA será, pois parece que o plano de execução oferece menos consultas remotas.

Interrompi a consulta abaixo após 26 horas porque acho que tenho um erro de lógica de sintaxe . Alguém pode explicar o que é e oferecer alguma sugestão, por favor?

Executado do ServidorA:

DECLARE @rowsUpdated INT

SET @rowsUpdated = 1

WHILE (@rowsUpdated > 0)
BEGIN
    UPDATE CLIP_IDs
    SET [Count] = x.[count]
    FROM (
        SELECT TOP 50000 c.package_uuid
            ,count(d.external_identification) AS [count]
        FROM CLIP_IDs c
        INNER JOIN ServerB.DATABASE.dbo.package p(NOLOCK) ON c.package_uuid = p.package_uuid
        INNER JOIN ServerB.DATABASE.dbo.doc2 d(NOLOCK) ON p.package_id = d.package_id
        WHERE c.messageextractstate = 1
            AND c.[count] IS NULL
        GROUP BY c.package_uuid
        ) x

    SET @rowsUpdated = @@rowcount

    PRINT N'Finished set of rows: ' + convert(VARCHAR, getdate(), 120)
END

Criei a seguinte consulta do SQL Server, mas ela está encontrando o defeito de junção anti-semi no SQL Server 2005, que resulta em estimativas de cardinalidade imprecisas (1 -- urgh!) e é executado para sempre. Como é um SQL Server de produção de longa data, não posso sugerir facilmente a atualização de versões e, como tal, não posso forçar a dica traceflag 4199 nessa consulta específica.

Estou tendo dificuldade em refatorar o arquivo WHERE AND NOT IN (SELECT). Alguém pode se importar em ajudar? Certifiquei-me de tentar usar as melhores junções com base em pares de chaves em cluster.

SELECT TOP 5000 d.doc2_id
    ,d.direction_cd
    ,a.address_type_cd
    ,d.external_identification
    ,s.hash_value
    ,d.publishdate
    ,d.sender_address_id AS [D2 Sender_Address_id]
    ,a.address_id AS [A Address_ID]
    ,d.message_size
    ,d.subject
    ,emi.employee_id
FROM assentor.emcsdbuser.doc2 d(NOLOCK)
INNER JOIN assentor.emcsdbuser.employee_msg_index emi(NOLOCK)
    ON d.processdate = emi.processdate
    AND d.doc2_id = emi.doc2_id
INNER LOOP JOIN assentor.emcsdbuser.doc2_address a(NOLOCK)
    ON emi.doc2_id = a.doc2_id
    AND emi.address_type_cd = a.address_type_cd
    AND emi.address_id = a.address_id
INNER JOIN sis.dbo.sis s(NOLOCK) ON d.external_identification = s.external_identification
WHERE d.publishdate > '2008-01-01'
    **AND d.doc2_id NOT IN (
        SELECT doc2_id
        FROM assentor.emcsdbuser.doc2_address d2a(NOLOCK)
        WHERE d.doc2_id = d2a.doc2_id
            AND d2a.address_type_cd = 'FRM'
        )**
OPTION (FAST 10)

Observe que a Employee_MSG_Indextabela tem 500m de linhas, doc21,5b de linhas, SIS~500m de linhas.

Qualquer ajuda seria apreciada!