1

GRANT CHANGE NOTIFICATION TO app_user;

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

import oracledb

def on_change(message):
    for query in message.queries:
        for table in query.tables:
            for row in table.rows:
                print(table.name, row.operation, row.rowid)

conn = oracledb.connect(user="app_user", password=pw,
                        dsn="db.example:1521/orclpdb1", events=True)

sub = conn.subscribe(callback=on_change,
                     operations=oracledb.OPCODE_INSERT | oracledb.OPCODE_UPDATE | oracledb.OPCODE_DELETE,
                     qos=oracledb.SUBSCR_QOS_QUERY | oracledb.SUBSCR_QOS_ROWIDS)
sub.registerquery("select id, status, updated_at from orders")   # columnas explícitas, nunca SELECT *

input("Ctrl+C para salir\n")

Cada COMMIT que cambie el resultado de esa consulta dispara on_change con los rowid afectados. Sin polling, sin triggers, sin GoldenGate.

Por qué

Cuando otro sistema necesita reaccionar a cambios en Oracle (invalidar una caché, replicar hacia otra base, disparar un proceso), lo habitual es preguntar cada N segundos con WHERE updated_at > :last. Funciona hasta que no: filas sin columna de fecha, borrados que no dejan rastro, carga inútil sobre la base.

Continuous Query Notification invierte el flujo: registras una consulta y Oracle te llama cuando cambia. En modo query (SUBSCR_QOS_QUERY) avisa solo si cambia el resultado de esa consulta; en modo object (sin ese flag) avisa ante cualquier cambio en las tablas implicadas. SUBSCR_QOS_ROWIDS incluye los rowid en la notificación, con lo que el callback puede leer exactamente esas filas.

El caso: replicar Oracle a PostgreSQL

oracle_fdw deja consultar tablas de Oracle desde PostgreSQL como si fueran locales, y es tentador pensar que un trigger sobre la foreign table se disparará cuando cambien los datos en Oracle. No: los triggers de una foreign table solo saltan con escrituras hechas desde PostgreSQL a través de ella. El autor de oracle_fdw lo dice tal cual: no hay forma automática de mantener sincronizada una tabla de PostgreSQL con una de Oracle desde el lado PostgreSQL; eso tiene que dispararlo Oracle.

Con CQN el pequeño servicio en Python es la pieza que falta:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

def on_change(message):
    rowids = [row.rowid for q in message.queries for t in q.tables for row in t.rows]
    with conn.cursor() as cur:
        cur.execute("select id, status, updated_at from orders where rowid in (%s)"
                    % ",".join(f"'{r}'" for r in rowids))
        for id_, status, updated_at in cur:
            pg.execute("insert into orders (id, status, updated_at) values (%s, %s, %s) "
                       "on conflict (id) do update set status = excluded.status, updated_at = excluded.updated_at",
                       (id_, status, updated_at))
    pg.commit()

Los borrados llegan con row.operation & oracledb.OPCODE_DELETE y un rowid que ya no existe: borra en PostgreSQL por la clave que guardaste asociada a ese rowid, o marca la fila.

Requisitos

• Permiso: GRANT CHANGE NOTIFICATION TO app_user, además de SELECT sobre las tablas.
• events=True en la conexión que se suscribe; sin eso subscribe() falla.
• Red de vuelta. Por defecto es la base la que abre una conexión hacia tu aplicación para entregar las notificaciones: la máquina del cliente necesita una IP alcanzable desde el servidor Oracle y un puerto abierto (subscribe(..., ip_address=…, port=…) fija cuáles). Detrás de NAT, en un contenedor o con firewall entre medias, las notificaciones simplemente no llegan y nadie avisa.
• client_initiated=True elimina ese problema: la conexión la abre tu app. Requiere modo Thick (oracledb.init_oracle_client() con Instant Client 19.4 o superior) y base 19.4 o superior. En modo Thin, el por defecto de python-oracledb, CQN funciona pero solo en el modo clásico.
• job_queue_processes mayor que cero en la base: las notificaciones se despachan por el job queue.

Trampas

• ORA-29977: Unsupported column type for query registration in guaranteed mode: en modo query hay tipos de columna que Oracle no admite (LOB, entre otros), y SELECT * los arrastra. Lista las columnas que necesitas o quita SUBSCR_QOS_QUERY y trabaja en modo object.
• Las notificaciones no son durables: si tu servicio está caído durante un cambio, no lo recibe. Al arrancar, haz una reconciliación (por updated_at, o completa) y después suscríbete. timeout=0 en subscribe mantiene la suscripción hasta que la conexión muera.
• Una suscripción por conexión viva: la conexión con events=True tiene que seguir abierta; ponle keepalives y reconecta con re-suscripción si se cae.
• Mucho volumen (miles de commits por segundo) no es territorio de CQN: ahí entra un CDC por redo log (GoldenGate, o Debezium con su conector de Oracle vía LogMiner).
• SELECT con funciones no deterministas o sobre vistas complejas puede no registrarse en modo query; simplifica la consulta o cae a modo object.

Referencia: Continuous Query Notification en la documentación de python-oracledb y la discusión en oracle_fdw.

1
2
3

; /etc/pgbouncer/pgbouncer.ini
[pgbouncer]
ignore_startup_parameters = extra_float_digits, options

1

systemctl reload pgbouncer          # o RELOAD; en la consola de admin: psql -p 6432 -U pgbouncer pgbouncer

extra_float_digits se puede ignorar sin efectos. options (lo que JDBC y DataGrip usan para -c search_path=…) también se ignora, pero entonces el search_path del cliente no llega: fíjalo en el rol con alter role app set search_path = app, public.

El error

1

FATAL: unsupported startup parameter: extra_float_digits

o, según el cliente, pooler error: unsupported startup parameter: extra_float_digits. Directo al puerto 5432 conecta; por el 6432 de pgbouncer, no. Lo mandan JDBC (todo lo que use el driver de PostgreSQL para Java: DBeaver, DataGrip, Spring, Jenkins), Npgsql y algunos ORMs; otros clientes mandan options.

Por qué pasa

Cuando un cliente abre conexión, mete en el paquete de inicio los parámetros de sesión que quiere (extra_float_digits=3, options=-c search_path=app). pgbouncer, en modo transaction o statement, comparte una misma conexión de servidor entre muchos clientes, así que solo deja pasar los parámetros que sabe guardar por cliente y restaurar en el servidor cuando le toca a ese cliente: client_encoding, datestyle, timezone, standard_conforming_strings, application_name. Cualquier otro sería un ajuste que se filtra de un cliente a otro; antes que eso, pgbouncer rechaza la conexión.

Dos formas de resolverlo:

extra_float_digits es inofensivo desde PostgreSQL 12: la salida de float ya es la representación más corta exacta y el parámetro no cambia nada. options con search_path sí importa: ignorado, el cliente verá el search_path por defecto de la base y las consultas sin esquema fallan con relation does not exist. La solución limpia es el rol:

1

alter role app set search_path = app, public;

’no such database'

1

pooler error: no such database: app_db

pgbouncer solo enruta bases que estén en [databases]. O añades la entrada, o pones un comodín:

1
2
3

[databases]
app_db = host=db.example port=5432 dbname=app_db
* = host=db.example port=5432

Con *, un cliente que pida otra_db obtiene host=db.example dbname=otra_db; esas entradas automáticas se limpian solas tras autodb_idle_timeout. Y comprueba el dbname= de la entrada: es habitual apuntar app_db a otra base por un copy-paste.

Trampas

• RELOAD basta para ignore_startup_parameters y [databases]; listen_* y auth_type piden reinicio.
• Modo transaction y SET: un SET search_path a mano en la sesión se pierde en cuanto la conexión de servidor pasa a otro cliente; usa SET LOCAL dentro de la transacción o el alter role.
• Prepared statements con nombre (JDBC prepareThreshold, PREPARE) no funcionan en modo transaction en pgbouncer antiguo; desde 1.21, max_prepared_statements = 200 los soporta.
• SCRAM: con auth_type = scram-sha-256 la userlist.txt necesita el hash SCRAM tal cual sale de pg_authid, o auth_query para que pgbouncer lo consulte.
• SHOW CONFIG; y SHOW DATABASES; en la consola de admin te dicen qué está cargado de verdad, no lo que crees haber escrito.

Ver también: PostgreSQL: cheat sheet de administración. Referencia: pgbouncer.ini.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

-- Filas exactas de todas las tablas de un esquema, en una sola consulta
select table_schema, table_name,
       (xpath('/row/cnt/text()', xml_count))[1]::text::bigint as row_count
from (
  select table_schema, table_name,
         query_to_xml(format('select count(*) as cnt from %I.%I', table_schema, table_name), false, true, '') as xml_count
  from information_schema.tables
  where table_schema = 'public' and table_type = 'BASE TABLE'
) t
order by row_count desc;

-- Estimación instantánea (no lee las tablas)
select relname, n_live_tup from pg_stat_user_tables order by n_live_tup desc;

-- Usuario de solo lectura (PostgreSQL 14 o superior)
create user reporting with password '…';
grant pg_read_all_data to reporting;

Contar filas

count(*) exacto sobre cada tabla exige recorrerla entera; en una base de cientos de GB tarda. Lo que casi siempre quieres es la estimación que mantiene el autovacuum, que se actualiza en cada ANALYZE y suele estar a un par de puntos del real:

1
2
3

select schemaname, relname, n_live_tup, n_dead_tup, last_autoanalyze
from pg_stat_user_tables
order by n_live_tup desc;

Cuando necesitas el número exacto de todas las tablas sin escribir un DO en PL/pgSQL, el truco de query_to_xml: ejecuta un count(*) dinámico por tabla, devuelve el resultado como XML y xpath extrae el número. Es SQL plano, funciona desde cualquier cliente, y se puede filtrar por esquema o por nombre. Solo recuerda que corre los conteos en serie: en tablas grandes, paciencia.

Tamaños

1
2
3
4
5
6
7
8
9

select pg_size_pretty(pg_database_size(current_database()));

select n.nspname as schema, c.relname as table,
       pg_size_pretty(pg_total_relation_size(c.oid)) as total,   -- datos + índices + TOAST
       pg_size_pretty(pg_relation_size(c.oid)) as data
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where c.relkind = 'r' and n.nspname not in ('pg_catalog', 'information_schema')
order by pg_total_relation_size(c.oid) desc
limit 20;

Sesiones

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

-- Quién está conectado y qué hace
select pid, usename, state, client_addr, application_name, left(query, 80) as query
from pg_stat_activity
where datname = current_database();

-- Cancelar una consulta (la sesión sigue)
select pg_cancel_backend(12345);

-- Expulsar a todos menos a ti (antes de un DROP o un restore)
select pg_terminate_backend(pid)
from pg_stat_activity
where datname = 'app_db' and pid <> pg_backend_pid();

-- O, desde PostgreSQL 13, directo:
drop database app_db with (force);

-- Uptime
select date_trunc('second', current_timestamp - pg_postmaster_start_time()) as uptime;

Usuario de solo lectura

En 14 o superior, un rol predefinido lo resuelve para todos los esquemas, incluidas las tablas que se creen mañana:

1
2

create user reporting with password '…';
grant pg_read_all_data to reporting;

En versiones anteriores, o si quieres limitarlo a un esquema, el camino clásico:

1
2
3
4
5
6
7
8
9

grant connect on database app_db to reporting;
grant usage on schema public to reporting;
grant select on all tables in schema public to reporting;
-- tablas futuras: solo cubre las que cree el rol que ejecuta esto (o FOR ROLE app_owner)
alter default privileges for role app_owner in schema public grant select on tables to reporting;

-- Deshacer
revoke all on all tables in schema public from reporting;
alter default privileges for role app_owner in schema public revoke select on tables from reporting;

alter default privileges no toca lo que ya existe y solo aplica a objetos creados por el rol indicado: si otra cuenta crea tablas, reporting no las verá. De ahí el valor de pg_read_all_data.

Contraseñas, timezone y psql

1
2
3
4
5

\password app_user                                  -- desde psql, sin dejar la contraseña en el historial
alter user app_user with password '…';

alter database app_db set timezone to 'America/Mexico_City';   -- nuevas conexiones a esa base
alter role reporting set timezone to 'UTC';                    -- nuevas sesiones de ese rol

1
2

psql -v ON_ERROR_STOP=1 -f data.sql app_db      # un script que se detiene en el primer error
psql -P pager=off app_db                        # sin paginador (o \pset pager 0 dentro)

Y dentro de psql, \x auto (columnas verticales cuando no caben) y \timing.

Mantenimiento mínimo

1
2

vacuum (verbose, analyze) orders;
reindex table concurrently orders;               -- 12+, sin bloquear escrituras

VACUUM FULL reescribe la tabla y la bloquea mientras dura; para recuperar espacio en producción, pg_repack.

Trampas

• n_live_tup es una estimación: recién analizada es fiel; en una tabla con mucho churn puede desviarse hasta el siguiente autoanalyze.
• pg_read_all_data no salta RLS ni concede DDL; es lectura de tablas, vistas y secuencias, nada más.
• pg_terminate_backend corta transacciones: la aplicación ve un error y reconecta. Para solo abortar una consulta, pg_cancel_backend.
• alter role … set timezone aplica a sesiones nuevas; la que ya está abierta sigue igual.
• quote_ident/format('%I') siempre que construyas SQL con nombres de tablas: un nombre con mayúsculas o guiones rompe la consulta sin ellos.

Ver también

• pgbouncer: unsupported startup parameter
• Cloud SQL: importar dumps sin errores de DEFINER, GTID o extensiones