MichaelD's questions

Usamos updlock em algumas instruções select para garantir que apenas uma conexão possa ler os dados. Isso não parece funcionar se o SQL Server puder buscar todos os dados de um índice, quando a outra consulta que também emite um updlock pode ser satisfeita com outro índice (não)clusterizado.

Qual seria a abordagem recomendada para ter bloqueios que realmente bloqueiem um registro de tabela, mesmo que outras consultas possam ser satisfeitas com dados de um índice?

Exemplo, conn2 deve ser bloqueado até que conn1 seja confirmado/revertido:

create database TestDB
go
use TestDB
go

create table LockTest(
    LockTestID int not null identity(1,1) primary key,
    Number int
)

create index IX_LockTest on LockTest(Number)

insert into LockTest(Number) values(1)


--Conn1
begin tran
select LockTestID from LockTest with(updlock) where LockTestID=1


--Conn2 -- The expectation here is, that this query waits untill Conn1 has committed
begin tran
select LockTestID from LockTest with(updlock) where Number=1

Mesmos resultados com holdlock ou lock

Temos uma tabela CustomerNote com 4 colunas ID, CustomerID, Note, Date

Existe um índice em CustomerID asc, Date desc

Quando a seguinte consulta é executada

select top 30 
    Date 
from CustomerNote
where CustomerID in (1,5)
order by Date desc

O índice é usado, mas ainda está buscando TODAS as CustomerNotes para os customerIDs 1 e 5, para então classificar/topar, causando muito uso da CPU.

Isso ocorre devido aos vários valores na cláusula "in". Eu sei que a cláusula "in" nunca terá mais valores do que 10, então seria uma abordagem muito melhor se o sql server iterasse sobre os 10, buscasse pelo menos 30 por customerID e a mesclagem, classificações e tops. Existe uma dica de consulta ou opção para conseguir isso?

Temos 2 ambientes de banco de dados exatamente iguais. O segundo ambiente contém uma cópia do banco de dados de produção e hospeda aproximadamente 11 milhões de registros na tabela Invoice. O objetivo desse ambiente é usado para ver quanto tempo as consultas de atualização específicas levarão para saber se haverá algum tempo de inatividade (já que as tabelas são bloqueadas durante a alteração do esquema)

ao executar a instrução add no segundo ambiente

alter table Invoice add IsVerified bit not null default(0)

A consulta é encerrada imediatamente, o que é estranho, pois há 11 milhões de registros nela. Eu esperaria pelo menos um pequeno atraso. Mesmo uma contagem selecionada(*) demora mais. No banco de dados de produção principal, no entanto, leva muito mais tempo, mais de 30 segundos, então temos que planejar essa consulta em uma janela de manutenção especial. Enquanto a consulta estava sendo executada não havia nada bloqueando o SPID (verificado usando sp_who2)

Qual poderia ser a razão, que a segunda cópia do banco de dados aparentemente não tem nenhum esforço para adicionar uma coluna em um banco de dados de 11 milhões de registros enquanto o outro maindb não pode terminar a tempo (<30 segundos). adicionar uma coluna de valor padrão sem a necessidade de ser gravada em todos os registros? Pode ser porque nosso ambiente de teste é a edição Developer, enquanto o ambiente de produção é a edição Standard? Talvez alguns recursos especiais na edição Developer que não estejam ativos no SQLStandard?

select count(*) from Invoice //result: 11701200
SQL Server Execution Times:
   CPU time = 2375 ms,  elapsed time = 608 ms.

Script para adicionar:

alter table Invoice add IsVerified bit not null default(0)
SQL Server parse and compile time: 
   CPU time = 0 ms, elapsed time = 0 ms.

 SQL Server Execution Times:
   CPU time = 0 ms,  elapsed time = 12 ms.

Configurar:

• Alta disponibilidade básica

• 2 réplicas (1 primária, 1 secundária).

  DB01 => primário inicial.

  DB02 => secundário inicial

• Confirmação síncrona em ambos

• Ambos estão em estado sincronizado

• Não há ouvinte configurado

• Tipo de cluster Nenhum

Quando paramos o serviço SQL DB01 (inicial e primário atual) usando services.msc (simulando uma falha amigável do servidor) e iniciamos um failover forçado no DB02 (inicial e secundário atual) usando:

ALTER AVAILABILITY GROUP [TestHA] FORCE_FAILOVER_ALLOW_DATA_LOSS;

O banco de dados secundário fica online, que é o que queremos.

No entanto, quando o serviço DB01 SQL Server é iniciado novamente, usando services.msc, o banco de dados DB01 assume novamente a função primária .

Portanto, atualmente existem 2 instâncias legíveis/graváveis ​​e fora de sincronia. Esperávamos que o primário inicial detectasse que um secundário assumiu a função primária e assumisse uma função secundária ou pelo menos ficasse inacessível para que os aplicativos não funcionassem com dados antigos.

O mesmo procedimento, mas usando a configuração de espelho obsoleta, se comporta dessa maneira.

Uma de nossas tabelas de log personalizadas tem 3 TB de tamanho. Precisamos criar um novo índice. A velocidade de leitura no próprio disco é de 10 mbyte/s.

Isso significa que o processo de criação do índice será 3.000.000/10 = 86 horas? O índice é gravado em outro grupo de arquivos em um disco rápido, portanto, o tempo de gravação não é um fator.

Usando o sql profiler, rastreamos todas as consultas lentas (filtro por duração/leituras) para ver onde podemos otimizar. Eventos usados:

• RPC: Concluído
• SQL:BatchCompleted

Filtre por Duração.

Se eu adicionar o evento ShowPlan XML, não posso filtrar a duração da consulta subjacente, criando uma carga enorme à medida que centenas/milhares de consultas chegam a cada segundo

Como capturar apenas o plano de execução para as entradas que correspondem à duração do filtro/leituras das consultas capturadas dos outros eventos?

Temos uma tabela com 190 milhões de registros. há um índice em uma coluna bastante exclusiva, mas ainda assim, se eu executar uma consulta na tabela selecionando os 10 primeiros com apenas a coluna indexada na cláusula where e select, ela ainda levará muito tempo para ser concluída.

Se eu ativar o plano de consulta ao vivo, o sql server mostra o botão giratório de espera 'esperando pelo plano de consulta'. Se a consulta finalmente terminar e se eu executá-la novamente, ela será concluída instantaneamente. o plano de consulta está demorando o tempo todo, mas não consigo reproduzir executando DBCC FREEPROCCACHE antes da consulta. Depois de um tempo, o mesmo problema ocorrerá novamente.

Nota: O banco de dados possui 2 grupos de arquivos. Índices e bancos de dados do sistema são armazenados no disco SSD, enquanto os dados normais da tabela são armazenados em um disco não SSD.

Eu tenho uma tabela com uma geometrycoluna. Para um registro, há apenas um Pointarmazenado. Um índice espacial foi criado, mas as consultas que procuram o local mais próximo não usam esse índice, resultando em desempenho ruim.

Exemplo de roteiro:

--Create the table
create table Location(
    LocationID int not null identity(1,1) primary key,
    LocationPoint geometry
)


--add records
declare @counter int =0
WHILE @counter<150000
BEGIN
    set nocount on
    --select 
    set @counter =@counter +1
    declare @RandomLocation geometry=geometry::Point(RAND() *1000, RAND() *1000, 0)     
    insert into Location(LocationPoint) values  (@RandomLocation)   
END

--create index
CREATE SPATIAL INDEX SPATIAL_StructureBE ON dbo.Location(LocationPoint)
USING GEOMETRY_GRID WITH ( 
    BOUNDING_BOX  = (xmin  = 0.0, ymin  = 0.0, xmax  = 1000, ymax  = 1000), 
    GRIDS = ( LEVEL_1  = MEDIUM, LEVEL_2  = MEDIUM, LEVEL_3  = MEDIUM, LEVEL_4  = MEDIUM),
    CELLS_PER_OBJECT  = 16, 
    STATISTICS_NORECOMPUTE = OFF, 
    ALLOW_ROW_LOCKS = ON, 
    ALLOW_PAGE_LOCKS = ON)

--Search, this query should use the index but it doesn't
declare @CurrentLocation geometry=geometry::Point(24,50, 0)
select top 1 *
from Location 
order by LocationPoint.STDistance(@CurrentLocation) asc

Como é possível que o tempo para enviar o valor seja maior que a sobrecarga do mirror commit? O espelho opera sob total segurança, então isso significa que o commit só é feito @ principal quando o commit é bem-sucedido @ mirror. Quando o tempo de envio é de 2 segundos, isso deve significar que a sobrecarga é de pelo menos 2 segundos. Ou eu estou esquecendo de alguma coisa?

Criei com sucesso um espelho com certificados entre dois servidores. Um desses servidores era um controlador de domínio. Depois de remover o domínio, o espelho foi interrompido. Após horas de pesquisa, reinstalei o SQL Server esperando que todos os possíveis problemas de remoção de domínio desaparecessem, mas o espelho ainda se recusa a funcionar. Continuo recebendo o vago erro:

Msg 1418, Nível 16, Estado 1, Linha 1 O endereço de rede do servidor "TCP://..." não pode ser alcançado ou não existe. Verifique o nome do endereço de rede e se as portas dos endpoints locais e remotos estão operacionais.

Se eu verificar o log de eventos do mirrorserver, vejo 2 erros:

1. Uma operação criptográfica falhou. Este erro indica um problema sério com o SQL Server. Verifique o log de erros do SQL Server e os logs de eventos do Windows para obter mais informações.
2. Uma chamada criptográfica do sistema falhou durante uma operação do Service Broker ou do Database Mirroring: erro do sistema '5(falha ao recuperar o texto para este erro. Motivo: 15105)'.

Alguma ideia/sugestão?