Налаштування продуктивності для величезної таблиці (SQL Server 2008 R2)


14

Передумови: У
мене є таблиця фактів у фазі UAT. Мета завантаження 5 років даних у Prod (очікуваний розмір 400 Mn записів). На даний момент у тесту є лише 2 роки даних.

Особливості таблиці:

  1. Без розмірів ~ 45
  2. Заходи ~ 30
  3. Недодаткові заходи та інші стовпці ~ 25
  4. Поточний розмір даних ~ 200 млн (дані за 2 роки)
  5. Перегляд часу: 3 різні перегляди місяця: фіскальний / календар / скорегований (тобто один і той же рядок може потрапляти в різні місяці, залежно від того, який перегляд шукаєте)
  6. Одночасно користувачеві буде потрібен лише один перегляд. (наприклад, у запиті буде використано лише один стовпець місяця, це зупиняє нас робити розділення під час перегляду)
  7. Індекси: 1 кластерний індекс за природними клавішами (8 стовпців)
  8. Через це показники величезні (всього 190 ГБ).
  9. Простір не обмежує (виділено 1 ТБ)
  10. 64 ГБ оперативної пам’яті доступно на сервері.
  11. Стиснення таблиці також робиться.

Вимога:
Запити в цій таблиці фактів повинні дати результат протягом 30 секунд (Загальні запити виберіть суму (міру) приєднавшись до декількох груп Dims за значеннями Dim). Звіти проводяться безпосередньо над цією таблицею фактів.

Проблема:
Будь-який запит, що включає стовпці, доступні в індексі, працює нормально, але якщо ми включимо будь-які інші стовпці, які не входять включити. Це займає більше 5-10 хвилин. Чи може хтось запропонувати якесь рішення, де воно добре працює для будь-якого вибраного нами виміру / стовпця. Чи може перегляд індексу допомогти у цій ситуації?

Відповіді:


6

Оновіть до SQL Server 2012 та використовуйте стовпці . Вони процвітають у цих вимогах. Серйозно, завантажте оціночне видання та спробуйте. Відкиньте всі індекси, опустіть кластерний індекс, просто додайте некластеризований індекс стовпців стовпців у всі стовпці і надайте йому кружляння. Я бачив такі випадки, як ваш, що скорочував час виконання до 2-3 секунд, головним чином через усунення сегменту, що починається . Деякі додаткові повідомлення:


0

Чи вирішить вашу проблему індексований вигляд? Наскільки актуальними повинні бути дані? Можна створити індексований вигляд для декількох перестановок. Але за допомогою багатьох мір та мір ви швидко втратите місце!

Як щодо використання SSD-дисків?


Дані оновлюватимуться щомісяця. Скільки часу знадобиться для оновлення Перегляду?

Якщо ваш існуючий запит займає 5-10 хвилин, то індексований вид займе 5-10 хвилин. Коли ви виконаєте той самий запит, він повернеться так, ніби він виходить із таблиці (тобто негайно). Індексований вигляд попередньо запускає певний біт SQL. Якщо ви подаєте SQL, який відповідає йому, він бере його з індексованого перегляду, а не запускає його заново. Основна перевага індексованого перегляду полягає в тому, що вам не потрібно змінювати існуючі запити, вони автоматично використовуватимуть його. Недоліком є ​​те, що вам доведеться створити один із кількох різних комбінацій.
Nick.McDermaid

Але я не пропоную створювати декілька індексованих представлень, щоб прискорити роботу - з часом у вас не вистачить часу та місця на диску. Це може бути лише одне, що потрібно поставити у свій арсенал.
Nick.McDermaid

і будь ласка ... загляньте в стовпці, як пропонується!
Nick.McDermaid
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.