IBM DB2 on Cloud, versão 11.5.9.0

Tentando criar um gatilho em uma tabela ( os nomes dos objetos são inventados, para simplificar ):

CREATE OR REPLACE TRIGGER MY_TRIGGER
AFTER UPDATE OR INSERT ON MY_TABLE
REFERENCING NEW TABLE AS NEW_STUFF
FOR EACH STATEMENT
BEGIN ATOMIC
    DELETE FROM TABLE_A WHERE P_N IN (SELECT DISTINCT P_N FROM NEW_STUFF);
    INSERT INTO TABLE_A SELECT * FROM VIEW_B WHERE P_N IN (SELECT DISTINCT P_N FROM NEW_STUFF);
END;

A visão VIEW_B tem TABLE_A como referência em sua definição.

Estou recebendo este erro:

SQL Error [42601]: An unexpected token "OR INSERT" was found following "".  
Expected tokens may include:  "".. 
SQLCODE=-104, SQLSTATE=42601

Se eu criar o mesmo gatilho apenas com AFTER UPDATE ON MY_TABLE ou apenas com AFTER INSERT ON MY_TABLE, ele funcionará bem. Ele falha quando eu especifico AFTER UPDATE OR INSERT .

Se eu tentar BEGIN em vez de BEGIN ATOMIC, recebo um erro diferente:

SQL Error [42898]: The definition of trigger "MY_SCHEMA.MY_TRIGGER" includes an 
invalid use of correlation name or transition table name "NEW_STUFF".
Reason code="4".. SQLCODE=-696, SQLSTATE=42898

Estudei a documentação e os poucos exemplos que consegui encontrar. Se alguém souber por que a combinação de UPDATE ou INSERT está causando falha, agradeceria qualquer ajuda.

Estou lutando para anexar uma partição a uma tabela com uma chave primária.

Eu tenho uma tabela particionada Transactions:

create table "Transactions"
(
    id          bigserial                                                       not null,
    uid         uuid                                                            not null,
    type        varchar(255)                                                    not null,
    amount      numeric(26, 10)                                                 not null,
    "createdAt" timestamp(3) default CURRENT_TIMESTAMP                          not null,
    primary key (id, "createdAt")
) partition by RANGE ("createdAt")

create index "Transactions_createdAt_idx" on "Transactions" ("createdAt" desc);
create index "Transactions_type_idx" on "Transactions" (type);
create index "Transactions_uid_idx" on "Transactions" (uid);

Eu crio uma nova partição todo mês com uma tabela particionada. Cada dia eu crio uma partição por um dia.

CREATE TABLE "Transactions_20240618" (LIKE "Transactions_20240617" INCLUDING DEFAULTS INCLUDING CONSTRAINTS INCLUDING INDEXES);
ALTER TABLE "Transactions_202406_parted" ATTACH PARTITION "Transactions_20240618" FOR VALUES FROM ('2024-06-18') TO ('2024-06-19');

No início do próximo mês, quero eliminar o mês particionado e criar uma partição normal para esse mês para reduzir o número de partições.

Estou tentando usar o seguinte script:

CREATE TABLE "Transactions_202404" (LIKE "Transactions_202404_parted" INCLUDING DEFAULTS);
INSERT INTO "Transactions_202404" SELECT * FROM "Transactions_202404_parted";
alter table "Transactions_202404" add primary key (id, "createdAt");
create index "Transactions_202404_createdAt_idx" on "Transactions_202404" ("createdAt" desc);
create index "Transactions_202404_type_idx" on "Transactions_202404" (type);
create index "Transactions_202404_uid_idx" on "Transactions_202404" (uid);
alter table "Transactions_202404" add constraint "Transactions_202404_check" check ("createdAt">='2024-04-01' and "createdAt"<'2024-05-01');
alter table "Transactions" detach partition "Transactions_202404_parted";
alter table "Transactions" attach partition "Transactions_202404" for values from ('2024-04-01') TO ('2024-05-01');
alter table "Transactions_202404" drop constraint "Transactions_202404_check";

Na pré-última linha, quando tento anexar a partição recém-criada, o PostgreSQL me culpa por tentar criar uma segunda chave primária na tabela "Transactions_202404":

[42P16] ERROR: multiple primary keys for table "Transactions_202404" are not allowed

Pelo que entendi, o PostgreSQL se recusa a usar a chave primária existente por algum motivo e tenta criar a sua própria como filha da chave primária da tabela "Transações".

Se eu tentar criar uma chave UNIQUE para minha nova partição e conectá-la à tabela principal, ela funcionará, mas estou faltando PK na nova partição.

O problema é que, se eu fizer todos os passos com chave única e depois criar um PK na tabela já anexada, reconecte-o para que o Postgres considere o PK como filho do PK principal, então funciona, verifique:

CREATE TABLE "Transactions_202404" (LIKE "Transactions_202404_parted" INCLUDING DEFAULTS);
INSERT INTO "Transactions_202404" SELECT * FROM "Transactions_202404_parted";
alter table "Transactions_202404" add unique (id, "createdAt");
create index "Transactions_202404_createdAt_idx" on "Transactions_202404" ("createdAt" desc);
create index "Transactions_202404_type_idx" on "Transactions_202404" (type);
create index "Transactions_202404_uid_idx" on "Transactions_202404" (uid);
alter table "Transactions_202404" add constraint "Transactions_202404_check" check ("createdAt">='2024-04-01' and "createdAt"<'2024-05-01');
alter table "Transactions" detach partition "Transactions_202404_parted";
alter table "Transactions" attach partition "Transactions_202404" for values from ('2024-04-01') TO ('2024-05-01');
-- start of PK fix
create unique index concurrently "Transactions_202404_pkey" on "Transactions_202404" (id, "createdAt");
alter table "Transactions_202404" add primary key using index "Transactions_202404_pkey";
alter table "Transactions" detach partition "Transactions_202404";
alter table "Transactions_202404" drop constraint "Transactions_202404_id_createdAt_key"; -- drop the unnecessary unique key
alter table "Transactions" attach partition "Transactions_202404" for values from ('2024-04-01') TO ('2024-05-01');
-- end of fix
alter table "Transactions_202404" drop constraint "Transactions_202404_check";

O que estou fazendo de errado? Alguém com bom conhecimento de como funciona poderia me dizer como anexar uma partição à tabela principal sem criar um índice exclusivo duas vezes?

Eu preciso excluir todas as coisas do mongoDB no meu mac.

eu segui o guia de desinstalação no guia oficial de desinstalação do mongoDB

mas na etapa 2 , que é

`launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.mongodb-community.plist
rm -f ~/Library/LaunchAgents/homebrew.mxcl.mongodb-community.plist
launchctl remove homebrew.mxcl.mongodb-community`

eu recebi este erro: Unload failed: 5: Input/output error Try running "launchctl bootout" as root for richer errors.

Estou tentando considerar todas as opções antes de configurar a replicação transacional no meu servidor 2008R2 para o servidor de distribuição 2012 para o servidor Assinante 2012. Todos os três servidores estão no modo de recuperação COMPLETO. O backup do log é feito a cada 15 minutos e o backup completo é feito diariamente, todos os dias, em todos os três bancos de dados do servidor usados ​​na replicação. Queremos usar o assinante como servidor de relatórios. O Publisher é nosso principal banco de dados OLTP.

Não estou usando 'Sincronizar com Backup' no Publisher e no Distribuidor, pois não quero latência definindo o editor para 'Sincronizar com backup', pois as transações só serão replicadas para o Distribuidor quando o backup for feito no Publisher (o que é feito a cada 15 min no meu Publisher) e não quero que as transações sejam acumuladas no Publisher definindo 'Sincronizar com backup' no Distribuidor, pois as transações só serão truncadas do editor quando o backup for feito no Distribuidor.

Agora minhas perguntas são:

1. o que acontecerá se o distribuidor ou o assinante cair? As transações continuarão aumentando no meu editor (o que é assustador)?

2. Os comandos (para serem replicados) estarão na fila do Publisher? Como posso configurar o período de retenção?

Sou bastante versado em postgresql, mas sou novo em qualquer extensão que não seja postgis. por exemplo, uma das primeiras coisas que faço ao configurar uma instância é instalar o postgis no template1, para que esteja disponível em todos os bancos de dados que eu criar (a maioria deles lida com dados geoespaciais).

Gostaria de algo semelhante para pg_cron e pgaudit, mas não tenho certeza se é obrigatório. essas extensões são "uma por cluster" ou precisam ser instaladas em cada banco de dados separado?

Acredito que o pgaudit seja por servidor, pois registra tudo, mas a confirmação seria útil.

pg_cron não tenho tanta certeza.

obrigado a todos!

Nesta questão, é uma detecção de parâmetro? existe um plano de execução anexado ao XML .

Por que está ParameterCompiledValuefaltando no XML do plano de execução?

       <ParameterList>
          <ColumnReference Column="@__trailerLocation_SbtAssetid_12" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9511'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_11" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'8184'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_10" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9628'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_9" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9683'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_8" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9234'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_7" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9204'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_6" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9628'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_5" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'9852'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_4" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'5842'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_3" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'4138'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_2" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'7505'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_1" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'7826'" />
          <ColumnReference Column="@__trailerLocation_SbtAssetid_0" ParameterDataType="nvarchar(12)" ParameterRuntimeValue="N'8604'" />
        </ParameterList>

Espero ambos ParameterCompiledValuee ParameterRuntimeValueno XML como neste exemplo.

        <ParameterList>
          <ColumnReference Column="@contactPersonID" ParameterDataType="int" ParameterCompiledValue="(1025)" ParameterRuntimeValue="(1025)" />
        </ParameterList>

DR

Como permitir acesso somente leitura a alguns usuários em uma réplica (em um grupo de disponibilidade do Sql Server), somente quando a réplica for secundária , e negá-la quando se tornar primária ?

Explicação

Estou pensando em uma configuração de grupo de disponibilidade, onde haverá duas réplicas, uma delas legível quando for secundária. Os aplicativos de leitura não essenciais (como BI e outros) conectam-se ao secundário; eles causam uma carga considerável nessa réplica; há muitos recursos não utilizados (já que é uma réplica secundária), então não se preocupe.

Agora, o primário falha e o secundário se torna o primário; a carga de leitura não é desejada, pois afetará cargas de missão crítica (que são transferidas para o novo primário). Podemos tolerar interrupções em leitores que não sejam de missão crítica, por isso desejamos que seus respectivos usuários sejam desativados e expulsos até que a réplica se torne secundária novamente.

Como isso seria possível?

Eu trabalho com PostgreSQL 12 e tenho tabelas particionadas que estou tentando agrupar. Cada partição tem aproximadamente o mesmo tamanho em termos de GB. No entanto, o desempenho pode variar significativamente, variando de 5 a 1.000 minutos de tempo de cluster por partição.

Estou agrupando várias partições em cluster em paralelo e meu banco de dados não está recebendo nenhuma solicitação além das solicitações CLUSTER.

Não entendo completamente os meandros do processo CLUSTER nos bastidores. O que poderia explicar variações tão grandes no tempo de agrupamento e o que posso fazer para melhorar o desempenho?

EDIT: Para ser mais preciso, tenho uma partição de 34 GB agrupada em cluster em 13 minutos e uma partição de 56 GB agrupada em cluster em 1288 minutos (quase um dia). Esses valores de tamanho são o tamanho antes do cluster. Estou recalculando os tamanhos.

Consulta usada para recuperar o tamanho:

SELECT table_name, 
       pg_size_pretty(pg_total_relation_size(table_schema || '."' || table_name || '"')) AS size
FROM information_schema.tables
WHERE table_schema = 'partitionschema' and table_name like 'mytable_%' order by table_name;

Eu não fiz ANALYZE ou VACUUM antes de agrupar.

Tenho E/S de disco de 900 MB/s e 128 GB de RAM (embora apenas 40 pareçam ser usados ​​de acordo com meu painel do datadog). Também não parece que meus processadores sejam uma limitação.

Tenho 300 partições para agrupar, em cada etapa do processo, estou tentando agrupar 8 partições em paralelo. Cada uma dessas partições está em ~ 50 GB

Algumas outras informações:

• manutenção_work_mem: 4 GB
• trabalho_meme: 64 MB
• buffer_compartilhado: 32 GB
• max_wal_size: 4 GB

Digamos que eu tenha uma tabela Conta que contém nome de usuário e senha de usuários para fazer login: -

account (
    account_id BIGINT PRIMARY KEY,
    username VARCHAR(30),
    password VARCHAR(30)
)

-- I have two more tables that stores their credentials in the above table:-

customer (
    delivery_address VARCHAR(100),
    account_id FOREIGN KEY,
    ..30 more customer columns
)

admin (
    sp_admin_code INT,
    account_id FOREIGN KEY,
    ..30 more admin columns
)

Um administrador não pode ser cliente e usar o mesmo nome de usuário e senha para fazer login como cliente.

Minhas perguntas:-

1. Esta é a maneira correta de implementar esse tipo de relacionamento? Se não, o que é?

2. Preciso adicionar alguma restrição na chave primária da tabela de contas para indicar que sua entrada única pode ser referenciada pela tabela de clientes ou pela tabela de administração de uma só vez?

3. Agora também sabemos que uma entrada na conta só pode existir se houver uma entrada para ela na tabela do cliente ou na tabela do administrador e vice-versa. Então, precisamos ou se quisermos adicionar alguma cascata/restrição, como fazemos ou como devemos fazer ou se devemos fazer? desculpe, estou confuso..

obrigado!

Existe alguma desvantagem em colocar tabelas de junção em seu próprio esquema?

Título, eu poderia ter alguns esquemas:

• aplicativo
  • do utilizador
  • permissão
• app_join
  • permissão_do_usuário

Se eu estiver trabalhando com sql, terei que incluir os nomes completos dos esquemas, o que não faz muita diferença, e se eu usar um orm, posso chamar suas funções de relacionamento e ignorar completamente o conhecimento dos esquemas. Existe alguma desvantagem óbvia com esta configuração? Qualquer coisa que só se revelasse em grande escala?