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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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