sábado, julio 19, 2008

Continuemos jugando con primos

En la documentación de Free Pascal observamos lo siguiente:

  • El tipo smallint es para enteros con signo de 16 bits por lo que el rango de enteros que puede almacenar es de -32768 a 32767.
  • El tipo word es para enteros sin signo por lo que llega a representar enteros de 0 a 65535.
  • Hay un tipo que ya nos interesa más que es el longword. Son 32 bits sin signo por lo que el límite llega a 4294967295.

De momento la primera modificación que vamos a hacer en el programa es el cambio de integer a longword.

Bueno, y ahora que hemos visto estas limitaciones del freePascal igual tenemos que ver que nos ofrece otro lenguaje. Por ejemplo el framework .NET.

Este interesante post http://varionet.wordpress.com/2007/10/23/%C2%BFpor-que-usar-los-tipos-de-datos-de-net-framework/ habla de otro tema relacionado, pero lo que más nos interesa es la tabla final con las posibilidades del framework.


Después de verlo hay que reconocer que claramente sus tipos enteros superan lo mejor de freePascal.


Ahora bien, teniendo en cuenta que el mayor número conocido en un determinado momento del año 2003 tenía 6.320.430 dígitos vemos que realmente lo fastidioso es la limitación "artificial" de los lenguajes a la hora de manejar enteros.

La proeza del 2003 podéis verla en www.laflecha.net/canales/ciencia/noticias/200312121


Mañána la primera solución.

martes, julio 15, 2008

Y nacieron los números primos

Hola,
Estoy reventado. Acabo de llegar a casa. Es bastante tarde en mi ciudad.
Voy a obligarme un poco a escribir mientras veo un rollo de película.

Creo que el tema de los números primos es muy importante en las matemáticas y que se pueden programar algunas funciones que nos den algún indicio de su comportamiento.

Primero un poco de historia para lo cual nos tenemos que remontar a los tiempos de euclides. No voy a reinventar la rueda. Me imagino que en Wikipedia hay suficiente información. Por lo tanto empezamos echando un vistazo a http://es.wikipedia.org/wiki/Euclides

Bien, en la wikipedia no han olvidado "Los elementos". La gran obra de Euclides. La recopilación de la mayor parte del conocimiento matemático a la que había llegado el hombre en 13 volúmenes.

El libro VII de Los elementos comienza con 22 definiciones entre las que se encuentran la del número par, el impar y el número primo. Dice que un número primo es aquel que no tiene otros divisores enteros distintos de la unidad y del propio número.

Una de las cosas que consiguió demostrar Euclides es que existen infinitos números primos. Veremos la demostración más adelante (me refiero a otro día).

Por hoy nos conformaremos con una función que nos diga si un número es primo o no. Se llamará función EsPrimo.


El código fuente:


program EsPrimo;
var
numero,i:integer;

function EsPrimo(var num):boolean;
begin
for i:=numero-1 downto 2 do
begin
if numero mod i = 0 then
begin
EsPrimo:=false;
exit;
end;
end;
EsPrimo:=true;
end;

begin
repeat
write('Introduce un numero mayor que 0: ');
readln(numero);
until numero>0;
if EsPrimo(numero) then
writeln('Es un numero primo')
else
writeln('No es un numero primo');
readln;
end.


domingo, julio 13, 2008

Programita que demuestra el post de ayer


Si, seguro que hay gente que no se cree que en el problemas de las tres puertas (vease post de ayer) es mejor pedir cambiar la selección.

El siguiente programa Pascal nos permite probar todas las veces que queramos para que nos convenzamos definitivamente.

En mi nuevo portátil Windows Vista no tenía compilador de Pascal.

En http://www.freepascal.org/ me he descargado la versión 2.2.0. Han sido 32 Mbytes de descarga.


El código fuente:




sábado, julio 12, 2008

Otro fallo de la intuición



Si, la intuición, ese sexto sentido al que siempre hay que prestar atención, muchas veces juega malas pasadas como vimos el otro día.
Estaba viendo la serie "NUMB3RS" y pusieron lo que después he sabido que es un problema típico de probabilidades.
El protagonista (o su hermano porque realmente no se quien es el protagonista principal de la serie) está impartiendo una clase en la universidad y para demostrar lo equivocados que estamos muchas veces plantea un problema.
Pone tres paneles de pie. Los alumnos están viendo la parte de atrás que está en blanco. Dice que en uno de los paneles hay un coche y los otros dos no hay regalo.
Le dice a una alumna (muy guapa por cierto) que seleccione un panel. Va ella y elige el del medio.
El profesor después de que la alumna haya hecho la selección (es un detalle muy importante), da la vuelta al panel de la derecha y se ve que está vacío.
Ahora le pregunta a la alumna a ver que quiere hacer, si decide cambiar de panel o se queda como está.
La alumna, que es tonta como nosotros, dice que como la probabilidad de que el coche esté en el panel de la izquierda es la misma que la que se encuentre en el centro, pues vaya, que prefiere dejarlo como está.
Y ahora es cuando el prota explica a toda leche que no, que si cambia de panel la probabilidad de conseguir el coche era de 2/3.
El profe descubre el panel de la izquierda donde estaba el super deportivo.
¿Que ha ocurrido aquí? ¿Es cierto lo que dicen? Te rompe todos los esquemas, ¡a que si!
La explicación es la siguiente:
¿Cuando elige la alumna cuales son las probabilidades? 1/3 de que acierte el deportivo.
Si selecciona justo el panel del deportivo y después de la selección del profesor cambia de panel, ¿que ocurre? Pues que pierde el deportivo. Adoptando la estrategia de cambio de panel tiene 1/3 de posibilidades de perder el deportivo.
¿Cuales son las probabilidades de que el deportivo esté en los otros 2 paneles? 2/3.
Bien, ahora el profesor coge el panel de la derecha y lo descubre. El no puede descubrir el de la izquierda ya que allí está el deportivo. Digamos que si el deportivo está en el de la derecha tiene que descubrir el de la izquiera. Por lo tanto, con la estrategia de cambio de panel tiene 2/3 de probabilidad de ganar el deportivo.
Bueno, yo he hecho lo que he podido, explicaciones magistrales aquí.

¿Quien lo diría eh?


miércoles, julio 09, 2008

Quiere jugar con tu Vista?


Bueno, seguro que llevas unos cuantos meses con tu flamante Windows Vista y no le acabas de ver demasiadas ventajas.
Vamos a ver una posibilidad que tiene para aumentar el rendimiento.
Ya se sabe que una de las formas más fáciles de aumentar el rendimiento del sistema es aumentar la memoria RAM. Lo que ocurre es que es algo incómodo y caro. Como todo no entra en la RAM el sistema operativo suele reservar parte del disco duro como si fuera memoria. Se le suele llamar memoria virtual. La parte de la memoria virtual que se guarda en disco es muchísimo más lenta que la memoria "real".

Hay una cosa que puedes probar para mejorar la velocidad. En líneas generales se trata de añadirle un pen-drive e indicarle al sistema operativo que lo puede utilizar como si fuera la memoria RAM.
Siendo el acceso al pen-drive más rápido que al disco duro que tiene que hacer movimientos mecánicos la memoria virtual sobre el pen-drive funcionará más rápido que sobre el disco.

En Windows Vista le han llamado a esto ReadyBoost
¿Como activarlo?
Muy fácil:
1-Conectar el pen-drive.
2-Ir a Equipo y ver donde ha añadido la nueva unidad.
3-Clic con el botón derecho y entrar en propiedades.
4-Clic en la pestaña ReadyBoost.

En este pestaña Windows nos indica si podemos utilizar ese pen-drive para aumentar el rendimiento.
Cuando he entrado yo me decía que no podía utilizar el dispositivo para aumentarlo. He hecho clic en el botón PROBAR y ahora ha cambiado de opinión. Esto es lo que indica:

martes, julio 08, 2008

La primera ley del ciclismo



Hoy he dado una vuelta con mi mountain bike con mi amigo Ripi. Ha sido una paliza impresionante y ahora me encuentro un poco perjudicado.


Esto me recuerda la primera ley del ciclismo. Lo podéis buscar en google (primera ley del ciclismo).


La ley dice así: "No importa la dirección que tome, siempre será cuesta arriba y contra el viento".


Esta Ley tiene bastante relación con la informática. Algunos autores se han dado cuenta y lo han llegado a publicar. En la quinta edición del libro "Ingeniería del Software. Un enfoque práctico" de Roger S. Pressman se dice en el capítulo dedicado a "EL PROCESO":


"Frecuentemente, el trabajo del software sigue la primera ley del ciclismo: no importa dónde vayas, ya sea montaña arriba y contra el viento".


Me imagino que la primera ley se ha modificado ligeramente por un problema de traducción.


Saludos.

domingo, julio 06, 2008

Sorprendente sentencia

Viacom (http://es.wikipedia.org/wiki/Viacom) ha conseguido una sorprendente sentencia.

Google va a tener que proporcionarle el historial de accesos de los usuarios de YouTube. Son datos como el identificador del usuario, su dirección IP, el vídeo que ha visto y la fecha y hora del acceso.

Un total de 12 terabytes con el que Viacom pretende demostrar que Google no está haciendo todo lo posible para eliminar contenidos protegido por copyright.

De nada a servido en este caso el argumento de Google de que proveer esos datos suponen la vulneración de la privacidad de los usuarios.

La noticia original en PC Magazine: http://www.pcmag.com/article2/0,2704,2324635,00.asp
Y el documento legal: http://beckermanlegal.com/Documents/viacom_youtube_080702DecisionDiscoveryRulings.pdf

jueves, julio 03, 2008

La intuición tan útil como frágil



Hola,

¡Cómo somos los informáticos!

El otro día vino al trabajo un experto de Oracle y hablando de una cosa y de otra terminó planteando el siguiente acertijo:

Supongamos que rodeamos la circunferencia de la tierra con un cuerda. Tendría que ser una cuerda largísima ¿no?

No sabíamos la cifra exacta en aquel momento pero estaba claro que tenía que ser larguísima. Tendría que ser una cuerda que midiera 40.075 km más o menos si pasara por el ecuador.

La cuerda estaría al ras del suelo, o sea, a una altura de 0 metros.

¿Cuanto habría que alargar esa cuerda de 40.075 km para que estuviera a un metro del suelo? es la pregunta que me hizo.

Pensadlo un momento antes de seguir.

Di una cifra aproximada.

¿Quieres saberlo?

Pues...

Algo más que ¡6,28 metros!

Pero, si yo pensaba que sería mucho más.

Pues no. Vamos a ver, el perímetro de una circunferencia de radio R es....
= 2 x pi x R

Y si el radio en lugar de R es R + 1...
= 2 x pi x (R +1)

O sea...
= 2 x pi x R + 2 x pi

Y ¿Cuanto es 2 x pi?
= 6,28

La intuición no siempre es buena consejera.

miércoles, julio 02, 2008

Buen blog sobre Windows Vista



Este (http://win-vista.es/) es un buen blog sobre Windows Vista.

Destacan entre otros los trucos para mejorar el rendimiento.

Habrá que seguirlo una temporada a ver que tal.

martes, julio 01, 2008

El UNDO en Oracle

Los antiguos segmentos de rollback se llaman a partir de Oracle9i segmentos de undo. El tablespace de UNDO es el lugar donde se van guardando las transacciones, esto es, las modificaciones sobre la base de datos antes de hacer commit.

¿Que se almacena en el UNDO?
No se guarda los bloques de datos modificados (error habitual). Lo que se guarda es la información mínima necesaria para cumplir los 2 objetivos del UNDO:

1.- Asegurar la consistencia en lectura. Significa que si hay 100 usuarios trabajando concurrentemente y uno de ellos hace una consulta sobre la base de datos para obtener un informe, aunque la consulta tarde 10 minutos en dar una respuesta Oracle debe darle la información del momento en el que la ha lanzado el usuario. Mientras se ejecutaba esa consulta ha podido haber cambios, pero el usuario necesita saber la situación en el momento de lanzarla.

2.- Permitir la recuperación en caso de rollback. Un usuario puede lanzar varias sentencias que formen una sola transacción. Un cliente compra un billete de avión. Hay que actualizar la tabla de billetes vendidos, la del cliente con sus datos y una cuantas más. Si cualquiera de las actualizaciones falla toda la transacción hay que echarla atrás deshaciendo los cambios realizados.

¿Cual es esa información mínima? Pues depende:
Si el usuario inserta una fila nueva en una tabla al undo sólo irá el rowid del registro insertado, ya que para deshacer lo único que tiene que hacer es una delete de ese rowid.
¿Que se actualiza un campo de un registro? El undo guardará la información de ese campo antes de su modificación.

Los errores que se producen con el UNDO:

En Oracle 9i surge la gestión automática del UNDO. Una de las cosas que tiene que decidir el DBA es cuanto tiempo (en segundos) debe ser capaz Oracle de retener esa información en el UNDO. Se llama UNDO_RETENTION.

Hay 2 errores típicos que se producen en Oracle por el tema del UNDO.

Uno es el temido ORA-01555, “Snapshot too old” que ocurre cuando hay una consulta en la base de datos que sobrepasa el UNDO_RETENTION. Como Oracle no es capaz de asegurar la consistencia en lectura devuelve un error. Así es Oracle, mejor un error que unos datos incosistentes (aunque sean buenos).

El otro error típico es el contrario. Tenemos un UNDO_RETENTION suficiente para cualquiera de nuestras potenciales consultas largas, pero el tablespace de UNDO se ha quedado pequeñito para poder almacenar todos los datos necesarios. Entonces se produce el error ORA-30036: “Unable to extend segment by <> in undo_tablespace <>.


Sentencias sql para la gestión del UNDO. Para ejecutarlas podemos abrir una sesión sql*plus como sysdba.

Para ver los parámtros actuales del undo:
show parameter undo;

Para ver que tablespaces y que ficheros físicos componen el undo:
Select tablespace_name, file_name
from dba_data_files
where tablespace_name like ‘UNDO%’
order by 1,2;

Creación de un tablespace de undo compuesto por un fichero de 25 Gigas: El nombre “UNDOTBS” es un ejemplo.
Create undo tablespace UNDOTBS datafile ‘/undo/undotbs01.dbf’
size 25000M;

Añadir un fichero (datafile) a un tablespace de undo:
Alter tablespace undotbs1
add datafile ‘/undo/undotbs03.dbf
size 20480M;


Modificación del undo_retention. 19800 son segundos. Si ponemos scope = memory los no se mantendran al reiniciar la base de datos.
alter system set undo_retention=19800 scope = both;

Para monitorizar el uso de UNDO se puede lanzar la siguiente sentencia:

SELECT A.SID, A.USERNAME, B.XIDUSN, B.USED_UREC, B.USED_UBLK
FROM V$SESSION A, V$TRANSACTION B
WHERE A.SADDR=B.SES_ADDR;


XIDUSN: Segmento de UNDO asociado a una transacción
USED_UREC: Numero de registros guardados en UNDO por la transacción
USED_UBLK: Numero de bloques usado por la transacción

Por último adjunto la nota de Oracle número 461480.1 sobre la gestión automática del UNDO. Creo que aquí viene todo lo necesario para cualquier DBA:


Subject: FAQ – Automatic Undo Management (AUM) / System Managed Undo (SMU)
Doc ID:
Note:461480.1 Type: FAQ
Last Revision Date: 09-DEC-2007 Status: PUBLISHED
In this Document
Purpose
Questions and Answers
What is Undo?
What is AUM / SMU?
Which are the major initialization parameters that controls AUM?
How many Undo tablespaces can we have for a database?
How to switch to a new undo tablespace?
What is UNDO Retention?
What is Automatic UNDO Retention (10g New Feature)? Explain.
What is Gaurenteed UNDO Retention? Explain.
Explain V$UNDOSTAT, and usage?
Explain the DBA_UNDO_EXTENTS View, and usage?
What are the various statuses for Undo Extents? Explain.
Explain V$TRANSACTION, and usage?
Explain DBA_ROLLBACK_SEGS, and usage?
Do we have scripts to monitor the undo growth/usage of the database?
What are the possible causes for excessive undo growth?
How to resize the undo datafile?
What is In Memory Undo?
References
________________________________________
Applies to:
Oracle Server - Enterprise Edition - Version: 9.0.1.4 to 11.1
Information in this document applies to any platform.
Oracle RDBMS Server
Purpose
This article is intended for Database Administrators with knowledge on Automatic Undo Management (AUM).
And we have covered major questions related to Automatic Undo Management (AUM) which will be helpful during creation (or) monitoring the undo tablespaces.
Questions and Answers
What is Undo?
Oracle maintains information to nullify changes made to the database. Such information consists of records of the actions of transactions, collectively known as undo. Oracle uses the undo to do the following:

- Rollback an active transaction

- Recover a terminated transaction

- Provide read consistency

- Recovery from logical corruptions


What is AUM / SMU?
Automatic Undo Management(AUM) is introduced in Oracle 9i, which replaces the rollback segments.
This is also called System Managed Undo(SMU) as the undo is mangaged by oracle.

Automatic undo management is undo-tablespace based. You allocate space in the form of an undo tablespace, instead of allocating many rollback segments in different sizes.

Oracle strongly recommends thier customers to use Automatic Undo Management (AUM).
Which are the major initialization parameters that controls AUM?
UNDO_MANAGEMENT Initialization Parameter

UNDO_MANAGEMENT specifies which undo space management mode the system should use. When set to AUTO, the instance starts in automatic undo management mode. In manual undo management mode, undo space is allocated externally as rollback segments.

By default, this parameter is set to MANUAL. Set this parameter to AUTO to enable automatic undo management mode.

This is a static parameter and cannot be modified dynamically using alter system command.
So if you wish to switch between Rollback Segments and AUM, then you need to restart the instance.

In RAC, multiple instances must have the same value.


UNDO_TABLESPACE Initialization Parameter
When an instance starts up in automatic undo management mode, it attempts to select an undo tablespace for storage of undo data.

UNDO_RETENTION Initialization Parameter
This parameter specifies (in seconds) the low threshold value of undo retention.

The UNDO_RETENTION parameter can only be honored if the current undo tablespace has enough space. If an active transaction requires undo space and the undo tablespace does not have available space, then the system starts reusing unexpired undo space. This action can potentially cause some queries to fail with a "snapshot too old" message.

The amount of time for which undo is retained for the Oracle Database for the current undo tablespace can be obtained by querying the TUNED_UNDORETENTION column of the V$UNDOSTAT dynamic performance view.
How many Undo tablespaces can we have for a database?
We can have many undo tablespaces in a database, but only one can be Active per instance.

In Oracle Real Application Clusters (RAC) enviornment, we need to have one Active undo tablespace per instance.
The UNDO_TABLESPACE parameter will be used for assigning a particular undo tablespace to an instance.

How to switch to a new undo tablespace?
You can switch from using one undo tablespace to another. Because the UNDO_TABLESPACE initialization parameter is a dynamic parameter, the ALTER SYSTEM SET statement can be used to assign a new undo tablespace.

The following statement switches to a new undo tablespace:
ALTER SYSTEM SET UNDO_TABLESPACE = undotbs_02;

Assuming undotbs_01 is the current undo tablespace, after this command successfully executes, the instance uses undotbs_02 in place of undotbs_01 as its undo tablespace.

If any of the following conditions exist for the tablespace being switched to, an error is reported and no switching occurs:

The tablespace does not exist

The tablespace is not an undo tablespace

The tablespace is already being used by another instance (in a RAC environment only)

The database is online while the switch operation is performed, and user transactions can be executed while this command is being executed. When the switch operation completes successfully, all transactions started after the switch operation began are assigned to transaction tables in the new undo tablespace.

The switch operation does not wait for transactions in the old undo tablespace to commit. If there are any pending transactions in the old undo tablespace, the old undo tablespace enters into a PENDING OFFLINE mode (status). In this mode, existing transactions can continue to execute, but undo records for new user transactions cannot be stored in this undo tablespace.

An undo tablespace can exist in this PENDING OFFLINE mode, even after the switch operation completes successfully. A PENDING OFFLINE undo tablespace cannot be used by another instance, nor can it be dropped. Eventually, after all active transactions have committed, the undo tablespace automatically goes from the PENDING OFFLINE mode to the OFFLINE mode. From then on, the undo tablespace is available for other instances (in an Oracle Real Application Cluster environment).

If the parameter value for UNDO TABLESPACE is set to '' (two single quotes), then the current undo tablespace is switched out and the next available undo tablespace is switched in. Use this statement with care because there may be no undo tablespace available.

The following example unassigns the current undo tablespace:
ALTER SYSTEM SET UNDO_TABLESPACE = '';

What is UNDO Retention?
Undo Retention refers to duration of retaining the undo data after a transaction.
After a transaction is committed, undo data is no longer needed for rollback or transaction recovery purposes. However, for consistent read purposes, long-running queries may require this old undo information for producing older images of data blocks. Furthermore, the success of several Oracle Flashback features can also depend upon the availability of older undo information. For these reasons, it is desirable to retain the old undo information for as long as possible.

Automatic undo management eliminates the complexities of managing rollback segment space and lets you exert control over how long undo is retained before being overwritten.

You can set the UNDO_RETENTION parameter to a low threshold value so that the system retains the undo for at least the time specified in the parameter.
What is Automatic UNDO Retention (10g New Feature)? Explain.
There is no parameter for this, Automatic UNDO Retention is enabled by default in 10g.
Oracle Database 10g automatically tunes a parameter called the undo retention period. The undo retention period indicates the amount of time that must pass before old undo information. Which means the undo information for committed transactions can be overwritten. The database collects usage statistics and tunes the undo retention period based on these statistics and on undo tablespace size. Provided that automatic undo management is enabled, the database automatically tunes the undo retention period as follows:
The current value for tuned undo retention can be viewed by following query.
SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TUNED_UNDORETENTION FROM V$UNDOSTAT;

For AUTOEXTEND undo tablespaces, the system retains undo for at least the time specified in this parameter, and automatically tunes the undo retention period to satisfy the undo requirements of the queries.
This could lead to excessive undo generation, to honour undo retention

For fixed- size undo tablespaces, the system automatically tunes for the maximum possible undo retention period, based on undo tablespace size and usage history, and ignores UNDO_RETENTION unless retention guarantee is enabled.

Automatic tuning of undo retention is not supported for LOBs. Because we dont store any undo information in undo tablespace for transactions on LOBs.

What is Gaurenteed UNDO Retention? Explain.
Oracle Database 10g lets you guarantee undo retention. In Oracle 10g Release 2, you can enable and disable undo retention.
When you enable this option, the database never overwrites unexpired undo data. That is undo data whose age is less than the undo retention period.

This option is disabled by default, which means that the database can overwrite the unexpired undo data to avoid failure of DML operations if there is not enough free space left in the undo tablespace.

By enabling the guarantee option, you instruct the database not to overwrite unexpired undo data even if it means risking failure of currently active DML operations. Therefore, use caution when enabling this feature.

To enable do the following against the undo tablespace.
ALTER TABLESPACE UNDOTBS RETENTION GUARANTEE;



A typical use of the guarantee option is when you want to ensure deterministic and predictable behavior of Flashback Query by guaranteeing the availability of the required undo data.

Explain V$UNDOSTAT, and usage?
This view is a replacement / enhancement for V$ROLLSTAT.

This view contains statistics for monitoring and tuning undo space. Use this view to help estimate the amount of undo space required for the current workload. The database also uses this information to help tune undo usage in the system. This view is meaningful only in automatic undo management mode.

The V$UNDOSTAT view is useful for monitoring the effects of transaction execution on undo space in the current instance. Statistics are available for undo space consumption, transaction concurrency, the tuning of undo retention, and the length and SQL ID of long-running queries in the instance.

Each row in the view contains statistics collected in the instance for a ten-minute interval. The rows are in descending order by the BEGIN_TIME column value. Each row belongs to the time interval marked by (BEGIN_TIME, END_TIME). Each column represents the data collected for the particular statistic in that time interval.
SELECT TO_CHAR(BEGIN_TIME, 'MM/DD/YYYY HH24:MI:SS') BEGIN_TIME,
TO_CHAR(END_TIME, 'MM/DD/YYYY HH24:MI:SS') END_TIME,
UNDOTSN, UNDOBLKS, TXNCOUNT, MAXCONCURRENCY AS "MAXCON",
MAXQUERYLEN, TUNED_UNDORETENTION
FROM v$UNDOSTAT;
The following table explains other useful columns of V$UNDOSTAT view
UNXPSTEALCNT The number of attempts when unexpired blocks were stolen from other undo segments to satisfy space requests
UNXPBLKRELCNT The number of unexpired blocks removed from undo segments to be used by other transactions
UNXPBLKREUCNT The number of unexpired undo blocks reused by transactions
EXPSTEALCNT The number of attempts when expired extents were stolen from other undo segments to satisfy a space requests
EXPBLKRELCNT The number of expired extents stolen from other undo segments to satisfy a space request
EXPBLKREUCNT The number of expired undo blocks reused within the same undo segments
SSOLDERRCNT The number of ORA-1555 errors that occurred during the interval
NOSPACEERRCNT The number of Out-of-Space errors
When the columns UNXPSTEALCNT through EXPBLKREUCNT hold non-zero values, it is an indication of space pressure.
If the column SSOLDERRCNT is non-zero, then UNDO_RETENTION is not properly set.
If the column NOSPACEERRCNT is non-zero, then there is a serious space problem.
In 10g DBA_HIST_UNDOSTAT view contains statistical snapshots of V$UNDOSTAT information.
Explain the DBA_UNDO_EXTENTS View, and usage?
DBA_UNDO_EXTENTS describes the extents comprising the segments in all undo tablespaces in the database. This view shows the status and size of each extent in the undo tablespace.
What are the various statuses for Undo Extents? Explain.
Transaction Status of the undo in the extent can be any of the following:
SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*)
FROM DBA_UNDO_EXTENTS GROUP BY STATUS;

ACTIVE - Undo Extent is Active, Used by a transaction.

EXPIRED - Undo Extent is expired (Exceeded the Undo Retention).

UNEXPIRED - Undo Extent will be required to honour UNDO_RETENTION.


Explain V$TRANSACTION, and usage?
V$TRANSACTION lists the active transactions in the system.

(a) The following columns together points to a transaction. (ie) The combination of the following should give unique transaction id for that database.

XIDUSN - Undo segment number
XIDSLOT - NUMBER Slot number
XIDSQN - NUMBER Sequence number

(b) The following columns explains the number of undo blocks / undo records used per transaction.
USED_UBLK - Number of undo blocks used
USED_UREC - Number of undo records used

In the case of transaction rollback, the above columns will give estimation about the number of undo blocks that needs to be rolled back.

The number of undo records and undo blocks (USED_UREC and USED_UBLK) decrease while the transaction is rolling back. When they reach 0, the transaction disappears from v$transaction.

The following query can be used to monitor the transaction rollback.
SELECT A.SID, A.USERNAME, B.XIDUSN, B.USED_UREC, B.USED_UBLK
FROM V$SESSION A, V$TRANSACTION B
WHERE A.SADDR=B.SES_ADDR;

(c) The STATUS following column explains the status of a transaction.

ACTIVE - Explains the transaction is active.

Before performing a normal/transactional shutdown, we can check this view to understand if we have any ACTIVE transactions.
SELECT XIDUSN, XIDSLT, XIDSEQ , SES_ADDR, STATUS FROM V$TRANSACTION;

Explain DBA_ROLLBACK_SEGS, and usage?
This view explains the various status of Undo Segments.
In RAC, we can also see the Instance number, and its associated tablespaces.
SELECT INSTANCE_NUM,TABLESPACE_NAME,SEGMENT_NAME,STATUS FROM DBA_ROLLBACK_SEGS;
In AUM DBA's dont have privilage to offline/online undo segments. And this is controled by SMON process. So this will be useful only in few scenarios, where we have interal errors with undo segments.
Do we have scripts to monitor the undo growth/usage of the database?
To understand the freespace with undo tablespace.
SELECT SUM(BYTES) FROM DBA_FREE_SPACE WHERE TABLESPACE_NAME='&UNDOTBS';

To understand state of the extents, space-used in the current undo tablespace.
SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*)
FROM DBA_UNDO_EXTENTS GROUP BY STATUS;

To understand the no of active transactions and its undo usage.
SELECT XIDUSN, XIDSLOT, XIDSQN, USED_UBLK FROM V$TRANSACTION WHERE STATUS='ACTIVE' ;


What are the possible causes for excessive undo growth?
There could be various causes for excessive undo growth. To start the diagnosis we need to understand the following.

Transactions with huge undo
It is obvious to see high undo usage when there are huge transactions.
If that is going to be the case this growth should be expected behaviour.

UNDO RETENTION
Higher undo retention will cause higher undo growth. Because we wont mark the undo extents as EXPIRED till the duration of undo retention.

Disabling autoextend on datafiles of active undo tablespace will reuse the UNEXPIRED extents when it has space crunch. It is a trade-off between undo retention and undo space.
If you wish to satisfy Undo Retention, swith on autoextend in undo tablespace datafiles.
SELECT FILE_ID, AUTOEXTENSIBLE FROM DBA_DATA_FILES WHERE
TABLESPACE_NAME='&UNDOTBS';
To make those datafile auto extensible, run the following command.
ALTER DATABASE DATAFILE '&FILE_ID' AUTOEXTEND ON;
If you wish to switch off auto extend and to reuse the UNEXPIRED space, do the following
ALTER DATABASE DATAFILE '&FILE_ID' AUTOEXTEND OFF;


State of undo extents
The status of the undo extents needs to be closely monitored.
There are few bugs with different releases where EXPIRED extents are not being reused.

(a) If good number of extents in UNEXPIRED status, it could be due to high undo_retention.
SELECT DISTINCT STATUS, SUM(BYTES), COUNT(*)
FROM DBA_UNDO_EXTENTS GROUP BY STATUS;

(b) There are few bugs associated with undo usage,

The unpublished bug 5442919 affects 10.2.0.3, 10.1.0.5 , 9.2.0.8 and its lesser patch levels, and the issue is fixed in 10.2.0.4.

Bug 5442919 EXPIRED EXTENTS NOT BEING REUSED
The above bug is unpublished, and the details can be reviewed through Note 5442919.8
And we also have Patch 5442919 for most of the latest versions. Kindly check metalink for patch availability.

How to resize the undo datafile?
It is possible to increase an undo datafile. For example, to increase the undo datafile size from 2000 MB to 3000MB we can do the following
ALTER DATABASE DATAFILE 39 RESIZE 3000M;
But it maynot be possible to resize to lesser value, when a undo datafile got auto extended to higher value. Even after the transactions are completed those undo extents will remain in EXPIRED status.
As the blocks are being used by undo extents, oracle will not allow you to resize, It will result in errors similar to following. In the following case the datafile size was 3500MB and a resize to 3000MB results in following errors.
SQL> alter database datafile 39 resize 3000m;
alter database datafile 39 resize 3000m
*
ERROR at line 1:
ORA-03297: file contains used data beyond requested RESIZE value

What is In Memory Undo?
In Oracle 10g, some of the top level DML's were performed in memory without any disk undo data. Which is termed as In Memory Undo (IMU). This can be controled by following hidden parameter.
_in_memory_undo=(true/false)
References
Note 135090.1 - Managing Rollback/Undo Segments in AUM (Automatic Undo Management)
Note 240746.1 - 10g NEW FEATURE on AUTOMATIC UNDO RETENTION
Note 4070480.8 - Bug 4070480 - Unexpired extents used when there is free space available in the UNDO tablespace
Note 5387030.8 - Bug 5387030 - Automatic tuning of undo_retention causes unusual extra space allocation
Note 5442919.8 - Bug 5442919 - Expired extents not being reused (ORA-30036)
Errors
ORA-1555 "snapshot too old (rollback segment too small)"
ORA-30036 unable to extend segment by %s in undo tablespace '%s'
ORA-3297 file contains blocks of data beyond requested RESIZE valu