Oracle RAC и последовательности

Question

У меня есть различные приложения баз данных, которые используют последовательности, я переношу эти приложения в Oracle RAC от 10g без RAC до 11g с RAC. Мне нужны упорядоченные последовательности, и пробелы переносятся.

Я думаю о последовательностях кеша с порядком, я не знаю, каков эффект в производительности. Как вы думаете, это хороший вариант? Каковы ваши опыты с последовательностями и RAC?

Спасибо,

Answer 1

Что именно вы имеете в виду под «заказал» в этом контексте?

По умолчанию каждый узел кластера имеет отдельный кэш порядковых номеров. Таким образом, узел 1 может выдавать значения 1-100, тогда как узел 2 передает значения 101-200. Значения, возвращаемые с одного узла, являются последовательными, но сеанс A на узле 1 может получить значение 15, тогда как сеанс B на узле 2 получает значение 107, поэтому значения, возвращаемые через сеансы, выглядят не по порядку.

Если вы укажете, что последовательность должна быть заказана, вы в основном побеждаете цель кеша последовательности, так как Oracle теперь должна связываться между узлами каждый раз, когда вы запрашиваете новое значение последовательности. Это может создать достойный объем служебных расходов. Если вы используете последовательность как своего рода метку времени, это может быть необходимо, но это обычно нежелательно.

Разница накладных расходов в практическом плане будет очень зависимой от приложения - она ​​будет неизмеримо малой для некоторых приложений и значительной проблемой для других. Также будет способствовать количество узлов RAC, скорость межсоединения и количество трафика межсетевого соединения. И поскольку это прежде всего проблема масштабируемости, практический эффект будет ограничивать, насколько хорошо масштабируется ваше приложение, которое по своей сути является нелинейным. Удвоение объема транзакции, обрабатываемого вашим приложением, будет намного больше, чем удвоить накладные расходы.

Если вы укажете NOCACHE, выбор ORDER или NOORDER в основном не имеет значения. Если вы укажете ORDER, выбор CACHE или NOCACHE в основном не имеет значения. Таким образом, CACHE NOORDER является наиболее эффективным, остальные три относительно взаимозаменяемы. Все они будут включать координацию между узлами и сетевой трафик каждый раз, когда вы запрашиваете значение последовательности, которое, очевидно, является потенциальным узким местом.

Обычно желательно добавить столбец TIMESTAMP в таблицу, чтобы сохранить фактическую метку времени, а не полагаться на последовательность, чтобы обеспечить порядок метки времени.

Answer 2

Последовательности не предназначены для заказа со значением. Проверьте это link to a response by Tom Kyte и некоторые его последующие ответы в той же теме.

Answer 3

Резюме

CACHE может значительно повысить производительность последовательности, которая использует ORDER, даже на RAC.

Это все еще не так быстро, как NOORDER, но это может быть удивительно близко. Особенно, если последовательность используется только на одном из узлов за раз.

Test Case

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 

Test Case Notes

Мои результаты были получены на RAC в 2-узла. Отображается только один набор результатов, но я несколько раз запускал тестовый пример в разных базах данных и получал почти одинаковые результаты.

Я также провел тесты одновременно, на разных узлах. CACHE по-прежнему значительно улучшает ORDER, хотя CACHE NOORDER более чем в 2 раза быстрее, чем CACHE ORDER.

Я также заметил подобное поведение в других средах в прошлом, хотя у меня нет никаких результатов для них.

Почему?

Я не понимаю, почему CACHE будет иметь такую ​​большую разницу, если используется ORDER. Количество времени на создание номера должно быть неактуальным по сравнению со временем отправки данных по сети. Это заставляет меня думать, что либо Oracle использует плохой алгоритм, либо мой тестовый пример неверен. (Если кто-нибудь может найти проблему с моим тестовым случаем, пожалуйста, дайте мне знать.)

Также в этом ответе обсуждается только время генерации последовательности. Могут быть другие преимущества использования NOORDER. Например, сокращение индекса, как описано here.