All perguntas(dba)

Gostaria de reduzir o escopo de uma consulta para uma tabela que tem uma coluna de registro de data e hora no formato: 2024-12-01 12:34:56.1234567. (Um tipo de dado "datetime2")

Supondo 10 milhões de linhas e supondo que minha estratégia para cortar o escopo da consulta para entradas recentes seja "onde Timestamp > MY_CUTOFF_DATE", minha pergunta é

Esses nanossegundos/segundos/minutos/horas devem ser motivo de preocupação ao adicionar um índice na coluna Timestamp?

Se o formato Timestamp fosse "2024-12-01" (data), meu palpite é que eu não estaria preocupado com o desempenho para meu propósito e requisitos. Mas adicionar o tempo total para 100 nanossegundos torna esse território desconhecido para mim.

Sei que devo testar, mas não tenho acesso à grande tabela de produção e esperava não ter que investir tempo preenchendo uma tabela de teste com dados de tempo realistas, se alguém respondesse "Não se preocupe se você não estiver buscando ganhos de desempenho abaixo de 2 segundos".

Quero dizer desde já que sei que isso é loucura.

Eu herdei um aplicativo que preciso manter de alguém que desnormalizou 6 conjuntos de colunas em uma única linha (por exemplo, algumas colunas principais, como ID , 00_c1, 00_c2, 00_c3, 01_c1, 01_c2, 01_c3, 02_c1, 02_c2, 02_c3, etc.).

Então ele quis normalizar novamente esse conjunto de colunas com a finalidade de criar objetos JSON a partir da linha.

Na implementação original, ele escreveu uma visão de renormalização que usava 6 UNION ALLs

por exemplo

SELECT ID, '0' as X, 00_c1 as c1, 00_c2 as c2, 00_c3 as c3
FROM table WHERE 00_c1 is not null
UNION ALL
SELECT ID, '1' as X, 01_c1 as c1, 01_c2 as c2, 01_c3 as c3
FROM table WHERE 01_c1 is not null
UNION ALL
SELECT ID, '2' as X, 02_c1 as c1, 02_c2 as c2, 02_c3 as c3
FROM table WHERE 02_c1 is not null
UNION ALL
...

Sua consulta jsonizada procura a linha em ID e então se junta à exibição em ID com FOR JSON PATH.

É extremamente ineficiente, então eu estava tentando substituir a normalização por CROSS APPLY (VALUES ())

Funcionou e é muito mais eficiente, mas estou obtendo um artefato estranho com a implementação de VALUES, onde todas as colunas em um conjunto são nulas e estou obtendo um objeto json vazio para isso.

Em outras palavras, nem todas as linhas têm todos os 6 conjuntos de colunas. Algumas podem ter 3, algumas 4, etc. e as colunas (05_c1, 05_c2, 05_c3) serão todas nulas. O json resultante para essa linha simplesmente sai {}

Existe alguma maneira (com FOR JSON ou VALUES) de ignorar uma linha onde todos os valores são nulos?

Ou a única solução real é reimplementar tudo com uma normalização adequada?

Tenho uma tabela da qual gero uma exibição Agrupando por Ano e somando os valores, e gostaria de saber se eu poderia de alguma forma incluir uma "soma de string" ou "concatenação de string" das datas ou meses agregados.

Exemplo: esta é a tabela base

ID | date | year | month | amount

Esta é a visão real

ID | year | sum(amount)

o que estou procurando é um campo adicional que concatene os meses para 03,05,11 (por exemplo ou algo semelhante), se um ano agrega dados de março, maio e novembro

ID | year | sum(amount) | list_of_months

Isso é possível ou preciso criar visualizações auxiliares para agregar isso?

Editar: Eu consegui responder a mim mesmo: Group_concat para a ajuda, conforme mostrado na resposta abaixo

Eu tenho usersmesa

CREATE TABLE tasks(
    id UUID PRIMARY KEY,
    status TEXT REFERENCES statuses, -- available statuses are 'NEW', 'PENDING', 'PROCESSING', 'COMPLETE'
    created_at TIMESTAMP WITH TIME ZONE NOT NULL DEFAULT NULL
);

Quero ter certeza de que apenas um processo mudará o status de PENDINGpara PROCESSINGno caso de várias tentativas de atualizações simultâneas; o restante deve observar zero linhas atualizadas.

A alteração do status da tarefa é acionada pelo processamento de solicitações HTTP externas. É importante que apenas uma solicitação resulte em sucesso. O restante deve detectar a alteração e retornar 409. Conflito. Não temos controle sobre quantas solicitações simultâneas podemos receber.

A instrução de atualização é a primeira coisa feita como parte de uma transação maior, depois que updateo processo observa que ele atualizou tasksa linha (a contagem de linhas atualizadas é 1), ele posteriormente insere/atualiza alguns dados em outras tabelas, etc.

Eu testei a seguinte consulta de atualização

UPDATE tasks 
  SET status = 'PROCESSING'
  WHERE id = '00000000-0000-0000-0000-000000000000' AND status = 'PENDING'

usando Java JDBC, múltiplos threads, conexões etc. e observo que apenas um processo faz atualizações ao usar o nível de isolamento padrão READ COMMITTED.

Quando pensei sobre esse problema, pensei que precisaria FOR UPDATEde um nível UPDATEde declaração ou SERIALIZABLEisolamento na transação, mas em testes reais não consegui detectar inconsistências no caso de múltiplas atualizações.

Minha pergunta: é suficiente filtrar ide statusgarantir que apenas um processo realizará a atualização ou preciso de ações adicionais para excluir comportamentos inesperados em geral?

Temos uma tabela com 54 colunas, ela é usada por muitos aplicativos, relatórios e usuários. A tabela é de um sistema legado, algumas colunas podem estar obsoletas.

Gostaríamos de descobrir quais colunas exatamente são realmente usadas - por SELECTe UPDATEconsultas. Como isso pode ser descoberto?

Se isso for possível, gostaríamos de recebê-lo no formato abaixo:

Column1 - SELECT - 1,890,123 times 
Column1 - UPDATE - 2,394 times 
Column2 - SELECT - 5,222,456 times 
Column2 - UPDATE - 567 times 
Column3...

Uma ideia era escanear todos os repositórios GIT (código-fonte de apps) para essas colunas, mas alguns apps podem não estar no GIT de fato. E os relatórios não estão no GIT.

A pesquisa acima é para:

1. Para descobrir colunas que não são consultadas e possivelmente se livrar delas.
2. Para descobrir colunas que são muito consultadas e não são atualizadas, revise a possibilidade de criar um índice columnstore não clusterizado.

Frequentemente acho a saída sp_spaceusedenganosa. O que parece ser o tamanho de todos os dados em um banco de dados é, na verdade, o tamanho combinado do arquivo de dados e do arquivo de log . Descobri recentemente sys.database_filese achei que é superior em todos os sentidos. É muito melhor do que sp_spacedusedisso, estou planejando beber até esquecer esse procedimento.

Isso me dá uma pergunta: Ao verificar o tamanho de um banco de dados, há algum recurso ou valor de retorno oferecido por sp_spacedusedque não pode ser obtido de sys.database_files? Eu verifiquei a documentação e tenho quase certeza de que não há.

Hoje, estou verificando cada tabela em um banco de dados enorme e escrevendo um resumo do que cada uma é. Isso significa que estou clicando com o botão direito e pressionando "Selecionar as 1000 principais linhas" muitas vezes. Existe uma maneira mais rápida? Eu preferiria uma guia por tabela, então truques de SQL provavelmente estão fora de questão. O que eu quero fazer é aumentar a velocidade com que estou navegando no SSMS.

Migrei o banco de dados postgresql de servidor único existente para o servidor flexível. Estou encontrando o erro abaixo ao definir a propriedade dessa forma ALTER TABLE schema.table OWNER TO comm_user;e estou conectado como administrador do servidor pgadmin.

ERRO: deve ser possível DEFINIR FUNÇÃO "comm_user" Estado SQL: 42501

Isso é confuso, pois consegui definir a propriedade antes da migração. Acho que a MS tem um bug.

Tenho um procedimento no banco de dados DB_Aque insere alguns dados na tabela Table_Ado mesmo banco de dados.

Este é um procedimento bem simples. No entanto, vejo que o processo que executa o procedimento fica em um estado SUSPENSO ou EM EXECUÇÃO por um tempo muito longo, mais de 30 minutos.

O mais estranho é que esse processo bloqueia outras duas tabelas em outro banco de dados que não estão relacionadas ao procedimento.

O procedimento é semelhante a este:

use DB_A;
go

create procedure dbo.spAddUrls @sURL nvarchar(500), @dtDate date
as
begin
    set nocount on;

    declare @nID_ bigint = dbo.ufnGetHash (@sURL);

    begin try
        begin tran
            insert into dbo.TableA (ID, [URL], MapDate)
            values (@nID_, @sURL, @dtDate);
        commit transaction
    end try
    begin catch
        declare @ErrorMsg varchar(1000) = error_message();

        if @@trancount > 0
        begin
            rollback transaction;
            raiserror (@ErrorMsg, 8, 1);
        end
    end catch
end

Mas vejo bloqueios exclusivos no banco de dados DB_Bem duas tabelas não relacionadas Table_Be Table_C.

Table_Anão DB_Apossui gatilhos ou chaves estrangeiras.

Por que as tabelas ficam DB_Bbloqueadas?

Nota: todas essas tabelas e o procedimento são parte da replicação. Mas não tenho certeza se estão relacionados.

Estamos tendo esse comportamento estranho ExclusiveLockem um de nossos bancos de dados executando o PostgreSQL 13. Não consigo descobrir o que leva a esse bloqueio, pois as informações de bloqueio são de uma ferramenta de monitoramento.

Pelo que vejo nos documentos ExclusiveLockadquiridos apenas por atualização materialised view, no entanto, não temos nenhuma visualização materializada em nosso banco de dados. Um pouco de pesquisa que acabei neste blog https://blog.heroku.com/curious-case-table-locking-update-query e o caso que esse cara compartilha é semelhante ao meu, pois posso ver alguns RowExclusiveLockdurante esse período e algumas consultas atualizando a mesma linha simultaneamente. No entanto, não consegui encontrar nenhum documento oficial sobre o comportamento do PostgreSQL na escalada de bloqueio, assim como outros bancos de dados fazem.

O Postgres escala o bloqueio em casos raros? Quais casos podem levar a escalações?