Pero para hacer eso pongo set newname desde principio

He leido que los “alias” dan algo de problemas. Pero bueno, pienso que falló y como de antemano sabes que puede pasar en ASM que no use el optimizador, pues después que falló, sería algo así como:

$> asmcmd
ascmd> cd “+DG_DATA/BST/”
asmcmd> mkalias system.262.688916473 system.dbf
…
asmcmd> mkalias users01.757.75757575 users01.dbf

bueno un poco tedioso, pero con un vi y v$datafile se hace más sencillo. Y despues volver a lanzar :

RUN {
ALLOCATE AUXILIARY CHANNEL T1 DEVICE TYPE DISK;
SET UNTIL SCN 536418;
DUPLICATE TARGET DATABASE TO BST
LOGFILE
GROUP 1 (’+DG_DATA/bst/redo01.dbf’) SIZE 50M,
GROUP 2 (’+DG_DATA/bst/redo02.dbf’) SIZE 50M,
GROUP 3 (’+DG_DATA/bst/redo03.dbf’) SIZE 50M;
}

No se si realmente RMAN se de cuenta de estos alias, por eso si tienes la oportunidad y lo puedes probar te lo agradecería, y además quería saber si lo habías hecho alguna vez .
Nada, era solo una idea, y por probar cosas.

En 10g que yo sepa si no ves ningun mismatch en v$sql_shared_cursor puede ser por los histogramas ó esta usando dynamic sampling la query.

–
LSC

No entiendo muy bien lo de mkalias.

Esto es lo que ejecutaba a princpio (hay menos datafiles en este caso para simplificar pero realmente habia 180 datafiles):

RUN {
ALLOCATE AUXILIARY CHANNEL T1 DEVICE TYPE DISK;
SET UNTIL SCN 536418;
DUPLICATE TARGET DATABASE TO BST
LOGFILE
GROUP 1 (‘+DG_DATA/bst/redo01.dbf’) SIZE 50M,
GROUP 2 (‘+DG_DATA/bst/redo02.dbf’) SIZE 50M,
GROUP 3 (‘+DG_DATA/bst/redo03.dbf’) SIZE 50M;
}

Si este duplicate falla por quedar sin espacio si ejecutas otra vez los comandos de arriba el RMAN volvera a restaurar de cero.

Sin embargo si usas el siguiente comando:

RUN {
ALLOCATE AUXILIARY CHANNEL T1 DEVICE TYPE DISK;
SET UNTIL SCN 536418;
SET NEWNAME FOR DATAFILE 1 TO ‘+DG_DATA/BST/system01.dbf’;
SET NEWNAME FOR DATAFILE 2 TO ‘+DG_DATA/BST/undotbs101.dbf’;
SET NEWNAME FOR DATAFILE 3 TO ‘+DG_DATA/BST/sysaux01.dbf’;
SET NEWNAME FOR DATAFILE 4 TO ‘+DG_DATA/BST/undotbs201.dbf’;
SET NEWNAME FOR DATAFILE 5 TO ‘+DG_DATA/BST/users01.dbf’;
SET NEWNAME FOR TEMPFILE 1 TO ‘+DG_DATA/BST/temp01.dbf’;
DUPLICATE TARGET DATABASE TO BST
LOGFILE
GROUP 1 (‘+DG_DATA/bst/redo01.dbf’) SIZE 50M,
GROUP 2 (‘+DG_DATA/bst/redo02.dbf’) SIZE 50M,
GROUP 3 (‘+DG_DATA/bst/redo03.dbf’) SIZE 50M;
}

RMAN detecta los duplicados y salta cuando ve que esta restaurado por ejemplo system01.dbf.

En que paso crees que deberia de poner el mkalias En el segundo reintento?

Un saludo

–
LSC

No he probado lo que dices (ahora no tengo clientes con ASM, y lo casero no sería buena prueba), pero una pregunta ¿Probaste usar los alias de los ficheros ASM? Igual estoy diciendo una tontería, porque no tengo todos los detalles de lo que hiciste, pero con mkalias de asmcmd “creo” que es lo mismo, al final están en V$ASM_ALIAS. Hay un ejemplo en utilities:

ASMCMD> mkalias ‘+DG_DATA/BST/system01.454.555341961′ ‘+DG_DATA/BST/system01.dbf’

Si no lo has probado, y lo quieres probar, me cuentas a ver si realmente funciona. Yo no tengo donde . Y si ya lo has probado y no funciona, pues nada, te agradecería que me lo dijeras.

Un saludo

John Ospino Rivas

ORA-00600: internal error code, arguments: [kkslgbv0]

Después de analizar el .trc se ve cuando se intenta “alocar” esa variable y de ese nuevo parent cursor. ¿Qué pasa? que si a esto le añades que usas CURSOR_SHARING=SIMILAR, tienes la Library Cache un poco “petada” pues salta.
El kksl es para Shring Cursors, la G no se que será pero bv0 lo más probable es que sea Bind Variables. El caso es que en el momento de hacer un hard parse, saltaba.
En fin, solución fresca:
_optim_peek_user_binds=FALSE

y se acabó el bind peeking.

Lo único que me faltó averiguar (y por esto pregunto) es donde está dentro de la shared_pool ¿Si lo sabes, te lo agradecería? lo estuve intendo en x$ksmss, pero nop, no entendi donde está, porque existe el parámetro:
_xpl_peeked_binds_log_size
Su descripción es:
maximum bytes for logging peeked bind values for V$SQL_PLAN (0 = OFF)

Pero pienso que puede existir un valor que determine la cantidad de tamaño máximo para las binds. Pero, ¿Será que este valor solo tiene que ver con la cantidad de “parent cursor” que puedas tener? y bueno si es ASMM, hay un poco de lio.

Bueno te dejo mis inquietudes de justo ayer. Que leí este post intentando buscar posible comportamientos por deshabilitar el Bind Peeking con CURSOR_SHARING=SIMILAR. Y además aprovecho para mandarte un saludo.

John Ospino

PD: CURSOR_SHARING=SIMILAR un poco caca, he visto como una contulta tiene mas de 36000!!! chils cursors. Ojo, no es broma, más treinta y seis mil, select count(8) from v$sql where sql_id = ‘XXX’. Yde momento sin saber el porque crea otro child, ya que en v$sql_shared_cursor no sale nada.

El problema era leian tanto a disco (habias varias sesiones con consultas de informes a tablas de 1200 millones registros con full scan) con cache de filesystem activado que el proceso de kswapd no daba a basto y cada vez que tenia que swapear la maquina se quedaba totalmente “colgada”, eso proceso lo tenia que hacer cada 1 ó 2 minutos por lo tanto empezaba a encolar peticiones.

El arreglo es muy facil, activar Direct I/O y no usar cache de filesystem para evitar el efecto de “double buffering”.