gran movimiento de datos

Me gustaría mover miles de millones de filas de schema1.table1 a nuevo schema2.table2 donde table2 es refactorizado de table1. Por lo tanto, su estructura de tabla es diferente. tanto table1 como table2 están particionadas pero table2 está vacío. Ambos esquemas están en el mismo oráculo DB. ¿Cuál es la forma eficiente de realizar esta migración de datos? ¿Desea realizar una confirmación solo al final o optar por una confirmación incremental? es decir, digamos que la migración de datos falla después de completar el 99% del trabajo, lo que tomó algunas horas. ¿Retrocede ahora? Si realiza la confirmación incremental, ¿cómo maneja la falla?

En paralelo INSERT APPENDcon la NOLOGGINGque sería la manera de hacer esto, a continuación, al igual que con todas las operaciones NOLOGGING, tomar una copia de seguridad inmediatamente después de terminar. Marque los índices inutilizables primero, deshabilite las restricciones, modifique la tabla, realice la operación, luego vuelva a habilitar las restricciones, etc.

Append hace que Oracle siempre tome espacio libre por encima de la marca de límite superior actual, por lo que no es eficiente en la reutilización del espacio en el segmento, pero evita jugar con la lista de freel y la sobrecarga de UNDO. Si tiene que comenzar de nuevo por alguna razón TRUNCATE, no lo haga DELETE.

En cuanto a la confirmación incremental, dependerá de cómo se segmenten sus datos, ¿puede decir fácilmente mover el valor de un mes a la vez (por ejemplo, el esquema de partición es el mismo en origen y destino)? Porque recuerda que si necesitas satisfacer algún predicado, eso obviamente te ralentizará. Realice una prueba para asegurarse de que la operación no fallará lógicamente (por ejemplo, tipos de datos incompatibles en el origen y el destino), luego asigne recursos suficientes y simplemente realice una transacción. ¡Buena suerte!

si el esquema de partición es el mismo (los datos de la partición a en la tabla 1 van a la partición a en la tabla 2, etc.), entonces iría a varias sesiones y cada sesión agregaría sus datos en su 'propia' partición. Esto evita muchos bloqueos y tiene la mejor velocidad. Dependiendo del hardware, puede llenar las tarjetas HBA hasta su cuello. Un commit para cada partición, suponiendo más de unas pocas filas para cada partición, no será un problema y ciertamente lo haría. Suponiendo que la aplicación está inactiva durante la migración, el respaldo es simple: no cambie la aplicación y trunca las particiones de table2 antes de volver a intentarlo, al menos para aquellas partes donde la aplicación cambió los datos antes de que pueda tener lugar una segunda ejecución.

espero que esto ayude