Значение Oracle Sequence не упорядочено

Возможный дубликат:
Oracle RAC и последовательности

У меня есть RAC Oracle, настроенный в моей локальной среде. Я проанализировал проблему с Sequnce, что число, генерируемое nextVal, не упорядочено. Предположим, что в первый раз, когда я получаю значение как 1, второй раз получить значение как 21 (я настроил последовательность, как с CACHE 20 и NOORDER).

В поиске я нашел решение, которое мне нужно для заказа последовательности. У меня вопрос, с которым лучше работать,

1) CACHE и ORDER

2) NOCACHE и ORDER

Я хочу знать, какой из вышеперечисленных вариантов лучше и почему?

Во-вторых, могу ли я добиться упорядочения, если я изменил последовательность как NOCACHE независимо от ORDER/NOORDER.

Спасибо

Ответ 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 большой размер кеша не загружает память ящика, так как оракул не сохраняет все числа в ОЗУ, только текущий + конечный номер ) и при необходимости рассмотрите ЗАКАЗ.