Существуют ли существенные различия с 500+ миллионами таблиц строк в Oracle?

Я работаю дизайнером баз данных в среде хранилищ данных. Я привык иметь дело с таблицами с максимум 1 миллионом строк и теперь сталкиваюсь с таблицами с более чем полмиллиарда строк. Есть ли существенные различия с инструментами в «наборе инструментов эффективности»? Могу ли я доверять своим предыдущим знаниям об индексах, разделах и т. П. Или некоторые из этих конкретных инструментов являются скорее помехой, чем помощью с такими большими данными? Любые другие советы по работе со столами?

(Уже нашел отличный пост по обновлению 700 миллионов строк до того же значения )

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

Тем не менее, вот (не обязательно полный) список вещей, которые стоит иметь в виду:

• Индексы B-дерева, скорее всего, будут иметь дополнительный уровень, поэтому стоимость их использования несколько выше. Однако в DW вы должны использовать растровые индексы (при условии, что у вас есть корпоративная версия)
• Это займет гораздо больше времени для расчета статистики для всей таблицы - до такой степени, что это может быть невозможно в обычном ночном окне. Это может быть преодолено
  • Использование меньшего estimate_percentпри сборе статистики, чтобы отбиралось меньше таблицы.
  • Использование инкрементного сбора статистики (актуально, только если у вас есть глобальные индексы для секционированных таблиц)
• Гистограммы для индексов ограничены 254 сегментами. Больше строк, вероятно, означает более четкие значения, а это означает, что «почти популярные» значения могут быть более серьезной проблемой для искаженных данных.
• Вероятность того, что вся ваша таблица будет помещаться в буферный кеш, приближается к нулю, а это означает, что у вас больше шансов на физическое (дисковое) чтение. Ваш обычный рабочий набор также может быть слишком большим для кэширования.
• Разбиение может быть вашим другом - если вы правильно поняли! Если вы обычно изменяете и запрашиваете данные в нескольких разделах, это может стоить вам больше, чем простые таблицы.
• Материализованные представления могут быть очень полезны для сокращения вашего рабочего набора. например, если у вас есть данные за 10+ лет, но подавляющее большинство пользовательских запросов только против последних 2 лет, то создание MV, ограниченного только этими данными, может быть большой помощью.
• Чем больше база данных, тем меньше вероятность того, что бизнес сможет (сможет) финансировать тестовую базу данных, которая является полной копией реальной среды. Это затрудняет воспроизведение проблем с производительностью в тесте, поскольку медленные запросы могут быть связаны с масштабом и / или физическим хранением данных. Вы не можете рассчитывать на возможность экстраполировать результаты запроса из гораздо меньшей тестовой БД на соответствующую производительность в реальном времени.

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

Количество имеет качество все свое.

При работе с таблицами такого размера полезно не рассматривать таблицу фактов как таблицу, а рассматривать ее на уровне сегмента или как набор отдельных таблиц. (Быть достаточно взрослым, чтобы помнить, что катящееся собственное разделение с представлениями раздела помогает.)

Статья Тима Гормана « Масштабирование до бесконечности» - бесценный ресурс.