Fajela Tajkiya's questions

Estive lendo a documentação da Microsoft sobre backups de log no SQL Server e me deparei com a seguinte declaração:

(Log Backup) Especifica um backup somente do log de transações. O backup do log é feito desde o último backup de log executado com êxito até o final atual do log. Antes de poder criar o primeiro backup de log, você deve criar um backup completo."

A partir disso, entendo que um backup de log faz backup dos registros do último backup de log. No entanto, também sei que os backups diferenciais e completos também incluem alguns registros de log. Isso me leva à minha pergunta:

Os backups de log também incluem os registros de log dos quais foi feito backup nos backups completos ou diferenciais anteriores? Ou um backup de log faz backup estritamente dos registros de log a partir do último backup de log, com backups completos ou diferenciais não intervindo ou afetando o que é copiado no backup de log subsequente?

Qualquer introspecção seria muito bem recebida. Desde já, obrigado!

Tenho trabalhado com SQL Server e seus tipos de instância - padrão e nomeada. Meu entendimento sempre foi que para conectar-se a uma instância nomeada, é necessário especificar o nome da instância. No entanto, descobri recentemente que, se eu definir a porta TCP como 1433, posso me conectar à instância nomeada sem precisar especificar o nome da instância e sem precisar definir aliases.

Estou curioso para saber se esse é o comportamento esperado. Não consegui encontrar nenhuma documentação que explique ou confirme esse comportamento. Alguém pode fornecer algumas dicas sobre isso? É normal poder conectar-se a uma instância nomeada sem fornecer o nome da instância quando a porta TCP está definida como 1433?

Agradeço qualquer esclarecimento sobre este assunto.

Desde já, obrigado!

Olá comunidade do SQL Server,

Estou tentando aprofundar minha compreensão dos threads de trabalho do SQL Server, especialmente no que diz respeito à configuração máxima de threads de trabalho em um sistema OLTP ocupado. Atualmente estou trabalhando com o sys.dm_os_threadsDMV e explorando a melhor forma de otimizar o gerenciamento de threads em nosso servidor.

Meu entendimento atual é que o SQL Server gerencia automaticamente os threads de trabalho com base na carga de trabalho do sistema se a configuração padrão de máximo de threads de trabalho permanecer inalterada. O SQL Server pode alocar mais threads de trabalho para lidar com cargas de trabalho maiores e pode recuperar ou destruir esses threads quando as tarefas forem concluídas, embora isso possa não ocorrer imediatamente.

No entanto, não tenho certeza se meu entendimento está correto, principalmente quando se trata de situações em que o SQL Server pode ter atingido seu limite para a criação de novos threads. Se isso acontecer e ainda houver novas solicitações recebidas, isso poderá resultar em uma condição de 'agendador de impasse'? Recentemente, enfrentamos esse problema em nosso ambiente e estou tentando entender se essa pode ser a causa.

Diante desse contexto, tenho algumas perguntas:

• Em um sistema OLTP ocupado, deveríamos considerar alterar a configuração máxima de threads de trabalho de seu valor padrão calculado pela fórmula da Microsoft?
• Se devêssemos alterá-lo, deveria ser para um número maior que o padrão?
• Qual a melhor forma de determinar o número ideal de threads de trabalho máximos para nosso ambiente específico para evitar o problema do 'agendador de deadlock'?

Seus insights ou conselhos sobre este assunto seriam muito apreciados. Obrigado.

Estive lendo a documentação do SQL Server e me deparei com a seguinte declaração sobre pontos de verificação automáticos:

Emitido automaticamente em segundo plano para atender ao limite de tempo superior sugerido pela opção de configuração do servidor de intervalo de recuperação. Os pontos de verificação automáticos são executados até a conclusão. Os pontos de verificação automáticos são limitados com base no número de gravações pendentes e se o Mecanismo de Banco de Dados detecta um aumento na latência de gravação acima de 50 milissegundos.

Estou tentando entender o que significa "Pontos de verificação automáticos executados até a conclusão". Não sou falante nativo de inglês e esta frase me parece muito estranha. Há algum ponto de verificação que não foi concluído e realiza apenas metade do seu trabalho?

Além disso, lembro-me de uma declaração de Paul Randal onde ele mencionou que o processo de checkpoint limitará IOs pendentes se a latência de IO for superior a 20 ms. Durante o desligamento, esse limite aumenta para 100 ms para agilizar o processo. No entanto, a documentação do SQL Server sugere um limite de 50 milissegundos para limitar os pontos de verificação automáticos. Houve uma alteração no valor limite ou estou entendendo mal o conceito?

Qualquer esclarecimento sobre estes pontos seria muito apreciado.

Agradeço antecipadamente!

Faço parte da equipe de banco de dados da minha empresa e atualmente estou enfrentando um dilema em relação à otimização e desempenho de consultas. Sempre que alguns de meus colegas se deparam com uma consulta lenta, a solução padrão é criar um índice para acelerá-la. Isso resultou em algumas tabelas com mais de 70 índices!

Pessoalmente, tendo a abordar esta questão de forma diferente. Em vez de criar novos índices a cada vez, muitas vezes me pego modificando os índices existentes, como adicionar uma coluna incluída adicional, etc., para acelerar uma consulta. Contudo, nem todos os membros da equipe adotam essa abordagem, levando a um número crescente de índices em nosso banco de dados.

Apesar desses esforços, notei uma desaceleração em outras operações DML à medida que o número de índices aumenta. Parece um beco sem saída: sem o índice, a consulta fica lenta, mas com o índice, todo o resto fica um pouco mais lento.

Estou procurando conselhos sobre como navegar nessa situação. Quantos índices são geralmente considerados “demais”? Existem práticas recomendadas ou estratégias para equilibrar a necessidade de consultas rápidas com o desempenho geral do banco de dados?

Quaisquer insights ou recursos seriam muito apreciados.

Obrigado!

Atualmente estou brincando com fn_dbloga função do SQL Server e me deparei com um conceito que estou tendo dificuldade para entender. No resultado da função, há uma coluna 'ID da página' e uma coluna 'ID do slot', combinação correspondente a um único registro de log.

Minha pergunta é: isso significa que um registro de log só pode (no máximo) descrever a modificação de uma única linha?

Estou tentando obter uma compreensão mais profunda de como o SQL Server gerencia e representa modificações de dados, principalmente no que diz respeito à função fn_dblog, portanto, quaisquer insights ou recursos serão muito apreciados.

Estou experimentando índices clusterizados e não clusterizados no SQL Server e notei algo interessante.

Aqui está uma versão simplificada do meu código T-SQL:

IF OBJECT_ID('dbo.dept') IS NOT NULL DROP TABLE dbo.dept;
CREATE TABLE dept(id INT, name NVARCHAR(20), address NVARCHAR(50));
GO

INSERT INTO dept(id, name, address) VALUES (1, 'Dept 1', 'Sarjapur Road');
INSERT INTO dept(id, name, address) VALUES (2, 'Dept 2', 'Whitefield');
INSERT INTO dept(id, name, address) VALUES (3, 'Dept 3', 'Electronic City');
INSERT INTO dept(id, name, address) VALUES (4, 'Dept 4', 'Koramangala');
GO

CREATE CLUSTERED INDEX cl ON dbo.dept(id);
CREATE INDEX ncl ON dbo.dept(address);
GO

SELECT *, %%lockres%% lock, %%physloc%% physloc, sys.fn_PhysLocFormatter(%%physloc%%) formatted
FROM dbo.dept WITH (NOLOCK, INDEX (cl))

SELECT *, %%lockres%% lock, %%physloc%% physloc, sys.fn_PhysLocFormatter(%%physloc%%) formatted
FROM dbo.dept WITH (NOLOCK, INDEX (ncl))

E aqui está o resultado:

+----+--------+-----------------+----------------+--------------------+------------+
| id | name   | address         | lock           | physloc            | formatted  |
+----+--------+-----------------+----------------+--------------------+------------+
|  1 | Dept 1 | Sarjapur Road   | (de42f79bc795) | 0xB01F000004000000 | (4:8112:0) |
|  2 | Dept 2 | Whitefield      | (9d6bf8154a2a) | 0xB01F000004000100 | (4:8112:1) |
|  3 | Dept 3 | Electronic City | (052c8c7d9727) | 0xB01F000004000200 | (4:8112:2) |
|  4 | Dept 4 | Koramangala     | (1a39e6095155) | 0xB01F000004000300 | (4:8112:3) |
+----+--------+-----------------+----------------+--------------------+------------+

+----+--------+-----------------+----------------+--------------------+-----------+
| id | name   | address         | lock           | physloc            | formatted |
+----+--------+-----------------+----------------+--------------------+-----------+
|  3 | Dept 3 | Electronic City | (b64f1cd4ff4f) | 0x1800000003000000 | (3:24:0)  |
|  4 | Dept 4 | Koramangala     | (4471456166ef) | 0x1800000003000100 | (3:24:1)  |
|  1 | Dept 1 | Sarjapur Road   | (7948805432b9) | 0x1800000003000200 | (3:24:2)  |
|  2 | Dept 2 | Whitefield      | (584262fe5906) | 0x1800000003000300 | (3:24:3)  |
+----+--------+-----------------+----------------+--------------------+-----------+

Como você pode ver, o lock e o physloc para os dois conjuntos de resultados são muito diferentes. No passado, sempre acreditei que essas pseudocolunas revelavam informações sobre a dbo.depttabela (o índice clusterizado ou o heap), já que estou selecionando a partir dela. Mas estes testes parecem provar que mostram informações sobre como os dados são acessados. Meu entendimento está correto?

Estive lendo uma postagem no blog de Paul Randal sobre o processo de backup do SQL Server, onde ele descreve as principais fases de um backup completo. Um ponto que ele menciona é que durante um backup completo, o processo lê "todas as extensões alocadas, independentemente de todas as 8 páginas da extensão estarem em uso".

Um backup completo tem as seguintes fases principais:

• Execute um ponto de verificação.
• Leia todos os dados em uso dos arquivos de dados (tecnicamente, lendo todas as extensões alocadas, independentemente de todas as 8 páginas da extensão estarem em uso).
• Leia todo o log de transações desde o início da transação não confirmada mais antiga, desde o ponto de verificação inicial até o momento em que a fase 2 terminou. Isso é necessário para que o banco de dados possa ser recuperado para um ponto consistente durante o processo de restauração (veja esta postagem para mais detalhes).
• (Opcionalmente, teste todas as somas de verificação da página, opcionalmente execute a compactação de backup e, opcionalmente, execute a criptografia de backup).

Essa afirmação me levou a pensar sobre os detalhes do que exatamente é feito o backup. Especificamente, o processo de backup inclui todas as extensões alocadas, mesmo que nem todas as páginas dentro dessas extensões estejam em uso?

Eu apreciaria quaisquer insights ou esclarecimentos sobre este tópico. Agradeço antecipadamente por sua ajuda!

Abaixo, o cenário de duas sessões tentando atualizar a mesma linha foi fornecido por Paul White.

Cenário 1:

1. A sessão 1 obtém um Ubloqueio na linha da tabela base durante a leitura.
2. Blocos da sessão 2, aguardando aquisição Una mesma linha da tabela base.
3. A sessão 1 define o valor como 10 e confirma.
4. A sessão 2 adquire seu Ubloqueio e não encontra nada para fazer, pois Value != 0 agora.

Resultado: o valor é definido como 10.

Com base em Paul, a sessão 2 já localizou a linha que precisa ser atualizada, mas foi bloqueada. Quando o bloqueio acabar e a sessão 2 obtiver o bloqueio U, será necessário verificar a condição novamente? Estou entendendo certo? Para mim é meio estranho. A sessão localizou esta linha porque avaliou o filtro que leva à identificação desta linha. Por que é necessário verificar a condição novamente antes da atualização real?

Uma das minhas unidades de arquivo de log do banco de dados de produção foi preenchida e notei as mensagens abaixo no log de erros do SQL Server.

2022-02-13 03:16:24.500 spid72  Error: 9002, Severity: 17, State: 4.
2022-02-13 03:16:24.500 spid72  The transaction log for database 'huge_database' is full due to 'ACTIVE_TRANSACTION'.
2022-02-13 03:16:26.060 spid72  Error: 9002, Severity: 17, State: 4.
2022-02-13 03:16:26.060 spid72  The transaction log for database 'huge_database' is full due to 'ACTIVE_TRANSACTION'.
2022-02-13 03:16:26.070 spid72  Error: 3314, Severity: 21, State: 3.
2022-02-13 03:16:26.070 spid72  During undoing of a logged operation in database 'huge_database', an error occurred at log record ID (2766:550754:254). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2022-02-13 03:16:26.090 spid72  Database huge_database was shutdown due to error 3314 in routine 'XdesRMReadWrite::RollbackToLsn'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.
2022-02-13 03:16:26.090 spid72  Error: 3314, Severity: 21, State: 5.
2022-02-13 03:16:26.090 spid72  During undoing of a logged operation in database 'huge_database', an error occurred at log record ID (2678:51796:1). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
2022-02-13 03:16:32.900 spid48s Starting up database 'huge_database'.
2022-02-13 03:16:37.980 spid48s Recovery of database 'huge_database' (20) is 0% complete (approximately 89573 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
2022-02-13 03:16:57.980 spid48s Recovery of database 'huge_database' (20) is 0% complete (approximately 60835 seconds remain). Phase 2 of 3. This is an informational message only. No user action is required.
...
2022-02-13 04:26:15.160 spid36s Recovery of database 'huge_database' (20) is 85% complete (approximately 721 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
...
2022-02-13 04:36:35.230 spid36s Recovery of database 'huge_database' (20) is 99% complete (approximately 1 seconds remain). Phase 3 of 3. This is an informational message only. No user action is required.
2022-02-13 04:36:35.790 spid36s 1 transactions rolled back in database 'huge_database' (20:0). This is an informational message only. No user action is required.
2022-02-13 04:36:35.790 spid36s Recovery is writing a checkpoint in database 'huge_database' (20). This is an informational message only. No user action is required.
2022-02-13 04:36:36.850 spid36s Recovery completed for database huge_database (database ID 20) in 4804 second(s) (analysis 4881 ms, redo 1196931 ms, undo 3600721 ms.) This is an informational message only. No user action is required.  

Parece que a unidade de log do banco de dados está cheia e iniciou um processo de recuperação, que levou mais de uma hora. Por que ele precisa se recuperar neste caso? Eu quero reproduzi-lo, mas não consegui. Abaixo está o meu código:

CREATE DATABASE MyDatabase
ON 
    (NAME = MyDatabase_Data,
    FILENAME = 'f:\mssql\data\MyDatabase_Data.mdf',
    SIZE = 10MB,
    MAXSIZE = 1000MB,
    FILEGROWTH = 5MB)
LOG ON
    (NAME = MyDatabase_Log,
    FILENAME = 'U:\data\MyDatabase_Log.ldf',
    SIZE = 5MB,
    MAXSIZE = 500MB,
    FILEGROWTH = 1MB);
GO

USE MyDatabase;
GO

CREATE TABLE MyTable (
    ID INT IDENTITY(1,1) PRIMARY KEY,
    Data VARCHAR(MAX) NOT NULL
);
GO

BEGIN TRANSACTION;

DECLARE @i INT = 0;
WHILE @i < 1000000
BEGIN
    INSERT INTO MyTable (Data) VALUES (REPLICATE('A', 8000));
    SET @i = @i + 1;
END;

-- Don't commit the transaction
-- COMMIT TRANSACTION;

Quando executo meu código, recebo isso no SSMS:

Msg 9002, Nível 17, Estado 4, Linha 30 O log de transação do banco de dados 'MyDatabase' está cheio devido a 'ACTIVE_TRANSACTION' e o lsn de assalto é (39:24:1).

E isso do log de erros do SQL Server:

2023-08-18 02:59:54.200 spid84  Error: 17053, Severity: 16, State: 1.
2023-08-18 02:59:54.200 spid84  U:\data\MyDatabase_Log.ldf: Operating system error 112(There is not enough space on the disk.) encountered.
2023-08-18 02:59:55.200 spid84  Error: 9002, Severity: 17, State: 4.
2023-08-18 02:59:55.200 spid84  The transaction log for database 'MyDatabase' is full due to 'ACTIVE_TRANSACTION' and the holdup lsn is (39:24:1).  

Não há processo de recuperação. Por que? Como imitar meu problema de banco de dados de produção?

Atualizar:

Aliás, durante a recuperação do meu banco de dados de produção, ainda consigo acessá-lo. Ele ainda tem o mesmo status que em outros bancos de dados em sys.databases. Isso é esperado? Embora os bancos de dados em recuperação não estejam acessíveis.

Atualização2:

Ao desfazer uma operação registrada no banco de dados 'huge_database', ocorreu um erro no ID do registro de log (2678:51796:1).

Este log de erro parece que o SQL não reservou espaço suficiente para reverter. Lembrei que Paul Randal disse que o SQL Server sempre reserva algum log para rollback. Se sim, por que isso pode acontecer?

Estou trabalhando com SQL Server e tenho duas tabelas, table1e table2. Ambas as tabelas têm uma DATETIMEcoluna indicada como dt. Preciso unir essas tabelas com base não apenas em certas condições, mas também para garantir que as linhas correspondentes tenham a mesma data (a hora não é considerada aqui) da dtcoluna.

Aqui está a consulta que estou usando atualmente:

select *
From table1 a inner join table2 b
    on a.id = b.a_id
    and convert(date, a.dt) = convert(date, b.dt)

Essa consulta funciona para obter os resultados de que preciso, mas estou preocupado com seu desempenho, especialmente à medida que as tabelas aumentam de tamanho.

Eu estou querendo saber se existem maneiras mais eficazes para alcançar o mesmo resultado? Existem técnicas ou recursos do SQL Server que possam me ajudar a otimizar essa consulta, principalmente a parte de comparação de datas?

Qualquer conselho ou sugestão seria muito apreciada. Agradeço antecipadamente.

Estou trabalhando com uma sessão de evento estendida no SQL Server e encontrei uma parte do código T-SQL que não entendo totalmente. Especificamente, estou intrigado com o uso de "Mode = 3 OR Mode = 4" na seguinte parte do código:

...
ADD EVENT sqlserver.latch_suspend_end
(WHERE (
Duration > 0
AND (Mode = 3 OR Mode = 4)
AND has_waiters = 1
)
)
...

Tenho tentado encontrar documentação ou qualquer tipo de informação que explique o que "Mode = 3" e "Mode = 4" representam neste contexto, mas até agora não tive sorte.

Além disso, estou interessado em encontrar uma fonte abrangente de documentação ou referência que descreva as propriedades e possíveis valores para diferentes eventos, não apenas para este exemplo específico. Alguém poderia me indicar a documentação relevante ou explicar o que esses valores de modo significam nesta sessão de evento estendida?

Agradeço antecipadamente por sua ajuda!

Eu sei que existe um DBCC INPUTBUFFERcomando no SQL Server, que

Exibe a última instrução enviada de um cliente para uma instância do SQL Server.

Para mim, parece que o buffer de entrada é o SQL que uma sessão está executando.

O SQL Server também possui sys.dm_exec_sql_text, que

Retorna o texto do lote SQL identificado pelo sql_handle especificado.

E sys.dm_exec_input_buffer, qual

Retorna informações sobre instruções enviadas a uma instância do SQL Server.

Estou meio confuso. Eles parecem muito semelhantes e não identificáveis ​​para mim.

Também encontrei um artigo Understanding the sql_text Action in Extended Events de Jonathan Kehayias. No artigo, ele afirma

Com esta sessão de evento criada, podemos executar alguns cenários de teste diferentes no ambiente para mostrar como esta ação não é o sql_text, mas sim o input_buffer para o evento que está sendo disparado

Ele está muito confiante de que o texto SQL não é um buffer de entrada, e não entendo o motivo. Alguém poderia ajudar a esclarecer um pouco por favor? Obrigado.

Estou tentando entender o significado da coluna "Tamanho" na saída do RESTORE FILELISTONLYcomando no SQL Server quando é usado com backups diferenciais e de log.

Para backups completos, entendo que o valor "Tamanho" representa o tamanho do arquivo no disco após a restauração do backup. No entanto, não tenho certeza de como interpretar esse valor para backups diferenciais e de log. Isso significa que depois de restaurar o backup, o arquivo no disco aumentará desse tamanho?

Aqui está um exemplo de RESTORE FILELISTONLYresultado para um backup diferencial:

+-------------+---------------+------+---------------+----------+
| LogicalName | PhysicalName  | Type | FileGroupName | Size     |
+-------------+---------------+------+---------------+----------+
| dx          | F:\dx.mdf     | D    | PRIMARY       | 83788608 |
| dx_log      | F:\dx_log.ldf | L    | NULL          | 46385562 |
+-------------+---------------+------+---------------+----------+

E aqui está um exemplo para um backup de log:

+-------------+---------------+------+---------------+----------+
| LogicalName | PhysicalName  | Type | FileGroupName | Size     |
+-------------+---------------+------+---------------+----------+
| dx          | F:\dx.mdf     | D    | PRIMARY       | 19386301 |
| dx_log      | F:\dx_log.ldf | L    | NULL          |  3327087 |
+-------------+---------------+------+---------------+----------+

Alguém pode me ajudar a entender a coluna "Tamanho" nesses cenários?

Estou fazendo alguns testes com grupo de disponibilidade no SQL Server. Quando estou na réplica primária, posso ver que todos os nós de réplica têm um ícone de atualização neles.

Mas quando verifico uma réplica secundária, todos os outros nós têm um ponto de interrogação em seus nomes de réplica. O que isso significa?

Aliás, estou usando SSMS 18 com SQL Server 2022.

Eu tenho a seguinte instrução TSQL, que geralmente é executada em várias sessões em paralelo e leva a sérias esperas de pagelatch_ex:

DELETE dbo.huge_table1  
WHERE c1 = 0  
      AND c3 IN (SELECT v FROM dbo.string_split(@c3_list));  

Capturei a carga de trabalho e descobri que muitas vezes o @c3_list passado não resulta em nenhuma linha a ser excluída. Considerando que DELETE sempre requer um bloqueio exclusivo, gostaria de saber se a reescrita a seguir poderia ajudar a reduzir as esperas de pagelatch_ex. Essencialmente, ele divide o DELETE em duas etapas: primeiro verificar se há alguma linha que precisa ser excluída e, em seguida, excluí-la.

INSERT INTO #tmp (c3)   
SELECT c3  
FROM dbo.huge_table1  
WHERE c1 = 0   
      AND c3 IN (SELECT v FROM dbo.string_split(@c3_list) );   

IF @@rowcount > 0
    DELETE t1 
    FROM dbo.huge_table1 t1 
        JOIN #tmp t2  
            ON t2.c3 = t1.c3; 

Minha lógica é que uma instrução select usa apenas a trava pagelatch_sh. Se nenhuma linha precisar ser excluída, nenhum pagelatch_ex desnecessário será gerado.

Essa reescrita ajudaria a reduzir as esperas de pagelatch_ex? Agradecemos antecipadamente por qualquer insights!

Percebi na documentação do SQL Server que os LSNs (Log Sequence Numbers) às vezes são descritos como numeric(25,0) e outras vezes como binary(10). Por que existem dois tipos de dados diferentes usados ​​para LSNs? Quando devo usar cada tipo?

https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/recover-to-a-log-sequence-number-sql-server?view=sql-server-ver16

LSNs são valores do tipo de dados numeric(25,0). Operações aritméticas (por exemplo, adição ou subtração) não são significativas e não devem ser usadas com LSNs.

https://learn.microsoft.com/en-us/sql/relational-databases/system-tables/cdc-lsn-time-mapping-transact-sql?view=sql-server-ver16

start_lsn binário(10)

No SQL Server, podemos usar set statistics profile onpara habilitar a criação de perfil para uma sessão. Em seguida, você pode executar qualquer instrução e o plano de execução correspondente será mostrado em forma de tabela. É possível salvar esse plano de formulário popular em alguma tabela para que eu possa filtrá-lo?

O exemplo deste plano de execução de formulário de tablet é assim:

Recentemente notei uma mensagem de erro em meu log de erros do SQL Server que dizia "O processador de consulta ficou sem recursos internos e não pôde produzir um plano de consulta." Suspeito que meu servidor esteja ficando sem memória ou recursos de CPU. No entanto, não tenho certeza de como confirmar isso.

Estou ciente dos comandos sysprocesses e sp_whoisactive, mas não tenho certeza se eles podem me dizer se meu servidor está ficando sem recursos neste momento.

Alguém poderia me fornecer algumas orientações sobre como verificar se meu SQL Server está ficando sem memória ou recursos de CPU? Qualquer ajuda seria apreciada.

Percebi que existem duas sintaxes de comando para alterar as configurações do banco de dados no SQL Server - ALTER DATABASE SCOPED CONFIGURATION e ALTER DATABASE SET. No entanto, não estou claro sobre quais configurações de banco de dados se enquadram em cada sintaxe.

Por exemplo, sei que a compatibilidade do banco de dados é uma configuração específica do banco de dados, mas usa a sintaxe ALTER DATABASE SET. Isso me faz pensar por que ele não usa a sintaxe ALTER DATABASE SCOPED CONFIGURATION.

Então, minha pergunta é: você tem algum guia mental que ajude a identificar quais configurações de banco de dados se enquadram em qual sintaxe? Eu apreciaria qualquer insight ou informação sobre este tópico.