All perguntas(dba)

Estou tentando descobrir o que uma transação específica está bloqueando que impede outras consultas de executar. Eu consultei pg_locks assim:

select c.relname, l.*
from pg_locks l
join pg_database d on l.database = d.oid
left join pg_class c on l.relation = c.oid
where d.datname = 'MYDB' and pid = MYPID

Isso retornou um monte de resultados como este

relationera NULL para a maioria (não todos) dos resultados. Para estes, classide objideram não nulos (como no exemplo acima). Como resolvo isso para identificadores de objeto úteis? De acordo com a documentação do pg_locks, os bloqueios são "identificados por OID de classe e OID de objeto, da mesma forma que em pg_description". Quando consulto pg_description , no entanto, não consigo encontrar esses oids. Os valores da coluna objoid estão todos abaixo de 20000 - não há nada como 805681436.

Edição: consulta atualizada com base na resposta de Laurenz Albe (obrigado!)

select l.granted, l.locktype, l.mode, l.classid, l.objid, l.classid::regclass
    , c.relname, cns.conname -- relation
    , cns.conrelid::regclass as constraint_table, cns.contype -- constraint
    , trg.tgrelid::regclass as trigger_table, trg.tgname -- trigger
from pg_locks l
join pg_database d on l.database = d.oid
left join pg_class c on l.relation = c.oid
left join pg_constraint cns on l.objid = cns.oid and l.classid::regclass = 'pg_constraint'::regclass
left join pg_trigger trg on l.objid = trg.oid and l.classid::regclass = 'pg_trigger'::regclass
where d.datname = 'MYDB' and pid = MYPID

Acabei de tentar atualizar uma instância do MySQL executando o MySQL 5.7.30 (no Docker) para o MySQL 8.4.3 (no Docker) e agora a instância não inicia, reclamando de um mysql.ibdarquivo ausente.

Verifiquei a pasta de dados do MySQL e esse arquivo não existe (a pasta mysql existe com todos os arquivos de tabela nela), mas verifiquei outros sistemas ainda no MySQL 5.7.x e o arquivo não está lá. Acho que talvez a atualização do MySQL 8.x deva criá-lo, pois entendi que o banco de dados do sistema mysql era um MyISAM antes da v8.x?

Pesquisei e não consegui encontrar nenhum relato do mesmo problema. Alguém sabe por que isso ocorreu e como resolver esse problema e colocar a nova instância em funcionamento?

Este foi um teste de atualização no local antes de tentar em sistemas ativos, então eu gostaria de entender como evitá-lo ao fazer atualizações reais.

2025-03-07 19:50:44+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 8.4.3-1.el9 started.
'/var/lib/mysql/mysql.sock' -> '/var/run/mysqld/mysqld.sock'
2025-03-07T19:50:45.450364Z 0 [System] [MY-015015] [Server] MySQL Server - start.
2025-03-07T19:50:45.794562Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.4.3) starting as process 1
2025-03-07T19:50:45.870761Z 1 [System] [MY-013576] [InnoDB] InnoDB initialization has started.
2025-03-07T19:50:51.814984Z 1 [ERROR] [MY-012592] [InnoDB] Operating system error number 2 in a file operation.
2025-03-07T19:50:51.815073Z 1 [ERROR] [MY-012593] [InnoDB] The error means the system cannot find the path specified.
2025-03-07T19:50:51.815110Z 1 [ERROR] [MY-012216] [InnoDB] Cannot open datafile for read-only: 'mysql.ibd' OS error: 71
mysqld: Can't open file: 'mysql.ibd' (errno: 0 - )
2025-03-07T19:50:52.210315Z 1 [ERROR] [MY-010334] [Server] Failed to initialize DD Storage Engine
2025-03-07T19:50:52.210893Z 0 [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
2025-03-07T19:50:52.210968Z 0 [ERROR] [MY-010119] [Server] Aborting
2025-03-07T19:50:52.214916Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.4.3)  MySQL Community Server - GPL.
2025-03-07T19:50:52.214957Z 0 [System] [MY-015016] [Server] MySQL Server - end.

Tenho o PostgreSQL 15 em execução em um pod do Kubernetes usando a imagem Zalando Spilo, gerenciada pelo Patroni. O contêiner tem um limite de memória de 16 GB e o tamanho do banco de dados é de 40 GB (diretório de dados no disco). Quando reinicializo uma réplica com o Patroni, ele executa "basebackup.sh", que por sua vez executa o comando "pg_basebackup": /usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/data -X none --dbname='dbname=postgres user=standby host=<Leader IP> port=5432'

Percebi que os primeiros 16 GB são copiados rapidamente, mas o processo fica significativamente mais lento depois (observei que, após a cópia, o tamanho é aproximadamente igual aos limites de memória do contêiner). Aumentar o limite de memória do contêiner para 32 GB mostrou um padrão semelhante: os primeiros 32 GB foram copiados rapidamente e, em seguida, o processo ficou mais lento.

Executando o comando manualmente: /usr/lib/postgresql/15/bin/pg_basebackup --pgdata=/home/postgres/pgdata/pgroot/dummy_dir -X none --dbname='dbname=postgres user=standby host=<Leader IP> port=5432' o problema foi reproduzido. Quando a memória total do contêiner (incluindo cache de páginas e arquivos inativos, que representam uma grande parte da memória RAM do contêiner) atinge o limite, o 'pg_basebackup' fica lento. Outras operações de gravação em disco (por exemplo, gerar e copiar arquivos grandes com 'dd') não são afetadas pelo limite de memória e permanecem rápidas.

Quando 'pg_basebackup' está lento e o limite de memória do contêiner é atingido, tentei descartar o cache de página com: " sync && echo 3 > /proc/sys/vm/drop_caches" e isso tornou 'pg_basebackup' rápido novamente.

O desempenho do 'pg_basebackup' é limitado pelo cache da página de arquivos? Você precisa de alguma informação adicional? Alguma sugestão? Obrigado pela ajuda!

É possível incluir uma verificação de data em uma tabela do Db2?

Eu tentei:

CREATE TABLE customers (
    id int GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    email VARCHAR(60) NOT NULL UNIQUE,
--  etc
    dob date,   -- Db2: CHECK (dob < current_timestamp - interval '18 years'), fails
--  etc
);

Consegui fazer isso em outros DBMSs; o código comentado acima, por exemplo, funciona para PostgreSQL. No entanto, quando tento no Db2, recebo uma mensagem como:

Erro SQL [42621]: Uma restrição de verificação ou coluna gerada que é definida com "current_date" é inválida

Talvez haja uma solução alternativa?

Inicie o evento estendido auto_stats, filtre algum ruído e prepare-se para monitorá-lo.

CREATE EVENT SESSION [AutoStatsTest] ON SERVER 
ADD EVENT sqlserver.auto_stats(
    WHERE ([duration]>1 AND [object_id] > 0) ) 
ADD TARGET package0.ring_buffer

ALTER EVENT SESSION [AutoStatsTest] ON SERVER
STATE = START
GO

Encontre uma tabela temporal. Eu tinha uma cópia do banco de dados StackOverflow2010 em mãos, então simplesmente versionei Voteso sistema.

ALTER TABLE Votes ADD
ValidFrom DATETIME2 GENERATED ALWAYS AS ROW START HIDDEN
    CONSTRAINT DF_InsurancePolicy_ValidFrom DEFAULT SYSUTCDATETIME(),
ValidTo DATETIME2 GENERATED ALWAYS AS ROW END HIDDEN
    CONSTRAINT DF_InsurancePolicy_ValidTo DEFAULT CONVERT(DATETIME2, '9999-12-31 23:59:59.9999999'),
PERIOD FOR SYSTEM_TIME(ValidFrom, ValidTo);
GO

ALTER TABLE Votes
    SET (SYSTEM_VERSIONING = ON);
GO

Com sua tabela temporal, faça algo que acione uma atualização automática de estatísticas. Isso funcionou para mim.

SELECT TOP (1000) [BountyAmount]
FROM [StackOverflow2010].[dbo].[Votes]
WHERE [PostId] < [BountyAmount]

UPDATE [StackOverflow2010].[dbo].[Votes]
SET BountyAmount = 4*PostId

SELECT TOP (1000) [BountyAmount]
FROM [StackOverflow2010].[dbo].[Votes]
WHERE [PostId] < [BountyAmount]

Agora inspecione o XML do seu Evento Estendido

SELECT target_data
FROM sys.dm_xe_session_targets AS xet
JOIN sys.dm_xe_sessions AS xe
ON (xe.address = xet.event_session_address)
WHERE xe.name = 'AutoStatsTest'

Se você for como eu, verá alguns campos que relatam um sample_percentage de 100%.

        <data name="sample_percentage">
            <type name="int64" package="package0">
            </type>
            <value>
                100
            </value>
        </data>

Considerando a duração (800 microssegundos na minha máquina patética), eu sabia que isso era um absurdo. Ao consultar sys.dm_db_stats_properties, descobri que a porcentagem real era muito menor que 100.

/*
Save yourself the pain of writing
the stats query
and just use sp_BlitzIndex from GitHub
*/
EXEC sp_blitzindex @databasename = 'StackOverflow2010', @tablename = 'Votes'

Em resumo, parece que o Evento Estendido auto_stats relata um sample_percentage incorreto para tabelas temporais . Isso é um bug do SQL Server ou é um mal-entendido meu? Se for um mal-entendido meu, onde posso ler mais? Eventos Estendidos individuais, até onde eu sei, são muito carentes de documentação.

Só vi isso acontecer com tabelas temporais. Já o encontrei tanto no SQL Server 2022 em uma máquina real (a tabela tinha vários terabytes, então gritei quando vi uma taxa de amostragem de 100% para a estatística da chave primária) quanto na minha máquina de teste local de 2019.

Adicionar um índice columnstore parece ajudar a reproduzir isso, mas não tenho 100% de certeza.

CREATE NONCLUSTERED COLUMNSTORE INDEX IX_ColStore
on dbo.Votes
(
    Id,
    PostId
)

Tenho absoluta certeza de que há um bug real aqui. No entanto, minhas tentativas de reproduzi-lo deram resultados inconsistentes. Suspeito que você precise de uma tabela com escala TB.

Atualização final: desisto de explicar isso. As estatísticas da tabela indicam que 90 vezes mais linhas do que as exibidas no plano de execução real (capturado em tempo real enquanto estava em produção, varrendo o índice columnstore não clusterizado) foram usadas para atualizar as estatísticas. O número de linhas no plano de execução real é 10.000 vezes menor que a contagem de linhas da tabela, e o evento estendido auto_stats indica que 100% das linhas da tabela foram lidas. É impossível que todas essas informações sejam verdadeiras ao mesmo tempo.

Suspeito que o que está causando tudo isso pode ser o bitmap excluído.

Recentemente, atualizamos o nível de compatibilidade do nosso SQL Server de 2012 para 2016, mas após atualizar o nível de compatibilidade, tivemos problemas de desempenho quando muitas subconsultas são usadas. Especialmente quando mais de 35 subconsultas são usadas.

Aqui está uma consulta com a qual posso reproduzi-lo:

SELECT 
  [PK_R_ASSEMBLYCOSTING],
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  (SELECT SUM([PRICEEXMARKUP]) FROM [R_ASSEMBLYCOSTINGITEM] WHERE [FK_ASSEMBLYCOSTING] = [PK_R_ASSEMBLYCOSTING]),
  [PK_R_ASSEMBLYCOSTING]
FROM [R_ASSEMBLYCOSTING]
WHERE [FK_ASSEMBLY] = 309961

Quando há menos de 35 subconsultas, o plano de consulta mostra que está usando buscas de índice para as subconsultas:

Mas para cada subconsulta adicional acima de 35, uma varredura de índice é usada:

Alguém tem alguma explicação do porquê isso acontece? Se Legacy Cardinality Estimation estiver habilitado, a consulta é rápida e não tem esse problema, mas queremos desabilitar isso.

Já tentei reconstruir os índices e atualizar as estatísticas, mas isso não faz diferença.

Sei que estou entrando em detalhes, mas estou implementando algo para processar um feed multilíngue.

Na tabela de ingestão bruta, que tem aproximadamente 190 milhões de linhas, eu queria capturar tudo o que o fornecedor nos enviou, mas devo repassar apenas as linhas que estão em um pequeno subconjunto de idiomas aprovados.

Originalmente, essa lista era apenas em inglês, mas agora eles querem aumentar a lista de idiomas "aprovados".

Então, tenho vários lugares onde a etapa de processamento é

WHERE lang_code = 'en'

que precisam de ajustes.

Eu criei algumas implementações

1. Variável de tabela muito pequena na rotina de processamento do feed com 2-3 linhas para códigos "aprovados".
2. Uma tabela permanente muito pequena contendo 2 a 3 linhas para códigos aprovados.
3. PATINDEX em uma string de vírgula com códigos aprovados (por exemplo, WHERE PATINDEX('%,'+lang_code+',%', ',en,de,pl,') > 0)

A lista pode crescer para 5 ou 6, mas é improvável que passe de 10.

Para esse tipo de lista muito curta, eu queria saber onde as pessoas podem ver a linha entre implementações de tabela e implementações apenas "nesta sequência curta".

Tenho uma tabela de banco de dados de documentos e uma tabela de banco de dados de versões de documentos. Há uma relação de um para muitos entre documento e versão de documento. Estou procurando conselhos sobre como modelar exatamente qual versão de documento está "ativa" para um dado documento.

CREATE TABLE documents (
  id serial primary key,
  name varchar(250) not null
  -- active_version integer REFERENCES document_versions(id) not null
);
CREATE TABLE document_versions (
  id serial primary key,
  document integer REFERENCES documents(id) not null,
  name varchar(32) not null
  -- active boolean not null default false
);

Estou procurando uma maneira de marcar qual das entradas da versão do documento está "ativa". Comentadas no esquema estão duas maneiras de fazer isso, mas não acredito que nenhuma delas seja necessariamente ideal.

No primeiro caso, a tabela de documentos tem uma referência de volta às versões do documento. Isso força exatamente uma versão do documento a estar ativa. Suponho que haja um catch-22, então não é possível realmente impor que a active_versioncoluna seja not null. O principal problema com essa abordagem, na minha opinião, é que há uma referência circular entre as duas tabelas.

A segunda maneira de fazer isso é com uma activecoluna booleana na tabela de versões do documento. Suponho que isso esteja ok, mas não tenho certeza de como fazer uma restrição para que apenas uma linha na tabela com um determinado documentvalor de chave estrangeira tenha um valor ativo de true. Também suspeito que isso poderia impor que 0 ou 1 versão ativa do documento exista, mas não impor que exatamente 1 versão ativa do documento exista.

Tenho uma View que tem um Index que eu gostaria de usar para consultas conhecidas. O problema é que a existência dessa Indexed View faz com que outras consultas tenham um desempenho ruim. Existe uma maneira de ocultar o Index ou a View para que ele seja usado somente quando especificamente incluído em uma dica ou algo do tipo?

test=# create table r (id serial primary key, x int, y int);
CREATE TABLE
test=# insert into r (x, y) select random() * 1000, random() * 1000 from generate_series(0, 1000000);
INSERT 0 1000001
test=# 
test=# create index r_x_idx on r using btree (x);
CREATE INDEX
test=# cluster r using r_x_idx ;
CLUSTER
test=# select * from r limit 5;
  id  | x |  y  
------+---+-----
   79 | 0 | 556
 5997 | 0 | 774
 6104 | 0 |  75
 6937 | 0 | 818
 7859 | 0 | 598
(5 rows)

test=# select * from r limit 5 offset 10000;
   id   | x  |  y  
--------+----+-----
 483314 | 10 | 842
 484136 | 10 | 741
 484568 | 10 | 729
 488499 | 10 | 311
 489022 | 10 | 613
(5 rows)

test=# select * from r limit 5;
   id   | x |  y  
--------+---+-----
 330361 | 9 | 614
 330928 | 9 |  48
 331658 | 9 | 712
 332175 | 9 | 448
 332818 | 9 | 920
(5 rows)

Conforme mostrado acima, criei a tabela r, depois criei um índice b+tree na coluna x, e então agrupei a tabela usando esse índice. Como esperado, quando executei select * from r limit 5;obtive registros com o menor xvalor, porque a ordem física dos registros agora é baseada na xcoluna (mais precisamente, com base no índice b+tree na coluna x). Mas depois de executar select * from r limit 5 offset 10000;, a ordem dos registros é alterada, sem nenhuma inserção. Alguém pode explicar esse comportamento?