Oracle RAC y secuencias

Question

Tengo varias aplicaciones de bases de datos que usan secuencias, estoy migrando estas aplicaciones a Oracle RAC de 10g sin RAC a 11g con RAC. Necesito secuencias ordenadas y se toleran las lagunas.

Estoy pensando en secuencias de caché con orden, no sé cuál es el efecto en el rendimiento. ¿Crees que esta es una buena opción? ¿Cuál es su experiencia con secuencias y RAC?

Gracias,

Answer 1

Exactamente lo qué se refiere con "ordenados" en este contexto?

De forma predeterminada, cada nodo del clúster tiene un caché separado de números de secuencia. Por lo tanto, el nodo 1 puede estar distribuyendo los valores del 1 al 100, mientras que el nodo 2 está distribuyendo los valores del 101 al 200. Los valores devueltos por un solo nodo son secuenciales, pero la sesión A en el nodo 1 puede obtener un valor de 15, mientras que la sesión B en el nodo 2 obtiene un valor de 107, por lo que los valores devueltos en las sesiones aparecen desordenados.

Si especifica que la secuencia tiene que ser ordenada, básicamente está derrotando el propósito de la secuencia de caché porque Oracle ahora tiene que comunicarse entre los nodos cada vez que solicita un nuevo valor de secuencia. Eso tiene el potencial de crear una cantidad decente de gastos generales de rendimiento. Si está utilizando la secuencia como una especie de marca de tiempo, esa sobrecarga puede ser necesaria, pero en general no es deseable.

La diferencia de gastos generales en términos prácticos va a ser altamente dependiente de la aplicación: será inmensurablemente pequeña para algunas aplicaciones y un problema importante para otras. La cantidad de nodos RAC, la velocidad de la interconexión y la cantidad de tráfico de interconexión también contribuirán. Y dado que esto es principalmente un problema de escalabilidad, el efecto práctico limitará la adecuación de su aplicación, que es inherentemente no lineal. Duplicar el volumen de transacción que maneja su aplicación va a ser más del doble de la sobrecarga.

Si especifica NOCACHE, la elección de ORDER o NOORDER es básicamente irrelevante. Si especifica ORDER, la elección de CACHE o NOCACHE es básicamente irrelevante. Así que CACHE NOORDER es de lejos el más eficiente, los otros tres son relativamente intercambiables. Todos van a involucrar la coordinación entre nodos y el tráfico de la red cada vez que solicite un valor de secuencia que es, obviamente, un posible cuello de botella.

Por lo general, sería preferible agregar una columna TIMESTAMP a la tabla para almacenar la marca de tiempo real en lugar de confiar en la secuencia para proporcionar una orden de fecha y hora.

Answer 2

Las secuencias no están diseñadas para ordenarse con un significado. Mira esto link to a response by Tom Kyte y algunas de sus respuestas de seguimiento en el mismo hilo.

Answer 3

Resumen

CACHE puede mejorar significativamente el rendimiento de una secuencia que utiliza ORDER, incluso en el RAC.

Todavía no es tan rápido como NOORDER, pero puede ser sorprendentemente cercano. Especialmente si la secuencia solo se usa en uno de los nodos a la vez.

caso de prueba

SQL> create sequence cache_order cache 20 order; 

Sequence created. 

SQL> create sequence cache_noorder cache 20 noorder; 

Sequence created. 

SQL> create sequence nocache_order nocache order; 

Sequence created. 

SQL> create sequence nocache_noorder nocache noorder; 

Sequence created. 

SQL> set timing on 
SQL> declare 
    2  v_temp number; 
    3 begin 
    4  for i in 1 .. 100000 loop 
    5    v_temp := cache_order.nextval; 
    6  end loop; 
    7 end; 
    8/

PL/SQL procedure successfully completed. 

Elapsed: 00:00:08.44 
SQL> declare 
    2  v_temp number; 
    3 begin 
    4  for i in 1 .. 100000 loop 
    5    v_temp := cache_noorder.nextval; 
    6  end loop; 
    7 end; 
    8/

PL/SQL procedure successfully completed. 

Elapsed: 00:00:07.46 
SQL> declare 
    2  v_temp number; 
    3 begin 
    4  for i in 1 .. 100000 loop 
    5    v_temp := nocache_order.nextval; 
    6  end loop; 
    7 end; 
    8/

PL/SQL procedure successfully completed. 

Elapsed: 00:00:35.15 
SQL> declare 
    2  v_temp number; 
    3 begin 
    4  for i in 1 .. 100000 loop 
    5    v_temp := nocache_noorder.nextval; 
    6  end loop; 
    7 end; 
    8/

PL/SQL procedure successfully completed. 

Elapsed: 00:00:35.10 

caso de prueba Notas

Mis resultados se obtuvieron en un RAC de 2 nodos. Solo se muestra un conjunto de resultados, pero ejecuté el caso de prueba varias veces, en diferentes bases de datos, y obtuve resultados casi idénticos.

También realicé las pruebas al mismo tiempo, en diferentes nodos. El CACHE aún mejora significativamente ORDER, aunque el CACHE NOORDER es más del doble de rápido que CACHE ORDER.

También he notado un comportamiento similar en otros entornos en el pasado, aunque no tengo ningún resultado para ellos.

¿Por qué?

No entiendo por qué CACHE marcaría una gran diferencia cuando se usa ORDER. La cantidad de tiempo para generar un número debe ser irrelevante en comparación con el tiempo para enviar datos a través de una red. Esto me hace pensar que Oracle está utilizando un algoritmo pobre, o mi caso de prueba está equivocado. (Si alguien puede encontrar un problema con mi caso de prueba, hágamelo saber).

Además, esta respuesta solo trata el tiempo para generar la secuencia. Puede haber otros beneficios de usar NOORDER. Por ejemplo, contención del índice reducido, como se describe here.