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

Сводка

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

Примечания к контрольному кейсу

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

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

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

Почему?

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

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

Answer 3

Последовательности не предназначены для упорядочения по смыслу. Посмотрите эту ссылку на ответ Тома Кайта и некоторые его последующие ответы в той же теме.