RE: [pgsql-es-ayuda] Monitoreo gráfico de postgresql

From: "Dario" <dario_d_s(at)unitech(dot)com(dot)ar>
To: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>, "Horacio Miranda" <hmiranda(at)gmail(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: [pgsql-es-ayuda] Monitoreo gráfico de postgresql
Date: 2005-08-13 05:00:04
Message-ID: MHEDJHCKDNOEHJKHIOCJMEOBCFAA.dario_d_s@unitech.com.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Respecto al monitoreo gráfico, yo preferiría una aplicación de seguimiento y
recuperación tipo rman.

[casi OffTopic] Oracle hace PITR con los archive logs, postgresql con los
wal. No es para malos dba, sino para cualquiera que cometa un error o (x
ejemplo) alguien al cual le inyecten código en la aplicación.

Oracle (según se) no puede volver el tiempo atr}as y desconfirmar
transacciones comprometidas (comiteadas), hay que hacer un restore y aplicar
archived logs. Se refiere a UNDO como el hecho deshacer cambios en los
datafiles cuando se ejecuta un rollback.
"REDO" es parte del recovery de transacciones ante la caida del servidor. Se
hace redo de todas las sentencias no escritas en los datafiles
(independientemente de si forman parte de una transacción comprometida o no)
hasta que se lee todo el log, luego hace un undo de las sentencias que
forman parte de una transacción que no se cerró.

Lo que se podría hacer ver como una vuelta atras, es la flashback query.
Sería algo así como poder decirle al motor que no me lea la última versión
ya comiteada de un registro, sino que use una tupla anterior (las que
después limpia el vacuum) aun siendo esta query parte de una transacción
posterior. Es una manera de recuperar datos (delete * from table --
where...; commit; auch) o de acceder información (select valor from
cotizaciones AS OF TIMESTAMP (systimestamp - interval 1 day)) sin tener que
crear una tabla de históricos... puede consumir mucho disco, pero el espacio
en disco es más barato que las horas/hombre.

Saludos.

-----Mensaje original-----
De: pgsql-es-ayuda-owner(at)postgresql(dot)org
[mailto:pgsql-es-ayuda-owner(at)postgresql(dot)org]En nombre de Alvaro Herrera
Enviado el: viernes, 12 de agosto de 2005 17:38
Para: Horacio Miranda
CC: pgsql-es-ayuda(at)postgresql(dot)org
Asunto: Re: [pgsql-es-ayuda] Monitoreo gráfico de postgresql

On Fri, Aug 12, 2005 at 04:06:32PM -0400, Horacio Miranda wrote:
> La unica explicacion que me doy a una utilidad como esa y que oracle
> la tiene es para los malos DBA o los malos programadores, me explico,
> si un dba se pitea una tabla o un desarrollador deja la escoba en la
> base y hay que volver para atras para recuperar datos en el tiempo (un
> time stamp específico),

En PostgreSQL existe una caracteristica llamada PITR que sirve para eso.
La idea es respaldar los archivos de registro transaccional (WAL), y
aplicarlos en una copia fisica del directorio de datos. Pero sigue
siendo "hacia adelante", es decir "redo", no hacia atras como seria
"undo".

> AL igual que creo que java es para los progamadores malos por tener
> try catch exec, pero ese es otro tema.

Las excepciones son un mecanismo de programacion poderoso. Un lenguaje
no es malo solo por tenerlas. (De hecho una cantidad importante de los
lenguajes tiene: C# tiene; Perl tiene die/eval, que es lo mismo pero mas
primitivo; Python tiene; Ruby tiene; C++ tiene. C tambien tiene, aunque
muy primitivo, se llama setjmp/longjmp. En Postgres se usa esto
extensivamente)

> La cosa es que mientras mas mecanismos tenga la base para recuperarse
> frente a catastrofe de disco, DBA o desarrollador mejor.

Se llaman respaldos (o redundancia para disminuir la probabilidad de
catastrofes)

--
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
One man's impedance mismatch is another man's layer of abstraction.
(Lincoln Yeoh)

---------------------------(fin del mensaje)---------------------------
TIP 8: explain analyze es tu amigo

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2005-08-13 16:16:19 Re: Monitoreo gráfico de postgresql
Previous Message Alvaro Herrera 2005-08-13 00:28:07 Re: Lectura corrupta de datos