Каковы недостатки выбора более высокой точности меток времени в Oracle? - PullRequest
12 голосов
/ 10 октября 2010

Oracle позволяет указать в таблице точность типа TIMESTAMP - количество цифр в дробной части поля SECOND datetime.Есть ли какие-либо недостатки в определении максимальной точности TIMESTAMP(9)?

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

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

Ответы [ 4 ]

15 голосов
/ 11 октября 2010

Недостатков нет, используйте отметку времени (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

Это где timestamp (9) быстрее, когда используется current_timestamp, который вам, вероятно, понадобится в какой-то момент для генерации данных.Но мы говорим только о разнице между 0,175 и 0,25 секундами на моем медленном рабочем столе для генерации 100K временных меток.Я не уверен, почему метка времени (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
);

РЕДАКТИРОВАТЬ: разница в производительности существует в 10g, но не 11g.

0 голосов
/ 18 августа 2017

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

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

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

0 голосов
/ 11 октября 2010

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

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

0 голосов
/ 10 октября 2010

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...