Repositório de consultas - aumentar max_storage_size_mb (retenção do repositório de consultas, tamanho máximo) funciona por um curto período e depois volta para 250?

A configuração não deve ser alterada por conta própria.

Você pode ver quem ou o que está alterando e quando, configurando uma sessão de eventos estendidos como esta:

CREATE EVENT SESSION [alter_statements] ON SERVER 
ADD EVENT sqlserver.object_altered
(
    ACTION(sqlserver.nt_username,sqlserver.server_principal_name)
    WHERE ([object_name]=N'QDSTest')
)
ADD TARGET package0.event_file (SET filename=N'alter_statements')
WITH (STARTUP_STATE=OFF)
GO

ALTER EVENT SESSION [alter_statements] ON SERVER 
STATE = START;
GO

Você precisaria substituir "QDSTest" pelo nome do banco de dados de interesse no seu caso.

Com isso, você poderá encontrar o nome de usuário associado à sessão que emitiu a ALTER TABLEinstrução que alterou as configurações do armazenamento de consultas, o que esperamos ser útil para rastrear quem ou o que está alterando isso.

Uma possibilidade é que você tenha implantações automatizadas para esse banco de dados que usam uma abordagem baseada em modelo (como implantações dacpac do SQL Server Data Tools). Se o "modelo" tiver o repositório de consultas configurado de uma determinada maneira, cada implantação tentará alterar as configurações de volta para o que está no modelo.

Gatilhos

Uma alternativa seria criar um gatilho para capturar e registrar os dados e, em seguida, revisar os dados após observar uma alteração.

Primeiro, você precisará de uma tabela:

CREATE TABLE 
    master.dbo.trigger_log
(
    id int PRIMARY KEY IDENTITY,
    PostTime datetime,
    LoginName sysname,
    CommandText nvarchar(4000)
);

Em seguida, você precisará de um gatilho:

CREATE OR ALTER TRIGGER [query_store_shenanigans] 
    ON ALL SERVER
    FOR ALTER_DATABASE
AS
SET NOCOUNT, XACT_ABORT ON;
BEGIN
      DECLARE 
          @command nvarchar(4000) = 
              (
                  SELECT 
                      EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]', 'nvarchar(4000)') 
              );

      IF UPPER(@command) LIKE '%SET QUERY_STORE%'
      BEGIN
      
          INSERT 
              master.dbo.trigger_log
          (
              PostTime,
              LoginName,
              CommandText
          )
          SELECT
              PostTime = 
                  x.c.value('(PostTime)[1]', 'datetime'),
              LoginName = 
                  x.c.value('(LoginName)[1]', 'nvarchar(128)'),
              CommandText = 
                  @command
          FROM
          (
              SELECT 
                  event_data = EVENTDATA()
          ) AS e
          CROSS APPLY e.event_data.nodes('/EVENT_INSTANCE') AS x(c);

      END
END;
GO

E um comando para testar o log:

ALTER DATABASE StackOverflow 
    SET QUERY_STORE 
    ( 
        WAIT_STATS_CAPTURE_MODE = ON 
    );

Uma consulta para revisar a tabela de log:

SELECT 
    tl.* 
FROM master.dbo.trigger_log AS tl;

Aqui estão os resultados que recebo localmente depois de executar algumas variações do comando:

Concordo com Josh Darnell que você deve configurar uma sessão de evento estendido, mas recomendo um evento mais específico. Eu usei isso recentemente para solucionar problemas do repositório de consultas.

CREATE EVENT SESSION [QueryStoreSettings] ON SERVER 
ADD EVENT qds.query_store_db_settings_changed
(
    ACTION
    (
        sqlserver.client_app_name,
        sqlserver.client_hostname,
        sqlserver.database_name,
        sqlserver.server_instance_name,
        sqlserver.sql_text,
        sqlserver.username
    )
)
ADD TARGET package0.event_file(SET filename=N'QueryStoreSettings',max_file_size=(5),max_rollover_files=(10))
WITH (STARTUP_STATE=OFF)
GO

ALTER EVENT SESSION [QueryStoreSettings] ON SERVER 
STATE = START;
GO

Esta é a saída que obtive ao fazer as alterações usando a GUI