Tabela grande com dados históricos aloca muito do SQL Server 2008 Std. memória - perda de desempenho para outros bancos de dados

Com base nesta pergunta e nas respostas dadas:

SQL 2008 Server - perda de desempenho possivelmente relacionada a uma tabela muito grande

Eu descobri um problema de alocação de memória com o SQL Server 2008.

Basicamente, temos 3 bancos de dados (EkDB cca 300 MB, SupervisionP cca 8 GB e Tarmac42 cca 42 GB) em 1 SQL Server e uma tabela muito grande fica na memória. O consumo de memória é assim:

Quase 6 GB são alocados por apenas uma tabela PenData com cerca de 211 milhões de linhas.

Esta tabela é definida da seguinte forma:

CREATE TABLE [dbo].[PenData](
    [IDUkazatel] [smallint] NOT NULL,
    [Cas] [datetime2](0) NOT NULL,
    [Hodnota] [real] NULL,
    [HodnotaMax] [real] NULL,
    [HodnotaMin] [real] NULL,
 CONSTRAINT [PK_Data] PRIMARY KEY CLUSTERED 
(
    [IDUkazatel] ASC,
    [Cas] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

ALTER TABLE [dbo].[PenData]  WITH NOCHECK ADD  CONSTRAINT [FK_Data_Ukazatel] FOREIGN KEY([IDUkazatel])
REFERENCES [dbo].[Ukazatel] ([IDUkazatel])

ALTER TABLE [dbo].[PenData] CHECK CONSTRAINT [FK_Data_Ukazatel]

Esta tabela contém muitos registros históricos que não são usados ​​ou usados ​​muito raramente e os dados são sempre acessados ​​usando condições como esta

 WHERE IDUkazatel=@a AND Cas BETWEEN @b AND @c

nunca sem esta condição. Os dados estão sendo inseridos a cada hora em uma série de inserções em massa, o banco de dados cresce cerca de 10 MB por dia.

Tentei excluir alguns registros (83 milhões) e, em seguida, executar o DBCC SHRINKDATABASE - parecia promissor no momento, mas no dia seguinte o SupervisionP ocupou novamente 5-6 GB.

Não consigo encontrar nenhuma razão para o SQL Server alocar tanta memória para esta tabela. O problema é que os dados armazenados em cache dos outros bancos de dados são descarregados regularmente e as consultas neles estão sendo executadas mais lentamente antes que os dados sejam carregados na memória novamente.

EDITAR

Esqueci de mencionar que é a edição Standard do SQL Server... Portanto, o particionamento não é possível. Eu considerei isso, mas não observei que é apenas para edição corporativa.

EDITAR 2

Eu examinei todos os procedimentos armazenados e devo admitir que existem vários comandos SQL que podem acessar mais linhas do que eu supunha, ou seja

SELECT @minCas=MIN(cas) FROM PenData WHERE IDUkazatel=@IDUkazatel 

SELECT @StazenoDoReal=MAX(cas) from PenData p INNER JOIN Ukazatel u ON u.IDUkazatel=p.IDUkazatel WHERE u.IDZapisovac=@IDZapisovac 

SELECT  TOP 365   DATEADD(dd, 0, DATEDIFF(dd, 0, dbo.PenData.Cas)) AS Den, MAX(dbo.PenData.Hodnota) AS MaxHodnota
FROM         dbo.Zapisovac INNER JOIN
                      dbo.VyrobniLinka ON dbo.Zapisovac.IDVyrobniLinka = dbo.VyrobniLinka.IDVyrobniLinka INNER JOIN
                      dbo.Ukazatel ON dbo.Zapisovac.IDZapisovac = dbo.Ukazatel.IDZapisovac INNER JOIN
                      dbo.PenData ON dbo.Ukazatel.IDUkazatel = dbo.PenData.IDUkazatel
WHERE     /*(dbo.PenData.Cas >= @Od) AND (dbo.PenData.Cas <= @Do) AND*/ (dbo.Zapisovac.IDVyrobniLinka = @IDVyrobniLinka AND dbo.Zapisovac.IDTypZapisovace!=4)
GROUP BY DATEADD(dd, 0, DATEDIFF(dd, 0, dbo.PenData.Cas)), ISNULL(dbo.Ukazatel.MinHodnotaProvoz, 10)
HAVING MAX(dbo.PenData.Hodnota)>ISNULL(dbo.Ukazatel.MinHodnotaProvoz, 10) OR MAX(dbo.PenData.Hodnota) IS NULL
ORDER BY Den DESC

O SELECT MIN de todos os registros precisa ler todos os registros o tempo todo? Acho que sim, talvez uma pergunta boba...

EDITAR 3

Então fiz o seguinte teste. Eu restaurei o banco de dados SupervisionP no servidor de teste. Após a restauração, ocupou apenas 1 MB no cache. Então eu executo esta consulta simples:

  SELECT MIN(cas) FROM PenData

A chave primária em cluster para PenData é um composto como mostrado acima - contendo Time + IndicatorID. Portanto, encontrar o primeiro ou o último registro em um índice clusterizado pode ser uma tarefa relativamente fácil, suponho, para o SQL Server. Mas o uso de memória cresceu muito abruptamente para 1285 MB (o servidor de teste tem 3,5 GB de memória total utilizável). A consulta está fazendo o Clustered Index Scan.

Quando eu faço:

 SELECT MIN(cas)  FROM PenData WHERE IDUkazatel=10

então é Clustered Index Seek e a memória permanece em 1 MB - é muito rápido e OK.

Quando eu corro:

 SELECT MIN(cas) from PenData p WHERE IDUkazatel IN (SELECT IDUkazatel FROM Ukazatel WHERE IDZapisovac=10)

ou

 SELECT min(cas) from PenData p WHERE IDUkazatel=24 OR IDUkazatel=25 OR IDUkazatel=26 OR IDUkazatel=97 OR IDUkazatel=97 OR IDUkazatel=98

então leva muito tempo e a alocação de memória sobe abruptamente. No entanto, os seguintes comandos, que fazem a mesma coisa, são executados em um instante e sem alocação de memória!!

SELECT min(cas) from PenData p WHERE IDUkazatel=24 
SELECT min(cas) from PenData p WHERE IDUkazatel=25
...

EDITAR 5

Abri uma nova pergunta, pois parece que esse comando é o motivo do problema

SELECT @StazenoDoReal=MAX(cas) from PenData p INNER JOIN Ukazatel u ON u.IDUkazatel=p.IDUkazatel WHERE u.IDZapisovac=@IDZapisovac 

Busca de índice muito mais lenta com condição OR em comparação com SELECTs separados