All perguntas(dba)

No PostgreSQL, a RETURNSpalavra-chave exige que você especifique o tipo exato que a função retorna. Isso pode ser um incômodo quando esse tipo é o resultado de uma consulta com vários JOINs, pois você acaba tendo que criar manualmente um TABLEtipo com cada coluna de cada tabela JOIN-ed. Se você se juntou employeescom profilesand jobs, agora você tem que listar todas as três colunas da tabela:

RETURNS TABLE(
  -- employees field #1
  -- employees field #2
  -- employees field etc.
  -- ... profiles fields
  -- ... jobs fields
)

Existe algum tipo de atalho para evitar isso e apenas dizer ao PostgreSQL "retorne o que a consulta retornar; não se preocupe com o tipo"? Eu descobri que o PostgreSQL tem um anytipo ... mas ele não parece deixar você usá-lo em uma RETURNScláusula.

Caso contrário, existe alguma maneira de criar tipos combinando outros tipos (por exemplo, o JOIN_TABLE(employees, profiles, jobs)tipo) ou criar tipos a partir de tabelas existentes (por exemplo, TABLE(...employees, integer job_id))?

Estou trabalhando com um banco de dados PostgreSQL e preciso de alguns conselhos sobre quando executar VACUUM ANALYZEem minhas tabelas.

1. Estou anexando uma tabela muito grande tmp_details(50 milhões de registros) como uma partição para uma tabela existente details(500 milhões de registros). A detailstabela é usada ativamente para relatórios, mas não estou realizando nenhuma outra operação de gravação nela. Dada a documentação do PostgreSQL ( https://www.postgresql.org/docs/current/populate.html ), sugere-se executar VACUUM ANALYZEapós carregar grandes quantidades de dados:

   • É necessário correr VACUUM ANALYZEna detailsmesa depois de acoplar tmp_detailsnela?
   • Se sim, devo aspirar a detailsmesa inteira ou apenas a divisória recém-fixada?

2. Também estou criando uma nova tabela notreconciled(10 milhões de registros) de tmp_details. A notreconciledtabela será usada tanto para relatórios quanto como uma partição mais tarde. Devo executar VACUUM ANALYZEna notreconciledtabela após criá-la?

Quaisquer insights ou melhores práticas seriam muito apreciados!

Temos um banco de dados SQL Server que está no meio da sincronização e continuará sincronizando por um bom tempo. Gostaria de criar um procedimento armazenado no banco de dados, no entanto, não parece ser possível criar um procedimento armazenado no banco de dados enquanto ele está sincronizando.

Alguém pode me informar se é possível criar um procedimento armazenado no banco de dados enquanto ele está sincronizando? Ou seja, sem Pausar ou Suspender a Sincronização

Estamos executando o SQL Server 15.0.4415.2

Como determinar o Banco de Dados SQL Primário? Fui informado de que se eu atualizar o Banco de Dados Primário, as alterações serão sincronizadas com o banco de dados secundário. Alguém pode me dizer como determinar o que é o Banco de Dados Primário? Pela imagem você pode ver que só consigo visualizar os bancos de dados secundários

Li que criar um procedimento armazenado não altera os dados ou o esquema que está sendo sincronizado. É uma operação de metadados, então os mecanismos de sincronização (por exemplo, replicação transacional, grupos de disponibilidade Always On) não devem ser afetados.

Entretanto, quando tento criar o seguinte procedimento, recebo o seguinte erro:

Msg 3906, Level 16, State 2, Procedure GenerateDeltaTable, Line 1 [Batch Start Line 0]
Failed to update database "xxxxx" because the database is read-only.


CREATE PROCEDURE [dbo].[DeltaTable]
    @Domain VARCHAR(100),
    @TableName VARCHAR(100),
    @DeltaTable VARCHAR(100)
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @sql NVARCHAR(MAX);

    -- Construct dynamic SQL for dropping and creating the target table
    SET @sql = '
    IF OBJECT_ID(''' + QUOTENAME(@Domain) + '.' + QUOTENAME(@DeltaTable) + ''', ''U'') IS NOT NULL
        DROP TABLE ' + QUOTENAME(@Domain) + '.' + QUOTENAME(@DeltaTable) + ';

    SELECT T.*, 
           LOWER(CONVERT(VARCHAR(64), HASHBYTES(''SHA2_256'', 
           (SELECT T.* FOR JSON PATH, WITHOUT_ARRAY_WRAPPER, INCLUDE_NULL_VALUES)), 2)) AS signature 
    INTO ' + QUOTENAME(@Domain) + '.' + QUOTENAME(@DeltaTable) + '
    FROM ' + QUOTENAME(@Domain) + '.' + QUOTENAME(@TableName) + ' AS T;';

    -- Execute the constructed SQL
    EXEC sp_executesql @sql;
END;

Estou tentando escrever uma função recursiva do PostgreSQL que basicamente diz:

1. Pegue um ID de grupo
2. Se houver um item naquele grupo, devolva-o
3. Caso contrário, encontre os subgrupos do grupo
4. Repita a função em cada um dos subgrupos

A função recebe um ID de grupo e o título de um item a ser encontrado, e o que tenho até agora para o corpo é:

RETURN QUERY SELECT -- ... return children with title, if any
-- If there were none, look for grandchildren (and so on)
IF NOT FOUND THEN
   -- Loop through the sub-group IDs
   FOR sub_group_id IN
     SELECT -- ... sub-groups of the provided group
   LOOP
     -- Recursion time ... stuck here

O que eu quero expressar é:

1. Correr SELECT * FROM this_function(sub_group_id, title);
2. Se retornar > 0 resultados, retorne esses resultados
3. Se isso não acontecer, continue em loop

Mas se eu apenas disser:

LOOP
  RETURN QUERY SELECT * FROM this_function(sub_group_id, title);

não tem o efeito desejado. Alguém pode me ajudar a expressar o acima no PostgreSQL?

Existe algum significado para o SQL Server ter BITdatatype em vez de BOOLEAN? É apenas uma maneira estranha de chamar a mesma coisa, ou existe alguma diferença conceitual sutil?

A documentação sobre BITo tipo de dados menciona:

O tipo de dados bit pode ser usado para armazenar valores booleanos.

Isso parece sugerir que, na verdade, elas não são a mesma coisa.

Estou ciente de que [a coisa que a MS chama de boolean] e [a coisa que a MS chama de bit] são diferentes, MAS do ponto de vista do programador, bité a melhor aproximação do booleanconceito platônico que a linguagem T-SQL oferece. E eu luto para acreditar que seja apenas uma casualidade e não uma intenção. O tipo de dado numérico que aceita apenas 0 e 1 parece pouco prático para outros usos.

Preciso replicar um banco de dados Postgres diariamente (também pode ser continuamente) para outro servidor, mas sem alterar as configurações do Postgres.

Não consigo alterar as configurações do banco de dados porque ele é do meu cliente. Tenho apenas as credenciais como usuário, senha e host.

Posso instalar qualquer software no servidor se for necessário, mas não posso alterar as configurações. E não quero enviar o backup completo diariamente, porque o banco de dados é pesado.

Preciso do banco de dados do meu cliente porque processamos uma grande quantidade de dados em nosso servidor.

Em todo lugar que pesquisei, sempre foi dito para habilitar e configurar o WAL no postgresql.conf. Mas não consigo alterar esse arquivo.

amcheck relata o seguinte erro:

select bt_index_parent_check(34465);
ERROR:  item order invariant violated for index "admin_access_rights_pkey"
DETAIL:  Lower index tid=(282,71) (points to heap tid=(201,46)) higher index tid=(282,72) (points to heap tid=(197,38)) page lsn=396C/DDF2FD00

Como posso corrigir esse problema?

A documentação diz que isso REINDEXpode não ajudar.

Um REINDEX pode não ser eficaz na reparação da corrupção.

Estou tentando resolver um problema usando o ms-replication e não tenho certeza se é a melhor opção para o problema em questão.

Problema: É preciso replicar todas as inserções iniciais e todas as atualizações, ignorando exclusões para uma assinatura. Essencialmente, um banco de dados de destino que continua a crescer e os dados nunca são removidos, mesmo quando os registros são excluídos na origem. Ser capaz de restaurar na origem sem destruir o destino seria um grande bônus.

Posso fazer a maior parte disso funcionar via ms-replication configurando ignore deletes em todos os artigos de tabela e configurando o modo de preparação de tabela para do-nothing. Isso lidaria com a manutenção de dados durante restaurações e manteria registros excluídos no destino, no entanto, como lidar com inserções que resultariam em violações de PK após uma restauração na origem. Não consigo encontrar nenhuma maneira documentada de "Ignorar registros existentes durante a inserção" e, mesmo que haja um hack, isso reduziria muito o desempenho da replicação?

NOTA: Devo mencionar que dar suporte a um backup não significa voltar a um ponto no tempo há muito tempo, significa apenas que se ocorrer uma falha grave, o banco de dados de origem precisa ser restaurado usando a cadeia de log mais recente. Haveria no máximo duas horas de inserções para lidar. Isso provavelmente poderia ser resolvido excluindo manualmente os registros no destino que não estão na origem, no entanto, eu estava tentando evitar isso completamente.

Não estou muito familiarizado com a base do processo de snapshot, além de tentar carregar dados via BCP. Se o modo de preparação da tabela for do nothing, há uma opção para pular opcionalmente a fase de "carregamento em massa" do snapshot e então continuar com o leitor de log normalmente após o snapshot ter sido aplicado?

Tenho uma tabela source_aepsfinswitch_tmp_detailscontendo um conjunto de dados muito grande. Meu objetivo é particionar essa tabela em duas partições com base na reconciliation_date_timecoluna:

1. Se reconciliation_date_timefor NULL, a linha deve ir para uma partição.
2. Se reconciliation_date_timefor NOT NULL, a linha deve ir para outra partição.

Devido ao tamanho dos dados, quero evitar usar INSERT INTOinstruções para mover os dados manualmente. Em vez disso, tentei a seguinte abordagem:

BEGIN;
CREATE TABLE IF NOT EXISTS public.source_aepsfinswitch_tmp_details_new (
    LIKE public.source_aepsfinswitch_tmp_details EXCLUDING CONSTRAINTS,
    PRIMARY KEY (uniqueid, reconciliation_date_time)
) PARTITION BY RANGE (reconciliation_date_time);

ALTER TABLE public.source_aepsfinswitch_tmp_details RENAME TO source_aepsfinswitch_tmp_details_old;
ALTER TABLE public.source_aepsfinswitch_tmp_details_new RENAME TO source_aepsfinswitch_tmp_details;
ALTER TABLE public.source_aepsfinswitch_tmp_details ATTACH PARTITION public.source_aepsfinswitch_tmp_details_old DEFAULT;
COMMIT;

Entretanto, quando executo isso, recebo o seguinte erro:

SQL Error [42804]: ERROR: column "reconciliation_date_time" in child table must be marked NOT NULL

Como posso atingir meu objetivo sem encontrar esse erro? Tentei LIST e RANGE, mas nenhum funcionou. Existe uma maneira de particionar a tabela conforme descrito sem exigir que a coluna reconciliation_date_timeseja NOT NULL? Existe alguma maneira de dividir a tabela em partições sem usar INSERT INTO?

Graças à sugestão de Laurenz Albe , consegui anexar a partição. No entanto, como posso criar duas tabelas com base na tabela pai? Estou recebendo o seguinte erro ao executar a consulta abaixo:

CREATE TABLE IF NOT EXISTS public.source_aepsfinswitch_tmp_details_new (LIKE public.source_aepsfinswitch_tmp_details EXCLUDING CONSTRAINTS) PARTITION BY LIST (reconciliation_date_time);    
ALTER TABLE public.source_aepsfinswitch_tmp_details RENAME TO source_aepsfinswitch_tmp_details_old;
ALTER TABLE public.source_aepsfinswitch_tmp_details_new RENAME TO source_aepsfinswitch_tmp_details;
ALTER TABLE public.source_aepsfinswitch_tmp_details ATTACH PARTITION public.source_aepsfinswitch_tmp_details_old DEFAULT;
CREATE TABLE IF NOT EXISTS public.source_aepsfinswitch_tmp_details_null PARTITION OF public.source_aepsfinswitch_tmp_details FOR VALUES IN (NULL);

SQL Error [23514]: ERROR: updated partition constraint for default partition "source_aepsfinswitch_tmp_details_old" would be violated by some row

Acho que esse problema é causado pela chave primária. Criar uma nova partição das mesmas transações que em outras partições no PostgreSQL pode estar causando o erro mencionado acima. Existe uma maneira de lidar com isso?

Recentemente atualizei o PostgreSQL 14 para o PostgreSQL 16 usando o método --clone. Ambos os meus diretórios de dados (cluster antigo e novo) estavam no mesmo volume. Depois de alguns dias, comecei a receber o erro abaixo.

53100: não foi possível estender o arquivo "base/160560/t64_168297303" com FileFallocate(): Não há espaço restante no dispositivo

No momento em que ocorrem erros, eu verifiquei o tamanho livre do volume usando (df -hT) e descobri que mais de 30% do espaço está disponível no volume. Em todos os casos, a consulta que dá esse erro é a consulta CREATE TEMP TABLE. Eu também verifiquei os íons livres durante o mesmo tempo (df -i) e descobri que havia o suficiente disponível.

Também removi o diretório de dados antigo, mas isso não resolveu o erro.

Tenho um servidor primário e 1 servidor de réplica em replicação assíncrona usando patroni.

Versão do PostgreSQL: PostgreSQL 16.6 (Ubuntu 16.6-1.pgdg22.04+1) em x86_64-pc-linux-gnu, compilado por gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0, 64 bits

Consegui criar manualmente um arquivo grande de 40 GB usando fallocate com sucesso, o que aumentou o espaço usado no volume para 96%. É um volume EBS anexado ao EC2 que armazena nada além do diretório de dados PG 16, que tem um link simbólico de pg_wal apontando para um volume diferente.

Mantive o tamanho do volume em 96% e esperei por um período em que o erro geralmente ocorre, mas não ocorreu. Uma coisa a mencionar: após remover o antigo diretório de dados PG 14, o erro ocorreu apenas uma vez. Antes, havia muitas ocorrências, mas não contínuas.