All perguntas(dba)

Uma vez por dia ou dois, obtemos o erro abaixo e o mysql trava:

2024-07-14T05:31:59.327696Z 0 [ERROR] [MY-012872] [InnoDB] [FATAL] Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2024-07-14T05:31:59.327741Z 0 [ERROR] [MY-013183] [InnoDB] Assertion failure: srv0srv.cc:1878:ib::fatal triggered thread 140039700203264
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-07-14T05:31:59Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=1758de1e111952b1f61480360c447dc27d6caddc
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x30000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x2130f51]
/usr/sbin/mysqld(print_fatal_signal(int)+0x397) [0xfee797]
/usr/sbin/mysqld(my_server_abort()+0x75) [0xfee8e5]
/usr/sbin/mysqld(my_abort()+0xe) [0x212adee]
usr/sbin/mysqld(ut_dbg_assertion_failed(char const*, char const*, unsigned long)+0x309) [0x237b9b9]
/usr/sbin/mysqld(ib::fatal::~fatal()+0xcf) [0x237e2ff]
/usr/sbin/mysqld(srv_error_monitor_thread()+0x7aa) [0x231c41a]
/usr/sbin/mysqld(void Detached_thread::operator()<void (*)()>(void (*&&)())+0xca) [0x224a87a]
/lib64/libstdc++.so.6(+0xc2b13) [0x7f5de9854b13]
/lib64/libpthread.so.0(+0x81da) [0x7f5dea8bc1da]
/lib64/libc.so.6(clone+0x43) [0x7f5de8e6be73]
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

E antes há muitos deles:

Mutex at 0x7fde903975e8, Mutex TRX_SYS created trx0sys.cc:565, locked by 140504716736256
--Thread 140504724723456 has waited at trx0sys.h line 598 for 240 seconds the semaphore:
2024-07-13T04:43:26.039036Z 0 [Warning] [MY-012985] [InnoDB] A long semaphore wait:
{}

Também vejo muitos desses avisos nos logs (acho que principalmente após a reinicialização):

[Warning] [MY-013865] [InnoDB] Redo log writer is waiting for a new redo log file. Consider increasing innodb_redo_log_capacity.

Não consegui descobrir qual é a causa desse problema. Aumentei innodb_redo_log_capacitymuito, mas aconteceu mesmo assim. Eu também tentei desligar, innodb_adaptive_hash_indexmas não ajudou. Pensei em aumentar innodb_log_buffer_sizeo que atualmente está definido para 1 milhão porque pensei que talvez isso estivesse causando lentidão na transação.

É importante dizer que o MySQL parece parar de fazer qualquer coisa nesses 600 segundos. Não consigo me conectar ao servidor neste momento, a CPU está reduzida a nada e então recebemos esse erro e uma queda. Como não é possível conectar-se ao banco de dados durante o tempo de inatividade, pensei que executar um evento agendado do próprio MySQL, escrevendo consultas em execução no disco, deveria resolver o problema - mas eu estava errado. Mesmo o uso de um evento agendado parou de gravar no mesmo horário em que o tempo de inatividade começou. Outra coisa que tentei é habilitar innodb_status_outputquais logs SHOW ENGINE INNODB STATUS;a stderrcada 15 segundos, mesmo isso parou de gravar ao stderrmesmo tempo em que o tempo de inatividade começou.

Usamos a versão MySQL8.0.34

Eu tenho uma tabela, como a seguinte. Vamos chamá-lo Fools.

Uma regra de negócio é que para cada FoolID, só podemos IsActiveFoolValueestar 1em uma linha. Quero algum tipo de chave ou restrição para impor isso. No entanto, que eu saiba, chaves e restrições não podem fazer isso. A única ferramenta é um índice exclusivo como

CREATE UNIQUE NONCLUSTERED INDEX OnlyOneActiveFoolValuePerFoolId
ON Fools(FoolID)
WHERE IsActiveFoolValue = 1 

isso é considerado um antipadrão? Os índices não devem ser restrições. Eles deveriam ser ferramentas de desempenho. As restrições devem ser impostas por chaves, restrições e talvez gatilhos. Se for considerado um antipadrão, que desvantagens traz e quais alternativas existem?

Estou assumindo o SQL Server 2019, porque alguns recursos de índices filtrados exclusivos não existiam em versões muito antigas e quero manter minhas opções abertas para quaisquer alternativas modernas.

Temos um cluster Cassandra em execução no GKE com um pool de nós de 32 CPUs e discos SSD. O tamanho atual do cluster é de quase 1 PB, com cada nó utilizando uma média de 5 TB em discos SSD alocados de 10 TB. O cluster é composto por 200 nós, cada um com discos de 10 TB, totalizando 2 PB de tamanho total alocado.

Dado o tamanho deste cluster, os custos de manutenção são substanciais. Como podemos conseguir uma recuperação de desastres de baixo custo para um cluster tão grande?

Uma opção que estou considerando é criar um novo data center em uma região diferente com fator de replicação 1 (RF1). Embora isso não seja recomendado, reduziria pelo menos o tamanho do cluster por um fator de três.

Qualquer sugestão seria muito apreciada.

Se eu executar isso no DBeaver:

alter table classes alter column reference set not null;

no meu banco de dados local, que só eu abri no DBeaver, ele foi concluído com êxito.

Mas não consigo abrir a tabela no explorer e a coluna ainda aparece como anulável.

Se eu tentar fechar o DBeaver, ele diz que há uma transação aberta, mas acho que não.

Porém, se eu executar commit, de repente tudo funciona, consigo visualizar a tabela e a coluna aparece como não nula.

Achei que as instruções DDL não tinham o conceito de confirmação e reversão: preciso confirmar após cada uma em meus scripts de atualização do Flyway?

Quando temos o ajuste automático definido como ON para criação de índice, o banco de dados de hiperescala SQL do Azure criou cerca de 10 índices para algumas de nossas tabelas grandes. Ao analisar os índices, alguns deles diferem apenas nas colunas 'incluídas', enquanto as colunas do índice eram iguais. Essa proliferação de índice prejudicará as operações INSERT e UPDATE nessas tabelas.

Existe uma opção no Azure para combinar/otimizar índices, em vez de eliminarmos e recriarmos manualmente índices melhores para muitas tabelas? A partir de agora, desligar a criação automática de índice parece ser a única coisa a fazer.

Existem outras sugestões?

Estou projetando um banco de dados postgres no qual existe uma tabela que possui uma coluna do tipo jsonb. Eu gostaria que esta coluna fosse única. Não há necessidade de ter dois objetos com exatamente a mesma configuração json na tabela. No futuro, isso me pouparia cerca de 5 minutos de tempo de computação por duplicata não salva no banco de dados. Estou ciente do risco de exclusividade do JSON quando se trata de dictos (a ordem das chaves não é garantida), mas acho que um bom codificador JSON pode mitigar isso.

Minha preocupação é com o desempenho do banco de dados. Quero ter certeza de que estamos fazendo todo o possível para garantir que as inserções não sejam terrivelmente retardadas com essa restrição de exclusividade no jsonb. Quão ruim seria uma restrição de exclusividade em jsonb comparada a uma exclusividade em varchar ou int? Estamos falando de milissegundos, segundos ou minutos?

Examinei o índice Hash , que parece ser tudo o que eu precisaria para obter o desempenho ideal. Mas. Somente o tipo de índice de árvore B pode ser único, o que é estranho. Por que?

Eu tenho duas mesas:

empregos

CREATE TABLE IF NOT EXISTS jobs (
    job_id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    job_name TEXT,
    prime_desc INTEGER NOT NULL REFERENCES descriptions(desc_id),
    scnd_desc INTEGER NOT NULL REFERENCES descriptions(desc_id),
);

INSERT INTO jobs (job_name, prime_desc, scnd_desc) VALUES ('Soldier', 1, 5);
INSERT INTO jobs (job_name, prime_desc, scnd_desc) VALUES ('Pastor', 2, 3);
INSERT INTO jobs (job_name, prime_desc, scnd_desc) VALUES ('Firefighter', 5, 4);

descrições

CREATE TABLE IF NOT EXISTS descriptions (
    desc_id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
    desc_name TEXT,
);

INSERT INTO descriptions (desc_name) VALUES ('Strong');
INSERT INTO descriptions (desc_name) VALUES ('Pious');
INSERT INTO descriptions (desc_name) VALUES ('Honest');
INSERT INTO descriptions (desc_name) VALUES ('Agile');
INSERT INTO descriptions (desc_name) VALUES ('Brave');

Neste exemplo, gostaria de poder adicionar duas descrições a um trabalho. O código funciona e posso consultá-lo:

SELECT * FROM jobs;

Isso retorna o resultado esperado:

1|Soldier|1|5
2|Pastor|2|3
3|Firefighter|5|4

O que estou tentando fazer é obter uma consulta que liste o nome do trabalho e os nomes das descrições primária e secundária:

Firefighter|Brave|Agile

Não consegui obter esse resultado.

Eu tentei:

SELECT
    jobs.job_name,
    desc.desc_name
FROM
    jobs
JOIN
    descriptions ON jobs.prime_desc = descriptions.desc_id
JOIN
    descriptions ON jobs.scnd_desc = descriptions.desc_id;

Isso retorna um erro:

Parse error: ambiguous column name: descriptions.desc_name
  SELECT jobs.job_name, descriptions.desc_name FROM jobs JOIN descriptions ON...
          error here ---^

Pesquisei na Internet sobre esse erro e não consegui encontrar nada que fosse um exemplo do que estou tentando realizar.

Eu tentei muitas combinações diferentes de:

RIGHT JOIN, LEFT JOIN, UNION, UNION ALL, ALIAS

em múltiplas configurações. O mais próximo que cheguei foi com UNION, mas não produziu os resultados desejados; aqui está o UNION que tentei:

SELECT
    jobs.job_name, descriptions.desc_name
FROM
    jobs
JOIN
    descriptions ON jobs.prime_desc = descriptions.desc_id
UNION
SELECT
    jobs.job_name, descriptions.desc_name
FROM
    jobs
JOIN
    descriptions ON jobs.scnd_desc = descriptions.desc_id;

Isso retorna:

Soldier|Strong
Pastor|Pious
Firefighter|Brave
Soldier|Brave
Pastor|Honest
Firefighter|Agile

Ele está retornando os resultados conforme solicitado, então sei que é algo que estou fazendo de errado. Só não sei o que estou fazendo que não imprime os resultados em uma linha por trabalho, conforme ilustrado pelo exemplo do Bombeiro acima.

Tentei criar um alias de coluna, um alias de tabela etc. Não sei como abordar isso. Qualquer ajuda é apreciada.

Eu tenho uma consulta simples, usando uma coluna indexada, em um conjunto de dados muito pequeno, retornando 1 linha, atingindo o Banco de Dados SQL do Azure - ocupando mais de meio segundo. Outra execução anterior desta consulta levou 38 ms.

Plano de Execução (obrigado JD)

A pergunta:

SELECT [a].[Id], [a].[ClaimType], [a].[ClaimValue], [a].[UserId]
FROM [AspNetUserClaims] AS [a]
WHERE [a].[UserId] = @__id_0

Existem 36 linhas no banco de dados. O UserId é uma string que é um GUID. O ClaimType e ClaimValue são strings com 1 a 35 caracteres.

O UserId é indexado.

2 linhas de dados:

Id  ClaimType   ClaimValue  UserId
5   SysAdmin    *   e69fac60-ea9b-4f73-8c7b-4cb75ec9721a
6   Admin   Arapahoe    e69fac60-ea9b-4f73-8c7b-4cb75ec9721a

Como faço para descobrir por que a leitura lenta (às vezes)?

Estamos no SQL Server 2019.

Temos vários trabalhos do Sql Agent e, por padrão, eles são de propriedade do sa.

A equipe de segurança da empresa emitiu um decreto determinando que todas as contas SA deveriam ser desativadas por motivos de segurança, e isso me deixou um pouco confuso.

Temos um trabalho do Sql Agent que começou a falhar. Quando falha, tem o erro

Login failed for user 'sa'. Reason: The account is disabled.

Eu pensei, ok, isso faz sentido; desativamos a conta. Então segui vários caminhos para tentar consertar.

1. Mude a propriedade para outra conta. Tentei várias, mas todas eram contas privilegiadas e ainda recebia o mesmo erro. Encontrei uma postagem em um fórum que dizia que o Sql Server padronizaria qualquer conta privilegiada para ser executada como sa.

2. Tentei alterar o usuário Run As na seção Avançado da etapa do trabalho. Isso mudou o erro para

   Access to the remote server is denied because the current security context is not trusted
   

   Então descobri que não era possível desmarcar esse atributo na definição da tarefa - só poderia alterar para quem ele apontava, e isso me levou de volta para "sa está desabilitado"

3. Então percebi que temos vários empregos de agente pertencentes a sa e apenas este está falhando. Não vejo as diferenças de configuração que explicariam por que este 1 falha e os outros 10-20 que pertencem a sa não. Não configuramos proxies e geralmente não tentamos alterar o Run As em lugar nenhum.

Qualquer indicação seria apreciada.

Obrigado

Eu tenho um banco de dados que foi dividido devido a problemas de agrupamento devido a uma migração de servidor.

1. Eu tenho o merge1banco de dados que é o banco de dados mais antigo, livre de dados corrompidos, mas não possui entradas mais recentes.

2. Eu tenho o merge2banco de dados que contém todas as entradas (antigas e novas), porém muitas das entradas mais antigas estão corrompidas (as entradas mais recentes estão bem).

3. Ambos os bancos de dados estão exatamente no mesmo servidor de banco de dados MariaDB. Já sei como fazer coisas como seletores de banco de dados ( merge1.table3).

4. Estou usando o rootusuário MariaDB que não é exposto ao público pois considero isso apenas uma manutenção puramente interna.

5. Não há absolutamente nenhuma diferença estrutural de banco de dados entre os dois bancos de dados e não haverá mudanças estruturais até que esta fusão de banco de dados seja concluída, sem que nenhuma esteja planejada de forma alguma.

Até agora, fiz um bom trabalho com o information_schema.COLUMNSbanco de dados e a tabela ( TABLE_NAMEe COLUMN_NAME). Portanto, tenho uma lista de todas as linhas de cada tabela:

SELECT `COLUMN_NAME` FROM information_schema.`COLUMNS` WHERE `TABLE_SCHEMA`='merge1';

Agora que o "quadro geral" está estabelecido, estou tentando determinar se e como tornar o trabalho mais fácil construindo dinamicamente as consultas, pois há muitas tabelas e algumas têm muitas colunas. Então, vamos que a tabela table3tenha xum número de colunas (duas colunas, dezenas, etc. Eu já sei que a merge1tabela tem 200 entradas básicas, então só preciso de INSERT201+ (um exemplo estático para manter as coisas simples).

Então aqui está meu exemplo aproximado e não funcional:

INSERT INTO merge1.table3 
(
 SELECT `COLUMN_NAME` 
 FROM information_schema.`COLUMNS` WHERE `TABLE_SCHEMA`='merge1'
)
VALUES 
(
 SELECT * FROM merge2.table3 information_schema WHERE id>200
);

O problema parece estar enraizado nos valores que estão sendo inseridos, já que o MariaDB parece estar satisfeito com o subfornecimento SELECTdos nomes das colunas. Talvez eu não esteja construindo dinamicamente a segunda metade da consulta?

Como faço para corrigir/melhorar a consulta para fornecer os nomes das colunas correspondentes sem ser forçado a defini-los estaticamente?