John Eisbrener's questions

Estou executando um SQL Server 2017 Enterprise no local no nível de patch/CU mais recente que dá suporte ao software do fornecedor, que se tornará importante mais tarde.

Estatísticas do servidor:

• Máquina virtual (a memória está fixada )
• Datacenter do Windows Server 2016
• 16 vCPU
• 192 GB de RAM (179 GB alocados ao SQL Server)
• Arquivo de página de 30 GB (prefiro que isso não esteja lá, mas não foi uma batalha que ganhei)
• Hospeda 5 bancos de dados de usuários, 1 dos quais tem aproximadamente 4 TB de tamanho
• Servidor Obrigatório do Fornecedor Padrão de 1 paramax degree of parallelism

Como dito acima, este sistema suporta uma plataforma de fornecedor popular e, embora o fornecedor seja muito bom sobre índices personalizados ou outros ajustes de modelo de dados transparentes, eles tendem a desaprovar alterações de funcionalidade que exigem ajustes em seu código de aplicativo (por razões óbvias, pois afetaria milhares de seus clientes).

A situação que estou enfrentando é que esse aplicativo de fornecedor executa row modeconsultas de longa duração que enfileiram uma lista de itens que são processados ​​item por item em seu código de aplicativo. Essas consultas podem (e funcionam) ser executadas por dias ou até semanas se as permitirmos (mostrando ASYNC_NETWORK_IOesperas, como esperado). Quando essas consultas são iniciadas, elas solicitam grandes quantidades SerialDesiredMemoryem comparação com o SerialRequiredMemoryque realmente precisam. O resultado é que a Memória Solicitada/Concedida no administrador de MEMORYCLERK_SQLQERESERVATIONSmemória excede em muito o que é Usado. Por exemplo:

-- What amount of query execution memory is asked for and used
SELECT    SUM(granted_memory_kb) / 1024 AS granted_memory_mb
        , SUM(requested_memory_kb) / 1024 AS requested_memory_mb
        , SUM(used_memory_kb) / 1024 AS used_memory_mb
        , (SUM(granted_memory_kb) - SUM(used_memory_kb)) / 1024 AS excess_memory_grant_mb
FROM    sys.dm_exec_query_memory_grants
OPTION (RECOMPILE)

Devoluções:

Isso é absolutamente aterrorizante E isso ocorre depois de habilitar RESOURCE GOVERNORe reduzir o REQUEST_MAX_MEMORY_GRANT_PERCENTpool de recursos em que essas consultas caem para 5%, embora eu provavelmente reduza isso até o mínimo de 1% do SQL 2017 com base no que estou vendo.

Minha pergunta é enquanto estou preso no SQL 2017, há mais alguma coisa que eu possa fazer para limitar a quantidade de RAM desperdiçada em meus planos de execução de consulta, além de reduzir ainda mais o REQUEST_MAX_MEMORY_GRANT_PERCENTvalor do pool de recursos para 1%?

Como este é um aplicativo de fornecedor, os guias de plano de consulta podem ser uma opção, mas o ajuste MAX_GRANT_PERCENTnão me dá nada além do que estou obtendo ao ajustar o REQUEST_MAX_MEMORY_GRANT_PERCENTvalor no pool de recursos. Existe algo que eu possa fazer em um guia de plano para forçar a batch modeexecução na esperança de que isso acione o recurso de feedback de memória do modo de lote que está disponível no SQL 2017? Novamente, como este é o código do aplicativo do fornecedor com o qual estou trabalhando, não tenho a capacidade de alterar as consultas, portanto, as abordagens padrão de tolice provavelmente não funcionarão aqui.

Atualizar para o SQL 2019 (ou preferencialmente SQL 2022) é a resposta óbvia aqui, pois me dá acesso a vários recursos que posso empregar nessa situação, como Row Mode Memory Feedback e valores de ponto flutuante paraREQUEST_MAX_MEMORY_GRANT_PERCENT , mas existem outras opções disponíveis com o SQL 2017 que ainda não toquei? Se não, tudo bem, estou apenas tentando esgotar todas as opções pendentes que ainda não pensei.

Atualmente, estou trabalhando em um ambiente que exige que habilitemos o SQL Server Audit , em toda a empresa. Geramos .sqlauditarquivos pois temos diretrizes de retenção e acesso, e estou descobrindo que precisamos compilar informações de tendências sobre os arquivos gerados, como número criado por hora, volume total de informações de auditoria, etc. de DMVs/DMFs que fornecem informações de definição de auditoria (a lista pode ser encontrada aqui ), mas nada relacionado à saída do processo de Auditoria do SQL Server.

Atualmente, estou executando scripts do PowerShell para coletar essas informações dos metadados dos .sqlauditarquivos, mas prefiro não depender de um processo externo, se possível. Eu examinei procedimentos armazenados estendidos, como xp_dirtree, mas isso só retorna o número de arquivos e não as informações de tamanho, portanto, não fornece uma imagem tão completa quanto eu preciso aqui. xp_cmdshell, embora viável, não é permitido por motivos óbvios de segurança e porque a conformidade com o NIST proíbe explicitamente seu uso. Existem abordagens dentro do mecanismo de banco de dados (estou perguntando sobre coisas que posso atingir com o TSQL) onde posso obter essas informações, como um evento estendido ou DMV oculto que ainda não encontrei? Sinto que fiz uma extensa pesquisa, mas nunca me surpreendo se perder alguma coisa.

Eu tenho uma configuração de AG de 4 nós da seguinte forma:

Configuração de hardware de VM de todos os nós:

• Microsoft SQL Server 2017 Enterprise Edition (RTM-CU14) (KB4484710)
• 16 vCPUs
• 356 GB de RAM (longa história para este...)
• grau máximo de paralelismo: 1 (conforme exigido pelo fornecedor do aplicativo)
• limite de custo para paralelismo: 50
• memória máxima do servidor (MB): 338944 (331 GB)

Configuração AG:

• Nó 1: Secundário não legível de confirmação primária ou síncrona, configurado para failover automático
• Nó 2: Secundário não legível de confirmação primária ou síncrona, configurado para failover automático
• Nó 3: Conjunto secundário legível com confirmação assíncrona, configurado para failover manual
• Nó 4: Conjunto secundário legível com confirmação assíncrona, configurado para failover manual

A consulta em questão:

Não há nada de muito louco nessa consulta, ela fornece um resumo dos itens de trabalho pendentes em várias filas dentro do aplicativo. Você pode ver o código em um dos links do plano de execução abaixo.

Comportamento de execução no nó primário:

Quando executado no nó Primário, o tempo de execução é geralmente em torno da marca de 1 segundo. Aqui está o plano de execução e abaixo estão as estatísticas capturadas de STATISTICS IO e STATISTICS TIME do nó primário:

(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 500 ms,  elapsed time = 656 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

Comportamento de execução no nó secundário somente leitura:

Ao executar em um nó secundário somente leitura (ou seja, nó 3 ou nó 4), esta consulta usa o mesmo plano de execução (este é um link de plano diferente) e aproximadamente as mesmas estatísticas de execução são mostradas (por exemplo, pode haver mais algumas páginas verificações, pois esses resultados estão sempre mudando), mas com exceção do tempo de CPU, eles são muito semelhantes. Aqui estão as estatísticas capturadas de STATISTICS IO e STATISTICS TIME do nó secundário somente leitura:

(347 rows affected)
Table 'Worktable'. Scan count 647, logical reads 2491, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'workitemlc'. Scan count 300, logical reads 7125, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Workfile'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulertask'. Scan count 1, logical reads 29, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'wfschedulertask'. Scan count 1, logical reads 9, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerservice'. Scan count 1, logical reads 12, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'schedulerworkerpool'. Scan count 1, logical reads 3, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'itemlc'. Scan count 1, logical reads 26372, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

(1 row affected)

 SQL Server Execution Times:
   CPU time = 55719 ms,  elapsed time = 56335 ms.
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

Outros detalhes:

Também executei o script sp_WhoIsActivede Paul RandalWaitingTasks.sql no secundário enquanto essa consulta está sendo executada, mas não vejo nenhuma espera ocorrendo, o que é francamente frustrante:

Isso também não parece ser um caso de latência de AG, pois o status de sincronização é realmente muito bom:

--https://sqlperformance.com/2015/08/monitoring/availability-group-replica-sync

SELECT 
       ar.replica_server_name, 
       adc.database_name, 
       ag.name AS ag_name, 
       drs.is_local, 
       drs.synchronization_state_desc, 
       drs.synchronization_health_desc, 
       --drs.last_hardened_lsn, 
       --drs.last_hardened_time, 
       drs.last_redone_time, 
       drs.redo_queue_size, 
       drs.redo_rate, 
       (drs.redo_queue_size / drs.redo_rate) / 60.0 AS est_redo_completion_time_min,
       drs.last_commit_lsn, 
       drs.last_commit_time
FROM sys.dm_hadr_database_replica_states AS drs
INNER JOIN sys.availability_databases_cluster AS adc 
       ON drs.group_id = adc.group_id AND 
       drs.group_database_id = adc.group_database_id
INNER JOIN sys.availability_groups AS ag
       ON ag.group_id = drs.group_id
INNER JOIN sys.availability_replicas AS ar 
       ON drs.group_id = ar.group_id AND 
       drs.replica_id = ar.replica_id
ORDER BY 
       ag.name, 
       ar.replica_server_name, 
       adc.database_name;

Esta consulta parece ser o pior ofensor. Outras consultas que também levam menos de um segundo no nó primário podem levar de 1 a 5 segundos no nó secundário e, embora o comportamento não seja tão grave, parece estar causando problemas.

Por fim, também examinei os servidores e verifiquei processos externos, como varreduras de A/V, trabalhos externos gerando E/S inesperadas, etc. e cheguei de mãos vazias. Não acho que isso esteja sendo causado por algo fora do processo do SQL Server.

A questão:

É apenas meio-dia onde estou e já foi um longo dia, então suspeito que estou perdendo algo óbvio aqui. Ou isso ou temos algo mal configurado, o que é possível, pois tivemos várias chamadas para o fornecedor e MS relacionadas a esse ambiente.

Para toda a minha investigação, eu simplesmente não consigo encontrar o que está causando essa diferença no desempenho. Eu esperaria ver algum tipo de espera ocorrendo nos nós secundários, mas nada. Como posso solucionar ainda mais isso para identificar a causa raiz? Alguém já viu esse comportamento antes e encontrou uma maneira de resolvê-lo?

ATUALIZAÇÃO #1 Depois de trocar os estados do terceiro nó (uma das réplicas somente leitura) para não legível e depois de volta para legível como um teste, essa réplica ainda está sendo mantida por uma transação aberta, com todas as consultas do cliente exibindo o HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONINGesperar.

A execução de um DBCC OPENTRANcomando produz os seguintes resultados:

Oldest active transaction:
    SPID (server process ID): 420s
    UID (user ID) : -1
    Name          : QDS nested transaction
    LSN           : (941189:33148:8)
    Start time    : May  7 2019 12:54:06:753PM
    SID           : 0x0
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Ao pesquisar este SPID em sp_who2, ele o mostra como um BACKGROUNDprocesso QUERY STORE BACKlistado como o comando.

Embora possamos fazer backups do TLog, suspeito que estamos enfrentando uma funcionalidade semelhante a esse bug resolvido , então pretendo abrir um tíquete com a MS sobre esse problema específico hoje.

Dependendo do resultado desse ticket, tentarei capturar um rastreamento de pilha de chamadas de acordo com a sugestão de Joe e ver para onde vamos.

Atualização final (problema resolvido automaticamente)

Depois de eclipsar a marca de 52 horas da transação do Query Store sendo aberta (conforme identificado acima), o AG decidiu fazer o failover automaticamente. Antes que isso acontecesse, eu puxei algumas métricas adicionais. Por este link , fornecido por Sean, o banco de dados em questão tinha um armazenamento de versão muito grande dedicado a este banco de dados, especificamente em um ponto eu havia registrado 1651360 páginas no reserved_page_countcampo e 13210880 para o reserved_space_kbvalor.

De acordo com os ERRORLOGs, o failover ocorreu após um dilúvio de 5 minutos de falhas de proteção de transações relacionadas a QDS base transactione QDS nested transactiontransações.

O failover causou uma interrupção de cerca de 10 minutos no meu caso. O banco de dados tem ~6 TB de tamanho e é muito ativo, então isso foi realmente muito bom na minha opinião. Enquanto o novo nó primário estava online durante esse período, nenhuma consulta de cliente pôde ser concluída, pois todos estavam aguardando o QDS_LOADDBtipo de espera.

Após o failover, os números de armazenamento de versão foram reduzidos para 176 reserved_page_counte 1408 para reserved_space_kb. As consultas nas réplicas somente leitura secundárias também começaram a ser executadas tão rapidamente quanto se fossem executadas a partir do primário, portanto, parece que o comportamento desapareceu completamente, como resultado do failover.

Estou executando o Microsoft SQL Server 2016 SP2-CU6 (13.0.5292.0) em uma VM de 4 vCPU com max degree of parallelismdefinido como 2e cost threshold for parallelismdefinido como 50.

De manhã, ao tentar exibir um Plano de Execução Estimado para uma consulta SELECT TOP 100, tenho grandes esperas e a operação para renderizar o plano estimado leva minutos, geralmente na faixa de 5 a 7 minutos. Novamente, esta não é a execução real da consulta, este é apenas o processo para exibir um Plano de Execução Estimado .

sp_WhoIsActivemostrará PAGEIOLATCH_SHesperas ou LATCH_EX [ACCESS_METHODS_DATASET_PARENT]esperas e quando executo o script WaitingTasks.sql de Paul Randal durante a operação, ele mostra CXPACKETesperas com os threads de trabalho mostrando PAGEIOLATCH_SHesperas:

*campo de descrição do recurso =exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen

Os threads de trabalho parecem estar trazendo a statstabela inteira para a memória (como os números de página, bem como os números de página subsequentes mostrados do ponto de consulta de Paul Randal de volta à chave agrupada da statstabela). Uma vez que o plano volta, é basicamente instantâneo pelo resto do dia, mesmo depois de ver a maior parte do statsatrito da tabela do cache com apenas vários registros restantes (que suponho que foram puxados devido a operações de busca de consultas semelhantes).

Eu esperaria esse comportamento inicial se a consulta estivesse realmente sendo executada com um plano que usasse operadores SCAN, mas por que está fazendo isso ao avaliar planos de execução apenas para chegar a um operador SEEK, conforme mostrado no plano vinculado acima? O que posso fazer (além de executar esta declaração antes do horário comercial para que meus dados sejam armazenados em cache adequadamente) para ajudar a melhorar o desempenho aqui? Estou assumindo que um par de índices de cobertura seria benéfico, mas eles realmente garantiriam alguma mudança no comportamento? Eu tenho que trabalhar com algumas limitações da janela de armazenamento e manutenção aqui, e a consulta em si é gerada a partir de uma solução de fornecedor, portanto, quaisquer outras sugestões (além de uma melhor indexação) seriam bem-vindas neste momento.

TL\DR

Estou procurando uma maneira de identificar com eficiência o objeto localizado mais próximo do final de um arquivo de dados do SQL Server . Essa abordagem precisa manter o desempenho em relação a arquivos de dados grandes.

O que eu tenho até agora

A consulta a seguir utiliza uma Função de Gerenciamento Dinâmico não documentada fornecida com o SQL 2012: sys.dm_db_database_page_allocations; este DMF fornece um equivalente aproximado do DBCC INDcomando.

A consulta a seguir identifica o último objeto em um determinado arquivo de dados ( Aviso: não execute isso em um banco de dados maior que 25 GB, a menos que você queira cancelá-lo em algum momento ):

-- Return object with highest Extent Page ID
SELECT   files.name as logical_file_name
        , files.physical_name as physical_file_name
        , OBJECT_SCHEMA_NAME(object_id) + N'.' + OBJECT_NAME(object_id) AS object_name
        , alloc.*
FROM sys.dm_db_database_page_allocations(DB_ID(), NULL, NULL, NULL, NULL) alloc
    INNER JOIN sys.database_files files
        ON alloc.extent_file_id = files.file_id
WHERE is_allocated = 1
    AND files.name = 'Logical_FileName'
ORDER BY files.name , files.physical_name, extent_page_id DESC

O que há de errado com essa abordagem

Como o Aviso acima indica, essa consulta será executada mais lentamente à medida que o tamanho do banco de dados aumenta porque a função é realmente projetada para uma abordagem direcionada para examinar um objeto específico e não um arquivo de dados específico em questão. Ao passar os NULLparâmetros como eu fiz, essa função provavelmente itera por todos os objetos dentro do banco de dados nos bastidores e cospe a saída combinada. Isso realiza o que eu preciso, mas o faz de uma maneira muito forçada que não se presta a otimizações.

O que estou pedindo

Espero que haja uma maneira de iterar pelas cadeias GAM, SGAM e/ou IAM para identificar rapidamente o objeto no final de um determinado arquivo de dados. Estou assumindo que tenho que empurrar essa abordagem para fora do TSQL para algo como o PowerShell e voltar a usar chamadas DBCC PAGE , ou algo dessa natureza, percorrendo mapas de alocação de página para descobrir qual é o último objeto de um determinado arquivo de dados. ... e espero que alguém já tenha lançado esse código ou conheça essas estruturas e/ou a saída desses procedimentos não documentados melhor do que eu.

Por que eu preciso disso?

Esta é a pergunta inevitável que muitos farão, então vou responder logo de cara. O projeto em que estou trabalhando é para acelerar um sistema legado, mas depois de consolidar várias tabelas de heap (o que foi um pesadelo por outros motivos), agora tenho muito espaço livre nos meus dados arquivos. Eu quero liberar esse espaço de volta para o sistema operacional, no entanto, a abordagem tradicional de migrar objetos para um arquivo de dados diferente não é viável neste estágio porque não tenho espaço livre suficiente para trabalhar no sistema (até que eu capaz de liberar mais espaço deste arquivo de dados).

Recorri a desabilitar o crescimento de arquivos e executar um DBCC SHRINKFILE TRUNCATEONLYcomando todas as noites para liberar todas as páginas abertas no final do arquivo de dados, mas esse é um processo lento e árduo que pode funcionar com tanta frequência quanto não. Espero identificar quais são os objetos no final do arquivo para que eu possa reconstruí-los manualmente e liberar espaço em um cronograma mais rápido.

Em suma

Existe uma maneira de identificar rapidamente o nome do objeto localizado no final de um determinado arquivo de dados? O método que estou empregando agora não está atendendo às minhas necessidades e estou aberto a usar qualquer abordagem disponível.

Tenho certeza de que estou perdendo uma solução óbvia para isso, mas estou tentando resumir valores para grupos definidos por um número de grupo explícito e uma ordenação implícita. Tenho certeza de que isso não torna isso muito mais claro, então digamos que eu tenha esta tabela de heap de origem de exemplo:

GroupID     Value
----------- -----------
1           5
1           5
1           3
2           4
2           1
1           4
2           3
2           5
2           2
1           1

Gostaria de uma consulta que me fornecesse os seguintes resultados:

GroupID     Values
----------- -----------
1           13
2           5
1           4
2           10
1           1

A ordenação implícita é o desafio que eu simplesmente não encontrei uma maneira de contornar... ainda. Qualquer ajuda seria apreciada.

Eu esperava poder criar uma ordem de linha determinística com uma consulta semelhante à seguinte:

SELECT    * 
        , ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS RowNum  
FROM Table WITH(TABLOCK)
OPTION (MAXDOP 1)

Espero que isso force uma varredura de ordem de alocação que me daria uma ordem de linha determinística.

Infelizmente, estou preso com os dados como estão. Não tenho outros indicadores aqui, como data, etc., que forneçam qualquer ordem definida. Minha esperança era que o truque descrito acima fosse suficiente, mas não estou totalmente certo de que será.

EDIT: Apenas para fechar isso, pois sei que havia perguntas sobre por que eu estava perguntando isso, eu tinha uma série de tabelas de heap, nomeadas por mês / ano, que continham valores de itens de linha que a empresa queria resumir por dia (que eles correlacionaram com os grupos implícitos na minha pergunta). Como não parece viável fazer isso de forma eficaz, decidimos agregar no nível do mês (por exemplo, tabela), então este post me ajudou a justificar a alteração nos requisitos de negócios. Obrigado pela contribuição de todos!

Eu tenho um relatório do SQL Server Reporting Services (SSRS) 2012 que é preenchido por meio de procedimento armazenado (SP). O SP retorna vários campos, um dos quais é um tipo de BIGINTdados. Quando executo o relatório do SSRS diretamente, o valor é exibido corretamente, mas quando exporto a saída para o Excel, ele é arredondado para o milésimo mais próximo.

Por exemplo, este é um exemplo do que estou vendo.

O valor adequado:480758225903628660

O valor mostrado no arquivo Excel:480758225903629000

Está arredondando 8660 para 9000 . Verdadeiramente frustrante, e a documentação da Microsoft não menciona nada sobre esse comportamento. Também pesquisei em todos os lugares do relatório que posso pensar que podem afetar isso, como as Propriedades da caixa de texto:

... as propriedades do espaço reservado:

... e o Valor do próprio campo:

Eu posso "consertar" convertendo o campo em uma string envolvendo o valor do campo em uma função CStr()ou.ToString() , mas isso também trata a saída como uma string e não como um número. Existe uma maneira de exportar isso para o Excel para que o arredondamento não ocorra, mas ainda mantenha esse valor numérico?

Suspeito que minhas habilidades no Google sejam insuficientes hoje, mas estou procurando um script TSQL rápido que identificará todos os pacotes SSIS no Package Store que estão usando um determinado nome de variável de ambiente.

Por exemplo, quando configuro um pacote e vejo a página de parâmetros, posso escolher uma determinada variável de ambiente. Na captura de tela a seguir, a variável de ambiente com a qual estou preocupado é denominada SMTP. Eu quero encontrar todos os pacotes usando essa variável de ambiente para que eu possa realizar algumas investigações/testes antes de fazer qualquer alteração em massa .

Se alguém tiver um script prontamente disponível, ficaria grato se você pudesse publicá-lo, caso contrário, postarei algo depois de codificá-lo.

Obrigado!

Estou trabalhando com o seguinte cenário onde tenho dados temporais que se enquadram em ilhas e lacunas . De vez em quando, preciso associar um evento que esteja dentro de uma lacuna existente à ilha mais próxima com base no horário do evento.

Para demonstrar, digamos que eu tenha os seguintes dados definindo meus períodos de tempo:

Esses dados são contíguos, exceto por uma lacuna que existe entre os IDs 2e 7, para o período de tempo 2017-07-26 00:03:00até 2017-07-26 00:07:00.

Para identificar a ilha mais próxima, atualmente estou dividindo a lacuna em dois períodos da seguinte forma:

Se eu tiver um evento que se enquadre nessa lacuna, os GapWindowStart/ Endtimes determinarão com qual ilha eu preciso associar o evento. Então, por exemplo, se eu tivesse um evento que ocorresse em 2017-07-26 00:03:20, eu associaria esse evento a ID 2e, inversamente, se eu tivesse um evento ocorrendo em 2017-07-26 00:05:35eu associaria esse evento a ID 7.

A maneira mais eficiente que consegui codificar minha abordagem, até agora, é montar as lacunas usando a 3ª solução de Itzik Ben-Gan do livro SQL Server MVP Deep Dives por meio da ROW_NUMBERfunção window e, em seguida, dividir as lacunas por uma CROSS APPLYinstrução que atua como uma operação simples UNPIVOT.

Aqui está o plano db<>fiddle da abordagem que estou usando para montar o conjunto de ilhas mais próximo.

Com as ilhas mais próximas identificadas, uso o tempo de evento de um evento para identificar a ilha mais próxima à qual associar esse evento. Como essas ilhas são voláteis ao longo do dia, não posso criar uma tabela mestre estática, mas preciso confiar na construção de tudo em tempo de execução quando os eventos são encontrados.

Aqui está um plano db<>fiddle mostrando qual valor NearestIsland deve ser usado em um evento aleatório.

Existem maneiras melhores de descobrir a ilha mais próxima para um determinado evento que normalmente cairia em uma lacuna? Por exemplo, existe um método mais eficiente para identificar as lacunas ou uma maneira mais eficiente de identificar a ilha mais próxima? Será que estou fazendo isso da melhor maneira lógica? Não há nada crítico sobre essa questão, mas estou sempre tentando descobrir se há uma abordagem "melhor" para as coisas e acho que esse problema se presta a alguma criatividade, então adoraria ver outras opções de desempenho.

O ambiente atual em que estou trabalhando é o SQL 2012, mas estaremos migrando para um ambiente SQL 2016 em breve, então estou aberto a praticamente qualquer coisa.

O código subjacente ao segundo link db<>fiddle é o seguinte:

-- Creation of Test Data
CREATE TABLE #tmp
(
      ID            INT PRIMARY KEY CLUSTERED
    , WindowStart   DATETIME2
    , WindowEnd     DATETIME2
)

-- Create contiguous data set
INSERT INTO #tmp
SELECT    ID
        , DATEADD(HOUR, ID, CAST('0001-01-01' AS DATETIME2))
        , DATEADD(HOUR, ID + 1, CAST('0001-01-01' AS DATETIME2))
FROM
(
    SELECT TOP (1500000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS ID
    --SELECT TOP (87591200) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS ID  -- Swap line with above for larger dataset
    FROM master.sys.configurations t1
    CROSS JOIN master.sys.configurations t2
    CROSS JOIN master.sys.configurations t3
    CROSS JOIN master.sys.configurations t4
    CROSS JOIN master.sys.configurations t5
) x


--DELETE 1000000 random records to create random gaps
DELETE FROM #tmp
WHERE ID IN (
    SELECT TOP 1000000 ID
    --SELECT TOP 77591200 ID -- Swap line with above for larger dataset
    FROM #tmp
    ORDER BY NEWID()
)


-- Create RandomEvent Times
CREATE TABLE #tmpEvent
(
    EventTime DATETIME2
)

INSERT INTO #tmpEvent
SELECT DATEADD(SECOND, X.RandomNum, Y.minWindowEnd) AS EventDate
FROM (VALUES (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))
           , (ABS(CHECKSUM(NEWID())))) AS X(RandomNum)
    CROSS JOIN (SELECT MIN(WindowEnd) AS minWindowEnd FROM #tmp) AS Y


SET STATISTICS XML ON
SET STATISTICS IO ON

--Desired Output Format - Best Execution I've found so far
;WITH rankIslands AS (
    SELECT    ID
            , WindowStart
            , WindowEnd
            , ROW_NUMBER() OVER (ORDER BY WindowStart) AS rnk
    FROM    #tmp
), rankGapsJoined AS (
    SELECT    t1.ID AS NearestIslandID_Lower
            , t1.WindowEnd AS GapStart_Lower
            , DATEADD(MINUTE, (DATEDIFF(MINUTE, t1.WindowEnd, t2.WindowStart) / 2), t1.WindowEnd) AS GapEnd_Lower
            , t2.ID AS NearestIslandID_Higher
            , DATEADD(MINUTE, -1 * (DATEDIFF(MINUTE, t1.WindowEnd, t2.WindowStart) / 2), t2.WindowStart) AS GapStart_Higher
            , t2.WindowStart AS GapEnd_Higher
    FROM rankIslands t1 INNER JOIN rankIslands t2
        ON t1.rnk + 1 = t2.rnk
            AND t1.WindowEnd <> t2.WindowStart
), NearestIsland AS (
    SELECT  xa.*
    FROM    rankGapsJoined t1
            CROSS APPLY ( VALUES (t1.NearestIslandID_Lower, t1.GapStart_Lower, t1.GapEnd_Lower)
                                ,(t1.NearestIslandID_Higher, t1.GapStart_Higher, t1.GapEnd_Higher) ) AS xa (NearestIslandId, GapStart, GapEnd)
)
-- Only return records that fall into the Gaps
SELECT e.EventTime, ni.*
FROM    #tmpEvent e INNER JOIN NearestIsland ni
                ON e.EventTime > ni.GapStart
                AND e.EventTime <= ni.GapEnd

SET STATISTICS XML OFF
SET STATISTICS IO OFF


DROP TABLE #tmp
DROP TABLE #tmpEvent

Perguntas: (@MaxVernon)

• O resultado desejado é uma tabela contendo as lacunas?

• Ou você está tentando atribuir linhas de entrada ao vizinho mais próximo?

• Ou você está procurando reproduzir a saída exata que você mostra no seu exemplo?

Responda:

Resumindo, sim, sim e não. O resultado desejado é identificar qualquer forma (outra/mais) eficiente de identificar a ilha mais próxima para um tempo de evento que normalmente cairia dentro de um intervalo. Tentei expandir a questão para mostrar qual seria um resultado final desejável.

Como eu estava juntando alguns conjuntos de dados de teste, notei um comportamento engraçado com tabelas temporárias. Ao trabalhar com grandes conjuntos de dados em tabelas temporárias clusterizadas que são preenchidas por meio de um plano de execução paralela, a chave clusterizada não parece ser respeitada ao selecionar os dados. Esse problema também parece afetar todas as versões do SQL Server que testei (incluindo vNext).

Aqui está um exemplo dbfiddle.uk do teste. Você pode ter que executá-lo algumas vezes para obter o resultado que estou encontrando, mas não deve demorar mais de uma ou duas execuções para produzir os mesmos resultados. Além disso, este é o plano de execução local que estou obtendo no meu ambiente, que mostra que a única diferença entre os conjuntos de dados grandes e pequenos é a maneira como os dados são alimentados nas tabelas (por exemplo, plano paralelo versus serial).

Se você quiser jogar em casa, aqui está o teste que estou executando:

-- Large Data Set
CREATE TABLE #tmp
(
    ID  INT PRIMARY KEY CLUSTERED
)

INSERT INTO #tmp
-- Purposely insert in reverse order
SELECT TOP 100 PERCENT RN
FROM
(
    SELECT TOP (10000000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
    FROM master..spt_values t1
    CROSS JOIN master..spt_values t2
) x
ORDER BY RN DESC


-- Smaller Data Set
CREATE TABLE #tmp2
(
    ID  INT PRIMARY KEY CLUSTERED
)

INSERT INTO #tmp2
-- Purposely insert in reverse order
SELECT TOP 100 PERCENT RN
FROM
(
    SELECT TOP (10000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
    FROM master..spt_values t1
    CROSS JOIN master..spt_values t2
) x
ORDER BY RN DESC

-- Large Record Set
-- Clustered Key Not Honored*
SELECT TOP 10 *
FROM #tmp

-- Small Record Set
-- Clustered Key Honored
SELECT TOP 10 *
FROM #tmp2

DROP TABLE #tmp
DROP TABLE #tmp2

Não encontrei nenhuma referência indicando que esse é o comportamento esperado, mas antes de enviar um item de conexão , primeiro queria entrar em contato e confirmar que esse não é um problema localizado. Alguém pode me indicar a documentação que identifica esse comportamento esperado ou, alternativamente, confirmar que isso é, de fato, um bug?

EDIT: Em resposta aos comentários sobre a não inclusão de uma ORDER BYcláusula, eu sempre supunha que a palavra-chave TOP retornasse os dados na ordem em que foram inseridos, que deveria , neste caso, ser a ordem ditada pela chave clusterizada. Ao executar a mesma instrução em uma tabela formal, o comportamento esperado é retornado:

-- Large Data Set with a Formal Data Table
CREATE TABLE tmp
(
    ID  INT PRIMARY KEY CLUSTERED
)

INSERT INTO tmp
-- Purposely insert in reverse order
SELECT TOP 100 PERCENT RN
FROM
(
    SELECT TOP (10000000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
    FROM master..spt_values t1
    CROSS JOIN master..spt_values t2
) x
ORDER BY RN DESC

-- Large Record Set
-- Clustered Key Not Honored*
SELECT TOP 10 *
FROM tmp

DROP TABLE tmp

(6325225 row(s) affected)


(1 row(s) affected)
ID
-----------
1
2
3
4
5
6
7
8
9
10

(10 row(s) affected)



(1 row(s) affected)

Até os planos de execução são os mesmos, então por que os diferentes conjuntos de resultados entre uma tabela temporária e uma tabela formalmente definida?

Finalmente, um salve para Joe Obbish enquanto eu roubei gratuitamente sua abordagem CROSS JOIN para construir grandes conjuntos de dados de teste, pois é bastante eficiente!

Estou usando o SQL Server 2012 Enterprise. Eu me deparei com um SQL Plan que está exibindo algum comportamento que não acho totalmente intuitivo. Após uma operação pesada de Parallel Index Scan, ocorre uma operação de Parallelism (Repartition Streams), mas está matando as estimativas de linha retornadas pelo Index Scan (Object10.Index2), reduzindo a estimativa para 1. Fiz algumas pesquisas, mas não encontrei nada que explique esse comportamento. A consulta é bastante simples, embora cada uma das tabelas contenha registros na casa dos milhões. Isso faz parte de um processo de carregamento DWH e esse conjunto de dados intermediário é tocado algumas vezes, mas a pergunta que tenho está relacionada às estimativas de linha em particular. Alguém pode explicar por que as estimativas de linha precisas vão para 1 dentro do operador de Paralelismo (Strems de Partição)? Também,

Eu postei o plano completo para Colar o Plano .

Aqui está a operação em questão:

Incluindo a Plan Tree no caso de adicionar mais contexto:

Eu poderia estar encontrando alguma variação deste item do Connect arquivado por Paul White (explicação mais detalhada em seu blog aqui )? Pelo menos é a única coisa que encontrei que parece estar remotamente perto do que estou encontrando, embora não haja um operador TOP em jogo.

Obviamente, ver o plano de execução real é um grande problema ao ajustar, e normalmente eu habilito a saída do plano de consulta SET STATISTICS XML ONe executo qualquer consulta que precise de algum TLC, mas como posso ver as contagens de registros reais para execuções históricas de um plano ou para um processo que não posso executar facilmente manualmente (ou simular em um ambiente de teste)?

Quando eu puxo essas informações do cache de consulta por meio de uma sys.dm_exec_query_planou sys.dm_exec_text_query_planapenas as contagens de linhas estimadas são mostradas. O mesmo comportamento existe ao usar o DMV do Repositório de Consultas, sys.query_store_plan. Como todos esses DMVs estão puxando planos reais que foram usados, eu esperaria ver as contagens reais de execução de linha incluídas nas representações gráficas do plano, mas elas não estão lá.

As informações retornadas do sys.dm_exec_query_statsDMV são apenas um pouco úteis, pois retornam contagens totais para a declaração, mas as contagens detalhadas de operadores dentro do plano parecem estar ocultas com planos históricos. Com 2014, conseguimos sys.dm_exec_query_profilesusar o DMV, o que ajuda nos planos que estão sendo executados, mas isso também não ajuda quando olhamos para execuções históricas.

Essas informações estão armazenadas em outro lugar? Devo tratar as contagens de linhas estimadas como números de contagem real (duvido, mas já que estou perguntando...)? Existe um item de conexão solicitando esse recurso que eu possa votar?

Estou tentando entender algum comportamento que estou vendo em um plano de consulta que é bastante grande e indisciplinado. Em particular, estou olhando para uma operação de busca de índice clusterizado contendo uma operação escalar dentro de seu predicado. Suspeito que a operação Scalar seja simplesmente o alias de uma das tabelas (conforme descrito em Scalar Operator in Seek Predicate ), pois ambas as colunas são do mesmo tipo e essa operação alimenta um operador de Loops Aninhados Paralelos (Left Outer Join) .

Minha pergunta, porém, é mais sobre a estimativa de linha chegando em 1, em vez de um número mais próximo do número real de linhas (~ 6,7 milhões). A operação escalar está matando a capacidade do otimizador de estimar as linhas corretamente? Eu suponho que sim e também assumo que isso está prejudicando meu plano de execução de consulta de ser ideal, mas eu realmente não tenho certeza. Alguém pode confirmar ou refutar minhas suspeitas junto com o porquê?

Aqui está a operação em questão:

Versão: SQL Server 2012 Enterprise

Isso é algo que me incomodou, embora nunca tenha causado nenhum problema real, pois geralmente posso localizar essas informações por outros meios, mas alguém pode explicar por que NULLpode ser retornado nas colunas dbid, objectid, e numberdo sys.dm_exec_sql_textDMV, mas ainda produz resultados na textcoluna? Entendo por que a saída retornaria inversamente (por exemplo, todas as colunas, mas textgeraria dados), mas já vi esse comportamento várias vezes em várias versões do SQL Server e a documentação não parece implicar que isso seja possível ou Só estou lendo errado.

Aqui está um exemplo da consulta que estou executando:

SELECT TOP 100 
      t.*
    , s.*
    , c.*
FROM    sys.dm_exec_query_stats s
        LEFT JOIN sys.dm_exec_connections c
               ON c.most_recent_sql_handle = s.sql_handle
        CROSS APPLY sys.dm_exec_sql_text(s.sql_handle) t
WHERE s.execution_count > 1 AND DATEDIFF (second, creation_time, GETDATE()) > 0
        AND t.dbid IS NULL

Aqui está uma amostra de um dos resultados da textcoluna que implica que isso não está relacionado a objetos temporários, que é o que eu normalmente acho que é a causa.

select * from [dbo].[Map_ProviderSpecialty]

Que situação está ocorrendo onde essas colunas estão retornando NULLvalores?

Como minhas habilidades de ajuste de desempenho nunca parecem suficientes, sempre me pergunto se há mais otimização que posso realizar em algumas consultas. A situação à qual esta pergunta se refere é uma função Windowed MAX aninhada em uma subconsulta.

Os dados que estou pesquisando são uma série de transações em vários grupos de conjuntos maiores. Eu tenho 4 campos de importância, o ID exclusivo de uma transação, o ID do grupo de um lote de transações e as datas associadas à respectiva transação única ou grupo de transações. Na maioria das vezes, a Data do Grupo corresponde à Data Máxima de Transação Única para um Lote, mas há momentos em que os ajustes manuais passam pelo nosso sistema e uma operação de data única ocorre após a captura da data da transação do grupo. Esta edição manual não ajusta a data do grupo por design.

O que eu identifico nesta consulta são aqueles registros onde a Data Única cai após a Data do Grupo. A consulta de exemplo a seguir cria um equivalente aproximado do meu cenário e a instrução SELECT retorna os registros que estou procurando, no entanto, estou abordando essa solução da maneira mais eficiente? Isso demora um pouco para ser executado durante o carregamento da minha tabela de fatos, pois meu registro conta o número nos 9 dígitos superiores, mas principalmente meu desdém por subconsultas me faz pensar se há uma abordagem melhor aqui. Não estou tão preocupado com nenhum índice, pois tenho certeza de que eles já estão em vigor; o que estou procurando é uma abordagem de consulta alternativa que alcançará a mesma coisa, mas de forma ainda mais eficiente. Qualquer feedback é bem-vindo.

CREATE TABLE #Example
(
    UniqueID INT IDENTITY(1,1)
  , GroupID INT
  , GroupDate DATETIME
  , UniqueDate DATETIME
)

CREATE CLUSTERED INDEX [CX_1] ON [#Example]
(
    [UniqueID] ASC
)


SET NOCOUNT ON

--Populate some test data
DECLARE @i INT = 0, @j INT = 5, @UniqueDate DATETIME, @GroupDate DATETIME

WHILE @i < 10000
BEGIN

    IF((@i + @j)%173 = 0)
    BEGIN
        SET @UniqueDate = GETDATE()+@i+5
    END
    ELSE
    BEGIN
        SET @UniqueDate = GETDATE()+@i
    END

    SET @GroupDate = GETDATE()+(@j-1)

    INSERT INTO #Example (GroupID, GroupDate, UniqueDate)
    VALUES (@j, @GroupDate, @UniqueDate)

    SET @i = @i + 1

    IF (@i % 5 = 0)
    BEGIN
        SET @j = @j+5
    END
END
SET NOCOUNT OFF

CREATE NONCLUSTERED INDEX [IX_2_4_3] ON [#Example]
(
    [GroupID] ASC,
    [UniqueDate] ASC,
    [GroupDate] ASC
)
INCLUDE ([UniqueID])

-- Identify any UniqueDates that are greater than the GroupDate within their GroupID
SELECT UniqueID
     , GroupID
     , GroupDate
     , UniqueDate
FROM (
    SELECT UniqueID
         , GroupID
         , GroupDate
         , UniqueDate
         , MAX(UniqueDate) OVER (PARTITION BY GroupID) AS maxUniqueDate
    FROM #Example
    ) calc_maxUD
WHERE maxUniqueDate > GroupDate
    AND maxUniqueDate = UniqueDate

DROP TABLE #Example

dbfiddle aqui

Temos vários bancos de dados 4.2.3.2 Greenplum que executam o PostGIS 1.4. Estamos tentando colocar esses bancos de dados em uma versão mais recente do Greenplum, como 4.3.8.1 ou a versão relançada de 4.3.9.1, mas estamos enfrentando uma série de problemas ao tentar atualizar o PostGIS para a versão 2.0. Tentamos várias maneiras diferentes de atualizar o banco de dados sem comprometer os dados e as funções que dependem do PostGIS 1.4, mas parece que quando executamos o utilitário gppkg com as novas extensões do PostGIS, obtemos apenas erros semelhantes ao seguinte:

gppkg -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg 
20160919:13:21:20:024675 gppkg:s-md-pv-gp-01-01:gpadmin-[INFO]:-Starting gppkg with args: -i postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg
20160919:13:21:20:024675 gppkg:s-md-pv-gp-01-01:gpadmin-[CRITICAL]:-gppkg failed. (Reason='__init__() got an unexpected keyword argument 'postupdate'') exiting...

Também executamos o gppkg passando o sinalizador -u, com resultados semelhantes:

gppkg -u postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg 
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[INFO]:-Starting gppkg with args: -u postgis-ossv2.0.3_pv2.0.1_gpdb4.3orca-rhel5-x86_64.gppkg
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-WARNING: The process of updating a package includes removing all
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-previous versions of the system objects related to the package. For
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-example, previous versions of shared libraries are removed.
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-After the update process, a database function will fail when it is
20160919:13:35:52:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[WARNING]:-called if the function references a package file that has been removed.
Do you still want to continue ? Yy|Nn (default=N):
> y
20160919:13:35:59:024930 gppkg:s-md-pv-gp-01-01:gpadmin-[CRITICAL]:-gppkg failed. (Reason='__init__() got an unexpected keyword argument 'postupdate'') exiting...

Uma grande advertência também pode estar relacionada ao fato de que apenas as versões 4.2.6.X a 4.2.8.X do Greenplum suportam as versões 1.4 e 2.0 do postGIS . Neste ponto, estamos procurando alguma orientação sobre como proceder na esperança de que outros possam ter encontrado alguns desses obstáculos.

Temos tíquetes com o fornecedor, Pivotal, mas eles não estão sendo frutíferos, então estou postando aqui na esperança de que a comunidade tenha alguma direção para me indicar.

Obrigado,

John

Executamos backups RMAN por meio de tarefas CRON, mas encontramos os e-mails prontos para uso com CRON para quase fazer o que queremos. Eu sei que podemos canalizar a saída do RMAN para /dev/null para que nenhum e-mail seja enviado, o que para qualquer execução bem-sucedida do RMAN é o resultado desejado, mas se o trabalho do RMAN apresentar um erro, eu gostaria que a saída padrão completa enviado por e-mail para a equipe de DBA para revisão. Suspeito que possa agrupar meus scripts RMAN com um script de shell bash que canalizará a saída padrão para o cron apenas em caso de falha, mas existe uma maneira melhor de fazer isso?

Para resumir:

1. Posso canalizar a saída padrão para um e-mail no caso de um erro (e ignorar a saída padrão se não houver erro) para que possamos usar a funcionalidade de e-mail padrão no cron?
2. Caso contrário, devo apenas agrupar meus scripts de backup do RMAN com lógica para que ele retorne apenas a saída do script de shell se um erro for encontrado?
3. Existe outra abordagem que não estou vendo ou não consigo encontrar online que faça isso?

Minhas desculpas se isso já foi perguntado. Encontrei várias perguntas e cenários pontuais, mas nada que eu senti correspondesse exatamente ao resultado desejado.

Obrigado!

Eu tenho que acreditar que há uma razão para isso, mas para a vida de mim eu não consigo descobrir. Parece que a ordenação de nomes de servidor em qualquer servidor de gerenciamento central é SENSÍVEL a maiúsculas e minúsculas, independentemente do agrupamento do servidor que atua como o próprio CMS.

Em anexo está um exemplo de um CMS hospedado em minha máquina local, que está configurado com um agrupamento de servidor de SQL_Latin1_General_CP1_CI_AS. CI significa maiúsculas e minúsculas. Ao selecionar na tabela do sistema que contém os objetos CMS, a ordem adequada é retornada, no entanto, como você pode ver nesta captura de tela, a maneira como os servidores são listados na interface do usuário, a ordem obviamente está sendo tratada de maneira sensível a maiúsculas e minúsculas.

Como não parece estar relacionado ao nível do servidor, presumo que esteja relacionado às ferramentas do cliente, mas não há nenhum lugar nas ferramentas em que eu possa identificar um nível de agrupamento (ou mesmo uma configuração de diferenciação de maiúsculas e minúsculas) que afetaria isso.

Obviamente, não há nada crítico sobre esta questão, mas se alguém souber como forçar a interface do usuário a não diferenciar maiúsculas de minúsculas, eu agradeceria, pois gosto de Camel Case meus nomes de servidor, o que está prejudicando a ordem.