Joshua's questions

Acho que preciso obter as N coisas mais recentes acessadas por cada usuário e tenho uma tabela de log de todos os acessos. Algo como

CREATE TABLE [AccessLog] ([UserId] UNIQUEIDENTIFIER, [ThingId] UNIQUEIDENTIFIER, [AccessDate] DATETIME)

Então eu escrevi

SELECT [UserId], [ThingId], [SequenceNumber]
  FROM (SELECT [UserId], [ThingId], DENSE_RANK()
          OVER (PARTITION BY [UserId] ORDER BY [AccessDate] DESC) SequenceNumber
          FROM [AccessLog]
     ) [AccessLog]
 WHERE [SequenceNumber] < @N

Isso não funciona porque, se o mesmo usuário acessou a mesma coisa repetidamente, obtemos o mesmo [ThingId]de volta até N vezes, em vez de N [ThingIds]de volta distintas para cada usuário.

Estou perplexo como realmente fazê-lo. A tabela é tão grande que, se eu tiver que escrever a junção N ao cubo como se fosse 2.000 novamente (juntar a tabela novamente uma vez para excluir cópias duplicadas e uma segunda vez para gerar a contagem), será mais rápido sugar toda a tabela e processá-lo no código do aplicativo.

É quase como eu quero

FOR EACH [UserId] IN (SELECT [UserId] IN [User])
    SELECT TOP (@N) [UserId], [ThingId]
      FROM [AccessLog]
     ORDER BY [AccessDate] DESC

Mas esse desempenho também é tão ruim que eu gostaria de ler melhor a tabela no código do aplicativo novamente.

Temos um problema de empilhamento de bloqueio em um site do cliente. Por uma combinação de ferramentas, conseguimos localizar o root locker. Definitivamente, está executando esta instrução SQL específica no momento do empilhamento de bloqueio:

INSERT INTO #Gather
SELECT (columns omitted for brevity)
  FROM dbo.vScheduleInsuranceRuleViolations WITH(rowlock) OPTION (MAXDOP 1)

A análise da hierarquia de bloqueio leva a uma conclusão inevitável: WITH (rowlock)não está fazendo nada de útil aqui.

A visão é muito longa e, com razão, leva muito tempo para ser avaliada. Existem vários chamadores que diferem apenas na cláusula WHERE de filtragem (a maior parte do banco de dados ou alguns registros) e na demanda de bloqueio/simultaneidade. Neste chamador específico, temos o pior filtro e a menor demanda de bloqueio ( WITH (rowlock)dentro de READ COMMITTED-- READ UNCOMMITTEDnão funcionará aqui).

Antes de copiar e colar a definição de exibição no chamador, quero saber por que isso não funciona, se possível; porque espero que se WITH (rowlock)aplique a todas as tabelas lidas na exibição.

Eu tenho essa chave semelhante a uma árvore (pense em OIDs de objetos - é muito semelhante) para armazenar e indexar em uma tabela, para a qual as consultas desejam selecionar subárvores. A maneira mais direta de fazer isso em um btree é usar o caminho da árvore como a chave única e descer a chave com uma operação start-with para encontrar os blocos de linha.

Portanto, a representação óbvia é VARBINARY(n)*. Não consigo pensar em uma maneira de expressar o início de uma maneira que o SQL Server possa descobrir para usar o índice do mesmo.

O próximo mais óbvio é empacotar os dados em alguns VARCHARcom um agrupamento binário e usar uma likeoperação; no entanto descobri que like @n + '%'nunca usará um índice, mas apenas like 'literal%. Adicionar a WITH INDEXdica ainda verifica o índice em sua totalidade porque o SQL Server simplesmente não entende. Eu realmente não quero pensar em como escapar de argumentos no SQL para que eu possa construir um arquivo EXEC. Isso é apenas loucura e um desastre de segurança esperando para acontecer.

Expressar isso em tabelas recursivas comuns e consultar com SQL recursiva está fora de questão. A consulta recursiva irá desligar o servidor de banco de dados.

Na verdade, tenho os dados em uma longa sequência de longvariáveis ​​agora e posso selecionar meu formulário de serialização. Como eu disse, a forma natural é VARBINARYe realmente se pareceria com 0x000000100004A010000000D0000A000. A consulta mais comum é da forma "me dê tudo começando com 0x000000100004A01" ou no modelo natural, os primeiros nvalores da string de longvalores. Eu poderia escrevê-los no formulário, a.b.c.d.e.f...mas os números individuais são longos e vêm de clicar em coisas na GUI.

Grosso modo, estou olhando para uma forma plausível de

CREATE TABLE Record (
   RecordId BIGINT NOT NULL IDENTITY(1,1),
   RecordedDate DATETIME NOT NULL,
   RecordClass CHAR(1) NOT NULL,
   UserId INT NOT NULL,
   ObjectId VARBINARY(384) NOT NULL,
   RecordValue NVARCHAR(100) NULL,
   OwnerId BIGINT NULL, -- Joins to another table
   SubOwnerId BIGINT NULL, -- and yet another table
   PRIMARY KEY (RecordId)
)
CREATE INDEX name ON Record(RecordedDate);
CREATE INDEX name ON Record(OwnerId);
CREATE INDEX name ON Record(SubOwnerId);
CREATE INDEX name ON Record(ObjectId);

Qual é a melhor maneira de fazer um índice começa com?

^{*Eu calculei o maior n possível e é menor que 400}

Conectar-se ao SQL Server (2008 R2 SP3 - KB 4057113) com o SSMS versão 18 produz:

Uma conexão foi estabelecida com sucesso com o servidor, mas ocorreu um erro durante o processo de login. (provedor: SSL Provider, erro: 0 - Uma conexão existente foi fechada à força pelo host remoto.) (.Net SqlClient Data Provider)

Para obter ajuda, clique em: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=10054&LinkId=20476

Número do erro: 10054 Gravidade: 20 Estado: 0

O log de falha de conexão está habilitado no servidor, mas nada é registrado. Por favor, note que o link para ajuda está morto. Eu tentei vários aplicativos de banco de dados. Nada passa. O problema parece estar no servidor, não na estação de trabalho, mas outras estações de trabalho podem se conectar ao servidor. Esta estação de trabalho também pode se conectar a outros servidores.

Eu tenho um bom palpite de que isso é de alguma forma relacionado ao TLS, porque foi o que foi da última vez (o servidor não suportava o TLS 1.2 e precisava de um patch). Desta vez não consigo encontrar o problema.