All perguntas(dba)

Temos um cluster de replicação do PostgreSQL 13 onde um dos standbys está configurado com recovery_min_apply_delay="x hr", o que pode ser útil em caso de corrupção de dados.

Para um cenário em que uma exclusão acidental aconteceu no servidor mestre , mas ainda não foi aplicada ao servidor em espera . Neste caso, estou tentando extrair os dados do servidor em espera removendo o atraso de repetição do WAL e adicionando recovery_target_timeum ponto antes da exclusão acontecer.

Até este ponto, tive sucesso, mas depois que terminei de puxar os dados do servidor standby para o master (estou pensando em postgres_fdw), preciso retomar a replicação. Mas quando executo pg_wal_replay_resume(), ele está criando uma nova linha do tempo e não está mais no cluster de replicação.

Existe alguma maneira de reproduzir o WAL além de usar recovery_target_time?

Dando um exemplo do que estou tentando alcançar,

Digamos que recovery_min_apply_delay=2hr , uma exclusão acidental aconteceu às 03:50 AM, neste momento transações confirmadas em standby são transações que aconteceram em ou antes de 01:50 AM. Se eu esperar mais 2hr e às 05:49 AM se eu conseguir pausar a repetição do WAL em standby, poderei ver um instantâneo dos dados que estão "logo antes" de DELETE. Então usarei postgres_fdw para extrair dados do standby.

Como eu consigo "logo antes" de uma forma precisa e sistemática? Também seria capaz de retomar o replay do WAL.

Estou observando um impacto significativo no desempenho de listas de seleção em UNIONconsultas classificadas.

O formato geral das UNIONconsultas com as quais estou trabalhando é:

SELECT * FROM (
  SELECT <select_list> FROM <table>
  UNION ALL
  ...
) q
ORDER BY <column>

A seleção externa é usada porque melhora significativamente o desempenho na presença de ORDER BY, mas isso está fora do escopo desta questão. UNION ALLé sempre usado, em vez de UNION.

Vou me referir ao desempenho como "rápido" (instantâneo) ou "lento" (5 segundos ou mais).

O desempenho foi medido executando consultas no console do DBeaver, que por padrão recupera apenas a primeira página, cujo tamanho é 200.

Alterar a lista de seleção afeta o desempenho das seguintes maneiras:

1. Quando <select_list> = <column>(ou seja, somente a coluna de classificação é selecionada), as consultas são rápidas. O plano de execução mostra varreduras de índice para a coluna de classificação e junções de mesclagem para concatenação.
2. Quando a lista de seleção inclui outras colunas além da coluna de classificação, as consultas podem ser rápidas ou lentas. Foi observado que quando as seguintes condições são todas verdadeiras, as consultas são rápidas:
   • A lista de seleção inclui a coluna de índice agrupado.
   • A lista de seleção começa com a coluna de índice agrupado ou com a coluna de classificação imediatamente seguida pela coluna de índice agrupado.

As observações foram feitas usando o Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) - 15.0.4365.2 (X64).

Não consegui encontrar nada sobre os efeitos das listas de seleção no desempenho UNIONna documentação do SQL Server.

Uma descrição simplificada do ambiente em que os experimentos foram conduzidos e as próprias consultas são fornecidas abaixo.

CREATE TABLE AUDIT1 (
    ID bigint NOT NULL,
    AUDITDATE datetime2 NULL,
    [USER] bigint NULL,
  -- Implies clustered index.
    CONSTRAINT PK_AUDIT1 PRIMARY KEY (ID)
);
CREATE INDEX I_AUDIT1_AUDITDATE ON AUDIT1 (AUDITDATE);

CREATE TABLE AUDIT2 (
    ID bigint NOT NULL,
    AUDITDATE datetime2 NULL,
    [USER] bigint NULL,
  -- Implies clustered index.
    CONSTRAINT PK_AUDIT2 PRIMARY KEY (ID)
);
CREATE INDEX I_AUDIT2_AUDITDATE ON AUDIT2 (AUDITDATE);

• A tabela AUDIT1contém 10 milhões de registros.
• A tabela AUDIT2contém 1 milhão de registros.
• Os valores de AUDITDATEin AUDIT2são maiores que aqueles em AUDIT1.
• Os valores de AUDITDATEsão alinhados com IDem uma sequência crescente, ou seja, IDestá sempre aumentando, e assim é AUDITDATE.

Consulta 1 : a lista de seleção contém apenas a coluna de classificação ( rápida ).

SELECT * FROM (
  SELECT AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Plano de execução:

|--Merge Join(Concatenation)
   |--Index Scan(AUDIT2.I_AUDIT2_AUDITDATE), ORDERED BACKWARD
   |--Index Scan(AUDIT1.I_AUDIT1_AUDITDATE), ORDERED BACKWARD

Consulta 2 : seleciona lista de tamanho > 1, contém a coluna de classificação, não contém a coluna de índice agrupado ( lento ).

SELECT * FROM (
  SELECT [USER], AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT [USER], AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Observe que colocar a coluna de classificação primeiro não teve efeito.

Consulta 3 : selecione uma lista de tamanho > 1, contenha a coluna de classificação, contenha a coluna de índice agrupado, a primeira coluna não é a coluna de classificação nem a coluna de índice agrupado ( lento ).

SELECT * FROM (
  SELECT [USER], ID, AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT [USER], ID, AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Consulta 4 : selecione uma lista de tamanho > 1, contenha a coluna de classificação, contenha a coluna de índice agrupado, a primeira coluna é a coluna de classificação ou a coluna de índice agrupado ( rápido ).

SELECT * FROM (
  SELECT ID, [USER], AUDITDATE FROM AUDIT2
  UNION ALL 
  SELECT ID, [USER], AUDITDATE FROM AUDIT1
) q
ORDER BY AUDITDATE

Esta consulta mostra que se a primeira coluna for ID, a consulta é rápida.

Os planos de execução para as consultas 2, 3, 4 são os mesmos:

|--Parallelism(Gather Streams, ORDER BY:([Union1007] ASC))
   |--Sort(ORDER BY:([Union1007] ASC))
      |--Concatenation
         |--Parallelism(Distribute Streams, RoundRobin Partitioning)
         |--Clustered Index Scan(OBJECT:(AUDIT2.PK_AUDIT2))
         |--Clustered Index Scan(OBJECT:(AUDIT1.PK_AUDIT1))

Eu sempre armazenei Application Options como um arquivo Ini no Windows, pois era mais rápido de acessar do que o banco de dados. Além disso, às vezes, você precisa ler algumas delas antes de acessar o banco de dados.

A desvantagem é que se você fizer backup do banco de dados, as opções não aparecerão.

Eu poderia salvá-los

• Como campos, mas isso tornaria a tabela uma única linha de 50-500 campos
• Como pares de chave-valor, mas isso seria lento para recuperar

Estou pensando em armazená-los como um array JSON em um campo. Há alguma desvantagem nisso?

Não acho que importe em que o aplicativo é escrito, pois posso implementar qualquer coisa dentro do razoável. Não só há bibliotecas JSON (e INI) incorporadas ao Delphi, como também tenho minhas próprias bibliotecas super-rápidas de manipulação de JSON (e INI). E o MariaDB também suporta JSON.

O aplicativo é escrito em Delphi (Pascal) compilado para Windows. Mas partes do conjunto podem muito bem ser escritas em PHP (mais adiante).

Sempre usei direitos de acesso do usuário como um conjunto (de bits) no código e os armazenei como vários bigints (dependendo de quantos eu precisava).

Estes são direitos como

• Permitido visualizar registros de clientes
• Permitido criar registros de clientes
• Permitido editar registros de clientes
• Permitido excluir registros de clientes
• Permitido executar relatórios de clientes
• Permitido registrar um celular
• Permitido visualizar o painel

Portanto, eles não estão relacionados apenas a bancos de dados.

Vejo que eu poderia armazená-lo como um array JSON de descrições, mas isso poderia ficar muito grande (e talvez lento). Eu poderia usar uma sigla de 4 letras para cada um.

Existe uma terceira maneira de fazer isso para minimizar a verbosidade no código?

No Oracle, estou tentando usar listagg para que a cada 8 valores, haja um delimitador diferente. Especificamente, quero que os valores sejam delimitados por vírgulas, e que cada 8 valores também sejam delimitados por quebras de linha. Existe uma maneira de fazer isso que não envolva usar row_number em uma subconsulta?

Se eu tiver vários leitores de banco de dados, que são basicamente instâncias do SQLite que abrem o arquivo db no modo "leitura", é normal que um único gravador que abre o db no modo "criação" não consiga liberar uma transação até que todos os leitores fechem o banco de dados?

Estou tentando descobrir se é um comportamento normal do sqlite ou um bug/limitação de uma biblioteca sqlite específica que estou usando.

Não entendo por que um escritor precisaria esperar que os leitores parassem de usar o arquivo de banco de dados. Não faz sentido para mim, porque os leitores não podem alterar os dados.

Tenho usado o comando "mysql" do console Unix há algum tempo. É mais conveniente para agendar tarefas ou iniciá-las sem supervisão.

O esboço de um script .sh para isso é:

#!/bin/bash

#DB Config
USR_BD=myUsr
PWD_BD=myPass
IP_BD=x.x.x.x

f_exec ()
{
echo `date` ' -> Executing sql file ' $1

mysql -h $IP_BD -u $USR_BD -p$PWD_BD my_schema < $1

echo `date` ' -> Executed sql file ' $1
}

f_exec my_sentences.sql

O problema é que passei por uma verificação de segurança e eles me disseram que não posso salvar a senha clara em uma variável ou em um arquivo de texto simples dentro de um script .sh

Minha pergunta é: como posso resolver esse problema?

• Se você puder salvar algo como um token, o token apresentará o mesmo problema que a senha.
• Se você der permissão para conectar sem senha ao host no qual eu executo o script, se você obtiver acesso a esse host, você também obterá acesso ao banco de dados.

Claro, é óbvio que não vou conectar às 3 da manhã para digitar a senha para executar o script. Ou esperar online por uma consulta pesada de 10 minutos.

Não sei como resolver a situação. Obrigado.

Estou praticando Point in Time Recovery (PITR) no PostgreSQL 13 contra exclusão acidental de dados. Como o PostgreSQL oferece vários parâmetros para executar PITR, estou um pouco confuso escolhendo entre Transaction XID e LSN.

Se uma DELETEdeclaração acidental removesse um grande número de linhas e eu obtivesse o correspondente XIDa partir LSNdo dump do WAL, executar o PITR produziria o mesmo resultado, independentemente de eu usar o XID ou o LSN?

Existe o risco de perder outras transações confirmadas se eu restaurar usando o XID?

Com o SQL Server 2022 Standard, se eu criar uma replicação transacional e inicializar a assinatura por meio de (A) um instantâneo ou (B) um backup de banco de dados, preciso garantir que o banco de dados de publicação fique inativo enquanto o banco de dados de assinatura é inicializado?

Ou seja, se ocorrerem alterações no banco de dados de publicação DEPOIS que o snapshot/backup for feito, mas ANTES que a replicação seja totalmente configurada e inicializada no banco de dados de assinatura, essas alterações serão aplicadas no banco de dados de assinatura?

Criei um pacote SSIS simples que extrai dados de seis tabelas SQL e despeja em arquivos simples. O pacote funciona bem no Visual Studio, mas continua recebendo o código de erro 0xC0048021 ao implantar no SSMS. Este é o erro principal

Tarefa de Fluxo de Dados:Erro: O componente está ausente, não registrado, não atualizável ou ausente nas interfaces necessárias. As informações de contato para este componente são "Flat File Destination;Microsoft Corporation; Microsoft SQL Server; (C) Microsoft Corporation; Todos os direitos reservados; http://www.microsoft.com/sql/support;1" .

Eu tentei CSV e TXT e ambos falharam, o destino do arquivo RAW funciona . SQL 2016 e o ​​pacote foi criado no Visual Studio 2019. Eu alterei as propriedades de configuração para a versão do servidor de destino para SQL 2016 conforme a imagem SSMS é a versão 20.2.30 O serviço SSIS está sendo executado como o serviço NT local

Qualquer conselho ou sugestão para tentar seria apreciado. Estou brincando com captura de erros agora para ver se isso ajuda.