El proceso de Capture de SharePlex leerá los cambios de los redo logsde la base de datos de origen, el orden de precedencia de este proceso de lectura es primero los redo logs en linea y luego los archivados, bajo circunstancias normales SharePlex es capaz de mantener el ritmo con Oracle y obtener todos los cambios de los redo logs en linea.
Si los redo logs cambian muy rápidamente por ejemplo, debido a un procedo en lotes muy grande, entonces SharePlex terminará leyendo de los redo logs archivados (archived log), para cambiarel comportamiento por defecto del proceso Capture y forzarlo a leer solo de los redo logs archivados (archived logs) se puede ajustar el parámetro SP_OCT_READ_ARC en el origen como se describe a continuación.
sp_ctrl>set param SP_OCT_READ_ARC 1
sp_ctrl>stop capture
sp_ctrl>start capture
He aquí algunas de las ventajas de configurar SharePlex de esta manera:
- Controlando que el proceso Capture lea los cambios de logs redo logs archivados en lugar de los en linea, se podrá controlar la contención del proceso LGWR, entonces se podría argumentar contención en el proceso ARCH ; dependiendo de las características de los dispositivos de almacenamiento que alberga los redo logs en linea y archivados podemos tomar ventaja de estas características para afinar solamente la lectura de los redo logs archivados (archived logs).
- Este parámetro es también util cuando se configura una base de datos física pasiva, Active Data Guard, etc, sin embargo esto se escapa de los alcances de esta solución.
Las siguientes son desventajas de configurar SharePlex de esta manera:
- El problema con esta solución es que el proceso Capture siempre irá detrás de Oracle y esto añadirá latencia en la replicación.
- Cuando se configura SharePlex de esta manera , es necesario asegurarse que el nivel de supplemental logging para llave primaria y llaves únicas está habilitado de tal manera que el proceso de Read no necesite ir a través del paso 2 mientras espera a que el proceso Capture se ponga al paso con Oracle.
