James Lupolt's questions

Percebi que em um servidor que executa o SQL Server 2016 SP1 CU6, às vezes, uma sessão de eventos estendidos mostra uma consulta SELECT causando gravações. Por exemplo:

O plano de execução não mostra nenhuma causa óbvia para as gravações, como uma tabela de hash, spool ou classificação que pode ser derramada no TempDB:

A atribuição de variável a um tipo MAX ou uma atualização automática de estatísticas também pode causar isso, mas também não foi a causa das gravações nesse caso.

De que mais poderiam ser as gravações?

Consultar uma tabela temporal com versão do sistema FOR system_time ALLparece omitir linhas em que os horários de início e término são iguais.

Por exemplo:

/* Create a simple system-versioned table */
CREATE TABLE [dbo].[svt_test](
    [string] [VARCHAR](30) NOT NULL,
    [validFrom] [DATETIME2](7) GENERATED ALWAYS AS ROW START NOT NULL,
    [validTo]   [DATETIME2](7) GENERATED ALWAYS AS ROW END NOT NULL,
CONSTRAINT [PK_svt_test] PRIMARY KEY CLUSTERED 
(
    [string] ASC
),
    PERIOD FOR SYSTEM_TIME ([validFrom], [validTo])
) 
WITH
(
    SYSTEM_VERSIONING = ON ( HISTORY_TABLE = [dbo].[svt_test_history] )
);

/* 
Insert and immediately delete a row. 
May have to try multiple times to get a row with the same start and end    
timestamp. 
*/
INSERT INTO dbo.svt_test (string) VALUES ('string'); 
DELETE dbo.svt_test WHERE string = 'string';

/* 0 rows */
SELECT * FROM dbo.svt_test;
/* 1 row */
SELECT * FROM dbo.svt_test_history;
/* 
0 rows. 
Should be the "union of rows that belong to the current and the history table" 
  per https://msdn.microsoft.com/en-us/library/dn935015.aspx 
*/
SELECT * FROM dbo.svt_test FOR system_time ALL;

/* 
   CONTAINED IN does not find the row either, even though MSDN says the    
   interval is defined as SysStartTime >= start_date_time AND SysEndTime <=   
   end_date_time
*/
DECLARE @Start DATETIME2(7);
SELECT @Start = validFrom FROM [dbo].[svt_test_history] WHERE string = 'string';
DECLARE @End DATETIME2(7);
SELECT @End = validTo FROM [dbo].[svt_test_history] WHERE string = 'string';
SELECT * FROM dbo.svt_test FOR system_time CONTAINED IN (@Start, @End);

/* Clean up */
ALTER TABLE dbo.svt_test SET (SYSTEM_VERSIONING = OFF);
DROP TABLE dbo.svt_test;
DROP TABLE dbo.svt_test_history;

Verifiquei isso em 2016 SP1 CU1 (12.0.4416) e 2016 CU3 (13.0.2186). Eu obtive o mesmo resultado com datetime2(0)em vez de datetime2(7).

Alguém saberia se isso é provavelmente um bug ou por design? Alternativamente, talvez eu tenha entendido mal alguma coisa?

fn_dblog()mostra IDs de transação neste formato:

0000:00049d43

E sys.dm_tran_database_transactionsmostra IDs de transação neste formato:

9811233

Acredito que os exemplos acima mostram o mesmo ID de transação em diferentes formatos.

Existe uma maneira de converter entre os dois formatos? Ou essas são realmente duas entidades diferentes - e, nesse caso, existe uma maneira de combinar fn_dblog()com os DMVs relacionados à transação?

Existe alguma documentação ou pesquisa sobre alterações no SQL Server 2016 para como a cardinalidade é estimada para predicados contendo SUBSTRING () ou outras funções de string?

A razão pela qual estou perguntando é que eu estava olhando para uma consulta cujo desempenho degradou no modo de compatibilidade 130 e o motivo foi relacionado a uma alteração na estimativa do número de linhas que correspondem a uma cláusula WHERE que continha uma chamada para SUBSTRING (). Corrigi o problema com uma reescrita de consulta, mas gostaria de saber se alguém conhece alguma documentação sobre alterações nessa área no SQL Server 2016.

O código de demonstração está abaixo. As estimativas são muito próximas neste caso de teste, mas a precisão varia dependendo dos dados.

No caso de teste, no nível de compatibilidade 120, o SQL Server parece estar usando o histograma para a estimativa, enquanto no nível de compatibilidade 130, o SQL Server parece assumir 10% fixos das correspondências da tabela.

CREATE DATABASE MyStringTestDB;
GO
USE MyStringTestDB;
GO
DROP TABLE IF EXISTS dbo.StringTest;
CREATE TABLE dbo.StringTest ( [TheString] varchar(15) );
GO
INSERT INTO dbo.StringTest
VALUES
( 'Y5_CLV' );
INSERT INTO dbo.StringTest
VALUES
( 'Y5_EG3' );
INSERT INTO dbo.StringTest
VALUES
( 'ZY_NE' );
INSERT INTO dbo.StringTest
VALUES
( 'ZY_PQT' );
INSERT INTO dbo.StringTest
VALUES
( 'ZY_T2V' );
INSERT INTO dbo.StringTest
VALUES
( 'ZY_TT4' );
INSERT INTO dbo.StringTest
VALUES
( 'ZY_ZKK' );
INSERT INTO dbo.StringTest
VALUES
( 'ZZ_LW6' );
INSERT INTO dbo.StringTest
VALUES
( 'ZZ_QO3' );
INSERT INTO dbo.StringTest
VALUES
( 'ZZ_TZ7' );
INSERT INTO dbo.StringTest
VALUES
( 'ZZ_UZZ' );

CREATE CLUSTERED INDEX IX_Clustered ON dbo.StringTest (TheString);

/* 
Uses fixed % for estimate; 1.1 rows estimated in this case.
    Plan for computation:
        CSelCalcFixedFilter (0.1) <----
            Selectivity: 0.1
*/
ALTER DATABASE MyStringTestDB SET compatibility_level = 130;
GO
SELECT * 
FROM dbo.StringTest 
WHERE SUBSTRING(TheString, 1, CHARINDEX('_',TheString) - 1) = 'ZZ'
OPTION (QUERYTRACEON 2363, QUERYTRACEON 3604);

/* 
Uses histogram to get estimate of 1
 CSelCalcPointPredsFreqBased <----
      Distinct value calculation:
          CDVCPlanLeaf
              0 Multi-Column Stats, 1 Single-Column Stats, 0 Guesses
      Individual selectivity calculations:
          (none)
    Loaded histogram for column QCOL: [DBA].[dbo].[StringTest].TheString from stats with id 1
*/
ALTER DATABASE MyStringTestDB SET compatibility_level = 120;
GO
SELECT * 
FROM dbo.StringTest 
WHERE SUBSTRING(TheString, 1, CHARINDEX('_',TheString) - 1) = 'ZZ'
OPTION (QUERYTRACEON 2363, QUERYTRACEON 3604);

/*
-- Simpler rewrite; works fine in both compat levels and gets better estimate.
SELECT * 
FROM dbo.StringTest 
WHERE TheString LIKE 'ZZ[_]%'
OPTION (QUERYTRACEON 2363, QUERYTRACEON 3604);
*/

É possível recuperar os mesmos dados a seguir com uma única busca ou varredura, modificando a consulta ou influenciando a estratégia do otimizador?

Código e esquema semelhantes a este estão atualmente no SQL Server 2014.

Script de reprodução. Configurar:

USE tempdb;
GO
IF OBJECT_ID('dbo.TestUpload', 'U') IS NOT NULL 
  DROP TABLE dbo.TestUpload; 


CREATE TABLE dbo.TestUpload(
    JobRunId bigint NOT NULL,
    ThingAName nvarchar(255) NOT NULL,
    ThingAType nvarchar(255) NOT NULL,
    ThingAGranularity nvarchar(255) NOT NULL,
    ThingBName nvarchar(255) NOT NULL,
    ThingBType nvarchar(255) NOT NULL,
    ThingBGranularity nvarchar(255) NOT NULL
);
CREATE CLUSTERED INDEX IX_JobRunId ON dbo.TestUpload (JobRunId);

GO

INSERT INTO dbo.TestUpload (JobRunId, ThingAName, ThingAType, ThingAGranularity, ThingBName, ThingBType, ThingBGranularity)
  VALUES (1, 'A', 'B', 'C', 'D', 'E', 'F');
GO 10

INSERT INTO dbo.TestUpload (JobRunId, ThingAName, ThingAType, ThingAGranularity, ThingBName, ThingBType, ThingBGranularity)
  VALUES (1, 'D', 'E', 'F', 'A', 'B', 'C');
GO 10

Consulta:

DECLARE @JobRunID bigint = 1;

SELECT JobRunId,
  ThingAName AS Name, 
  ThingAType AS [Type], 
  ThingAGranularity AS Granularity
FROM dbo.TestUpload
WHERE JobRunId = @JobRunID
UNION
SELECT JobRunId,
  ThingBName AS Name, 
  ThingBType AS [Type], 
  ThingBGranularity AS Granularity
FROM dbo.TestUpload
WHERE JobRunId = @JobRunID;

Destruir:

IF OBJECT_ID('dbo.TestUpload', 'U') IS NOT NULL 
  DROP TABLE dbo.TestUpload;

Eu acho que isso provavelmente não é modelado idealmente. Estou tentando obter mais informações do desenvolvedor sobre como o esquema foi escolhido, mas estou curioso para saber se há um truque TSQL que estou ignorando, pois será mais fácil alterar a consulta do que o esquema.

Estou testando a exclusão de dados de um índice columnstore clusterizado.

Percebi que há um grande operador de spool ansioso no plano de execução:

Isso se completa com as seguintes características:

• 60 milhões de linhas excluídas
• 1,9 GiB TempDB usado
• 14 minutos de tempo de execução
• plano de série
• 1 reencadernação no carretel
• Custo estimado para digitalização: 364.821

Se eu induzir o estimador a subestimar, obtenho um plano mais rápido que evita o uso do TempDB:

Custo estimado da varredura: 56.901

(Este é um plano estimado, mas os números nos comentários estão corretos.)

Curiosamente, o spool desaparece novamente se eu liberar os armazenamentos delta executando o seguinte:

ALTER INDEX IX_Clustered ON Fact.RecordedMetricsDetail REORGANIZE WITH (COMPRESS_ALL_ROW_GROUPS = ON);

O spool parece ser introduzido apenas quando há mais do que algum limite de páginas nos armazenamentos delta.

Para verificar o tamanho dos armazenamentos delta, estou executando a seguinte consulta para verificar as páginas in-row da tabela:

SELECT  
  SUM([in_row_used_page_count]) AS in_row_used_pages,
  SUM(in_row_data_page_count) AS in_row_data_pages
FROM sys.[dm_db_partition_stats] as pstats
JOIN sys.partitions AS p
ON pstats.partition_id = p.partition_id
WHERE p.[object_id] = OBJECT_ID('Fact.RecordedMetricsDetail');

Existe algum benefício plausível para o iterador de spool no primeiro plano? Devo presumir que se destina a melhorar o desempenho e não a proteção do Dia das Bruxas, porque sua presença não é consistente.

Estou testando isso no 2016 CTP 3.1, mas vejo o mesmo comportamento no 2014 SP1 CU3.

Publiquei um script que gera esquema e dados e orienta você na demonstração do problema aqui .

A questão é principalmente por curiosidade sobre o comportamento do otimizador neste ponto, pois tenho uma solução alternativa para o problema que gerou a pergunta (um grande spool cheio de TempDB). Agora estou excluindo usando a troca de partição.

Eu gostaria de executar uma assinatura SSRS após algum trabalho ETL executado por um pacote SSIS que leva um tempo variável para ser concluído. Estou pensando em usar este método , que consiste basicamente em SSIS chamando o mesmo procedimento armazenado que os trabalhos do SQL Server Agent para chamadas de assinaturas para executar uma assinatura.

No entanto, não tenho certeza de qual seria a melhor maneira de gerenciar permissões para executar a assinatura. Por exemplo, estou relutante em adicionar usuários ao RsExecRoleporque isso é desencorajado pela Microsoft em alguns documentos, e estou relutante em conceder permissões de nível de objeto para executar o ReportServer.ado.AddEventprocedimento porque eles provavelmente serão ignorados em qualquer migração. (Editar: suponho que poderíamos contornar isso fazendo com que algo execute o trabalho do agente em vez de chamar o procedimento armazenado.)

Também espero evitar problemas com o código que executa a quebra de assinatura quando um dos GUIDs é alterado.

Como os profissionais do SSRS gerenciam as permissões para esse tipo de solicitação? Como alternativa, existe um método mais simples que contorne esses problemas?

Digamos que eu tenha uma tabela Foocom colunas ID1, ID2e uma chave primária composta definida por ID2, ID1. (Atualmente, estou trabalhando com um produto System Center que possui várias tabelas definidas dessa maneira com as colunas de chave primária listadas na ordem oposta em que aparecem na definição da tabela.)

CREATE TABLE dbo.Foo(
  ID1 int NOT NULL,
  ID2 int NOT NULL,
CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED (ID2, ID1)
);
GO

-- Add a row and update stats so that histogram isn't empty
INSERT INTO Foo (ID1, ID2) VALUES (1,2);
UPDATE STATISTICS dbo.Foo;

A key_ordinalcoluna em sys.index_columnsmostra as colunas de índice na mesma ordem em que foram declaradas na chave primária composta:

SELECT t.name, i.name, c.column_id, c.name, ic.index_column_id, ic.key_ordinal
FROM sys.tables AS t
JOIN sys.indexes AS i
ON t.[object_id] = i.[object_id]
JOIN sys.index_columns AS ic
ON ic.[object_id] = i.[object_id]
AND ic.index_id = i.index_id
JOIN sys.columns AS c
ON ic.column_id = c.column_id
AND ic.[object_id] = c.[object_id]
WHERE t.name = 'Foo';

O histograma também mostra as estatísticas na mesma ordem:

DBCC SHOW_STATISTICS ('Foo',PK_Foo);

No entanto, sys.stats_columnsmostra as colunas listadas na ordem inversa ( ID1, ID2).

SELECT s.name, sc.stats_column_id, c.name
FROM sys.stats AS s
JOIN sys.stats_columns AS sc 
ON s.stats_id = sc.stats_id 
AND s.[object_id] = sc.[object_id] 
JOIN sys.columns AS c 
ON c.[object_id] = s.[object_id]
AND c.column_id = sc.column_id
JOIN sys.objects AS o 
ON o.[object_id] = c.[object_id] 
WHERE o.name = 'Foo'
AND s.name = 'PK_Foo';

O Books Online diz que stats_column_idé um "ordinal baseado em 1 dentro do conjunto de colunas de estatísticas", então eu esperava que o valor 1 apontasse para a primeira coluna no objeto de estatísticas.

Isso é um bug sys.stats_columnsou um mal-entendido da minha parte?

Verifiquei que esse comportamento ocorre nas compilações atuais do SQL Server 2005, 2008, 2008 R2, 2012 e 2014.

sys.stats_columnsparece refletir a ordem dentro do objeto de estatísticas em outras situações, por exemplo:

CREATE TABLE dbo.Foo2(
  ID1 int NOT NULL,
  ID2 int NOT NULL,
  ID3 int NULL,
  String VARCHAR(10) NULL,
CONSTRAINT [PK_Foo2] PRIMARY KEY CLUSTERED (ID2, ID1)
);

GO

INSERT INTO Foo2 (ID1, ID2, ID3, String) VALUES (1,2,3,'String');

CREATE STATISTICS ST_Test ON Foo2 (ID3, String);
CREATE STATISTICS ST_Test2 ON Foo2 (String, ID3);

DBCC SHOW_STATISTICS ('Foo2',ST_Test);
DBCC SHOW_STATISTICS ('Foo2',ST_Test2);


SELECT s.name, sc.stats_column_id, c.name
FROM sys.stats AS s
JOIN sys.stats_columns AS sc 
ON s.stats_id = sc.stats_id 
AND s.[object_id] = sc.[object_id] 
JOIN sys.columns AS c 
ON c.[object_id] = s.[object_id]
AND c.column_id = sc.column_id
JOIN sys.objects AS o 
ON o.[object_id] = c.[object_id] 
WHERE o.name = 'Foo2'
AND s.name LIKE 'ST_Test%';

Aqui está outro exemplo onde sys.stats_columnsparece retornar os dados corretos, desta vez para estatísticas em um índice:

--drop table dbo.Foo3
CREATE TABLE dbo.Foo3(
  ID1 int NOT NULL,
  ID2 int NOT NULL,
  ID3 int NULL,
  String VARCHAR(10) NULL,
CONSTRAINT [PK_Foo3] PRIMARY KEY CLUSTERED (ID2, ID1)
);

GO

INSERT INTO Foo3 (ID1, ID2, ID3, String) VALUES (1,2,3,'String');
UPDATE STATISTICS Foo3;

CREATE INDEX IX_Test ON Foo3 (ID3, String);
CREATE INDEX IX_Test2 ON Foo3 (String, ID3);

DBCC SHOW_STATISTICS ('Foo3',IX_Test);
DBCC SHOW_STATISTICS ('Foo3',IX_Test2);

SELECT s.name, sc.stats_column_id, c.name
FROM sys.stats AS s
JOIN sys.stats_columns AS sc 
ON s.stats_id = sc.stats_id 
AND s.[object_id] = sc.[object_id] 
JOIN sys.columns AS c 
ON c.[object_id] = s.[object_id]
AND c.column_id = sc.column_id
JOIN sys.objects AS o 
ON o.[object_id] = c.[object_id] 
WHERE o.name = 'Foo3'
AND s.name LIKE 'IX_Test%';

Estou trabalhando com um desenvolvedor que está lutando para interromper o seguinte erro:

O servidor interromperá a conexão porque o driver cliente enviou várias solicitações enquanto a sessão está no modo de usuário único. Esse erro ocorre quando um cliente envia uma solicitação para redefinir a conexão enquanto ainda há lotes em execução na sessão ou quando o cliente envia uma solicitação enquanto a sessão está redefinindo uma conexão. Entre em contato com o fornecedor do driver do cliente.

Quando esse erro ocorre, um resultado típico é uma sessão que está mantendo bloqueios, mas não tem nenhum SQL em execução (nenhuma linha sys.dm_exec_requestspara o session_id) e causa bloqueio até que seja eliminado. A causa do bloqueio é direta, mas como impedir que o erro ocorra não é.

Alguns fatos sobre o problema:

• O cliente está usando Entity Framework (sim, eu sei...), com MARS habilitado (sim, eu sei...)
• A versão do SQL Server é 10.00.5844 (SQL Server 2008 SP3 CU12). Eles provavelmente não atualizarão as versões principais sem testes extensivos, mas a aplicação de uma CU mais recente é viável.
• O programa cliente aparece sys.dm_exec_connectionscomo .Net SqlClient Data Provider
• A conexão aberta parece definitivamente ter o MARS ativado, como net_transportnos sys.dm_exec_connectionsshows Session.
• Disseram-me que a string de conexão do aplicativo tem processamento assíncrono ativado, de acordo com o comentário de Matt Neerincx neste tópico (não tenho acesso aos servidores de aplicativos para confirmar isso sozinho):

Se você definir Async=true na cadeia de conexão, isso deve evitar esse problema. Se você estiver usando MARS e usando a mesma conexão em vários threads simultâneos, o que pode acontecer é que a chamada para redefinir a conexão pode ficar um pouco atrasada e acionar esse erro. Se você definir Async=true, executaremos um bloqueio adicional no driver cliente para evitar que isso aconteça.

Mais informações sobre esse erro são escassas. Parece sugerir que o programa do cliente está chamando sp_reset_connectionenquanto um lote ainda está em execução. Eu poderia configurar um rastreamento para confirmar isso, mas teria que registrar muitas atividades não relacionadas e o problema está acontecendo apenas uma vez a cada poucos dias. Além disso, não tenho certeza se o desenvolvedor seria capaz de tirar proveito dessa evidência para resolver o problema.

Existe alguma outra técnica que eu possa usar como DBA ou administrador de sistema para solucionar isso ainda mais, ou qualquer coisa que eu possa sugerir ao desenvolvedor que possa fornecer a ele informações úteis ou tornar o problema menos provável de acontecer?

Dadas as seguintes constantes:

• O mesmo banco de dados com a mesma estrutura (tabelas, índices, etc)
• os mesmos dados
• O mesmo SQL Server e configuração de hardware
• As mesmas estatísticas
• As mesmas opções SET no cliente
• As mesmas versões do SQL Server
• Os mesmos sinalizadores de rastreamento

Dadas essas constantes, o SQL Server sempre produzirá o mesmo plano para uma determinada consulta?

Se não, há outras considerações? Existe também um elemento de não determinismo a ser considerado?

Estou trabalhando em um projeto em que preciso procurar os nomes de host associados aos endereços IP que foram registrados fazendo solicitações HTTP. Atualmente, as pesquisas acontecem como parte de um trabalho ETL diário. O método atual é usar uma função CLR escalar (código semelhante a este é postado em vários lugares na web, postado abaixo com minhas revisões; não tenho certeza de quem era o autor original):

using System.Data.SqlTypes;
using System.Net;
using System.Security;
using System.Text.RegularExpressions;
using Microsoft.SqlServer.Server;

public partial class udfn_GetHostName
{

[Microsoft.SqlServer.Server.SqlFunction]
public static string udfn_GetHostname(string IPAddr)
{
    try
    {
        /* 
         Using deprecated method intentionally.
         GetHostEntry() is now recommended.
         But it does some irritating things like returning an error if a PTR
         record points to a name that doesn't have an A record.
        */
        IPHostEntry IpEntry = Dns.GetHostByAddress(IPAddr);
        // Test whether the record returned has at least one alphabetic character
        // If it does, then it's a name
        // Otherwise the DNS server might have returned the IP address
        Match match = Regex.Match(IpEntry.HostName.ToString(), @"[a-zA-Z]+");

        if (match.Success)
        {
            return IpEntry.HostName.ToString();
        }
        else
        {
            return "None";
        }      

     }
    catch(Exception ex)
    {
        return "Failed";
        //return ex.Message.ToString();
    }
  }
} 

Não sou um desenvolvedor C#, então a qualidade do código CLR provavelmente não é boa.

Então eu chamo a função assim depois de carregar novas linhas na dimensão:

-- Update only rows that we just inserted
UPDATE DIM.Network_Addresses
SET reverse_dns = dbo.[udfn_GetHostname](client_ip) 
WHERE reverse_dns IS NULL 
AND is_current = 1
AND created_date = (SELECT MAX(created_date) FROM DIM.API_Network_Address);

Esse método funciona, mas é muito lento, pelo menos por alguns motivos.

1) O uso de uma função escalar faz com que o SQL Server chame a função CLR uma vez por linha que precisa ser atualizada, usando um novo contexto SQL.

2) As próprias chamadas de função são muito lentas devido à forma como GetHostname() e outras funções de resolução de nome CLR funcionam: tempos limite longos, às vezes várias viagens de ida e volta pela rede que atingem o tempo limite se um servidor DNS não responder ou não houver PTR registro, etc

Alguém poderia recomendar um padrão de design que melhorasse o desempenho da pesquisa de registros DNS reversos e da atualização da tabela?

Estou considerando algumas coisas diferentes:

1) Mova este trabalho para fora do banco de dados e use uma ferramenta como dig para fazer as pesquisas em paralelo.

2) Tente encontrar uma maneira de chamar a função em paralelo ou convertê-la em uma função in-line (não progredindo muito nisso!)

No entanto, qualquer ideia seria bem-vinda.

Recebo o seguinte erro ao tentar conectar o SSMS ao Integration Services usando um nome de rede específico do cluster do SQL Server:

A conexão com o serviço Integration Services no computador 'FooDB' falhou com o seguinte erro: "Acesso negado".

Esse erro ocorre quando o computador não foi configurado para permitir conexões remotas por meio de DCOM ou o usuário tem permissão para acessar o serviço SQL Server Integration Services por meio de DCOM.

Este é um problema rotineiro com uma solução bem documentada. Por exemplo, veja as soluções aqui e aqui .

No entanto, tentei todas as soluções que conheço e o problema persiste.

Mais detalhadamente, fiz o seguinte:

• Verificado que os usuários conectados têm as permissões DCOM listadas nos artigos vinculados acima em MsDtsServer100:

  1. Permissões de inicialização e ativação: Permitir inicialização local, permitir inicialização remota, ativação local, ativação remota

  2. Permissões de acesso: Permitir acesso local, permitir acesso remoto

  3. Permissão de configuração: Permitir leitura

• Confirmado com um sniffer de pacote que todo o tráfego relacionado à conexão está vindo com sucesso através do firewall. O último pacote mostrado antes da conexão TCP ser interrompida é uma resposta do servidor contendo o código de status do Windows para 'acesso negado' dentro de um cabeçalho MSRPC.

• Testado adicionando os usuários ao grupo 'Distributed COM Users' e/ou ao grupo de administradores locais e, em seguida, reiniciando os servidores. Isso permitiu que os usuários se conectassem ao SSIS a partir do SSMS usando os nomes dos nós locais (FooDBN1, FooDBN2), mas ainda recebiam um erro de 'acesso negado' ao se conectarem ao nome da rede do cluster (FooDB), que é o que eles estão acostumados usar e o que funciona em nossos outros clusters.

Além disso, não achei necessário alterar a associação desses grupos em outros clusters.

Nos outros clusters que verifiquei, posso conectar o SSMS ao SSIS usando o nome do cluster sem nenhuma configuração não padrão.

Sei que isso pode ser mais apropriado para ServerFault e estou bem com a questão de ser migrada, se necessário, mas também é um problema do SQL Server e acho que os usuários aqui podem ter lidado com isso antes.

Detalhes da plataforma:

• Windows Server 2008 R2 SP1
• SQL Server 2008 R2 SP2
• Cluster ativo-passivo de 2 nós com uma única instância do SQL Server

Alguém poderia sugerir o que eu deveria estar olhando a seguir aqui?

Atualização : isso misteriosamente começou a funcionar hoje, mas apenas para membros do grupo de administradores locais. Nada mudou, tanto quanto eu posso dizer.

Já vi várias pessoas ligarem SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTEDantes de ler os DMVs do sistema. Existe algum motivo para fazer isso, supondo que você não esteja misturando chamadas para DMVs e tabelas na mesma transação?

Uma solicitação frequente que recebo dos clientes é para ajudar a descobrir quais consultas ou clientes estão fazendo a maior contribuição para o SQL Server saturando um link Ethernet.

Idealmente, eu examinaria alguns contadores ou DMVs mostrando E/S de rede agregada por consulta, cliente, aplicativo, banco de dados etc.

Como não parece haver uma maneira direta de fazer isso, como substituto, geralmente olho para as colunas *_rows em sys.dm_exec_query_stats (essas colunas existem apenas em 2008 R2+, eu acho) e também procuro consultas que parecem envolvem BLOBs.

Existe uma maneira melhor de abordar esse problema?

Existe uma maneira de obter estatísticas de uso de recursos por login no SQL Server?

Idealmente, gostaria de ter uma versão sys.dm_exec_sessionsque rastreie o uso de todas as sessões, em vez de apenas as conectadas no momento. Então eu poderia apenas executar algo assim:

select login_name, sum(reads) as reads, 
       sum(writes) as writes, 
       sum(cpu_time) as cpu_time, 
       count (login_name) as sessions 
from sys.dm_Exec_Sessions 
where login_name is not null 
group by login_name

Obviamente, isso é executado atualmente, mas mostra apenas as estatísticas das sessões conectadas no momento.

Meu empregador está pensando em implantar um software de desfragmentação NTFS que usa a API Windows MoveFile para desfragmentar arquivos abertos. Isso seria implantado em milhares de servidores SQL Server executando versões do SQL de 2005 a 2012 e versões do Windows de 2003 e 2008 R2. Se importa, o produto de que estou falando é o PerfectDisk, mas acredito que existam programas semelhantes que funcionem da mesma maneira.

Os testes até agora não revelaram muitos problemas além de problemas ocasionais de desempenho de E/S, o que não é nenhuma surpresa e pode ser contornado reagendando e ajustando a desfragmentação. No entanto, estou mais preocupado com o risco de corrupção de dados.

Alguém aqui tem experiência em executar esse tipo de software em produção em servidores de banco de dados? Você experimentou alguma corrupção de dados?

Estou bastante preocupado com isso, apesar de não conseguir encontrar nenhuma evidência sólida de que isso representa um problema.

Obrigado por qualquer resposta.

Editado para adicionar: Felizmente, essa ideia horrível foi esquecida, possivelmente em parte devido a alguns dos avisos que dei.