ORACLE: DB Links

Cuando existen db_link creados sin db_domain y ahora la base tiene db_domain configurado, el db_link queda inaccesible. Para reconstruirlo con el db_domain, hay que eliminar temporalmente el db_domain desde el global_name.

• Select db_link from dba_db_link;
• enlace
• Select * from global_name;
• ORCL.WORLD
• Update sys.props$ set value$ = ‘ORCL’ where name = ‘GLOBAL_DB_NAME’;
• Commit;
• Select * from global_name;
• ORCL
• Drop public database link enlace;
• Alter database rename global_name to ORCL.WORLD;
• Select * from global_name;
• ORCL.WORLD
• Create public database link enlace …;
• Select db_link from dba_db_link;
• Enlace.world
• Si sólo hubiésemos hecho el alter database rename, no toma el cambio.

ORACLE: Migración de Vistas Materializadas

En dataware house es muy común la utilización de vistas materializadas.

En mi caso sucedió lo siguiente: por una migración de 9.2 a 11.2 de motor de base, se realizó una exportación/importación tradicional a nivel de esquemas. Estas herramientas incluyeron la metadata de las vistas materializadas. En el 9.2 tenía un db_domain configurado, mientras que la 11.2 estaba sin db_domain definido.

Para aquellas MV donde no tienen definido el tipo de refrescamiento (por defecto toma FORCE), o tienen explícitamente el tipo FORCE, la MV primero intenta hacer un FAST REFRESH y para ello se basa en el metadato almacenado en el campo dba_mviews.master_link, que como estamos hablando de una MV que viene migrada desde el 9.2 con db_domain, acarrea ese mismo valor. Como en la 11.2 quedaron los db_links con el dominio definido en NULL, al momento de hacer el refresh de la MV, esta intenta hacer un fast refresh utilizando el db_link informado en dba_mviews.master_link, en este caso no va a poder encontrar el mismo en la nueva base, y va a fallar por completo el refrescamiento. El problema de recrear por completo las MV, es principalmente el tiempo, por el volumen de datos que deben recuperar.

Una posible solución sería, eliminar la MV sin olvidar la cláusula PRESERVE TABLE. Esto hace que ante Oracle, la tabla contenedora de la vista, se vean como una tabla común y corriente ante el motor de la base. Luego, se volvería a contruír la MV con la cláusula ON PREBUILD TABLE, para que la tabla sea interpretada por el motor como una tabla contenedora de la nueva MV.

Las condiciones para poder efectuar satisfactoriamente esta maniobra, es que la MV sea exportada de un motor 9i en adelante, y que la nueva MV y la preexistente tabla tengan el mismo nombre y se encuentren en el mismo esquema.

TODO: debo probar qué pasa, si corrijo directamente la definición del db_link en el campo sys.snap$.mlink del diccionario de datos de la instancia, maniobra NO sugerida por metalink!

Languagesen>es GoogleDicCE

ninguno, imposible, prohibido, negativa, voto negativo, voto en contra, no

ORACLE: Undo TableSpace

Calculating the Space Requirements For Undo Retention

Given a specific UNDO_RETENTION parameter setting and some system statistics, the amount of undo space required to satisfy the undo retention requirement can be estimated using the following formula:

UndoSpace = UR * UPS + overhead

where:

• UndoSpace is the number of undo blocks
• UR is UNDO_RETENTION in seconds
• UPS is undo blocks for each second
• overhead is the small overhead for metadata (transaction tables, bitmaps, and so forth)

As an example, if UNDO_RETENTION is set to 2 hours, and the transaction rate (UPS) is 200 undo blocks for each second, with a 4K block size, the required undo space is computed as follows:

(2 * 3600 * 200 * 4K) = 5.8GBs.

Such computation can be performed by using information in the V$UNDOSTAT view. In the steady state, you can query the view to obtain the transaction rate. The overhead figure can also be obtained from the view.

V$UNDOSTAT

V$UNDOSTAT displays a histogram of statistical data to show how well the system is working. The available statistics include undo space consumption, transaction concurrency, and length of queries executed in the instance. You can use this view to estimate the amount of undo space required for the current workload. Oracle uses this view to tune undo usage in the system. This view is available in both automatic undo management mode and manual undo management mode.

Each row in the view keeps statistics collected in the instance for a 10-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. The first row of the view contains statistics for the (partial) current time period. The view contains a total of 1008 rows, spanning a 7 day cycle.

Column	Datatype	Description
BEGIN_TIME	DATE	Identifies the beginning of the time interval
END_TIME	DATE	Identifies the end of the time interval
UNDOBLKS	NUMBER	Represents the total number of undo blocks consumed. You can use this column to obtain the consumption rate of undo blocks, and thereby estimate the size of the undo tablespace needed to handle the workload on your system.
TXNCOUNT	NUMBER	Identifies the total number of transactions executed within the period
SSOLDERRCNT	NUMBER	Identifies the number of times the error ORA-01555 occurred. You can use this statistic to decide whether or not the UNDO_RETENTION initialization parameter is set properly given the size of the undo tablespace. Increasing the value of UNDO_RETENTION can reduce the occurrence of this error.
NOSPACEERRCNT	NUMBER	Identifies the number of times space was requested in the undo tablespace and there was no free space available. That is, all of the space in the undo tablespace was in use by active transactions. The corrective action is to add more space to the undo tablespace.

Extraído de los manuales oficiales de Oracle 9i r2. También se puede obtener más información en la nota ID 460481.1 de metalink.