variable's questions

Recebi um arquivo de backup do banco de dados.

Após a restauração, executei o script neste banco de dados e ele me mostra a contagem de linhas em termos de consulta:

SELECT qs.execution_count,  
    SUBSTRING(qt.text,qs.statement_start_offset/2 +1,   
                 (CASE WHEN qs.statement_end_offset = -1   
                       THEN LEN(CONVERT(nvarchar(max), qt.text)) * 2   
                       ELSE qs.statement_end_offset end -  
                            qs.statement_start_offset  
                 )/2  
             ) AS query_text,   
     qt.dbid, dbname= DB_NAME (qt.dbid), qt.objectid,   
     qs.total_rows, qs.last_rows, qs.min_rows, qs.max_rows  
FROM sys.dm_exec_query_stats AS qs   
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt   
WHERE qt.text like '%SELECT%'   
ORDER BY qs.execution_count DESC;

No entanto, isso não retorna a mesma saída que vejo ao executá-lo no banco de dados de produção.

Os valores sys.dm_exec_query_stats são armazenados na alavanca do servidor ou no nível do banco de dados? Quero dizer, os dados não são retidos após a restauração?

A concessão de procedimentos armazenados de execução (todos) permite implicitamente quaisquer privilégios críticos? Por exemplo, privilégio para controlar a segurança, etc., executando os processos armazenados relevantes?

A maneira de conceder a execução de todos os procedimentos armazenados é:

GRANT EXECUTE TO [user]

Supondo que eu tenha AG em um cluster de 4 nós, com 2 nós no site primário e 2 nós no site de DR, 1 testemunha de nuvem. O modo failover é manual.

Agora, por algum motivo, suponha que a rede do site primário caia, especificamente, não consigo me conectar ao data center primário.

Caso 1: o primário tem quorum, pois ainda é capaz de se comunicar com a testemunha da nuvem. Como há algum problema de rede no site primário, o SQL ainda está em execução no site primário e pensa que é o primário.

Caso 2: o primário não consegue se comunicar com a testemunha da nuvem e perdeu o quorum. Testemunho dinâmico e quórum dinâmico podem entrar em ação.

Suponha que agora eu me conecte a um dos nós de DR e invoque um failover manual forçado.

O SQL no site de DR pensará que é o principal, pois invoquei o failover manual. Tecnicamente, este é um cenário de cluster dividido.

O cenário de divisão no caso 1 é óbvio. No caso 2, pode ser devido ao testemunho dinâmico e ao início do quórum dinâmico.

Quando a rede primária for restabelecida, o que preciso fazer para lidar com esse cenário? Porque se o que estou pensando estiver certo, ambos os sites pensarão que possui o servidor SQL primário.

Restaurei um banco de dados para um servidor SQL diferente, mas curiosamente as tabelas de backupset msdb neste servidor estão mostrando o histórico de backup do banco de dados do servidor de origem.

Isso é esperado?

Nota: não restaurei o msdb.

Passos para reproduzir:

1. No servidor de origem, execute um backup completo, seguido de alguns backups de log.
2. No servidor de destino, usando a UI de restauração do banco de dados, execute a restauração do backup completo e dos backups de log.
3. Abra a consulta abaixo no servidor de destino e você verá o histórico completo e de backup de log (do servidor de origem) deste banco de dados aparecer aqui.

Consulta:

SELECT 
   CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server, 
   msdb.dbo.backupset.database_name, 
   msdb.dbo.backupset.backup_start_date, 
   msdb.dbo.backupset.backup_finish_date, 
   msdb.dbo.backupset.expiration_date, 
   CASE msdb..backupset.type 
      WHEN 'D' THEN 'Database' 
      WHEN 'L' THEN 'Log' 
      END AS backup_type, 
   msdb.dbo.backupset.backup_size, 
   msdb.dbo.backupmediafamily.logical_device_name, 
   msdb.dbo.backupmediafamily.physical_device_name, 
   msdb.dbo.backupset.name AS backupset_name, 
   msdb.dbo.backupset.description 
FROM 
   msdb.dbo.backupmediafamily 
   INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id 
WHERE 
   (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7) 
ORDER BY 
   msdb.dbo.backupset.backup_finish_date desc

Quando o ajuste automático está habilitado, usando SET AUTOMATIC_TUNING (FORCE_LAST_GOOD_PLAN), então com base na regressão de consulta, suponha que o SQL Server auto decida forçar um plano, então quando ele revisita sua decisão e reavalia se existe ou não um plano melhor que pode executar a consulta mais rápido/com menos recursos?

Eu tenho os seguintes exemplos de predicados XE:

Amostra 1:

Duration>1000000
AND cputime>1000
OR logicalreads>25000

Amostra 2:

Duration>1000000
OR cputime>1000
AND logicalreads>25000

Entendo que ocorre curto-circuito, mas como funciona a lógica sem a presença de colchetes?

Para a amostra 1 é:

(A and B) or C
A and (B or C)

Para a amostra 2 é:

A or (B and C)
(A or B) and C

Estou usando a edição empresarial SQL 2022 local.

A opção de avaliação de vulnerabilidade SQL foi retirada do SSMS 19.1 em diante.

Estou lendo que esse recurso agora faz parte do Defender for Cloud.

Se alguém já tentou isso, é grátis? E preciso pedir ao administrador do Azure para configurar o defensor para a nuvem agora apenas para poder fazer a avaliação de vulnerabilidade do SQL?

Desejo configurar o HA DR para um servidor SQL de instância única adicionando uma nova instância em outra máquina e configurando vários AGs básicos ( com modo de failover manual ).

Quero que todos os aplicativos clientes possam usar a mesma cadeia de conexão para acessar o servidor. Para isso eu uso o listener (crio um listener para apenas 1 AG, ​​e uso isso em toda string de conexão) ou uso o endpoint de espelhamento de banco de dados?

Em uma instalação SQL padrão, a conta do mecanismo é NT Service\MSSQLSERVER e a conta do agente é NT Service\SQLSERVERAGENT

Na segurança SQL, posso ver os dois listados como logins com função sysadmin.

Eles também têm as permissões de segurança necessárias nas várias pastas automaticamente.

Se eu alterar a conta do mecanismo e do agente por meio do gerenciador de configuração para contas locais ou de domínio (como meudomínio\sqlengine, meudomínio\sqlagent), então:

1. Preciso criar essas contas na segurança SQL e atribuir a função sysadmin a elas?

2. Existem outras etapas de postagem (como qualquer outra atribuição de permissões - como a seguir: https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and- permissions?view=sql-server-ver16#Windows - ou isso é aplicado implicitamente por meio da conta virtual?)?

3. Posso excluir as 2 contas de serviço NT acima dos meus logins do SQL Server?

A razão para perguntar é que - eu sei que nos bastidores o mecanismo SQL faz uso da NT SERVICE\MSSQLSERVERconta sid de serviço, e o agente faz uso de , para as várias permissões de pasta (dados/ log NT SERVICE\SQLSERVERAGENT/etc.) e privilégios e direitos do Windows como Log in as a service,, Replace a process level tokenetc. Mas ele ainda usa essa conta virtual para acessar as pastas/arquivos mesmo depois de alterar a conta de serviço do mecanismo do servidor SQL para uma conta de usuário de domínio?

Quando alterei a conta de serviço do servidor SQL por meio do gerenciador de configuração para uma conta de usuário de domínio, ela não fez alterações automáticas nos dados, na pasta de log ou nas permissões de arquivo. O pop-up de segurança de pasta/arquivo sempre foi exibido MSSQLSERVER(não a conta de usuário do domínio) e o servidor SQL funciona perfeitamente bem.

Isso significa que o mecanismo do servidor SQL usa NT SERVICE\MSSQLSERVER mesmo que a conta de serviço do mecanismo SQL seja alterada para uma conta de usuário de domínio?

Eu tenho um problema em que a reconstrução do índice está causando uma grande fila de refazer no nó secundário do AG síncrono.

Este problema ocorre apenas em 1 db, e a única diferença entre este db e todos os outros dbs é que este db tem durabilidade atrasada forçada. Em média, todos os dbs variam de 300 a 600 GB de tamanho de arquivo de dados.

Com base na documentação, entendo que, para este banco de dados, a durabilidade da transação não é garantida (por exemplo, após a reinicialização ou falha) e o cliente recebe confirmação antes do registro de log gravado no disco no nó AG primário/secundário.

Minha pergunta é: quando o log é finalmente liberado para o disco no nó primário (seja por meio de uma transação durável ou comando de descarga forçada), o log também é enviado para o nó secundário neste ponto? Então, efetivamente, este é um grande pedaço de registros e provavelmente a razão pela qual a fila de refazer se torna grande?

Atualização: o acúmulo da fila de refazer durante a reconstrução do índice dura apenas cerca de 20 segundos (quando a durabilidade atrasada é forçada). Se eu desativar a durabilidade atrasada, não haverá acúmulo de fila de refazer durante a reconstrução do índice. Estou me perguntando se os grandes pedaços de descarga (devido à durabilidade atrasada) estão causando o acúmulo momentâneo da fila de refazer.

Temos tarefas do agente SQL que reconhecem o AG: a primeira etapa da tarefa verifica se o servidor é primário (se sim, vá para a próxima etapa, que é a etapa real da tarefa), caso contrário, saia do relatório de sucesso da tarefa.

Existe 1 banco de dados que não está participando do AG (o plano é restaurar manualmente este banco de dados se houver um failover). Há um trabalho no primário que invoca um SP deste banco de dados. Sou solicitado a criar este trabalho no servidor secundário (para que após o failover, só tenhamos que restaurar o banco de dados sem precisar recriar o trabalho). Como o banco de dados não existe no secundário, não consigo criar um trabalho para esse banco de dados no secundário. Mesmo que eu restaure uma cópia do banco de dados no secundário, crie o trabalho e exclua o banco de dados, o menu suspenso do banco de dados (dentro do trabalho) ficará vazio.

Uma solução é criar manualmente o failover da postagem de trabalho após restaurar esse banco de dados. Existe alguma solução alternativa que me permita criar o trabalho do agente sem que o banco de dados exista?

A configuração de durabilidade atrasada (forçada) em um banco de dados garante que o aplicativo cliente obtenha a confirmação sem esperar que o log seja liberado (gravado) no disco.

O AG síncrono requer que a transação seja gravada no log primário (flush to disk) e no log secundário (flush to disk), somente então o cliente receberá o commit.

Para um banco de dados que participa de um AG, essa configuração (durabilidade atrasada = forçada) se aplicará ao banco de dados primário e secundário e, em ambos os servidores, o mecanismo SQL não aguardará a gravação do log no disco?

A consulta SELECT requer um bloqueio SCH-S. Isso pode ser compartilhado com outras consultas de leitura.

A consulta UPDATE requer um bloqueio SCH-M. Isso não pode ser compartilhado com outras consultas de leitura/atualização.

Link: https://www.mssqltips.com/sqlservertip/5880/why-is-index-reorganize-and-update-statistics-causing-sql-server-blocking/

O exemplo mostra um bloqueio de reorganização de índice (Sch-S) bloqueia o bloqueio Sch-M da atualização de estatísticas. Mas por que ele também bloqueia o bloqueio Sch-S subsequente solicitado pela consulta SELECT? Os bloqueios Sch-S não são compartilhados?

A unidade C é a unidade do sistema operacional

A unidade D é a unidade de dados (dbs do sistema e do usuário)

A unidade E é a unidade de log (dbs do sistema e do usuário)

A unidade D travou. Portanto, o sql não está iniciando porque o arquivo mestre mdf está ausente.

Eu poderia ter iniciado o servidor sql apontando para o backup do arquivo mestre mdf e, em seguida, restaurar msdb/model/user dbs. Mas todos os meus arquivos de backup estão no formato .bak.

Tenho backups completos e de log de dbs do sistema/usuário (.bak). Como faço para extrair o arquivo mestre mdf para inicializar meu servidor sql?

Talvez restaure o mestre em um novo servidor de teste e copie esse arquivo mdf mestre para o servidor sql original. Ou seria apropriado reconstruir os dbs do sistema e, em seguida, restaurar os dbs mestre/msdb/modelo/usuário?

Qual é a maneira correta de corrigir o usuário órfão:

sp_change_users_login @Action='update_one', 
@UserNamePattern='TestUser1', 
@LoginName='TestUser1'

Ou

ALTER USER TestUser1 WITH LOGIN=TestUser1

Ambos corrigem o usuário órfão.

Estou configurando um login sql em um servidor prod AG. E criá-lo com o mesmo lado no nó AG secundário.

Também precisamos desse usuário em outros servidores SQL autônomos prod, servidores AG SQL e servidores dev sql.

Existe algum risco em reutilizar o sid de 1 servidor sql em outro servidor sql ao criar o mesmo login?

O benefício é não ter que lidar com usuários órfãos depois de mover dbs entre servidores. Não tem certeza se há riscos?

Em um AG de 2 nós, suponha que um nó não esteja acessível, inativo ou travado, então o tamanho do arquivo de log no nó primário continuará crescendo.

Nessa situação, existe alguma maneira de impedir o crescimento do log além de:

1. Removendo o outro nó do AG
2. Corrigindo os problemas com o outro nó

Os backups de log são importantes para a recuperação pontual e para truncar automaticamente o arquivo de log (no modelo de recuperação total) para liberar espaço para a reutilização do log.

Mas quando o secundário está inacessível devido a um problema de rede ou após o failover, estou aprendendo que o log continua crescendo (porque evita o truncamento: https://www.sqlshack.com/sql-server-transaction-log-growth- monitoramento-e-gerenciamento/ ).

Nesse cenário, o backup de log não truncará os logs, então isso significa que os backups de log que ocorrem se comportam como backups de log apenas de cópia? Ou seja - os backups de log não truncarão os logs (portanto, cada tamanho de backup de log subsequente continua crescendo) e, ainda assim, também permite a recuperação pontual.

Esse é um entendimento correto sobre o comportamento de backup de log?

Eu tenho todas as configurações padrão de WSFC e AG. Modo de sincronização e failover automático.

O AG tem 2 nós: Node1 e Node2

Nó1 é primário.

Reiniciei o serviço do servidor SQL no Nó1, o que resultou em failover para o Nó2.

Em seguida, reiniciei o serviço do servidor SQL no Node2. Mas isso não resultou em failover para Node1.

Por que o failover do SQL AG não está funcionando quando reiniciei o serviço sql no novo primário (nó 2)?

Estou explorando o rastreamento de consulta de eventos estendidos e tenho dúvidas sobre algumas consultas estranhas, como a seguir:

Exemplo 1:

select top 10  *   from   (   SELECT [id]       ,[date]       ,[ordnum]       ,
[customer]  ,[amt]   ,[gm pc]   FROM [DbName].[dbo].[tblSales]  ) as [_]
where [date]>='2022-01-01T00:00:00.000'

Exemplo 2:

select [_].[id],      [_].[date],   [_].[ordnum],  [_].[customer], [_].[amt], 
[_].[gm pc]  
from   (  SELECT [id] ,[date] ,[ordnum] ,  [customer]  ,[amt]  ,[gm pc]   
FROM [DbName].[dbo].[tblSales]  ) as [_]  where [_].[date] >= 
convert(datetime2, '2020-01-01 00:00:00') 
    and [_].[date] < convert(datetime2, '2021-01-01 00:00:00')

Portanto, na subconsulta, ele seleciona todas as linhas. E então, na consulta externa, ele aplica os critérios where.

Se funcionar literalmente assim, significa que a subconsulta fará a varredura completa da tabela e aplicará a cláusula where ao resultado. Ou essa consulta é otimizada para que a cláusula where seja aplicada diretamente na tabela?