Второ, мога ли да постигна подреждането, ако променя последователността да beNOCACHE, независимо от ORDER/NOORDER.
да, тъй като NOCACHE е ефективно подреден, тъй като принуждавате да записвате в таблицата sys.seq$ на всяко увеличение, което трябва да се сериализира и върху възли.
--
Бих оспорил приетия отговор в този възможен дубликат. има огромна разлика в CACHE + ORDER и NOCACHE в RAC. Вие не отричате кеша с 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.
т.е. КЕШ без поръчка. Сега започваме две сесии. Използвам RAC база данни с 4 възли 10.2.0.4 в този тест:
моят тестов скрипт е просто
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 срещу 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 МИНУТИ за същия работен комплект.
какво ще кажете за КЕШ + ПОРЪЧКА?
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 прави много ping между RAC възлите, но НЕ трябва да запишете неща обратно в seq$, докато размерът на кеша се изразходва, тъй като всичко се прави в паметта.
бих, ако бях на твое място, да задам подходящ размер на кеша (p.s. големият размер на кеша не натоварва паметта на кутията, тъй като oracle не съхранява всички числа в RAM; само текущото + крайното число) и помислете ПОРЪЧАЙ, ако е необходимо.
