Hola a todos, hoy queríamos comentar con vosotros una cosa muy curiosa que nos ha pasado con una migración mediante expdp/impdp en 19c.
La migración consiste en una migración lógica de datos entre una versión 11 y una 19. El export lo habíamos realizado con parallel 8 para agilizar los tiempos de la migración y al realizar el import con los mismos parámetros nos encontramos que ha tardado mucho más de lo esperado. Para ver los tiempos que utilizaba cada uno de los pasos hemos utilizado el parámetro LOGTIME=ALL, que incluye en el fichero de log la información que necesitamos. Al revisar de nuevo el import vemos lo siguiente:
Solo en el paso de crear los procedimientos almacenados ha tardado 2 horas y media!!??😨😨
Veamos por qué está tardando
Al revisar las esperas de las sesiones del import vemos que se quedan en Library Cache Lock, pudiendo llegar a tardar casi 200 segundos para un solo procedimiento y cuando hay muchos los tiempos se alargan más de la cuenta. Viendo que las únicas sesiones en la base de datos son las del import hemos probado a realizar el import con PARALLEL=1 para ver el comportamiento. En este caso, el paso de los procedimientos se ha resuelto en muy poco tiempo pero el import de las tablas hace que nos salgamos de la ventana de migración, por lo que tenemos un problema.
Investigando en metalink hemos encontrado esta nota:
‘Library Cache Lock’ (Cycle) Seen During DataPump Import in 12.2 RAC Environment (Doc ID 2407491.1)
Parece que es un fallo que se produce desde 12.2 en el mecanismo de bloqueo en los procesos de import. Al ver las posibles soluciones vemos:
1/ Run metadata import with parallel=1 (default).
– or –
2/ Disable S-Optimization using:
ALTER SYSTEM SET "_lm_share_lock_opt"=FALSE SCOPE=SPFILE SID='*';
and restart all RAC instances.
La opción 1 ya hemos visto que no es viable, por lo que pasamos a probar la opción 2.
Retomando la migración
Realizamos el cambio del parámetro y reiniciamos las dos instancias. Una vez hecho volvemos a probar el import con parallel 8 y el resultado es:
12-AUG-21 14:53:54.121: Processing object type DATABASE_EXPORT/SCHEMA/PROCEDURE/PROCEDURE
12-AUG-21 14:53:56.577: Processing object type DATABASE_EXPORT/SCHEMA/PROCEDURE/GRANT/OWNER_GRANT/OBJECT_GRANT
El import de los procedimientos ha tardado menos de 3sg!!
Con estos tiempos ya es posible realizar la migración sin problemas, por lo que nos guardamos el parámetro para futuras migraciones. Una vez terminada la migración volvemos a dejar el parámetro como estaba anteriormente:
alter system reset "_lm_share_lock_opt" scope=spfile sid='*';
El cambio requiere reinicio.
Esperamos que os sea de utilidad la entrada y que os ahorre algún susto en el futuro.
Si no quieres perderte nuestras publicaciones, suscríbete a nuestra newsletter. Con un email al mes estarás informado de todo nuestro contenido.
¿Aún no conoces Query Performance? Descubre cómo puede ayudarte en tu entorno Oracle. Más información en su página de LinkedIn.
Sígue a GPS en LinkedIn
Si prefieres que nosotros realicemos la migración por vosotros, no dudéis en contactar sin compromiso en nuestra página de contacto. Gracias.
Más info sobre el export/import: https://oracle-base.com/articles/10g/oracle-data-pump-10g