geofftnz's questions

Estamos experimentando um crescimento lento de memória roubada em nossos servidores de banco de dados no espaço de vários dias. Parece atingir um platô em torno de 130-140 GB, momento em que começamos a ter problemas maiores, como erros de falta de memória, congelamentos de vários segundos e failovers de AG. Os problemas começam a se manifestar cerca de uma semana após a reinicialização. Comecei a registrar o histórico de memória roubada, que é mostrado abaixo:

Olhando para sys.dm_os_memory_clerks, parece que a maior parte disso vem da memória não-página registrada no buffer pool no nó NUMA 0:

O rastreamento do total pages_kbdo buffer pool ao longo do tempo mostra o declínio no número de páginas à medida que virtual_memory_committed_kbaumenta. (Em 13 de abril, o servidor foi reinicializado para atualizações do Windows. O pool de buffers chega a 400 GB em cerca de uma hora)

Alguém já viu esse comportamento antes?

Estamos executando o SQLServer 2016 CU12 13.0.5698.0 O servidor é uma instância AWS EC2 i3.16xlarge de 64 núcleos. Temos vários outros clusters do mesmo tamanho que estão apresentando esse problema. Também temos alguns clusters em instâncias i3.8xlarge de 32 núcleos que também mostram o crescimento da memória roubada, mas não acabam travando / gerando erros de falta de memória. A única diferença (além da escala) é que os servidores de 64 núcleos possuem 2 nós NUMA.

Atualização: MS indicou que a correção de bug no KB4536005 não está sendo portada para SQL2016.

Eu tenho um usuário em um banco de dados SQL Server 2014 que só tem permissões para inserir em uma tabela (sem permissões de seleção). Quando o rastreamento de alterações estiver ativado na tabela, as inserções falharão comThe SELECT permission was denied on the object ...

Por que este é o caso?

Passos para reproduzir:

USE [master];
CREATE DATABASE insert_test;
GO
USE insert_test;
GO
CREATE TABLE dbo.test(id INT NOT NULL IDENTITY(1,1) PRIMARY KEY, value NVARCHAR(50));
ALTER DATABASE insert_test SET CHANGE_TRACKING=ON;
ALTER TABLE dbo.test ENABLE CHANGE_TRACKING;
GO
CREATE LOGIN test_user WITH PASSWORD='FD3nIk1p(4$LKH!eSY';
CREATE USER test_user FOR LOGIN test_user;
GRANT INSERT ON dbo.test TO test_user;
GO
EXECUTE AS USER='test_user';
INSERT INTO dbo.test(value) VALUES(N'hello');  -- Fails with: The SELECT permission was denied on the object 'test', database 'insert_test', schema 'dbo'

/*
-- Cleanup
USE [master];
GO
DROP DATABASE insert_test;
GO
DROP LOGIN test_user;
GO
*/

Estou envolvido no gerenciamento de um aplicativo com um grande número de bancos de dados SQL Server 2014 e estou extraindo tamanhos de tabela e índice para rastrear a capacidade. Estou usando a seguinte consulta:

select
    db_name() as DBName,
    object_schema_name(i.object_id) as SchemaName,
    object_name(i.object_id) as TableName,
    isnull(i.name,'(HEAP)') as IndexName,
    ps.SizeInPages
from
    sys.indexes i
        inner join 
        (
            select ps.object_id,ps.index_id,sum(ps.row_count) as IndexRows, sum(ps.used_page_count) as SizeInPages, count(*) as PartitionCount
            from sys.dm_db_partition_stats ps
            group by ps.object_id,ps.index_id
        ) ps on 
            ps.object_id = i.object_id and
            ps.index_id = i.index_id
where
    object_schema_name(i.object_id) not in ('cdc','sys')

Idealmente, eu gostaria de executar esta consulta a partir de um SQL Login com as permissões mínimas necessárias, mas até agora parece que o usuário precisa VIEW SERVER STATEe SELECTpermissões em todas as tabelas. Também tentei colocar a consulta acima em um procedimento armazenado e conceder EXECUTEpermissões à conta do usuário, mas sys.indexesainda é filtrada com base no que o usuário tem direitos de seleção.

Existe outra maneira de fazer isso que estou perdendo?

Eu tenho uma tabela de aproximadamente 1 bilhão de linhas. Eu então crio um índice da seguinte forma:

CREATE NONCLUSTERED INDEX [IX_Index1] 
ON [dbo].[MyTable]( [CustomerID] ASC )  -- CustomerID is uniqueidentifier
WITH (DATA_COMPRESSION=PAGE);

Isso resulta em um índice de 9,15 GB (compactado), no entanto, o log de transações passou de vazio para 158 GB enquanto o índice estava sendo criado (nenhuma outra atividade de banco de dados). Por que a quantidade de espaço de log usada é muito maior do que o tamanho resultante do índice?

O banco de dados é o SQLServer 2014 Enterprise em modo de recuperação total em um grupo de disponibilidade.

Atualização Larguei e recriei o índice com a opção SORT_IN_TEMPDB = ON. As gravações de log de transações resultantes foram 10,4 GB para o tlog do banco de dados e 1,27 GB para o tempdb tlog.