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

Ответ 1

Точно, что вы подразумеваете под "упорядоченным" в этом контексте?

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

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

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

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

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

Ответ 2

Резюме

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

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

Контрольный пример

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

Замечания по тестированию

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

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

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

Почему?

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

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

Ответ 3

Последовательности не предназначены для упорядочения со значением. Проверьте ссылку на ответ Tom Kyte и некоторые его ответы в этом же потоке.