Кластерный индекс в SQL Server против индексированных таблиц в Oracle

8

Я делаю переход как разработчик базы данных с SQL Server на Oracle и уже нашел здесь несколько фантастических ресурсов ( Как сделать переход с DBA на SQL Server на Oracle? И как на уровне DBA, как мне перейти с Oracle на SQL Server? ? ) но мне трудно найти хорошую информацию об использовании таблиц, организованных по индексу, в Oracle.

В моей предыдущей жизни мы с большим успехом широко использовали кластерные индексы в SQL Server в нашем OLTP-хранилище данных. Являются ли индексированные таблицы удобным инструментом в Oracle?

sql-server oracle index

— JHFB
источник

1

Похоже, мои исследования показывают, что они не так широко используются - правда, как говорит @Gaius : dba.stackexchange.com/questions/1847/… ? Оракулы просто пропускают?

— JHFB

IOT очень редко используются в Oracle. Думаю, я когда-либо использовал 2 только за свои 12 лет в качестве администратора

— базы

1

stackoverflow.com/questions/3382939/…

— Philᵀᴹ

7

Если вы переходите с SQL Server на Oracle, я бы посоветовал сначала попробовать таблицы кучи, поскольку они являются стандартной формой хранения данных в Oracle. Для большинства рабочих нагрузок таблицы кучи с обычными индексами в Oracle являются наиболее сбалансированными формами хранения в отношении DML и производительности запросов.

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

Что касается IOT, в частности, я бы посоветовал не использовать их повсеместно, потому что есть много «ловушек», в которые вы, возможно, не захотите войти как новичок:

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

— Винсент Малграт
источник

6

IOT в Oracle не совсем совпадают с кластеризованными индексами в SS, потому что статистика Oracle включает физическое разброс строк, тогда как SS не включает физическое местоположение в свою статистику. Посмотрите эту дискуссию между Льюисом и Фричи о статистике в Oracle и Sql Server для получения дополнительной информации. ( http://www.red-gate.com/products/oracle-development/deployment-suite-for-oracle/education/webinars/webinar-statistics-oracle-sql-server-jonathan-lewis ). Именно поэтому Индекс в СС лучше кучи. Кластерный индекс добавляет данные физического местоположения в статистику. IOT хороши, когда вы знаете, что индекс обеспечивает размещение строк данных, по которым будет производиться поиск, например, индекс для order_date и customer для таблицы заказов будут хорошим IOT.

— Джим
источник

Спасибо, Джим. Похоже, кластерные индексы в SS преодолевают недостаток физической информации в статистике; при этом Oracle теоретически должен работать быстрее без такого индекса? Также, чтобы уточнить, я хотел бы использовать IOT, чтобы гарантировать близкое физическое расположение строк данных для определенных столбцов?

— JHFB

1

@JHFB - да, IOT гарантирует, что данные, составляющие индекс первичного ключа для таблицы, будут физически упорядочены в соответствии со столбцами в индексе. Таким образом, это можно использовать для обеспечения того, чтобы строки в дочерней таблице для данного родителя были физически расположены рядом друг с другом.

— Крис Саксон,

3

Винсент делает несколько важных замечаний относительно предостережений от IOT, но вы также можете получить от них существенные преимущества.

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

У Мартина Видлейка есть отличная серия постов о IOT. Есть несколько существенных преимуществ, которые вы можете получить, используя их:

Значительно сократить физические и логические чтения IO
Более эффективное использование буферного кеша, что может повысить производительность всей системы
Экономия места, поскольку вы просто поддерживаете индекс, а не таблицу (если у вас нет сегментов переполнения)

Однако, чтобы получить эти преимущества, вам нужны таблицы, в которых вы (почти) всегда включаете в запросы ведущие столбцы первичного ключа, и вы, вероятно, будете получать несколько строк одновременно. Некоторые распространенные примеры таких таблиц:

Основные данные, которые часто встречаются в заказах - позиции заказа, счета-фактуры - строки счетов-фактур и т. Д.
Таблицы разрешения «многие ко многим», которые обычно запрашиваются «односторонне». например, в customer_addressesтаблице гораздо чаще можно найти все адреса для клиента, а не все клиенты для адреса.

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

— Крис Саксон
источник