DLLs com otimização de memória não sendo removidas

Na BOL, meu entendimento é que os DBAs não precisam administrar DLLs criadas para tabelas com otimização de memória ou procedimentos armazenados compilados nativamente, pois são recompilados automaticamente quando o serviço SQL Server é iniciado e removido quando não é mais necessário. Mas estou testemunhando que, mesmo depois que uma tabela otimizada para memória foi descartada e o serviço reiniciado, as DLLs ainda existem no sistema de arquivos E ainda são carregadas na memória SQL e anexadas ao processo. Isso pode ser testemunhado pelo fato de que eles ainda estão visíveis em sys_dm_os_loaded_modules e estão bloqueados no sistema de arquivos se você tentar excluí-los, enquanto o Serviço SQL estiver em execução.

Isso é um inseto? Ou eles são limpos posteriormente? Se, posteriormente, o que aciona a limpeza, se não for uma reinicialização da instância?

Isso é um inseto?

Não, não é um bug. É por design. Eles são mantidos para fins de solução de problemas e suporte.

No whitepaper SQL_Server_2014_In-Memory_OLTP

Os administradores de banco de dados não precisam manter os arquivos gerados pela compilação nativa. O SQL Server remove automaticamente os arquivos gerados que não são mais necessários, por exemplo, na exclusão de tabela e procedimento armazenado e no banco de dados descartado, mas também na reinicialização do servidor ou banco de dados.

Tentei reproduzir seu cenário no SQL Server 2014 + RTM + (Build12.0.2000.8)servidor - Dev Edition criando uma tabela otimizada para memória de teste e verificando a dll carregada usando

     SELECT name, description FROM sys.dm_os_loaded_modules
WHERE description = 'XTP Native DLL'

Depois que eu soltei minha tabela, o dllitem ainda aparece na saída da instrução select acima e os arquivos ainda estão na pasta e, após a reinicialização, eles ainda estão lá.

De Livros Online -

Nenhuma interação do usuário é necessária para gerenciar esses arquivos ( .c, .obj, .xml, .pdb., .dll). O SQL Server criará e removerá os arquivos conforme necessário.

Então eu acho que só precisamos seguir o que a Microsoft diz - o SQL Server irá gerenciá-los para nós :-)

SOMENTE PARA FINS EDUCACIONAIS:

Eu consegui limpar os arquivos antigos

• Emitindo um manual CHECKPOINTno banco de dados.
• Colocar o banco de dados offline e colocá-lo online.

Idealmente, você não deve reiniciar a instância do servidor, apenas o ponto de verificação manual e o offline / online do banco de dados limparão os arquivos.

por exemplo, Repro:

USE master
GO
create database db1
GO
ALTER DATABASE db1 ADD FILEGROUP db1_mod CONTAINS memory_optimized_data
GO
-- adapt filename as needed
ALTER DATABASE db1 ADD FILE (name='db1_mod', filename='D:\SQLServer2014\MSSQL12.SQL2014\MSSQL\DATA\db1_mod') -- change here as per your need !!
 TO FILEGROUP db1_mod
GO
USE db1
GO
CREATE TABLE dbo.t1
(c1 int not null primary key nonclustered,
c2 int)
WITH (MEMORY_OPTIMIZED=ON)
GO

--- agora verifique se a dll está carregada ou não

SELECT nome, descrição FROM sys.dm_os_loaded_modules WHERE description = 'XTP Native DLL'

--- agora solte a tabela e faça um ponto de verificação manual

use db1;
drop table dbo.t1;
checkpoint

Ainda assim, o módulo está carregado na memória (até a reinicialização do servidor carregará o módulo algumas vezes )

Os ( .c, .obj, .xml, .pdb., .dll) ainda estão presentes na pasta:

Agora coloque o banco de dados offline e coloque-o on-line - todos os ( .c, .obj, .xml, .pdb., .dll) desapareceram ...