En segundo lugar, ¿puedo lograr el pedido si modifico la secuencia para que sea NOCACHE independientemente de ORDEN/NOORDER?
sí, ya que NOCACHE se ordena de manera efectiva, ya que está forzando una escritura en la tabla sys.seq $ en cada incremento, que también debe serializarse en los nodos.
--
Disputaría la respuesta aceptada en ese posible duplicado. hay una gran diferencia en CACHE + ORDEN y NOCACHE en RAC. No estás negando el CACHE con ORDEN; simplemente reduciendo su eficacia. Personalmente, vi que el rendimiento de una aplicación de nivel medio se degradaba drásticamente, ya que usaban NOCACHE en una secuencia y accedían a varios nodos a la vez. Cambiamos su secuencia a ORDER CACHE (ya que querían una orden entre rac). y el rendimiento mejoró drásticamente.
en resumen:la velocidad de la secuencia será de la más rápida a la más lenta como "CACHE NOORDER"->"CACHE ORDER" y muy MUY por detrás de "NOCACHE".
Esto también es fácilmente comprobable:
Así que comenzamos con una secuencia estándar:
SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;
Sequence created.
es decir, CACHE sin orden. Ahora encendemos dos sesiones. Estoy usando una base de datos RAC de 4 nodos 10.2.0.4 en esta prueba:
mi script de prueba es simplemente
select instance_number from v$instance;
set serverout on
declare
v_timer timestamp with time zone := systimestamp;
v_num number(22);
begin
for idx in 1..100000
loop
select daz_test.nextval into v_num from dual;
end loop;
dbms_output.put_line(systimestamp - v_timer);
end;
/
/
ahora ejecutamos la primera prueba (CACHE NOORDER):
SESSION 1 SESSION 2
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
+000000000 00:00:07.309916000 +000000000 00:00:07.966913000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
+000000000 00:00:08.430094000 +000000000 00:00:07.341760000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
entonces 7-8 segundos para seleccionar 100,000 iteraciones de la secuencia.
Ahora probemos NOCACHE (ORDER vs NOORDER es irrelevante para esto, ya que estamos forzando una escritura en seq$ para cada llamada a la secuencia).
SQL> alter sequence daz_test nocache;
Sequence altered.
SESSION 1 SESSION 2
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
+000000000 00:08:20.040064000 +000000000 00:08:15.227200000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
+000000000 00:08:30.140277000 +000000000 00:08:35.063616000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
así que saltamos de 8 segundos a 8 MINUTOS para el mismo conjunto de trabajo.
¿Qué hay de CACHÉ + PEDIDO?
SQL> alter sequence daz_test cache 100 order;
Sequence altered.
SQL> @run_test SQL> @run_test
INSTANCE_NUMBER INSTANCE_NUMBER
--------------- ---------------
2 1
+000000000 00:00:25.549392000 +000000000 00:00:26.157107000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
+000000000 00:00:26.057346000 +000000000 00:00:25.919005000
PL/SQL procedure successfully completed. PL/SQL procedure successfully completed.
así que, en resumen, para 100 000 recuperaciones de una sola llamada, CACHE NOORDER =8 segundos NOCACHE =8 minutos, CACHE ORDER =25 segundos
para el orden de caché, Oracle hace muchos ping entre los nodos RAC, pero NO tiene que volver a escribir cosas en seq $ hasta que se agote el tamaño del caché, ya que todo se hace en la memoria.
Si fuera usted, establecería un tamaño de caché adecuado (por ejemplo, un tamaño de caché alto no carga la memoria de la caja, ya que Oracle no almacena todos los números en la RAM; solo el número actual + final) y considere PEDIR si es necesario.
