Cuando para confirmar los cambios?

Question

Utilizando Oracle 10g, accede a través de Perl DBI, tengo una tabla con un par de decenas de millones de filas están actualizando un par de veces por segundo, mientras se leen de mucha más frecuencia de la forma de otro proceso.

Pronto la frecuencia de actualización va a aumentar en un orden de magnitud (tal vez dos).Alguien sugirió que la comisión de cada N de las actualizaciones en lugar de después de cada actualización ayudará al rendimiento.

Tengo un par de preguntas:

• Tendrá que ser más rápido o más lento o depende (planificación de referencia tanto en forma, tan pronto como se puede obtener una decente simulación de la nueva carga)
• Por qué va a ayudar o dificultar el rendimiento.
• Si "depende..." , ¿en qué ?
• Si ayuda ¿cuál es el mejor valor de N ?
• Por qué no puede mi local DBA tiene una útil recta respuesta cuando necesito uno?
  (En realidad, yo sé la respuesta a que uno) :-)

EDITAR:

@codeslave :Gracias, por cierto de perder uncommited cambios no es un problema, yo no borrar los datos originales utilizados para la actualización hasta que estoy seguro de que todo está muy bien , por cierto señora de la limpieza ¿ desconecta el servidor, dos veces :-)

Algunas google mostró podría ayudar debido a la cuestión relativa a la reversión de segmentos, pero yo todavía no sé de un la regla del pulgar para N cada pocas decenas ?cientos?mil ?

@diciu :Gran info, definitivamente, voy a ver en que.

Answer 1

Una confirmación de los resultados en Oracle materia de la escritura en el disco - es decir,en el archivo redo log para que lo que la transacción está confirmada ha hecho, puede ser recuperable en caso de un fallo de alimentación, etc.La escritura en el archivo es más lenta que la escritura en la memoria para una confirmación será más lento que si se realiza para muchas operaciones en una fila en lugar de un conjunto de unieron actualizaciones.

En Oracle 10g hay una asincronía en el commit que hace que sea mucho más rápido, pero menos fiable: https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-6158695.html

PS estoy seguro de que, en un escenario que he visto en una determinada aplicación, cambiar el número de unieron actualizaciones a partir de 5K a 50K hace más rápido por un orden de magnitud (10 veces más rápido).

Answer 2

La reducción de la frecuencia de la cometa será sin duda la velocidad de las cosas, sin embargo como son la lectura y escritura en esta tabla con frecuencia existe el potencial para los bloqueos.Sólo usted puede determinar la probabilidad de que la misma los datos que se actualizan al mismo tiempo.Si la probabilidad de que este es bajo, compromete cada 50 filas y seguimiento de la situación.Prueba y error, yo tengo miedo :-)

Answer 3

Así como la reducción de la confirmación de la frecuencia, también se debe considerar la realización masiva de las actualizaciones en lugar de individuales.

Answer 4

Si usted "no borrar los datos originales utilizados para la actualización de hasta [que son] de que todo está bien", entonces ¿por qué no eliminar todos los incremental se compromete en el medio, y de reversión si hay un problema?Parece que efectivamente han construido una transacción de sistemas en la parte superior de las transacciones.

Answer 5

@CodeSlave tu pregunta es contestada por @stevechol , si puedo eliminar TODOS los incremental se compromete habrá bloqueos.Supongo que si no hay nada mejor que viene voy a seguir su consejo escoger un número al azar , controlar la carga y ajustar en consecuencia.Mientras que la aplicación de @diciu twaks.

PS:la transacción en la parte superior de la transacción es sólo accidental, puedo obtener los archivos que se utilizan para las actualizaciones a través de FTP, y en lugar de eliminarlos de inmediato me puse un cron job para los elimina una semana más tarde (si no hay nadie en el uso de la aplicación se ha quejado) eso significa que si algo va mal, tengo una semana para la captura de los errores.

Answer 6

Más Rápido O Más Lento?

Probablemente será un poco más rápido.Sin embargo, se corre un mayor riesgo de correr en los interbloqueos, perder los cambios no confirmados de que algo catastrófico ocurra (señora de la limpieza desconecta el servidor), FUD, Fuego, Azufre, etc.

¿Por qué iba a ayudar?

Obviamente menos operaciones de confirmación, que a su vez significa un menor número de escrituras en disco, etc.

DBA y respuestas directas?

Si fuera fácil, no necesita uno.