Каковы недостатки выбора более высокой точности времени в Oracle?

Ответ 1

Нет недостатков, используйте временную метку (9), если это имеет смысл.

Временная метка (9) и временная метка (1) используют одинаковое пространство, а их производительность идентична. Я мог найти только один случай, когда была разница в производительности, и в этом случае временная метка (9) была на самом деле быстрее, чем временная метка (1).

(Я пощажу вам множество строк скучного кода, вставляющих в столбцы timestamp (1) и timestamp (9), и сравнивая разные операции над ними.)

Это демонстрирует, что они используют одно и то же пространство (вставляя множество значений и сравнивая dba_segments):

--Create tables with timestamps and populate them with the same data (with different precision)
--Set initial and next to a low value so we can closely check the segment size)
create table timestamp1 (t1 timestamp(1), t2 timestamp(1), t3 timestamp(1), t4 timestamp(1), t5 timestamp(1))
storage(initial 65536 next 65536);

insert into timestamp1
select current_timestamp(1), current_timestamp(1), current_timestamp(1), current_timestamp(1), current_timestamp(1)
from dual connect by level <= 100000;

create table timestamp9 (t1 timestamp(9), t2 timestamp(9), t3 timestamp(9), t4 timestamp(9), t5 timestamp(9))
storage(initial 65536 next 65536);

insert into timestamp9
select current_timestamp(9), current_timestamp(9), current_timestamp(9), current_timestamp(9), current_timestamp(9)
from dual connect by level <= 100000;


--Segment size is identical
select segment_name, bytes from dba_segments where segment_name in ('TIMESTAMP1', 'TIMESTAMP9');

--SEGMENT_NAME   BYTES
--TIMESTAMP1     8388608
--TIMESTAMP9     8388608

В этом случае временная метка (9) выполняется быстрее при использовании current_timestamp, которую вам, вероятно, придется использовать в какой-то момент для генерации данных. Но мы говорим только о разнице между 0.175 и 0.25 секунд на моем медленном рабочем столе, чтобы генерировать отметки времени в 100 КБ. Я не уверен, почему timestamp (9) работает быстрее, возможно, временные метки всегда генерируются как временная метка (9), а затем округляются до других значений?

--current_timestamp(9) is slightly faster than current_timestamp(1)
select count(*) from
(
  select *
  from dual
  --where current_timestamp(9) = current_timestamp(9)
  where current_timestamp(1) = current_timestamp(1)
  connect by level <= 100000
);

EDIT: разница в производительности существует в 10g, но не 11g.

Ответ 2

Проблема - производительность. Вы должны торговать с точностью. Меньшие числа считываются и записываются с меньшим количеством инструкций процессора. Инструкция CPU занимает меньше, чем наносекунда, но если ваш сервер обслуживает миллионы транзакций, вы можете обнаружить некоторое снижение производительности, и это предполагает, что вы принимаете меньшую точность или даже отсутствие точности (округление всех временных меток до секунд вполне приемлемо в большинстве сценариев, даже в банковской сфере).

Но если вы, почему-то, т.е. ведение журнала в режиме реального времени, требуется больше точности, вы вынуждены использовать более высокую точность и, следовательно, снижать производительность. Если ваш сервер не обрабатывает большое количество tps, у вас почти нет влияния на производительность, но если вам не нужна точность, вы теряете память.

Надеюсь, что это поможет. Если вы хотите поделиться с нами своими требованиями к БД, мы можем помочь вам выбрать лучший компромисс.

Ответ 3

Разница заключается не в техническом использовании типа данных Timestamp, а в приложении. FERC и NERC часто требуют определенной точности при использовании в приложениях с меткой critical infrastructure, и поэтому они будут использовать максимально возможную точность.

Конечно, для того, чтобы костюмы были довольны своей последовательностью записей событий, часто требуется сделать больше, чем выложено CIP-002 through CIP-009

Ответ 4

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

• Вы усекаете данные перед их отображением?
• Является ли это требованием соблюдения и в основном читается?
• Преобразуете ли этот столбец в строку, чтобы сравнить ее с другим столбцом?
• Это требование для аудита или для захвата заказа?

Не слишком беспокоитесь о чтении и написании различий в производительности, вы пренебрежимо малы, оцените свои общие требования как целого от хранилища до пользовательского интерфейса.