Ответ 1
Во-вторых, могу ли я добиться упорядочения, если я изменю последовательность, которая будет NOCACHE независимо от ORDER/NOORDER.
да, поскольку NOCACHE эффективно упорядочивает, так как вы заставляете писать таблицу sys.seq $на каждом приращении, который также должен сериализоваться и над узлами.
-
Я бы оспаривал принятый ответ в этом возможном дубликате. есть огромная разница в CACHE + ORDER и NOCACHE в RAC. Вы не отрицаете CACHE с ORDER; просто снижая его эффективность. Я лично видел, что производительность приложения среднего уровня резко ухудшается, поскольку они использовали NOCACHE в последовательности и сразу обращались к нескольким узлам. Мы переключили их последовательность на ORDER CACHE (так как они хотели получить растровый порядок). и производительность значительно улучшилась.
вкратце: скорость последовательности будет от самого быстрого до самого медленного, как "CACHE NOORDER" → "CACHE ORDER" и путь пути за "NOCACHE".
Это легко проверить:
Итак, мы начинаем со стандартной последовательности:
SQL> create sequence daz_test start with 1 increment by 1 cache 100 noorder;
Sequence created.
т.е. CACHE без заказа. Теперь мы запускаем две сессии. Я использую базу данных 4 node RAC 10.2.0.4 в этом тесте:
мой тест script просто
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;
/
/
теперь мы запускаем первый тест (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.
так 7-8 секунд, чтобы выбрать 100 000 итераций последовательности.
Теперь попробуйте NOCACHE (ORDER vs NOORDER для него нерелевантно, поскольку мы заставляем писать seq $для каждого вызова последовательности).
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.
поэтому мы перепрыгнули с 8 секунд до 8 МИНУТ за тот же рабочий набор.
как насчет CACHE + ORDER?
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.
поэтому в резюме для 100 000 выборок одного вызова CACHE NOORDER = 8 секунд NOCACHE = 8 минут CACHE ORDER = 25 секунд
для порядка кэша, oracle делает много пинговых сообщений между узлами RAC, но DOESNT должен написать материал обратно до seq $до тех пор, пока размер кэша не будет исчерпан, поскольку все это сделано в памяти.
i, если бы я был вами, установите соответствующий размер кеша (ps большой размер кеша не загружает память ящика, так как оракул не сохраняет все числа в ОЗУ, только текущий + конечный номер ) и при необходимости рассмотрите ЗАКАЗ.