Aleksey Vitsko's questions

Temos uma tabela com 54 colunas, ela é usada por muitos aplicativos, relatórios e usuários. A tabela é de um sistema legado, algumas colunas podem estar obsoletas.

Gostaríamos de descobrir quais colunas exatamente são realmente usadas - por SELECTe UPDATEconsultas. Como isso pode ser descoberto?

Se isso for possível, gostaríamos de recebê-lo no formato abaixo:

Column1 - SELECT - 1,890,123 times 
Column1 - UPDATE - 2,394 times 
Column2 - SELECT - 5,222,456 times 
Column2 - UPDATE - 567 times 
Column3...

Uma ideia era escanear todos os repositórios GIT (código-fonte de apps) para essas colunas, mas alguns apps podem não estar no GIT de fato. E os relatórios não estão no GIT.

A pesquisa acima é para:

1. Para descobrir colunas que não são consultadas e possivelmente se livrar delas.
2. Para descobrir colunas que são muito consultadas e não são atualizadas, revise a possibilidade de criar um índice columnstore não clusterizado.

Criamos uma sessão de Eventos Estendidos para capturar erros com gravidade 16 ou superior:

CREATE EVENT SESSION [Error_Reporting] ON SERVER 
ADD EVENT sqlserver.error_reported(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_name,sqlserver.session_server_principal_name,sqlserver.sql_text,sqlserver.username)
    WHERE ([severity]>(15)))
ADD TARGET package0.event_file(SET filename=N'https://storageaccount.blob.core.windows.net/logs/Errors.xel',max_file_size=(10240), max_rollover_files=1)
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

Agora podemos consultá-lo executando:

select cast(event_data as xml), timestamp_utc
from sys.fn_xe_file_target_read_file('https://storageaccount.blob.core.windows.net/logs/Errors_0_133667581914690000.xel', NULL, NULL, NULL)

A coluna event_dataé do tipo nvarchar, mas contém valores XML, que representam uma tabela.

Pergunta :

Como event_dataa coluna pode ser convertida (dividida) em várias colunas (como UserName, Error_number, Categoria, Destino, Mensagem e assim por diante), quando consultada no editor de texto no SSMS?

Exemplo de dados XML: https://pastecode.io/s/tjg7jo40

Estou olhando para o servidor IIS que hospeda dezenas de aplicativos. Alguns deles são bem antigos. Todos eles usam cadeias de conexão armazenadas em machine.config em C:\Windows\Microsoft.NET\Framework64.

Todas as cadeias de conexão apontam para o SQL Server 2016 e usam System.Data.SqlClient para conexões:

providerName="System.Data.SqlClient" 

O objetivo é migrar dados para a nova Instância Gerenciada de SQL do Azure e substituir cadeias de conexão para que apontem para o novo servidor.

Na Instância Gerenciada de SQL do Azure, a criptografia para conexões é obrigatória, não é possível desligá-la. Você só pode selecionar a versão mínima do TLS (1.0, 1.1 ou 1.2).

As cadeias de conexão MI contêm arquivos Encrypt=True;TrustServerCertificate=False. Tentei configurar Encrypt=Falseo SSMS para teste, mas a consulta sys.dm_exec_connectionsencrypt_option ainda estava aparecendo TRUE.

Todas as versões do System.Data.SqlClient oferecem suporte à criptografia para conexões ou existem algumas versões antigas que não oferecem suporte?

Perguntando isso porque quero evitar situações em que, após a migração, algum aplicativo possa parar de funcionar porque seu driver cliente não suporta criptografia.

Temos uma máquina com 256 GB de RAM.
A memória máxima do servidor para o SQL Server é definida como 180 GB.

De 180 GB, o SQL Server normalmente usa:

• Memória de cache do banco de dados - ~ 140-150 GB
• Cache do plano - ~ 10 GB
• Memória roubada do servidor: ~ 30 GB
• Memória livre: ~ 9 GB
• Memória de espaço de trabalho garantida: geralmente muito baixa, os picos podem ser de 0,5 a 1 GB

Taxa de acerto do Cache de Buffer - paira acima de 99,9% o tempo todo.
A expectativa de vida da página é um número bastante alto.

Tamanho total dos arquivos de dados do banco de dados - 650 GB.
A taxa de crescimento de dados é de cerca de 500-1500 MB diariamente (mas! os dados mais antigos são excluídos a cada 6-8 meses, então, basicamente, os arquivos de dados crescem muito mais lentamente do que isso).

Pergunta

Há um requisito para migrar o SQL Server para outra máquina. Visando o SQL Server 2022 quando for lançado.

É uma carga de trabalho mista do tipo OLTP e OLAP, os mesmos bancos de dados usados ​​por muitos aplicativos; a maior parte da RAM é usada por páginas de banco de dados em cache, o que significa que o SQL Server não precisa lê-la do disco o tempo todo.

Parece que 128 GB para uma nova máquina serão suficientes, com Max Server Memory definido para ~ 110 GB, deixando 18-13 GB para o sistema operacional.

O servidor de destino estará na VM do Azure e lá você não poderá dimensionar vCPU e RAM independentemente um do outro. Uma máquina com 256 GB de RAM terá o dobro de núcleos em comparação com uma máquina de 128 GB, resultando em uma diferença de custo bastante grande. Acho que reduzir o custo em relação ao que foi projetado inicialmente pode trazer benefícios para mim a longo prazo, então acho que vale a pena explorar. No Azure, você pode escalar a qualquer momento, se necessário.

Se você fosse eu, como você provaria cientificamente ao seu gerente que cortar a memória pela metade não vai matar o desempenho do SQL Server, não vai explodir a taxa de acertos do Buffer Cache ou algo assim?

Eu sei que para um DBA, pode parecer seguro reduzir o tamanho desta máquina para 128 GB, já que a carga de trabalho não será alterada. Mas como você convenceria um gerente com base em sua experiência?

De acordo com os links abaixo, NULLos valores ocupam algum espaço de armazenamento:

https://stackoverflow.com/questions/3731172/how-much-size-null-value-takes-in-sql-server
https://www.sqlservercentral.com/forums/topic/null-storage-2

Se a coluna tiver o tipo de dados de largura fixa - NULLocupa o comprimento da coluna

char(10) NULL takes 10 bytes
INT NULL takes 4 bytes

Se a coluna tiver largura variável - NULLleva 0 bytes

varchar(1000) NULL takes 0 bytes (+ 2 bytes of varchar column overhead ?)

Além disso, há uma sobrecarga por ter uma coluna anulável. As informações nos links são um pouco contraditórias.
Alguém pode dar uma luz sobre isso?

Aqui estão minhas perguntas:

1. Algumas pessoas dizem que a sobrecarga por ter uma coluna anulável é de 1 bit por linha, outras que é de 1 byte por linha
   . Qual é verdade? Eu suponho que seja 1 bit por linha (portanto, 8 linhas fazem 1 byte), estou certo?

2. Para valores NULL em varchar, ainda há uma sobrecarga de 2 bytes por linha - é realmente verdade?

3. Pergunta mais importante:
   eu tenho uma tabela com ~ 250 milhões de linhas de dados, o tamanho total é ~ 115 GB
   Eu adicionei 7 colunas usando o código abaixo, verificando o tamanho da tabela usando sp_spaceused após cada comando

colunas adicionadas:

alter table MyTable add TestVarchar10 varchar(10) NULL      
alter table MyTable add TestVarchar1000 varchar(1000) NULL  
alter table MyTable add TestVarchar10DefaultTest varchar(10) NULL default 'test'        
alter table MyTable add TestVarchar10DefaultTestWithValues varchar(10) NULL default 'test' with values  

alter table MyTable add TestINT int NULL
alter table MyTable add TestINTDefault99 int NULL default 99
alter table MyTable add TestINTDefault99WithValues int NULL default 99 with values

E qualquer uma das colunas adicionais, não aumentou o tamanho da tabela
Como pode ser isso? Eu esperaria que o tamanho da tabela mudasse à medida que o NULLarmazenamento ocupasse espaço

Dentro de um procedimento armazenado executado com frequência (às vezes até 10-15 vezes por segundo), há duas instruções específicas que aparecem nas 10 consultas mais pesadas por impacto cumulativo na CPU

Estas são instruções DDL para criar tabelas #Temp:

1.

SELECT cast(0 as int) as rowId
     , Column1 as tColumn1
     , Column2 as tColumn2
     , ...
     , Column14 as tColumn14
     , cast(0 as datetime) as tUTC
     , -1 as tRefId
INTO #TempTable1
FROM Table1 WITH(NOLOCK)
WHERE 0=1

SELECT    tColumn1, ..., tColumn14, tUtc, tRefId
INTO    #TempTable2
FROM    #TempTable1
WHERE    0=1

Qualquer um dos DDL acima, leva em média 10-15 ms de tempo de CPU, simplesmente para criar uma tabela #temp
Alterar a lógica do procedimento armazenado, para que NÃO crie tabelas temporárias, não é uma opção

Pergunta : Como o tempo de criação da tabela temporária pode ser acelerado, em termos de tempo de CPU?

Eu tenho uma consulta simples com um agrupamento, que funcionou bem, até adicionar mais uma junção:

select 
   [ca].Value,
   [c].cID, 
   [c].Name

from ReportingDB..Table1 [t1]

join MainDB..Companies [c] on
    [t1].CompanyID = [c].cID
    and [c].cID not in (1)

join MainDB..CompanyAttributes [ca] on -- this is the join that causes trouble
    [t1].CompanyID = caCID
    and caAttr = 26

group by [ca].Value, [c].cID, [c].Name

Informações:

Companies tabela é uma tabela de "pesquisa" e tem 2254 linhas, cIDé PK
CompanyAttributestem muitos para um relacionamento Companiese tem 4055 linhas
Table1tem muitos para um relacionamento com a Companiestabela e tem 3.485.150 linhas e

O plano de execução estimado não parece incomum.

• Quando tento executar a consulta, ela não termina e depois de 1 hora eu a paro, então não consigo ver o que está acontecendo com o plano de execução real
• Estatísticas de consulta ao vivo fizeram meu SSMS travar
• Se remover a cláusula "group by", ele começa a buscar linhas sem nenhum problema rapidamente. Ou quando a última junção é removida, também funciona bem - com agrupamento
• O servidor não está ocupado, tem recursos suficientes e não vejo aumento perceptível da CPU ao iniciar a consulta
• olhando para sys.dm_exec_requests, wait_type é NULL cpu_timee logical_readscontinua a crescer, para a sessão que executa a consulta

Qual é a causa ROOT da consulta original rodando mais de 1 h sem terminar?

Resolvi o gargalo de desempenho em si (veja minha resposta), mas não entendo o QUE exatamente faz com que a consulta original seja executada por 1 hora e não termine em um servidor decente, as tabelas consultadas não são enormes. Esperaria que a consulta original terminasse em menos de 1 minuto.

Tenho algumas perguntas sobre escalações de bloqueio de mesa. Confirme ou refute:

1. O operador Index Scan em uma consulta resulta em Table Lock Escalation? sempre ou não (mesas pequenas) ?

2. Quando o bloqueio compartilhado é escalado para um nível de tabela, ele bloqueia pequenas atualizações e exclui ? inserções também?

3. É possível obter contagens de lock_escalationeventos de tabela, agrupados por login e depois por tabela? Por exemplo:

login1 - table1 - 11
login1 - table2 - 5
login2 - table1 - 29
etc...

Eventos estendidos pareciam permitir apenas um nível de agrupamento, se não me engano

Índice de armazenamento de colunas em cluster atualizável (SQL Server 2016+) - ele tem limitação de tamanho máximo de linha (8060) ou você pode colocar qualquer tamanho de linha que desejar?

Em outras palavras, é possível obter o erro abaixo com o CCI atualizável?

Não é possível criar uma linha de tamanho 8061 maior que o tamanho máximo permitido de linha de 8060.

Tenho poucas tabelas com índices altamente fragmentados (mais de 90% de fragmentação) e grandes o suficiente (dezenas de gigabytes) em tamanho. O objetivo de desfragmentá-los é reduzir o consumo de espaço pelas tabelas acima.

Gostaria de evitar a execução de operações REBUILD, pois consome muitos recursos. Também tentando evitar o log no log de transações e o crescimento do log, e grandes tamanhos de backup do log de transações como resultado.

É por isso que a operação REORGANIZE foi escolhida em vez de REBUILD, para lidar com alta fragmentação.

Em relação ao REORGANIZE, tenha as seguintes perguntas:

1. Se executar várias operações REORGANIZE em índices separados ao mesmo tempo (digamos 10+, em janelas/sessões SSMS separadas) - isso pode causar corrupção de dados ou outros problemas conhecidos?

2. As operações REORGANIZE são registradas no log de transações de alguma forma?

3. Que tipo de bloqueios são mantidos pela REORGANIZE ? Quais consultas podem sofrer com isso?

A única razão para a desfragmentação no meu caso é reduzir o consumo de espaço de armazenamento, e isso realmente ajuda (por exemplo, o índice era de 18 GB antes e depois se tornou 8 GB e assim por diante). Essa é uma saída mais fácil do que solicitar armazenamento adicional, no meu caso.

Alguns dos desenvolvedores da minha equipe sabem senhas de contas SQL que têm permissões estendidas
Gostaríamos de rastrear e ser alertados sempre que algum desenvolvedor estiver usando qualquer uma dessas contas SQL para se conectar

Estamos prestes a implementar logon triggerisso para cada tentativa de login, avaliar as propriedades do login e enviar um relatório por e-mail se eles corresponderem a determinados critérios. A lógica é a seguinte:

se original_login() em (...lista de contas SQL aqui...) e:
a) o endereço IP do cliente é 192.168.xx sub-rede VPN (nenhum aplicativo de produção se conectando a partir desta sub-rede, somente desenvolvedores podem) ou
b) nome do host do cliente em (... lista de nomes de máquinas host do Dev...) ou
c) nome do aplicativo cliente em (SSMS, az-Data etc.)
exec sp_send_dbmail (enviar relatório por e-mail para o DBA)

O gatilho teria a cláusula "execute as" e seria executado em nome de um logon SQL cuja única permissão é enviar e-mails de db mail

Quais podem ser os efeitos colaterais indesejados de habilitar esse tipo de acionador de logon na produção?
Pode retardar o processo de login ou causar outros problemas?

ps Estou ciente DACe como usá-lo.
Testado conectando usando DACe contando com ele para me ajudar a desativar o gatilho se algum problema começar

Eu me conectei a alguns servidores SQL do Azure (aqueles que hospedam alguns bancos de dados SQL do Azure neles) no SSMS Object Explorer e vejo que a versão é 12.0.2000.8

select @@Versionmostra abaixo:

Microsoft SQL Azure (RTM) - 12.0.2000.8 20 de fevereiro de 2021 17:51:58 Direitos autorais (C) 2019 Microsoft Corporation

Para comparação, minha outra caixa é o SQL Server 2017 e a versão mostrada é 14.0.3370.1

Eu esperava ver os SQL Servers do Azure como 15.0.something (correspondem ao SQL Server 2019), mas eles parecem corresponder ao SQL Server 2014 (versão 12)

Perguntas:

Os servidores SQL do Azure não deveriam atualizar automaticamente para a versão mais recente?
Como posso atualizá-los para a versão 15 manualmente?

Gostaria de conceder abaixo as permissões ao grupo Desenvolvedores, no SQL Server de Produção:

VIEW SERVER STATE
VIEW DEFINITION (server level)

Isso é feito para torná-los capazes de consultar algumas visualizações e funções de gerenciamento dinâmico, visualizar dados de desempenho, bem como ver o código (definições) de todos os procedimentos e funções armazenados

Existem desvantagens ou razões pelas quais isso não é bom em determinados cenários?
Quaisquer possíveis efeitos colaterais indesejados da concessão das permissões acima?

Segunda pergunta - se eu conceder VIEW DEFINITIONno banco de dados mestre, isso o torna no nível do servidor e não precisa ser concedido em nenhum banco de dados do usuário? O mesmo com SHOWPLAN?

Na semana passada, houve um problema em um dos SQL Servers, a CPU começou a queimar mais de 80% (o normal é 10-30%)
Isso durou cerca de 2 horas até que eu fiz failover manualmente para a réplica secundária no AG (e isso resolveu o problema)

Início do problema: 12h15
Fim do problema: 14h15 (após o failover manual do AG)

Informações do servidor:

SQL Server 2017  
32 logical processors (max DOP = 8)  
256 GB RAM (Max Server Memory = 180 GB, used 179 GB)

As métricas abaixo NÃO mudaram visivelmente antes do problema x após o início do problema

• Conexões do usuário/s (média 200-300)
• Solicitações em lote/s (média 200 e inferior)
• Memória Cache do Banco de Dados (~ 150 GB)

Abaixo das métricas PICOS consideravelmente, o que NÃO é típico para este servidor (geralmente estes são baixos):

• CPU (mais de 80%)
• Concessões de memória pendentes
• Bloqueio de Esperas/s, Avg. Tempo de espera de bloqueio, impasses
• Tempo de espera da trava
• Memória de espaço de trabalho concedida e memória de servidor reservada

Consultas:

Não notei mudanças nas cargas de trabalho para este servidor quando o problema começou
Os desenvolvedores também confirmaram que os aplicativos fizeram seu trabalho normal e estavam executando consultas normais, sem picos na carga do aplicativo

Durante esse problema de "alto uso da CPU", as 10 principais consultas por CPU não pareciam incomuns
Todas as mesmas 10 principais consultas que costumamos ver mesmo quando a CPU está normal (10-30%)

Problema:

O problema parecia estar em alguns procedimentos armazenados relacionados, esse aplicativo geralmente é executado de 1 a 4 vezes / segundo e geralmente é concluído em 50 ms, mas durante o problema, sempre que verifiquei o sys.dm_exec_requests (também usado exec ViewSessionsConnections 'running' https ://github.com/aleksey-vitsko/Database-Administrator-Tools/blob/master/Sessions%20-%20ViewSessionsConnections.sql ), estavam sentados como 50-70 sessões de 1 aplicativo, todos tentando concluir os procedimentos acima mencionados , e foi lento

Ao analisar as 10 principais consultas por Duração em uma ferramenta de monitoramento, as principais 1 e 2 eram duas instruções dos procedimentos acima - elas não consumiam muita CPU, MAS tinham esperas excessivas (RESOURCE_SEMAPHORE, LCK_M_IS)

Normalmente, eles são concluídos em 10 ms ou menos, executados de 1 a 4 vezes por segundo e não causam problemas, e agora começaram a ter duração de 4.000 a 8.000 ms por 1 execução, que era o problema

RESOURCE_SEMAPHORE NÃO é absolutamente típico para este servidor, mas durante o problema estava entre as principais esperas (RESOURCE_SEMAPHORE - Consultas aguardando a concessão de memória; total de 135400234 ms em 2 horas; média de 4174 ms )

Granted Workspace Memorye Reserved System Memoryno SQL Server disparou de 0 para ~ 110 GB durante o problema

Perguntas:

1. Quais são seus pensamentos e experiências acima?

2. As esperas constantes de RESOURCE_SEMAPHORE e concessões de memória pendentes podem causar pressão na CPU apenas para alocar memória do espaço de trabalho para consultas? Porque quando analisamos as 10 principais consultas por CPU durante o problema, os números da CPU pareciam normais / usuais

3. Como pode ser isso Granted Workspace Memorye Reserved Server Memorycomeçar a consumir ~ 112 e 110 GB quando o problema começou, visto que Max Server Memorysão 180 GB e Database Cache Memory remained~ 150 GB o tempo todo? Será que sobrecarrega a memória ou algo assim?

4. Por que uma instrução dentro do SP que geralmente é concluída em 10 ms por meses, começa a experimentar RESOURCE_SEMAPHORE esperar e concluir em 4000-8000 ms?

5. Como o problema pode ser resolvido de maneira mais cirúrgica, sem fazer failover manual para a réplica secundária? Como posso acalmar a consulta e trazê-la de volta para 10 ms? O plano precisa ser descartado ou a consulta recompilada, etc. ? Qual é a melhor maneira de fazê-lo e monitorá-lo?

6. Brent Ozar First Responder Kit ou outros procedimentos de diagnóstico - em que sequência devem ser executados durante problemas de desempenho, para entender melhor o que está acontecendo?

Tenho abaixo duas consultas sobre Produção:

Consulta nº 1: Script que exclui dados históricos mais antigos da tabela principal "Tabela1" com base na coluna "Data"

Existem ~20 tabelas que apontam para "Tabela1" por chave estrangeira com regra de cascata, portanto, quando você exclui da "Tabela1", os dados também são excluídos de ~20 outras tabelas

O script exclui dados em lotes de 50 linhas por vez com intervalo de 1 segundo entre os lotes
O script NÃO faz com que os bloqueios Exclusivos escalem para bloqueio em nível de tabela, quando o lote tem apenas 50 linhas; ele apenas coloca bloqueios de nível de linha/página (X)

Consulta nº 2: Aplicativo de produção que extrai dados de "Tabela1", "Tabela2", "Tabela3" e algumas outras tabelas

Esta é uma consulta de leitura pesada, que coloca bloqueios compartilhados em tabelas. Não faz nenhuma inserção/atualização/exclusão

Problema:

Às vezes, o deadlock ocorre quando Query # 2(aplicativo Prod) lê dados e eu executo simultaneamente Query # 1(script excluindo dados mais antigos) no SSMS. Query # 2é sempre uma vítima, pelo que entendo, porque NÃO está fazendo nenhuma alteração no log de transações, Query # 1enquanto

Tentando resolver isso, adicionei set deadlock_priority -10a Query # 1, esperando que ele se torne Query # 1vítima em quaisquer possíveis impasses

Primeiro parecia que funcionou, Query # 1tornou-se vítima em situações de impasse, lançando o erro 1205 ao excluir alguns dos lotes.

MAS - recentemente descobri que às vezes Query # 2ainda se torna uma vítima

Pergunta:

Como é possível que Query # 2às vezes se torne uma vítima mesmo depois de eu ter set deadlock_priority -10parado Query # 1?

Existe uma maneira de corrigi-lo e ter certeza de Query # 1que será a vítima em 100% dos casos?

Atualização : gráfico adicionado abaixo

Eu criei um gatilho DML (AFTER INSERT, UPDATE, DELETE) em uma tabela
A lógica do gatilho leva cerca de 30 segundos para executar

Portanto, se você alterar até 1 linha, leva ~ 30 segundos devido à execução do gatilho
O desenvolvedor me perguntou "Existe uma chance de o gatilho ser uma ação de disparar e esquecer?"

Eu disse que não, mas é realmente assim?

Pergunta:

O gatilho pode ser executado no modo "assíncrono"?
O aplicativo atualiza algumas linhas em poucos ms e pensa que a transação foi concluída e, em seguida, o gatilho é executado silenciosamente nos bastidores?

Eu entendo que isso realmente não parece bom do ponto de vista da consistência, mas ainda assim, é possível?

Eu tenho uma configuração onde 3 servidores combinados em Grupo de Disponibilidade

Todos os 3 servidores têm unidades SSD conectadas diretamente e os arquivos do banco de dados do usuário são hospedados nessas unidades

Mas os bancos de dados do sistema (master e msdb) de cada servidor no AG, estão hospedados em um dispositivo SAN que é acessado pela rede

Ainda não os moveu para unidades SSD locais

Perguntas:

Em uma situação hipotética em que a conexão de rede entre qualquer um dos servidores e o dispositivo SAN é perdida (cabo ruim, NIC ruim, alguma falha temporária de rede etc.),

• O serviço do SQL Server nesse servidor ficará offline ou deixará de funcionar corretamente imediatamente?

• Ou continua a funcionar por algum tempo se master e msdb foram armazenados em cache na RAM antes da rede cair?

Temos um arquivo de configuração E:\SQL_Server_2016_Install\MyConfigFile.inique se parece com abaixo:

[OPTIONS]
ACTION = "Install"
FEATURES = SQLENGINE
INSTANCENAME = MSSQLSERVER
AGTSVCACCOUNT = "MyDomain\MyAccount"
SQLSVCACCOUNT = "MyDomain\MyAccount"
QS
IACCEPTSQLSERVERLICENSETERMS

O SQL Server é então instalado usando o arquivo de lote abaixo:
E:\SQL_Server_2016_Install\Setup.exe /ConfigurationFile=MyConfigFile.ini /InstanceName="TestSQLServer"

Pergunta:

O /InstanceName="TestSQLServer"parâmetro substituirá o que temos no arquivo de configuração ( /InstanceName = MSSQLSERVER(instância padrão)) e instalará o SQL Server como uma instância nomeada TestSQLServer?

Tamanho da máquina virtual DS3(em tamanhos de geração mais antigos)
Portal do Azure (ao implantar VM) mostra que DS3suporta até 16 discos de dados / até 12800 IOPS- tudo bem,

Mas o que me interessa é o armazenamento local/temperatura 28 GB D: drive
A documentação mostra que esta unidade local/temp é SSD, mas o que não consigo encontrar são informações sobre quantos IOPS essa unidade pode suportar?

Mais especificamente, se meu TempDB tiver um requisito de IOPS de até 1900, o D: drive na DS3VM pode lidar com esse requisito?
A partir desta fonte https://learn.microsoft.com/en-us/azure/virtual-machines/sizes-previous-gen , posso adivinhar que D: é 3200IOPS, mas não tenho certeza se entendi corretamente ...

Preciso receber um e-mail quando o espaço livre em disco em E: ou H: for inferior a 20%

Eu sei que isso pode ser alcançado configurando um trabalho que execute scripts do PowerShell ou T-SQL em um agendamento, que verifique o espaço livre em disco e envie um e-mail de alerta quando o espaço em disco estiver baixo

Mas a questão é: a mesma tarefa pode ser alcançada usando apenas um Alerta?
Existe um tipo de alertaSQL Server performance condition alert

Existe um Object/ Counterque possa ajudar a verificar o espaço em disco e acionar este alerta se o valor "Cair abaixo" do limite especificado?