Rogerlr's questions

Na documentação do Oracle 12c não ficou claro qual é a diferença entre os comandos srvctl start e srvctl enable para serviços associados a um banco de dados. Na view dba_service um banco de dados que tem um serviço já iniciado, tem a coluna ENABLED com NO , o que notei é que quando um serviço RAC já foi iniciado e você tenta habilitar, ele informa que já está habilitado.

srvctl enable service -d mydb -s myservice
PRCC-1010: myservice was already enabled
PRCR-1002: Resource ora.mydb.myservice.svc is already enabled 

Estou tentando fazer uma consulta que deve retornar registros com base em uma subconsulta. Aqui está um exemplo:

selecione ... onde tablename like ('%subquery_result%');

A subconsulta está gerando a string conforme o esperado:

appldb=# select '''%_p' || 
replace(substring(CAST(current_date - INTERVAL '1 MONTH' AS text), 1, 7),'-', '_') || '%''';
   ?column?
---------------
 '%_p2019_09%'
(1 row)

Usando a string acima, os registros são retornados:

select tablename from pg_tables 
where tablename like '%_p2019_09%' limit 2;
      tablename
---------------------
 part_p2019_09_26
 part_p2019_09_29
(2 rows)

Mas quando uso a query completa não tenho retorno:

appldb=# select tablename 
from pg_tables 
where tablename like ( select '''%_p' || 
replace(substring(CAST(current_date - INTERVAL '1 MONTH' AS text), 1, 7),'-', '_') || '%''' );
 tablename
-----------
(0 rows)

Eu já tentei remover parênteses ao redor da subconsulta. Mas a consulta deu um erro.

Perdi alguma etapa para garantir a cláusula where para interpretar a subconsulta?

Considere que estou usando um procedimento externo C ou java chamado do meu Oracle 12.2 Listener (parâmetro de ouvinte EXTPROC). Esse banco de dados Oracle será migrado para o Postgres.

Minha dúvida é como migrar o procedimento externo C ou java?

Devo instalar a extensão C ou java para o Postgres e compilar esses procedimentos dentro do meu banco de dados Postgres?

Minha configuração tem 2 hosts Postgres:

• host SRV1como primário com 2 instâncias e IP 192.168.1.241

  • Instância Aescutando na porta 5432
  • Instância Bescutando na porta 5433

• host SRV2como standby com instância Ce IP 192.168.1.243 usando a porta padrão.

Eu configurei com sucesso a replicação de instace Apara instância Cusando repmgr .

Estou usando o PostgreSQL 10 e o rempgr 4.

Como eu poderia configurar a replicação de novas instâncias, por exemplo B, para uma nova instância no host SRV2(standby) usando repmgr?

Fiz o backup do meu banco de dados:

-bash-4.2$ pg_dump -d mydb --format=custom -f /tmp/dump 
-bash-4.2$ 

Abaixo verifiquei e vi minhas funções lá:

-bash-4.2$ pg_restore -l /tmp/dump | grep -i addconf
233; 1255 39949 FUNCTION public addconfiguration(text) mydb
247; 1255 39950 FUNCTION public addconfiguration2(text) mydb
273; 1255 39951 FUNCTION public addconfiguration3(text) mydb

Então tentei restaurar uma função usando as instruções do Postgres pg_restore :

-bash-4.2$ pg_restore -d postgres --function=addconfiguration2(text) -v /tmp/dump 
-bash: syntax error near unexpected token `('

Eu também tentei sem os parênteses e o argumento, mas não funcionou:

-bash-4.2$ pg_restore -d postgres --function=addconfiguration2 -v /tmp/dump 
pg_restore: connecting to database for restore
pg_restore: implied data-only restore

Após as tentativas verifiquei se a função foi criada \dfdentro do psql, mas sem sucesso.

Como eu poderia restaurar funções usando pg_restore?

Eu configurei a replicação repmgr em node1 e node3 (primário e standby respectivamente), e a configuração funcionou com sucesso criando novos registros e objetos em standby conforme o esperado. Mas depois de algumas semanas eu notei que a replicação não estava mais funcionando, porém alguns comandos repmgr estão retornando resultados enquanto a replicação está funcionando. Tentei reiniciar e registrar novamente o nó de espera, mas não funcionou.

Como posso continuar a replicar?

Aqui está o status dos nós:

-bash-4.2$ psql -V
psql (PostgreSQL) 10.3

NÓ1 - PRIMÁRIO

-bash-4.2$ repmgr node check
Node "node1":
    Server role: OK (node is primary)
    Replication lag: OK (N/A - node is primary)
    WAL archiving: OK (0 pending archive ready files)
    Downstream servers: OK (this node has no downstream nodes)
    Replication slots: OK (node has no replication slots)
-bash-4.2$

NÓ3 - EM ESPERA

-bash-4.2$ repmgr -f /etc/repmgr/10/repmgr.conf node check 
Node "node3":
    Server role: OK (node is standby)
    Replication lag: OK (0 seconds)
    WAL archiving: OK (0 pending archive ready files)
    Downstream servers: CRITICAL (1 of 1 downstream nodes not attached; missing: node3 (ID: 3))
    Replication slots: OK (node has no replication slots)

-bash-4.2$ repmgr node status 
Node "node3":
    PostgreSQL version: 10.3
    Total data size: 2393 MB
    Conninfo: host=node3 user=repmgr dbname=repmgr connect_timeout=2
    Role: standby
    WAL archiving: disabled (on standbys "archive_mode" must be set to "always" to be effective)
    Archive command: /bin/true
    WALs pending archiving: 0 pending files
    Replication connections: 0 (of maximal 10)
    Replication slots: 0 (of maximal 10)
    Upstream node: node3 (ID: 3)
    Replication lag: 0 seconds
    Last received LSN: 4/AC000000
    Last replayed LSN: 4/AC000140