All perguntas(dba)

Recebi uma solicitação para encontrar o backup de log transacional mais recente. Neste servidor específico, ele não está funcionando por algum motivo.

aqui está a pergunta:

SELECT
    @@Servername AS [Server_Name],
    B.name AS Database_Name,
    ISNULL(STR(ABS(DATEDIFF(day, SYSDATETIME(), MAX(A.backup_finish_date)))), 'NEVER') AS DaysSinceLastBackup,
    ISNULL(CONVERT(CHAR(11), MAX(A.backup_finish_date), 113) + ' ' + CONVERT(VARCHAR(8), MAX(A.backup_finish_date), 108), 'NEVER') AS LastBackupDate,
    BackupSize_GB = REPLACE(CONVERT(VARCHAR(50), CAST(CAST(COALESCE(MAX(A.compressed_backup_size), MAX(A.backup_size), 0)/1024.0/1024.0/1024.0 AS NUMERIC(18,2)) AS MONEY),1), '.00',''),
    BackupSize_MB = REPLACE(CONVERT(VARCHAR(50), CAST(CAST(COALESCE(MAX(A.compressed_backup_size), MAX(A.backup_size), 0)/1024.0/1024.0 AS NUMERIC(18,2)) AS MONEY),1), '.00',''),
    [Last Backup Duration (sec)] = DATEDIFF(s, MAX(A.backup_start_date), MAX(A.backup_finish_date)),
    [AVG Backup Duration (sec)] = AVG(CAST(DATEDIFF(s, A.backup_start_date, A.backup_finish_date) AS INT)),
    [Longest Backup Duration (sec)] = MAX(CAST(DATEDIFF(s, A.backup_start_date, A.backup_finish_date) AS INT)),
    [Shortest Backup Duration (sec)] = MIN(CAST(DATEDIFF(s, A.backup_start_date, A.backup_finish_date) AS INT)),
    A.type,
    media_set_id = MAX(A.media_set_id),
    B.create_date,
    B.recovery_model_desc,
    B.state_desc,
    B.is_read_only,
    B.database_id,
    Backup_Started = MAX(A.backup_start_date),
    Backup_Finished = MAX(A.backup_finish_date)
FROM sys.databases B WITH(NOLOCK)
LEFT OUTER JOIN msdb.dbo.backupset A WITH(NOLOCK)
    ON A.database_name = B.name
    AND A.type = 'L' -- Solo Transaction Log
WHERE 1=1
--B.Name = 'My_database'
GROUP BY
    B.Name,
    B.database_id,
    B.create_date,
    B.recovery_model_desc,
    B.state_desc,
    B.is_read_only,
    A.type

O Postgres aborta transações atuais em caso de erro? Em qualquer caso, você pode fornecer uma referência?

Pesquisar no Google "site:postgres.org transaction abort rollback error" não produziu resultados, e o GPT tem alucinações.

Encontrei essa afirmação no StackOverflow, mas ela não é apoiada por nada.

O Postgres aborta automaticamente as transações sempre que qualquer instrução SQL termina com um erro

Como posso dizer ao PostgreSQL para não abortar a transação inteira quando uma única restrição falhar?

Também encontrei isto . É semelhante, mas diferente, pois não lanço exceções (além disso, esse "normalmente" o torna confuso).

A opção level especifica a gravidade do erro. Os níveis permitidos são DEBUG, LOG, INFO, NOTICE, WARNING e EXCEPTION, com EXCEPTION sendo o padrão. EXCEPTION gera um erro (que normalmente aborta a transação atual ); os outros níveis geram apenas mensagens de diferentes níveis de prioridade. Se mensagens de uma prioridade específica são reportadas ao cliente, gravadas no log do servidor ou ambas, é controlado pelas variáveis ​​de configuração log_min_messages e client_min_messages. Veja o Capítulo 19 para mais informações.

• Meu ambiente de desenvolvimento tem XAMPP, o que significa que tenho o MariaDB instalado.
• A produção tem o MySQL 8 instalado.

1. Quando transfiro novas alterações de esquema do MariaDB para o MySQL, funciona na maior parte do tempo. Às vezes, tenho que mexer.

2. Mas meu principal problema é quando faço backup do esquema e dos dados do MySQL e tento restaurá-los para meu PC, bem, desisti. Isso requer muitas alterações. Muitos problemas estão relacionados a conjuntos de caracteres.

Há algo que eu possa fazer para tornar o #2 mais fácil? Talvez algumas regras sobre o que evitar no MySQL.

Provavelmente um tiro no escuro, mas a string @@VERSION pode ser substituída? Temos um software legado que roda bem em versões mais recentes do SQL Server, mas tem uma verificação codificada para uma string específica em @@VERSION na inicialização.

O aplicativo é executado na plataforma Ingres OpenROAD, se isso importa.

Tenho um servidor REST em execução no Amazon EC2 Windows com MySQL. Parece que, após um longo período de inatividade, o MySQL está encerrando as conexões. Estou usando Delphi com FireDAC. Recebo este erro nos logs

conFD: TFDPhysMySQLConnection: . O servidor MySQL foi embora [errno=2006, sqlstate="HY000"]

Pelo Google, parece que são 8 horas. Eu poderia aumentar isso, mas eventualmente isso ainda vai acontecer durante os feriados (talvez).

É a única tarefa do MySQL em execução, então não preciso conservar recursos. Qual é outra maneira de resolver isso?

Já reli este artigo várias vezes , mas ainda não consigo entender alguns momentos...

1. eu tenho um cluster de produção com 3 dc e a tabela com rf=3 em cada dc
2. Eu tirei um snapshot com o Ansible em cada nó simultaneamente

2.1) Criei o mesmo esquema no cluster de teste para keyspace e table

3. próximo passo é copiar cada instantâneo para cada servidor de teste? Exemplo: prod1 --> test1:path_to_table, prod2 --> test2:path_to_table?
4. etapa final: onde exatamente devo executar o sstableloader? Devo executá-lo em cada servidor no cluster de teste? ou apenas em alguém? A opção -d significa nó de origem ou nó de destino? Por favor me ajude.

select * from tblA a 
 left join tblB b on b.id = a.bId 
   group by a.bId 

Se eu agrupar com base em uma coluna, obtenho apenas o primeiro registro dos registros que têm o mesmo bIDvalor. Existe uma maneira de também obter o número total de registros que têm o mesmo bIdvalor para cada linha? Sem fazer uma consulta separada...

id | bId
--------
1  |  1
2  |  1
3  |  1
4  |  2
5  |  3


so in the above query I would expect

id | bId. | counts
-------------------
1  |  1  |  3   <- 3 records with bId = 1
4  |  2  |  1
5  |  3  |  1

Estou planejando remover vários bancos de dados grandes de um AG, mas não tenho um ambiente de teste adequado para testar meu script. Só tenho um ambiente de teste para bancos de dados que são muito menores em tamanho.

O que pretendo fazer, no entanto, é:

1. selecione os vários bancos de dados grandes em Detalhes do Object Explorer e faça o script removendo-os em uma planilha de consulta e, em seguida, execute a coleção de instruções alter com script na planilha de consulta de uma só vez. Em seguida, faça algo semelhante para remover os bancos de dados 'Restoring' na réplica secundária de uma só vez.
2. ou selecionar os vários bancos de dados grandes no Object Explorer e simplesmente removê-los diretamente com um clique no SSMS. Da mesma forma, excluir os bancos de dados 'Restaurando' no secundário com um clique no SSMS Object Explorer Details.

Minha preocupação é que eles são grandes bancos de dados, alguns deles têm cerca de 2 TB cada e cerca de 300 deles. O Automatic Seeding é usado para adicioná-los. Há algo com que eu precise me preocupar ao fazer a remoção do AG, de tantos bancos de dados grandes com um clique?

Gostaria que me informassem sobre quaisquer questões que precisem ser destacadas ao realizar isso, por favor.

Obrigado

Estamos usando o PostgreSQL-13 como nosso servidor principal e encontramos um gargalo de desempenho.

O hardware inclui 2 CPUs (AMD EPYC9754 com 128 núcleos e 256 threads cada), 128 GB de memória, hardware RAID0 inclui 2 * 4T SSD (Samsung990Pro).

Acho que o servidor PG não consegue usar todo o potencial do hardware.

Antes de fazer esta pergunta aqui, eu fiz as seguintes coisas:

1. Verifique minha consulta SQL (usando exatamente a chave primária, sem varredura de sequência);
2. Confirmar se meu programa roda corretamente (embora eu tenha escrito a mesma lógica em Python e C++, ambos rodam lentamente);
3. Configurar meu servidor PG para usar o HugePage (configurei 80 GB de memória HugePage no total e permiti que o servidor PG use 64 GB shared_buffers);
4. Aumentar os limites de memória de cada trabalhador PG( work_mem, temp_buffers,...);
5. Aumentar o número de trabalhadores paralelos( max_worker_processes, max_parallel_workers_per_gather, max_parallel_workers,...);
6. Ligar force_parallel_mode;
7. Diminua o custo de io e o custo da CPU cfg( random_page_cost=1.01, cpu_tuple_cost=0.0025, cpu_index_tuple_cost=0.001,...);
8. Maximizado default_statistics_targetpara 1000;
9. Desabilitar replicações;
10. 32 ou 64 processos de inicialização se conectam paralelamente ao servidor e consultam diferentes linhas de uma mesma tabela com diferentes chaves primárias.
11. Todas as consultas são somente leitura e NÃO há operações de inserção/atualização/DDL durante os testes;

O que estou esperando:

1. O servidor PG usa pelo menos 50% dos recursos de CPU/memória;
2. Não há nenhum processo único bloqueando outras consultas;
3. O rendimento total basicamente aumenta linearmente conforme a quantidade de recursos que aloquei ao servidor PG (talvez eu seja ingênuo?);

Meus testes:

1. A definição da tabela:

   CREATE TABLE IF NOT EXISTS ob_lots(
       t_stamp INT8 NOT NULL,
       trd_sec INT4 NOT NULL,
       o_level INT2 NOT NULL,
       i_olots INT4 NOT NULL,
       f_olots FLOAT4 NULL,
   CONSTRAINT prk_ob_lots PRIMARY KEY( t_stamp, o_level ) );
   

2. A pergunta:

   SELECT f_olots, t_stamp, trd_sec FROM ob_lots
   WHERE t_stamp BETWEEN $1 AND $2
   ORDER BY t_stamp DESC, o_level DESC
   LIMIT 4096;
   

3. Programa de teste: Inicie muitas instâncias do meu programa que consultam aleatoriamente linhas da tabela acima paralelamente com o SQL de consulta acima. Quando o número de clientes estava aumentando de 2 para 4, ou de 4 para 8, ou de 8 para 16, observamos que o rendimento total quase dobrou todas as vezes. Mas de 16,32 ou mais, o rendimento total nunca mudou.

4. Explicação SQL:

   Gather  (cost=1000.28..1002.41 rows=1 width=18) (actual time=6.840..9.232 rows=0 loops=1)
   Workers Planned: 1
   Workers Launched: 1
   Single Copy: true
   Buffers: shared hit=8
   ->  Limit  (cost=0.28..2.31 rows=1 width=18) (actual time=0.033..0.033 rows=0 loops=1)
           Buffers: shared hit=8
           ->  Index Scan Backward using prk_ob_lots_sc5555 on ob_lots_sc5555  (cost=0.28..2.31 rows=1 width=18) (actual time=0.031..0.031 rows=0 loops=1)
               Index Cond: ((t_stamp >= 123) AND (t_stamp <= 456))
               Buffers: shared hit=8
   Planning:
   Buffers: shared hit=109
   Planning Time: 0.759 ms
   Execution Time: 9.274 ms
   

As seguintes coisas me parecem estranhas:

1. Há um processo PG que usa quase 100% de um único núcleo de CPU, e os outros usam muito menos;
2. NÃO há io, NENHUMA troca durante o teste, e muitos recursos de memória/CPU/io estão livres/ociosos. Algo parece que todos os outros trabalhadores estão esperando pelo processo PG mestre (imagino que um use 100% da CPU), e resulta em um gargalo;
3. O banco de dados de teste usou cerca de 4 GB de espaço em disco, pequeno o suficiente para ser mantido inteiramente na memória pelo PG. De fato, como observamos, não há nenhuma operação de io;

O que está fazendo? Por que todos os trabalhadores estão esperando por um único processo?

Esta é a parte principal da minha configuração PG (eu apenas listo as linhas que alterei):

max_connections = 2048

buffers compartilhados = 64 GB

huge_pages = ligado

temp_buffers = 256 MB

max_prepared_transactions = 256

work_mem = 256 MB

manutenção_trabalho_mem = 16 GB

memória_de_trabalho_de_vácuo_automático = -1

tipo_de_memória_compartilhada_dinâmica = posix

simultaneidade_io_efetiva = 1000

manutenção_io_concorrência = 1000

max_worker_processes = 256

max_parallel_maintenance_workers = 256

max_parallel_workers_per_gather = 256

parallel_leader_participation = ligado

max_parallel_workers = 256

fsync = desligado

synchronous_commit = desligado

full_page_writes = desativado

wal_compression = ativado

wal_buffers = -1

atraso_do_escritor_wal = 10000ms

wal_writer_flush_after = 1 GB

atraso_de_commit = 100000

commit_siblings = 128

tempo_limite_do_ponto_de_verificação = 1d

max_wal_size = 128 GB

tamanho_min_wal = 32 GB

meta_de_conclusão_do_ponto_de_verificação = 1.0

checkpoint_flush_after = 0

aviso_do_ponto_de_verificação = 0

max_wal_senders = 0

custo_da_página_seq = 1,0

custo_da_página_aleatória = 1,01

custo_tupla_da_cpu = 0,0025

custo_da_tupla_do_índice_da_cpu = 0,001

custo_operador_cpu = 0,00125

tamanho_do_cache_efetivo = 64 GB

meta_estatística_padrão = 1000

force_parallel_mode = ativado

autovacuum = ligado

E as saídas de tope iotop:

topo - 16:38:16 acima 4:09, 2 usuários, média de carga: 14,16, 9,14, 3,97

Número: 1581 no total, 2 em execução, 1573 dormindo, 0 parado, 6 zumbis

%Cpu(s): 3,5 us, 4,3 sy, 0,0 ni, 92,1 id, 0,0 wa, 0,0 hi, 0,1 si, 0,0 st

GiB Mem: 125,6 total, 34,6 grátis, 82,9 usado, 9,1 buff/cache

GiB Swap: 1,0 total, 1,0 grátis, 0,0 usado. 42,6 disponível Mem

进程号 USER PR NI VIRT RES SHR SWAP %CPU %MEM TIME+ COMMAND

31159 leon 20 0 4654,2m 105,1m 12,5m 0,0m S 152,7 0,1 7:09,93 carga

3186 postgres 0 -20 66,7g 18,6m 16,2m 0,0m R 99,5 0,0 5:03.16 postgres #é o mestre?

3192 postgres 0 -20 80,4m 6,8m 3,6m 0,0m S 8,2 0,0 0:24,97 postgres

32218 postgres 0 -20 66,7g 13,5m 9,9m 0,0m S 5,8 0,0 0:12,90 postgres

31217 postgres 0 -20 66,7g 13,4m 9,9m 0,0m S 5,3 0,0 0:12,74 postgres

31234 postgres 0 -20 66,7g 13,5m 9,9m 0,0m S 5,3 0,0 0:12,74 postgres

(muitos muitos processos postgres...)

Total de LEITURA DE DISCO: 0,00 B/s | Total de GRAVAÇÃO DE DISCO: 0,00 B/s

LEITURA DE DISCO atual: 0,00 B/s | GRAVAÇÃO DE DISCO atual: 0,00 B/s

TID  PRIO  USER     DISK READ DISK WRITE>    COMMAND

  1 be/4 root        0.00 B/s    0.00 B/s init

  2 be/4 root        0.00 B/s    0.00 B/s [kthreadd]

  3 be/0 root        0.00 B/s    0.00 B/s [rcu_gp]

  4 be/0 root        0.00 B/s    0.00 B/s [rcu_par_gp]

  5 be/0 root        0.00 B/s    0.00 B/s [slub_flushwq]

Tenho um único servidor físico executando Cassandra. Dado que Cassandra tem desempenho ruim com fat nodes, qual estratégia é melhor:

• Executando um único nó grande no servidor (alocando todos os recursos para essa instância)
• Executar vários nós menores no servidor e simular um cluster (dividindo os recursos nas instâncias)

Desde já, obrigado.