Mickael's questions

Decidimos testar e talvez implementar o novo query_abortrastreamento de eventos estendido em todos os nossos servidores de banco de dados para saber mais sobre nossas consultas de tempo limite. Atualmente, utilizamos o rpc_completedevento com status=2filtro.

Usaremos a ferramenta SQLCallStackResolver conforme detalhado neste vídeo da Microsoft e usaremos a task_callstack_rvacoluna processada pela ferramenta.

Aqui está um dos vestígios que temos de uma SELECTdeclaração:

00 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
01 YYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYYY
00 SqlDK!ThreadScheduler::SwitchWorker
01 SqlDK!SOS_Scheduler::Switch
02 SqlDK!SOS_Scheduler::SuspendNonPreemptive
03 SqlDK!WaitableBase::Wait
04 sqllang!TDSSNIClient::WriteStatus
05 sqllang!WaitOnWriteAsyncToFinish
06 sqllang!write_data
07 sqllang!flush_buffer
08 sqllang!CTds74::SendRowImpl
09 SqlTsEs!CEsExec::GeneralEval4
0a sqllang!CXStmtQuery::ErsqExecuteQuery
0b sqllang!CXStmtSelect::XretExecute
0c sqllang!CExecStmtLoopVars::ExecuteXStmtAndSetXretReturn
0d sqllang!CMsqlExecContext::ExecuteStmts<1,0>
0e sqllang!CMsqlExecContext::FExecute
0f sqllang!CSQLSource::Execute
10 sqllang!process_request
11 sqllang!process_commands_internal
12 sqllang!process_messages
13 SqlDK!SOS_Task::Param::Execute
14 SqlDK!SOS_Scheduler::RunTask
15 SqlDK!SOS_Scheduler::ProcessTasks
16 SqlDK!Worker::EntryPoint
17 SqlDK!ThreadScheduler::RunWorker
18 SqlDK!SystemThreadDispatcher::ProcessWorker
19 SqlDK!SchedulerManager::ThreadEntryPoint
<frame id="28" address="0x776D11E7" />
1d WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
1e ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ

Pelo que entendi, a consulta está sendo processada e entra em vários estados e esperas, como atribuição a um agendador, por exemplo. Mas como essas informações nos ajudam a entender o que causou o tempo limite? Na verdade, parece-me que tudo está indo bem.

Eu tenho que migrar 8 instâncias do SQL Server para um novo cluster SQL Server 2019 AlwaysON. Cada instância será replicada para um nó secundário passivo. Globalmente, queremos usar gMSA em vez de contas de domínio clássicas.

Não consigo encontrar as melhores práticas relacionadas a isso:

• Devo usar o mesmo gMSA para todos os serviços sql em todos os nós?
• Devo usar um gMSA dedicado para cada instância? (nó primário e secundário).
• Se sim, posso instalar mais de um serviço gMSA em cada nó?( Install-ADServiceAccount gMSAsqlservice)

obrigada

Sou novo no MongoDB e estou procurando por várias horas como promover minha instância autônoma do mongo em um replicaset. Meu ambiente real é um servidor ubuntu

root@UMONGO1:/home/msc# lsb_release -a

Distributor ID: Ubuntu
Description:    Ubuntu 20.04.3 LTS
Release:    20.04
Codename:   focal

executando uma instância autônoma do mongodb localmente na porta 27017:

root@UMONGO1:/var/lib# systemctl status mongod
● mongod.service - MongoDB Database Server
     Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-01-01 15:46:52 CET; 10min ago
       Docs: https://docs.mongodb.org/manual
   Main PID: 964 (mongod)
     Memory: 222.6M
     CGroup: /system.slice/mongod.service
             └─964 /usr/bin/mongod --config /etc/mongod.conf



# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
#  engine:
#  wiredTiger:

# where to write logging data.
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log

# network interfaces
net:
  port: 27017
  bindIp: 127.0.0.1


# how the process runs
processManagement:
  timeZoneInfo: /usr/share/zoneinfo

#security:

#operationProfiling:

#replication:

#sharding:

## Enterprise-Only Options:

#auditLog:

#snmp:

Importei um banco de dados daqui O objetivo é criar mais dois servidores e replicar os dbs neles.

Referindo-se à documentação:

Converter um Standalone em um Conjunto de Réplicas Estou confuso sobre os dois parâmetros --port e --dbpath que preciso usar. Se eu quiser promover minha instância real, devo usar o caminho e a porta do banco de dados existente, certo? Mas o que quer que eu esteja tentando é um fracasso.

Usando outra porta:

mongod --port 27017 --dbpath /var/lib/mongodb/ --replSet rs0

"ctx":"initandlisten","msg":"Error setting up listener","attr":{"error":{"code":9001,"codeName":"SocketException","errmsg":"Address already in use"}}}

mongod --port 27018 --dbpath /var/lib/mongodb/ --replSet rs0

BException in initAndListen, terminating","attr":{"error":"DBPathInUse: Unable to lock the lock file: /var/lib/mongodb/mongod.lock (Resource temporarily unavailable). Another mongod instance is already running on the /var/lib/mongodb/ directory"}}

Usando um novo diretório:

mongod --port 27017 --dbpath /media/msc/MONGO/rs/ --replSet rs0

"replication":{"replSet":"rs0"},"storage":{"dbPath":"/media/msc/MONGO/rs/"}}}}
{"t":{"$date":"2021-12-31T16:55:28.885+01:00"},"s":"E",  "c":"CONTROL",  "id":20568,   "ctx":"initandlisten","msg":"Error setting up listener","attr":{"error":{"code":9001,"codeName":"SocketException","errmsg":"Address already in use"}}}

mongod --port 27018 --dbpath /media/msc/MONGO/rs/ --replSet rs0

{"t":{"$date":"2021-12-31T16:57:11.762+01:00"},"s":"I",  "c":"-",        "id":4939300, "ctx":"monitoring-keys-for-HMAC","msg":"Failed to refresh key cache","attr":{"error":"NotYetInitialized: Cannot use non-local read concern until replica set is finished initializing.","nextWakeupMillis":2000}}

e esta espera "nextWakeupMillis" nunca para.

Você pode fornecer ajuda sobre qual é a configuração correta e qual é o problema?

****************** EDIT: 01/03/2022 ******************

Agora posso promover minha instância usando:

mongod --port 27017 --dbpath /var/lib/mongodb/ --replSet rs0

e, em seguida, abrir um novo shell e enviar

rs.initiate()

Mas por que o serviço não inicia com essa nova configuração?

● mongod.service - MongoDB Database Server
     Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Mon 2022-01-03 11:39:51 CET; 1min 12s ago
       Docs: https://docs.mongodb.org/manual
    Process: 904 ExecStart=/usr/bin/mongod --config /etc/mongod.conf (code=exited, status=14)
   Main PID: 904 (code=exited, status=14)

janv. 03 11:39:35 UMONGO1 systemd[1]: Started MongoDB Database Server.
janv. 03 11:39:51 UMONGO1 systemd[1]: mongod.service: Main process exited, code=exited, status=14/n/a
janv. 03 11:39:51 UMONGO1 systemd[1]: mongod.service: Failed with result 'exit-code'.

Além disso, se eu reiniciar o servidor, tenho que repetir essas ações. Existe alguma maneira de corrigir a configuração e iniciar o serviço mongod?

Eu tenho um cluster Always On do SQL Server de 2 nós hospedando 3 instâncias do SQL Server e configurado da seguinte forma:

• A memória total do servidor é de 768 G para cada nó.
• O consumo de memória é de 98%.
• LPIM está ativado.
• A memória mínima do servidor da instância "A" é de 102 G, máx. de 512 G.
• A memória mínima do servidor da instância "B" é de 102 G, máx. de 490 G.

Recentemente, instalei uma nova instância "C" com memória mínima e máxima do servidor definida para 8G.

Parece que "C" está tendo muitos problemas em relação à memória disponível. Na inicialização:

Às vezes, a conexão ou AG falhou com a mensagem:

"Há memória de sistema insuficiente no pool de recursos 'interno' para executar esta consulta"

Referindo-se à documentação , existem várias causas relacionadas.

Meu primeiro palpite é que as instâncias "A" e "B" ainda estão pegando toda a memória disponível e, quando a nova instância é iniciada, o sistema operacional recupera uma parte dela.

Meu segundo palpite é que não há mais memória para essa nova instância no servidor, então a maior parte é enviada para o arquivo de paginação.

Gostaria de ter sua opinião sobre este assunto.

A única solução que vejo aqui é reconfigurar corretamente a memória máxima do servidor para cada instância e deixar algum espaço livre para o sistema operacional.

Tentei parar a instância "B", liberando muita memória e depois reiniciei minha instância recém-instalada. Há muita memória disponível no sistema operacional, mas o erro ainda está acontecendo.

Outro ponto que notei é que o atendente do SOSMEMMANAGER está pegando toda a memória.

Temos uma demanda para criar um novo usuário com capacidade de SELECIONAR apenas 4 tabelas específicas. Para fazer isso, criamos o login e o mapeamos para o banco de dados necessário:

USE [master]
GO
CREATE LOGIN [pos] WITH PASSWORD=N'XXXX', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO

USE [TARGETED_DB_NAME]
GO
CREATE USER [pos] FOR LOGIN [pos]
GO

Depois disso, o usuário pode fazer qualquer instrução DML, enquanto não tem privilégios, exceto a função pública. Verificamos as permissões de função pública, permissões de servidor, etc., mas não descobrimos por que o usuário pode ver todas as tabelas do banco de dados.

O problema não está presente quando criamos o usuário em outro banco de dados na mesma instância.

Alguma idéia de por que o login pos obter esses privilégios?

Eu tenho um cluster SQL Server 2012 AlwaysON composto por:

win-mssql1: compartilhamento de arquivo testemunha

win-mssql2 (INSTÂNCIA 1): servidor principal

win-mssql3 (INSTÂNCIA 2): servidor secundário

Recentemente, tive o host "win-mssql4 (INSTANCE 3)" como uma nova réplica secundária. Meu objetivo é:

1. Sincronize manualmente um enorme banco de dados (vamos chamá-lo de "BaseSyncManual") com este novo servidor. 2.Posteriormente, sincronize os demais bancos de dados que estão no AG.

Para fazer o primeiro passo, usei os seguintes comandos:

No servidor principal:

BACKUP DATABASE BaseSyncManual TO DISK = 'I:\MSSQL\MSSQL12.MSSQLSERVER\MSSQL\Backup\setra_full.bak';
BACKUP log BaseSyncManual TO DISK = 'I:\MSSQL\MSSQL12.MSSQLSERVER\MSSQL\Backup\setra_log_2.trn';

No servidor secundário:

  RESTORE DATABASE BaseSyncManual FROM DISK = 'I:\MSSQL\MSSQL12.MSSQLSERVER\MSSQL\Backup\setra_full.bak'
    WITH NORECOVERY

    RESTORE DATABASE BaseSyncManual FROM DISK = 'I:\MSSQL\MSSQL12.MSSQLSERVER\MSSQL\Backup\setra_log_2.trn'
    WITH NORECOVERY

No primário: inicie o assistente para adicionar uma réplica e escolha "pular sincronização de dados inicial"

No secundário:alter database BaseSyncManual set hadr availability group = AvailabilityGroup1;

Tudo corre bem e o resultado é o que eu esperava:

Agora eu quero executar novamente o "add a new replica assistant" para sincronizar os bancos de dados restantes (Base1,Base2,BaseSyncAuto) com o parâmetro "full" (restaurar automaticamente o backup e ingressar no AG). Mas não há como fazer isso! a réplica já foi adicionada ao AvailabilityGroup:

e não consigo adicionar um banco de dados usando "adicionar banco de dados" porque eles já são membros do AvailabilityGroup na primeira replicação secundária:

Quais são minhas opções para sincronizar esses bancos de dados com minha nova réplica secundária? Estou condenado a fazer isso com backup-restauração-junção manual para AG?

Em nossos bancos de dados oracle, executamos regularmente a exportação do banco de dados por meio do utilitário expdp/impdp (encapsulado para facilitar a leitura):

$ expdp user/[password] SCHEMAS=<nom_schema> DIRECTORY=expDatapump 
     DUMPFILE=exp.<schema>.dmp LOGFILE=exp.<schema>.log

Graças a ele, podemos atualizar os dados de um esquema específico no banco de dados de teste, por exemplo.

Eu estou querendo saber se existe uma maneira de fazer isso no Microsoft SQL Server. Eu testei o assistente -> tarefas -> "exportar dados" no SSMS, mas isso não foi muito útil (utilizável apenas para bancos de dados muito pequenos, PK e FK excluídos, etc.).

Você pode executar dumps de seus bancos de dados do SQL Server? Por outro lado, é preferível (se possível) restaurar diretamente um esquema específico do SQL Server de um arquivo .bak?

Preciso instalar o Service Pack 3 em uma instância SQL em execução com o SP1. Sem teste, a instalação é diretamente no servidor de produção. Bem, esta não é uma tarefa complexa e o tópico já foi solicitado para outra versão, mas gostaria de não esquecer algumas etapas e receber feedback de dba experientes é sempre bem-vindo. Aqui minha lista de verificação planejada personalizada:

1.liste todos os bugs que foram resolvidos no Service Pack. ou seja: https://support.microsoft.com/en-us/kb/2509302

2. Faça um backup da máquina virtual e faça backup de todos os bancos de dados.

3.Desative o agente SQL Server.

4.Aplique o Sp.

5.Reinicie o servidor/instância, se necessário.

6.Verifique o nível do Service Pack da instância SQL.

7.Verifique todas as entradas no log de erros do SQL Server sobre a atualização do Service Pack e certifique-se de que não haja erros gravados.

8. Consultando o passo N°1, verifique se há problemas de bugs eventuais.

9. Ative o SQL Server Agent.

Do lado do cliente:

1. Verifique se há algum problema de compatibilidade entre o software dele e o SP3.
2. Após a instalação, verifique a conectividade do cliente entre o banco de dados/software.

Existe alguma etapa que você achará pertinente para adicionar/remover/modificar a isso?

Para um de nossos SQL Server, recentemente adicionamos mais memória. O valor inicial era de 12GB. O servidor apresentou falta de memória física, então adicionamos mais 12 GB, totalizando 24 GB. Então eu defini os seguintes valores: min. memória do servidor 1024 MB - memória máxima do servidor: 19456. Bem, tudo está funcionando bem, mas tenho algumas perguntas sobre o uso da memória do SQL Server. De fato, o servidor SQL de repente usou toda a memória atribuída:

Eu tenho um bom livro que diz: "Uma vez que o uso da memória aumentou além da configuração mínima de memória do servidor, o SQL Server não liberará nenhuma memória abaixo desse valor" - A mesma coisa está acontecendo aqui com a memória máxima do servidor?

Estou me perguntando (de novo) como medir quanta memória o SQL está realmente usando. Estou confuso com o parâmetro " Total server memory (KB) " ("esse contador mede o uso total do buffer pool do SQL Server"). De acordo com o perfmon, são apenas 2 MB:

Talvez possamos poupar o ESX de alguma RAM e a memória do SQL Server (ou seja, PLE) ainda mostrará bons valores - Como ter certeza? Uma boa explicação sobre como funciona a memória SQL nesse caso será muito apreciada!

Experimentando comportamentos de VLFs com meu laboratório de testes. Primeiro, criei dois bancos de dados (BASE2 e BASE3) com tamanhos de arquivos de log diferentes (1024 e 2048 MO):

Em segundo lugar, estou executando as seguintes consultas para determinar o uso do espaço de log e a parte ativa do VLF:

USE BASE2
dbcc loginfo
GO
USE BASE3
dbcc loginfo
GO

DBCC SQLPERF(LOGSPACE)

Portanto, na minha opinião, há muito espaço que posso recuperar. Agora, iniciando esta consulta para reduzir todos os arquivos de log do banco de dados:

DECLARE
@db nvarchar(255),
@fileName nvarchar(255),
@cmd nvarchar(255)

BEGIN

DECLARE dbcursor CURSOR
FOR

SELECT table2.name AS BASE, table1.name AS FICHIER_JOURNAL_BASE

    --table1.database_id, 
    --table1.physical_name, 
    --table1.type_desc
FROM sys.master_files AS table1

INNER JOIN sys.databases AS table2 
ON table1.database_id = table2.database_id

WHERE table1.database_id > 4 AND table1.type_desc = 'LOG' 
AND table2.state_desc = 'ONLINE' AND table2.recovery_model_desc = 'FULL';

OPEN dbcursor  
FETCH NEXT FROM dbcursor INTO @db, @fileName;
WHILE (@@FETCH_STATUS <> -1)
BEGIN

--print @db;

 SET @cmd = 'USE ['+ @db +']; DBCC SHRINKFILE ('''+@fileName+''',512);'
      PRINT 'USE ['+ @db +']; DBCC SHRINKFILE ('''+@fileName+''',512);'
        EXECUTE (@cmd)

FETCH NEXT FROM dbcursor INTO @db, @fileName;
END
CLOSE dbcursor;
DEALLOCATE dbcursor;
END

termine aqui o resultado:

O valor solicitado foi 512MO, mas o valor atual no disco está em torno de 650MO. Se eu reiniciar a consulta com

USE [BASE2]; DBCC SHRINKFILE ('BASE2_log',8);
USE [BASE3]; DBCC SHRINKFILE ('BASE3_log',8);

o valor no disco será em torno de 250 MO. Então, por que minha primeira consulta não reduziu os arquivos de log para o valor solicitado 512 MO? De fato, não havia VLF ativo no final do arquivo e ainda muito espaço não utilizado.

Como DBA do SQL Server, tenho trabalhos de manutenção para reconstruir/reorganizar índices regularmente. Recentemente, me perguntei sobre a fragmentação de tabelas no SQL Server. Então eu li o artigo sobre tabelas de heap e sua fragmentação. Verificamos constantemente o status dos servidores SQL de várias maneiras e gostaria de saber se adicionar uma verificação na fragmentação da tabela será útil.

Estou pensando em desenvolver algo como: "É um índice de cluster?" sim -> não faça nada, não -> verifique:

percentage of fragmentation > x%

numbers of forward pointing > x

numbers of rows > x

se x > alguns valores, acione um alerta.

O que você acha de configurar esse tipo de verificação, útil ou não?

A desfragmentação de tabelas heap reduzirá o tamanho físico dos arquivos do banco de dados no disco?

EDITAR:

Eu finalmente uso este pedaço de código para detectar tabelas heap que precisam ser reconstruídas:

SELECT Database_id, Object_name([object_id]) as TableName, Index_type_desc, 
Avg_fragmentation_in_percent, rowmodctr, forwarded_record_count
From sys.dm_db_index_physical_stats(db_id(),object_id(''),null,null,'detailed') AS SDDIPS
Inner join sys.sysindexes AS SI on SDDIPS.[object_id] = SI.id 
AND SDDIPS.index_id = SI.indid
--Inner join sysobjects AS SO on  SI.id = SO.id
Where index_level = 0 AND index_type_desc = 'HEAP' AND Avg_fragmentation_in_percent > 40 
AND rowmodctr > 100 AND forwarded_record_count > 1000

No entanto, ele é executado por um longo período de tempo e o desempenho como o colapso do PLE