NReilingh's questions

TL;DR: Ao se conectar ao meu contêiner SQL Server Docker por meio de um nome que resolve para o loopback IPv6 ( ::1), as chamadas SMO são muito lentas. Ao usar 127.0.0.1, eles são rápidos.

Estou tentando aprender a usar a imagem do Docker microsoft/mssql-server-windows-developer . De acordo com a documentação da Microsoft, esse contêiner expõe apenas a porta 1433 TCP.

docker run -d -p 1433:1433 -e sa_password=Passw0rd! -e ACCEPT_EULA=Y -v C:\dockerdb:C:\dockerdb microsoft/mssql-server-windows-developer

Estou executando o contêiner no Windows 10 e consegui iniciá-lo com êxito, autenticando com autenticação do SQL Server e executando consultas na instância usando sqlcmd e SSMS 17.4 no host do Windows (conectando-se ao localhost ou “.”) e SQL Operations Studio em um mac ao lado conectando por IP. Não vejo problemas de desempenho perceptíveis ao executar consultas dessa maneira.

No SSMS, também posso navegar no explorador de objetos, mas se eu tentar fazer algo no menu do botão direito em um objeto no explorador de objetos, como abrir a janela de parâmetros de instância ou anexar um banco de dados, o SSMS não mostra uma resposta por cerca de 5 -10 minutos, momento em que exibe a janela que solicitei ou exibe esta mensagem de erro:

Também estou tentando fazer alguns scripts do PowerShell nessa instância usando o objeto SMO Scripter e vejo o mesmo tipo de comportamento. O script PS faz um loop pelos objetos no banco de dados e os scripts para arquivo e, embora trabalhe para reunir a lista de objetos de forma relativamente rápida, cada objeto individual leva de 5 a 10 minutos para o script - muito lento para ser usado.

Eu tenho um palpite de que a única porta exposta não é suficiente e que o SMO e o SSMS estão tentando se conectar de uma maneira semelhante que os está desacelerando. Também pode ser que, ao se conectar ao localhost, essas ferramentas suponham que haja outros canais de comunicação presentes que normalmente não seriam protegidos por firewall? Existem parâmetros de conexão adicionais que eu poderia estar usando? Alguém pode validar minha suposição de que o SSMS está usando o SMO ou outra coisa para falar com o SQL Server?

ATUALIZAÇÃO: ainda estou investigando, mas é plausível que este seja um problema do Docker em torno de restrições de recursos. Isso é confuso porque a maior parte da documentação parece indicar que os contêineres do Windows não têm restrições de recursos padrão (e não podem ser definidas na GUI do Docker para Windows — apenas para contêineres do Linux ), mas parece que, na realidade, o Windows contêineres em execução no Windows 10 obtêm uma alocação de RAM padrão de 1 GB. Ainda estou tentando descobrir como inspecionar um contêiner em execução para ver sua alocação de RAM e CPU, mas em seguida tenho que tentar aumentá-los de quaisquer que sejam os padrões, usando docker runparâmetros.

ATUALIZAÇÃO ADICIONAL: Não estou conseguindo obter nenhum tipo de métrica confiável do docker que me diga quais limites de CPU e memória ele possui para o contêiner. Pesquisas variadas indicam que os contêineres do docker não têm um limite de memória por padrão, ou têm e são 1 GB, mas tudo o que posso verificar no momento é que docker statso contêiner SQL está usando apenas entre 750 e 850 meg, e quando Eu tento adicionar um parâmetro de execução para definir a memória disponível para 4 gb, dá erro. Então parei de seguir esse segmento de consulta e fui para uma verificação de intestino diferente: entrar em uma sessão interativa do powershell no contêiner em execução e, em seguida, invocar meu script do powershell vinculado acima de dentro do contêiner.

Rodando dentro do container não houve problema. Ele atravessou 2780 objetos em apenas alguns minutos. Acho que isso confirma que o problema está no limite do contêiner/host, então vou ver se consigo abrir essa porta UDP. ATUALIZAÇÃO: Abrir a porta 1434 UDP não ajudou.

MAIS ATUALIZAÇÕES - Solução alternativa alcançada, não é um problema de restrição de recursos: parece haver problemas relacionados à configuração de grandes alocações de memória para contêineres do Windows - eu estava recebendo erros semelhantes para 3g e 2g, mas finalmente consegui iniciar o contêiner com 1,5g e Eu vi uma diferença no docker statscontêiner que (eu acho) confirma que estava sendo executado com uma alocação padrão de 1 GB. Nas configurações padrão, a estatística PRIV WORKING SET (para a qual não consigo encontrar nenhuma documentação, mas meu melhor palpite é que é RAM) está entre 700MiB e 850MiB. Comdocker run —memory="1.5g"definido, é em torno de 1.0GiB. Então, ele se expandiu, mas parece estar deixando mais alocação livre do que antes. Eu interpreto isso (talvez incorretamente) como significando que este servidor (que está executando absolutamente NENHUMA carga e NÃO possui bancos de dados de usuários) não está sob pressão de memória. Verifiquei a configuração de memória máxima do servidor para confirmar que ela está definida no máximo padrão de 2PiB.

Então as coisas ficaram estranhas. Ainda estou testando as coisas executando meu script powershell de vários locais. Rápido dentro do container, lento no host. Então eu fiz RDP para outra máquina Windows na rede e executei o script dessa máquina, conectando-me ao meu host Windows 10 por IP. E foi RÁPIDO! Isso parece apoiar a teoria de que, ao se conectar a algo que deveria ser localhost, o SMO está tentando se conectar ao SQL Server usando algo diferente da porta 1433 TCP, que aguarda um tempo limite muito longo antes de retornar à conexão TCP.

Decidi tentar validar essa teoria inserindo uma entrada de arquivo hosts para se referir a localhost por um nome diferente de localhost:

        127.0.0.1       dockersucks

Eu me conectei no SSMS a dockersucks em vez de localhost ou ".", e imediatamente as coisas ficaram mais rápidas. A navegação no explorador de objetos foi como de costume, e a abertura de painéis como anexar banco de dados ou propriedades do servidor aconteceu tão rapidamente quanto o normal. E, quando executei meu script powershell do host do Windows 10 usando esse alias como nome do servidor, também foi rápido.

Adicionei essa atualização à pergunta em vez de uma resposta, pois ainda estou procurando uma explicação de por que isso está ocorrendo e se há uma maneira de corrigi-la para conexões com "localhost" com esse nome.

Considere o seguinte:

CREATE PROCEDURE dbo.usp_trantest AS
SELECT @@TRANCOUNT as trancount;
GO

Quando eu chamo usp_trantestmanualmente de dentro do SSMS, o trancount é 0. Se eu executar um relatório do SSRS que contém um conjunto de dados que consulta o mesmo procedimento armazenado, o trancount é registrado como 1.

Fazer um rastreamento T-SQL do método SSRS mostra um evento de rastreamento para a chamada do procedimento armazenado que é idêntico ao que fiz do SSMS.

Existe algum comportamento que pode mudar com base no contexto do SSRS? Tipo, uma transação implícita sendo aberta para a chamada sql dinâmica ou algo assim, ou SSRS criando um contexto de transação fora do T-SQL?

Editar:

Em uma resposta agora excluída de alguém (obrigado, estranho!), Foi sugerido que o conjunto de dados do relatório SSRS pode ter marcado "Usar transação única ao processar as consultas". Este foi realmente o caso!

Fiz mais alguns testes e, com essa configuração desmarcada, @@TRANCOUNTé a mesma execução no SSMS ou em um relatório do SSRS.

Portanto, podemos concluir que essa configuração da fonte de dados faz com que o relatório do SSRS crie um contexto de transação no banco de dados antes de executar as consultas. Como essa transação extra não aparece no rastreamento T-SQL, provavelmente podemos assumir que ela está sendo aberta usando um método API, em vez de uma instrução T-SQL.

Estou tentando escrever uma consulta que retorna uma linha da tabela A sempre que uma coluna na tabela unida B contém vários valores distintos para uma única linha correspondente na tabela A. (A -> B é um relacionamento 1 -> muitos.) Eu construí um violino SQL para demonstrar isso no contexto: http://sqlfiddle.com/#!6/83952/1

Neste violino, a designcoluna da perf_ticket_typetabela deve ser a mesma para todas as ticket_typeque possuem o mesmo perf_id, mas estou tentando selecionar apenas as instâncias em que isso não ocorre. Portanto, para perf_id3, há mais de um único designsendo retornado com a consulta que estou usando atualmente.

O que eu quero como resultado são as duas colunas da performancetabela apenas para perf_id3, com base nos múltiplos valores de designpara isso perf_idna tabela unida.

Fiquei frustrado por entender o GROUP BY no passado, então não tenho certeza se há algo diferente que eu poderia fazer aqui para obter o resultado desejado. No momento, acho que posso selecionar o que tenho no violino em uma tabela temporária e, em seguida, fazer outra seleção com a paraGROUP BY perf_id HAVING COUNT(*) > 1 obter o que quero (conforme as linhas selecionadas em que a coluna contém os mesmos dados em mais de um registro ), mas isso parece ser um passo extra.

Eu gostaria de poder verificar facilmente quais identificadores únicos não existem em uma tabela, daqueles fornecidos em uma consulta.

Para explicar melhor, eis o que eu faria agora, para verificar quais IDs da lista "1, 2, 3, 4" não existem em uma tabela:

1. SELECT * FROM dbo."TABLE" WHERE "ID" IN ('1','2','3','4'), digamos que a tabela não contém nenhuma linha com ID 2.
2. Despeje os resultados no Excel
3. Execute um PROCV na lista original que procura cada valor de lista na lista de resultados.
4. Qualquer PROCV que resulte em um #N/Aestá em um valor que não ocorreu na tabela.

Estou pensando que deve haver uma maneira melhor de fazer isso. Estou procurando, idealmente, por algo como

Lista para verificar -> Consulta na tabela para verificar -> Membros da lista não estão na tabela

Estou trabalhando em uma consulta SQL que reúne o histórico do cliente com base em compras anteriores (o setor é a venda de ingressos). O relatório será GRANDE, algo como 80-90 colunas, com uma coluna por evento ou categoria de evento por registro no CSV de saída.

A estrutura do banco de dados exige que eu use instruções de seleção aninhadas para obter os dados necessários em colunas para cada registro--cada coluna contendo uma quantidade de ingressos para esse tipo de evento. Eu sei como fazer isso em teoria, mas cada instrução de seleção incorporada é tão grande que o relatório completo ultrapassaria o limite de 8.000 caracteres na minha interface de banco de dados. Uma dessas declarações se parece com isso:

(select count (*)
FROM
guest ig, event2 e, eventseat es, "order" o
WHERE ig.guestid = g.guestid
and ig.guestid = o.guestid
and o.orderid = es.orderid
and e.eventid = es.eventid
and e.incometype = 'T'
and e.eventtype in ('SS', 'BMF')
and es.status in ('2','4')
and es.price <> '0.00'
and es.price <> '5.00'
and e.year = '2010'       <-- THESE LINES ARE THE ONLY ONES THAT 
and e.run in ('SS-DANCE') <-- CHANGE PER SELECT STATEMENT 
) as 'SS-Dance',

São cerca de 400 caracteres, o que deixa espaço suficiente para menos de 20 iterações em uma única consulta sem ultrapassar o limite de caracteres.

Existe uma maneira de reduzir isso ou generalizá-lo para que eu não precise desperdiçar todos esses caracteres com informações duplicadas em cada SELECT?

Montei um exemplo no link a seguir que contém uma versão simplificada da minha estrutura de banco de dados e alguns dados de amostra. O objetivo é obter os mesmos dados de resultado sem usar tantos caracteres por SELECT aninhado.

http://sqlfiddle.com/#!3/fc316/2

Ok, como você provavelmente pode ver na última parte do título, esta não é uma situação ideal.

Estou usando um software de interface da Web específico do setor do qual garanto que ninguém nunca ouviu falar e, embora a funcionalidade que ele oferece para fazer entrada de dados em massa seja escassa, ele me permite executar consultas SQL diretamente em seu subjacente Banco de dados MS SQL por meio de um formulário da Web limitado a 8.000 caracteres. Esse é o acesso mais direto que tenho ao banco de dados.

Preciso atualizar um determinado campo em cerca de 3.700 registros com dados exclusivos para cada um. De acordo com esta resposta , eu tenho feito o seguinte:

UPDATE guest
  SET info4 = CASE guestid
    WHEN 12345 THEN 'BNID: 917546553'
    WHEN 67890 THEN 'BNID: B04695465'
    [etc, etc.]
    ELSE info4
  END

(No momento, o info4campo está vazio para todos os registros.) Posso encaixar cerca de 200 casos em uma consulta antes de atingir o limite de caracteres e ter que executar uma nova atualização com o próximo bloco de dados.

Coisas que descobri até agora:

• Não incluir a ELSEdeclaração no final esvaziará o campo em todos os registros que não atendem a um caso.
• Antes de confirmar, recebo "Linhas afetadas: [# de linhas na tabela]" em vez do número de linhas que realmente obterão novos dados.

Entendo que deveria colocar um WHERE guestid IN (12345, 67890)no final para evitar executar a atualização em todas as linhas, mas será um inferno evitar ultrapassar meu limite de caracteres com cada pedaço da instrução de atualização.

Por acaso, atualmente estou pegando meus dados de origem de uma planilha do Excel, colando tudo no Notepad ++, executando localizar/substituir nele para inserir a sintaxe SQL necessária e, em seguida, dividi-los de acordo com o limite de caracteres.

Então, em poucas palavras, minha pergunta é: eu explorei isso na medida do possível? Há algo grande e óbvio que estou perdendo, ou devo abordar isso de uma maneira completamente diferente? Pontos de bônus para menos caracteres por caso!