Dave's questions

No SSRS 2016, os relatórios móveis são uma nova opção para o servidor de relatórios no modo nativo. Eu criei vários agora e parece haver consistência entre as cores em diferentes tabelas e gráficos se as mesmas colunas forem usadas na configuração de cada elemento. No entanto, não consigo encontrar nenhuma maneira de manter as cores consistentemente nas alterações do slicer. Existe uma solução alternativa, uma configuração perdida, um código por trás, alguma maneira de garantir que, quando eu alterar um parâmetro, minhas legendas de gráfico não troquem de cor repentinamente?

Isso ocorre com uma configuração de nível "All" nos parâmetros.

Este é o novo esquema de cores depois que um parâmetro foi selecionado e o relatório é atualizado com as novas quantidades. Totalmente inaceitável - isso torna o relatório quase inútil.

Esse comportamento ocorre em relatórios e conjuntos de dados para mim. Eu teria tentado definir uma ordem conforme ela parece mudar com base nas alterações de quantidade em cada categoria, mas não há configurações de ordem para gráficos de pizza.

Estou no SQL Server 2016 e me divertindo muito... meu DB Mail não está enviando e estou ficando sem lugares para procurar. Verifiquei duas vezes as permissões da conta SQL para o executável do DBmail - ele leu e executou. Digitei uma regra para a porta de saída 587 do firewall. Tentei outra conta de e-mail e perfil com os mesmos problemas não enviados. As únicas entradas nos logs (logs de correio db) estão iniciando e terminando o serviço. Não há erros em qualquer lugar que eu possa encontrar. Os e-mails parecem simplesmente entrar na fila de envio e nunca mais sair dela. As contas podem enviar e receber emails por conta própria e de uma instância do SQL Server 2014 em outra máquina.

Eu tenho uma fila de itens com status de enviados "não enviados" e verifiquei todos os locais normais com resultados esperados em todos eles, além de uma longa fila de emails não enviados:

SELECT * FROM msdb..sysmail_event_log order by log_id DESC

SELECT * FROM dbo.sysmail_mailitems

SELECT * FROM dbo.sysmail_sentitems

USE msdb
SELECT sent_status, *
FROM sysmail_allitems

 SELECT is_broker_enabled FROM sys.databases WHERE name = 'msdb';

 EXECUTE msdb.dbo.sysmail_help_status_sp

Eu tentei desligá-lo e ligá-lo novamente... então eu perdi um DMV etc. que poderia esclarecer essa situação? Este é um problema conhecido com o SQL Server 2016 que não tenho em minhas pesquisas? Quaisquer outras etapas possíveis para enviar este e-mail?

O SQL Server 2016 trava continuamente ao executar uma consulta de origem ETL. A memória começa a consumir a uma taxa fantástica, atinge o máximo e o serviço é desligado. Isso parece ridículo, especialmente porque a consulta é executada perfeitamente no SQL Server 2014 com menos memória e discos mais lentos. < O que poderia ter mudado e, mais importante, existe uma maneira de alterar a consulta do servidor ou as configurações de memória em 2016 que evitará esse cenário de travamento? Alguém pode restringir o problema (e confirmar que é um bug) ou fornecer uma solução mais robusta?

MAXDOP é definido como 4, a memória mínima é 8000, a máxima é 24000 com 28 GB no sistema. A máquina SQL 2014 também tinha o SharePoint em execução (instância SQL diferente) e, como resultado, tem uma memória máxima inferior (12533 ​​MB). A máquina SQL 2016 é uma cópia exata, exceto que não possui a instalação do SharePoint e foi atualizada para SSDs.

A consulta tem apenas 9 colunas (6 INTs) para 7.122.737 registros com duas pequenas junções de tabelas e filtragem mínima... não há nada que possa mudar com a consulta e novamente estava funcionando perfeitamente no SQL 2014. Na verdade, ele roda um minuto mais rápido no SQL 2014 vs SQL 2016, apesar dos SSDs e quase o dobro das adições de memória para uma versão supostamente mais rápida!

Portanto, depois de muita pesquisa, várias instalações diferentes, revertendo para um banco de dados, são instaladas apenas em locais padrão. Identifiquei principalmente o problema. Uma das colunas que está sendo hash é uma VARCHAR(MAX)que aciona uma solicitação de memória massiva de HASHBYTES. Não é totalmente irracional, embora a coluna mais longa tenha apenas 49 caracteres. Sistema de origem ... a solução alternativa será lançá-lo dinamicamente, eu acho.

Se o SQL Server atingir a memória máxima, que chega rapidamente com essa consulta, ele trava. Isso parece imprevisível e pode gerar outros erros, deixando o servidor ativo. Adicionar DISTINCT garante o comportamento de travamento, a menos que quantidades excessivas de memória estejam presentes.

Criei um problema do Microsoft Connect aqui se você tiver testes ou ideias adicionais ou puder reproduzir o problema. Eu diria que esta é apenas parcialmente a resposta, pois ainda está meramente restrita a uma gama de possibilidades, que não tenho tempo ou capacidade para identificar completamente. No entanto, não parece ser uma pressão de memória geral ou um resultado de configuração e serviços gerais do SQL 2016.

O seguinte pode reproduzir o problema.

CREATE TABLE Testing (
    VarCharMAX VARCHAR(MAX) NULL,
    VarCharRealistic VARCHAR(100) NULL
) ON PRIMARY
GO

SELECT TOP 1000000
    IDENTITY(INT, 1, 1) AS Number
INTO Numbers
FROM master.dbo.syscolumns x
CROSS JOIN master.dbo.syscolumns
GO --Ensure 1 million rows were inserted

INSERT INTO Testing
        (VarCharMAX, VarCharRealistic)
SELECT
     CAST(Number As VARCHAR(MAX)) + 'a' AS VarCharMAX
    ,CAST(Number As VARCHAR(100)) + 'a' AS VarCharRealistic
FROM Numbers
GO

--Server crash under ~16GB memory
SELECT DISTINCT
    HASHBYTES('md5', VarCharMAX)
FROM dbo.Testing

No SQL Server 2012, um SPID de processo pode ser alterado no meio da operação? Temos uma consulta muito exclusiva que monitoramos (produção, mas teste controlado) e a vimos em diferentes intervalos com diferentes SPIDs. É uma consulta exclusiva que ninguém mais deve executar, pelo menos com esses parâmetros e, como tal, não devemos vê-la com um SPID diferente, a menos que... uma consulta pode alterar os SPIDs no meio do processo?

Pelo que entendi, isso é impossível, portanto, é mais provável que, por algum motivo desconhecido, o aplicativo esteja reenviando essa consulta exclusiva e destrutiva de desempenho, gerando assim um novo SPID, apesar de nenhuma interação do usuário.

Estou configurando um Azure D11 SQL Server para ser usado para um data warehouse. Só posso anexar 4 discos de dados e fiz isso, agora preciso determinar como configurá-los e dividir os arquivos de banco de dados. Estou tentando adaptar a orientação do MS à minha situação específica.

Desenho Tradicional:

OS Disk/Azure Temp Disk
1 data disk - TempDB
1 data disk - Log
2 data disk - Data

Espero que suas diretrizes sejam para servidores OLTP gerais/potencialmente. Tenho um data warehouse em modo de recuperação simples com um único processo ETL todas as noites. Não sou particularmente fluente em gerenciamento de arquivos de log, mas minha inclinação é o log e o TempDB pode ir em um único disco de dados, deixando três discos disponíveis para distribuir e maximizar IO para o ETL noturno e, mais importante, relatórios diurnos.

É razoável colocar o log e o tempdb em um único disco e distribuir três para os dados ou o arquivo de log realmente precisa estar em um disco separado?

Eu estava tentando instalar o Report Builder CTP 2.3 e não consigo instalá-lo em nenhum dos três sistemas testados.

O primeiro sistema foi o Windows Server 2012 R2 Datacenter - imagem de visualização do MS Azure SQL 2016 com SSDT 2016 Preview instalado e Report Server SQL 2016 configurado e em execução. Este não é um software de servidor, mas todos os componentes para visualização do SQL 2016 e o ​​serviço SSRS estão presentes...

O segundo sistema foi o Windows 7 Ultimate e o terceiro foi o Windows 8.1. Todos resultam exatamente na mesma mensagem de erro:

Alguém instalou com sucesso o Report Builder CTP 2.3 e, em caso afirmativo, como conseguiu isso?

Contexto: Eu tenho um banco de dados SQL Server 2012 fornecido por um fornecedor, portanto, a modificação de consultas e tabelas é limitada. Nós possuímos o banco de dados, portanto, podemos adicionar e manter índices.

Os índices não foram mantidos ou reconstruídos, então há centenas com mais de 30% de fragmentação... essa é minha suspeita inicial de uso massivo e constante da CPU, mas enquanto trabalhamos para corrigir isso, estou investigando outros problemas.

Não estou vendo nenhuma pressão significativa de memória ou E/S de disco. Este é um sistema OLTP relativamente pouco usado e foi bem provisionado para recursos... realmente não deveria ter nenhum problema, ou pelo menos deveria ter apenas picos perceptíveis, sem uso constante de CPU.

Duas questões:

1. As estatísticas desatualizadas e os índices altamente fragmentados em todo o banco de dados podem causar o uso excessivo da CPU?

2. A combinação de estatísticas de espera listadas abaixo deste sistema desacredita a explicação da fragmentação do índice?

Em formação:

WaitType                                    Wait_S
---------------------------------           -----------    
CXPACKET                                    773345.21
PAGELATCH_UP                                737295.83
SOS_SCHEDULER_YIELD                         140425.24
LATCH_EX                                    69877.95
RESOURCE_SEMAPHORE_QUERY_COMPILE            60985.48
LCK_M_SCH_S                                 39488.17

Consulta de origem para os resultados da espera:

WITH [Waits] AS
(
 SELECT
     [wait_type],
     [wait_time_ms] / 1000.0 AS [WaitS],
     ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
     [signal_wait_time_ms] / 1000.0 AS [SignalS],
     [waiting_tasks_count] AS [WaitCount],
     100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
     ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
 FROM 
     sys.dm_os_wait_stats
 WHERE 
     [wait_type] NOT IN (... common waits )
     AND [waiting_tasks_count] > 0)
SELECT
    MAX ([W1].[wait_type]) AS [WaitType],
    CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
    CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
    CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
    MAX ([W1].[WaitCount]) AS [WaitCount],
    CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
    CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
    CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
    CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum]
HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95;