Re: Mover BD grande

[Lautaro Palamidessi]

Hola Jairo,
tuve el mismo escenario en mi trabajo con una base de 400GB.
Una semana antes de la migracion montamos un suscriptor de réplica en la
nube. Tardó un dia el pg_basebackup... y la noche de la migracion fue
solamente parar el soft, parar la replicacion y promover el slave de la
nube a Master tocando tres parámetros en el PostgreSQL.conf... reiniciar
servicio y en dos minutos de downtime teniamos el nuevo Master en la nube.

Suerte!

El mié., 11 de sep. de 2019 7:00 p. m., Jairo Graterón 
escribió:

> Saludos lista
>
> Quisiera que me ayudaran al siguiente requerimiento
>
> En la compañía que trabajo me están solicitando mover una BD Postgres 11
> de unos 30GB a AWS
>
> La BD está actualmente en Digital Ocean y bueno no tengo experiencia en
> mover una BD de ese tamaño, ni cuales serían los programas y también me
> piden calcular tiempo necesario que durará el proceso.
>
> He movido BD con pg_backup y pg_restore pero con ese tamaño no creo que
> sea la solución óptima.
>
> Si pueden compartir sus experiencias. Gracias.
>
>
>

¿Extraño comportamiento en vista?

[Lautaro Palamidessi]

Buenos días lista,

Hace unos días (el 2 de septiembre) tenía que "detectar" en una tabla las
transacciones de "ayer" y si bien lo lógico es usar una función con
parámetros "desde" y "hasta" que las filtre, por adaptar algo que ya
existía tomé para el lado de usar una vista con fechas filtradas entre
'yesterday' y 'today':

--Sobre una tabla que contenga un campo TIMESTAMP:
CREATE TABLE IF NOT EXISTS prueba (campo_fecha timestamp without time zone);

--Creo una vista que la filtre por los registros de "AYER":
CREATE OR REPLACE VIEW vw_prueba AS
SELECT campo_fecha
FROM   prueba
WHERE  campo_fecha BETWEEN 'yesterday' and 'today';  --> TRANSACCIONES DE
"AYER"

Ese día funcionó bien pero para mi sorpresa a partir del día siguiente
empezó a fallar mostrándome siempre las transacciones del mismo día
inicial.
--Entré a revisar mi vista:
--Me fijo cómo quedó la definicion:
select * from pg_get_viewdef('vw_prueba')

--y para mi sorpresa veo que devuelve:
" SELECT prueba.campo_fecha
   FROM prueba
  WHERE ((prueba.campo_fecha >= '2019-09-01 00:00:00'::timestamp without
time zone) AND (prueba.campo_fecha <= '2019-09-02 00:00:00'::timestamp
without time zone));"

o sea: Al compilar y grabar la vista, mis "variables" se convirtieron en
"constantes"!

La solución fue fácil, pasar:
1) 'yesterday' a CURRENT_DATE - '1 day'::interval
2) 'today' a CURRENT_DATE
y todo se arregló.
Pensé que las causas venían por lo "no determinista" del "today" pero para
desempatar probé compilar la vista usando "random()" y no hardcodeó valores
sino que respetó la funcion.

Las preguntas que hago a la lista son:
Si 'today' y 'yesterday' fueran funciones, ¿hay un bug al grabarse en la
vista como constantes?
Si 'today' y 'yesterday' fueran constantes: ¿por qué hoy valen una cosa y
mañana valen otra cosa?
Si 'today' y 'yesterday' no son ni funciones ni constantes, ¿qué son?

Estoy usando PostgreSQL 11.5 sobre Centos, pero probé que sucede desde al
menos 9.2 en adelante.
Saludos, gracias!

Re: Transformar un procedimiento Firebird a PostgreSQL

[Lautaro Palamidessi]

Buen dia, usa la funcionalidad LAG de las window functions:
https://www.postgresql.org/docs/current/functions-window.html

Saludos

El vie., 31 may. 2019 a las 12:22, José Vicente Zahonero García (<
joviz...@hotmail.com>) escribió:

> Hola de nuevo, tengo un procedimiento en Firebird que recorre una tabla
> comparando un registro con el inmediatamente posterior y que devuelve la
> mayor diferencia entre dos registros consecutivos. No sé como
> implementarlo  en PostgreSQL. ¿Puede alguien echarme una mano?. Gracias.
>
>
> CREATE OR ALTER PROCEDURE DIAS_SIN RETURNS (
> "RESULT" INTEGER
> )
> AS
> DECLARE VARIABLE AUX INTEGER;
> BEGIN
>   AUX= 0;
>   RESULT = 0;
>   FOR
> SELECT max(DATEDIFF(DAY FROM DT2.FECHA TO DT1.FECHA))
>   FROM DATOS DT1, DATOS DT2
>   WHERE DT1.SALIDA_NUM = DT2.SALIDA_NUM + 1
> INTO :AUX
>   DO
> IF(AUX > RESULT) THEN RESULT = AUX;
>   SUSPEND;
> END
>
>

-- 

[image: logo conexia] <http://conexia.com/>

*Lautaro Palamidessi*
Consultor Técnico DBA
*T:* +5411 5173 6159

[image: facebook conexia] <https://goo.gl/OxO8kd> [image: twitter conexia]
<https://goo.gl/XGpgl3> [image: linkedin conexia] <https://goo.gl/epcLtV>
www.conexia.com <http://conexia.com/>

 [image: line]

Re: Postgresql problema !!!

[Lautaro Palamidessi]

¿Probaste ejecutar:

select * from pg_stat_activity where state <> 'idle';

para ver qué está corriendo el postgres?

El 19 de diciembre de 2017, 13:52, Angelo Astorga <angeloasto...@gmail.com>
escribió:

> Hola lista,
> Desde un momento a otro la cpu del servidor se fue a 100%, donde gran
> parte de este consumo lo absorve postgresql. Desconozco que paso, dado que
> el mismo día x la mañana el servidor y sus recursos andaban como avión y
> ahora solamente al subir servicio postgresql, comienzan las cpu a irse al
> 100%, haciendo inoperante el sistema.
> Plataforma centos + php + postgresql.
>
> Pensamos q eran los discos del raid pero estan bien, luego corrupcion bd y
> como tal, volvimos a montar y sigue igual.
>
> Alguien habrá pasado x esta experiencia q me pueda orientar para descubrir
> causa del problema?
>
> Saludos y gracias.
>



-- 

[image: logo conexia] <http://conexia.com/>

*Lautaro Palamidessi*
Consultor Técnico DBA
*T:* +5411 5173 6159

[image: facebook conexia] <https://goo.gl/OxO8kd> [image: twitter conexia]
<https://goo.gl/XGpgl3> [image: linkedin conexia] <https://goo.gl/epcLtV>
www.conexia.com <http://conexia.com/>

 [image: line]

Re: Informacion archivos base de datos

[Lautaro Palamidessi]

No olviden que como DBA debemos garantizar Integridad!
Un restore tiene datos íntegros cuando los archivos están dentro de la base.
Fuera de la base: Quien backupea filesystem y garantiza integridad?

Y si la carpeta de adjuntos es remota y montada podría estar inaccesible...
Múltiples problemas.
Dentro de la base está todo e íntegro!

El 27 oct. 2017 5:27 PM, "Alejandro Flores"  escribió:

> Hola.
>
> Yo prefiero guardarlos en la base de datos,   me ahorro mucho en la
> administración de archivos.
>
> Saludos
>
>
>
> El 27 oct. 2017 9:48 AM, "Ricardo Alvarado" 
> escribió:
>
>> Buenos días compañeros, me gustaría saber si se puede guardar archivos o
>> imagenes en base de datos, cuales son su pro y contras.
>>
>> Gracias
>>
>> --
>> *Ricardo Alvarado*
>>
>>
>>
>>

Re: Registros desaparecidos de la BD

[Lautaro Palamidessi]

Buen día, con sólo poner:

log_statement = 'MOD'

y enviar un reload al servicio postgres, en el LOG comenzará a registrar todas
las sentencias que modifican datos (no loguea SELECT's pero sí INSERT,
UPDATE y DELETE, que es lo que te interesa).

Saludos

El 3 de octubre de 2017, 9:26, Jairo Graterón <jgrate...@gmail.com>
escribió:

> Buen día, verifica además la aplicación ya que una posible transacción no
> culminada, es decir, en alguna parte iniciaste BEGIN y no hiciste el
> respectivo COMMIT, hace que se pierdan registros cuando la aplicación se
> cierre de manera inesperada,
>
>
> Para encontrar el error activar la siguiente variable de postgresql.conf
>
> log_statement = 'all'
>
> Revisa todas las sentencias y seguimientos de transacciones.
>
> Saludos
>
>
> El 3 de octubre de 2017, 8:08, Gerardo Herzig <gher...@fmed.uba.ar>
> escribió:
>
>>
>>
>> - Mensaje original -
>> > De: "Fernando A" <soporteallpurp...@gmail.com>
>> > Para: "Lista PostgreSQL" <pgsql-es-ay...@postgresql.org>
>> > Enviados: Martes, 3 de Octubre 2017 8:54:35
>> > Asunto: Registros desaparecidos de la BD
>> >
>> > Estimados,
>> > en tres ocasiones, me encuentro con que han desaparecido algunos
>> registros
>> > de distintas tablas de una BD,.
>> > Descarto que sea un problema de seguridad, dado que el cliente ha podido
>> > observar el problema casi  en el momento que le sucedio y parece mas una
>> > falla o del sistema o de la BD.
>> > Sin embargo aun no encuentro las causas.solo puedo observar que
>> los
>> > numeros de identidad saltan y en el log que deja postgres no encuentro
>> > información directa con el problema,
>> > salvo los siguientes mensajes (de los muchos) que podrian estar o no
>> > vinculados:
>> >
>> > 2017-10-03 03:44:00 ART LOG:  no se pudo recibir datos del cliente:
>> > Conexión reinicializada por la máquina remota
>> > 2017-10-03 03:44:00 ART LOG:  se encontró fin de archivo inesperado en
>> la
>> > conexión del cliente
>> >
>> >
>> > Sin embargo no se si se relacionan con el problema en si o no, ya que el
>> > cliente no me pudo identificar con exactitud la hora en que fue el
>> problema.
>> > Por otro lado, si los mensajes anteriores estan relacionados con el
>> > problema en si, pueden desaparecer 20 registros (20 insert) cada uno
>> > correspondiente a un solo proceso ?
>> > La version de postgres es la  9.1, corriendo sobre un Debian Wheezy y
>> > terminales Windows.
>> > Cualquier ayuda, se agradece desde ya!
>> >
>> > Cordiales Saludos,
>> > Fernando
>> >
>> Lo primero que haria es poner el log mas "verboso", para que te quede
>> registrada toda la actividad de la base.
>> Revisa los parametros log_statements, log_line_prefix
>> https://www.postgresql.org/docs/9.1/static/runtime-config-logging.html
>>
>> A partir de ahi podes hacer una auditoria mas detallada.
>> HTH
>> Gerardo
>>
>>
>>
>


-- 

[image: logo conexia] <http://conexia.com/>

*Lautaro Palamidessi*
Consultor Técnico DBA
*T:* +5411 5173 6159

[image: facebook conexia] <https://goo.gl/OxO8kd> [image: twitter conexia]
<https://goo.gl/XGpgl3> [image: linkedin conexia] <https://goo.gl/epcLtV>
www.conexia.com <http://conexia.com/>

 [image: line]