Re: Monitoreo grfico de postgresql, wal, oracle, etc

This is a multi-part message in MIME format.

--bound1124066064
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Si, en oracle el rollback es una operación costosa. Pero, usualmente, la mayoría de las transacciones terminarán siendo comprometidas ( o así debería estar implementada la lógica de la aplicación, teniendo en cuenta esto). Oracle dice que así mejora la performance de un select posterior. (no estoy haciendo juicio de valor ni tengo pruebas. Se que depende de las pruebas que se realicen. Menciono la forma que trabaja oracle nomás, cultura general 8-) )

Preguntas (baja prioridad, es curiosidad teórica):
- ¿Porque guarda WAL la página involucrada en una modificación, posterior al checkpoint?. ¿Estoy entendiendo mal? ¿cuando dice "posterior al checkpoint", debería pensar en posterior al inicio del checkpoint o posterior a la finalización del checkpoint?,
¿Cuál es la amenaza sobre esa página? ¿Esta página contiene información especial (metadata)? ¿No guarda WAL todas las sentencias de las transacciones? Estuve googleando, y no le encuentro la vuelta.

- ¿Es (o será) posible hacer uso de un backup o incremental? ¿Aceleraría la restauración y recuperación de una base en postgresql?

- ¿Alguien tiene a mano un documento de WAL? (si es relacionado a postgresql, mejor, sino también)

Saludos.

Alvaro Herrera wrote ..
> On Sat, Aug 13, 2005 at 02:00:04AM -0300, Dario wrote:
>
> > 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.
>
> Aja, esto es exactamente igual que en Postgres. Interesante!
>
> > Se refiere a UNDO como el hecho deshacer cambios en los datafiles
> > cuando se ejecuta un rollback.
>
> Aca aparece la diferencia: Postgres no hace UNDO para el rollback,
> porque el MVCC se maneja de manera diferente. Postgres deja la version
> antigua y la nueva de la tupla en el "heap" de la tabla (el archivo
> donde estan los datos); por lo tanto para hacer rollback, basta con
> marcar en alguna parte "esta transaccion hizo rollback", y cuando se
> examinan ambas versiones de las tuplas hay que ver si la transaccion
> hizo rollback o commit. Para limpiar el heap de las versiones viejas se
> hace VACUUM.
>
> En cambio Oracle guarda una sola version de la tupla en el heap de la
> tabla, las otras versiones se guardan en un "rollback segment". Por lo
> tanto nunca se necesita VACUUM, pero la desventaja es que la transaccion
> que esta modificando los datos tiene que escribir en el rollback
> segment, ademas de escribir en el heap.
>
> El compromiso entre usar un "overwriting storage manager" (como hace
> Oracle) versus un "non-overwriting storage manager" (como Postgres) es
> ese: quien tiene la responsabilidad de limpiar la tabla, si la misma
> transaccion que la modifica, o bien se deja para despues. La decision
> que se usa en Postgres (el non-overwriting) significa que la transaccion
> misma puede tener mejor rendimiento porque tiene menos trabajo; y
> ademas, un rollback es muy barato porque no hay que hacer UNDO. La
> desventaja es tener que ejecutar VACUUM de vez en cuando.
>
> > "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ó.
>
> En Postgres se hace todo el REDO y listo. No es necesario hacer el
> UNDO, por las mismas razones de arriba.
>
> > 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.
>
> En el POSTGRES que salio de Berkeley existia esta caracteristica. Se
> llamaba "time travel". Una de las primeras cosas que se hicieron en
> PostgreSQL fue eliminarla, porque traia varios problemas complicados.
>
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> "Vivir y dejar de vivir son soluciones imaginarias.
> La existencia está en otra parte" (Andre Breton)
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 5: ¿Has leído nuestro extenso FAQ?
>
> http://www.postgresql.org/files/documentation/faqs/FAQ.html

--bound1124066064--