17.03.2007, 11:13 | #1 |
Участник
|
aEremenko: Нужно ли использовать секционирование в Microsoft SQL Server 2005 для DAX 3.0
Источник: http://blogs.msdn.com/aeremenk/archi...7/1898066.aspx
============== Сразу хочу заметить, что речь пойдет о Microsoft Dynamics AX 3.0, не о новой версии 4.0. Если рассматривать пути увеличения производительности и использование для этого секционирования, то получение эффекта от секционирования не очевидно. Лучше рассматривать стандартные пути увеличения производительности: * TempDb на разных устройствах. С Microsoft SQL Server 2005 возможность возникновения проблемы конкуренции в tempDB гораздо более высока по сравнению с Microsoft SQL Server 2000. Файловая группа для базы данных tempdb должна содержать несколько идентичных файлов одинакового размера; количество файлов должно определяться числом процессоров сервера (логических процессоров при гипертрейдинге, или физических при использовании процессоров с несколькими ядрами). Желательно разместить файлы на разных физических дисках, использующие разные контроллеры. * Журналы на отдельном от данных устройстве с RAID 10. * Данные на RAID 10, что гораздо более эффективно, чем использование секционирования. Основная цель использования секционирования в случае DAX 3.0 – для целей администрирования. Обычно, администратор баз данных создает дополнительные файловые группы для операций обслуживания (резервное копирование, восстановление, и т.п.), а не для повышения производительности. В версии 5 будут введены изменения в процесс синхронизации для поддержки секционирования. Следует также заметить, что для оптимальной работы Microsoft Dynamics AX 3.0 с Microsoft SQL Server 2005 необходим достаточно серьезный анализ оптимальности использования индексов, в частности кластерных по сравнению с Microsoft SQL Server 2000. Также, рекомендуется использовать последние пакеты обновления для Microsoft SQL Server 2005, поскольку в базовой версии базы данных были проблемы, влияющие на производительность системы и исправленные в пакетах обновления, например, работа с автоматическим расширением файлов или возникновение ошибок при работе с курсорами (Microsoft Dynamics AX использует курсоры). Источник: http://blogs.msdn.com/aeremenk/archi...7/1898066.aspx |
|
18.03.2007, 09:26 | #2 |
Участник
|
Цитата:
Очень хотелось бы получить более развернутое обоснование этого утвержения. |
|
19.03.2007, 09:36 | #3 |
Модератор
|
Цитата:
- секционирование объявляем "нестандартным способом" (то-то разработчики удивятся) - логические конструкции вида "RAID10 вместо секционирования" - нет цифр, подтверждающих эти утверждения и т.д.
__________________
-ТСЯ или -ТЬСЯ ? |
|
25.03.2007, 21:30 | #4 |
Участник
|
Цитата:
Сообщение от Blog bot
Лучше рассматривать стандартные пути увеличения производительности:
* TempDb на разных устройствах. Файловая группа для базы данных tempdb должна содержать несколько идентичных файлов одинакового размера; количество файлов должно определяться числом процессоров сервера (логических процессоров при гипертрейдинге, или физических при использовании процессоров с несколькими ядрами). Желательно разместить файлы на разных физических дисках, использующие разные контроллеры. Цитата:
* Журналы на отдельном от данных устройстве с RAID 10.
Цитата:
Некоторые рекомендации по применению RAID массивов для баз данных Axapta:
|
|
26.03.2007, 10:48 | #5 |
Модератор
|
__________________
-ТСЯ или -ТЬСЯ ? |
|
|
За это сообщение автора поблагодарили: gl00mie (3). |
27.03.2007, 09:37 | #6 |
Участник
|
Не согласен с автором. Секционирование может быть полезно и при размещении секций на одном физическом диске (рэйд массиве). Разделение таблицы на секции можно воспринимать, как второй "кластерный" индекс. "Кластерный" специально пишу в кавычках. Одно из преимуществ кластерного индекса перед простым заключается в том, что оптимизатор может использовать его при выборке в запросе большого массива данных (>15-20% результирующих строк запроса от общего кол-ва строк в таблице). Применительно к Аксапте например, на мой взгляд, было бы полезно секционировать таблицу бух. проводок (LedgerTrans) по полю даты (TransDate), если конечно кластерный индекс не создан или не содержит это поле первым (вторым после DataAreaId).
PS. Максимальная отдача от секционирования, на мой взгляд, может быть получена при использовании прямых SQL запросов PS2. Это пока только теория, конкретных цифирок у меня нет |
|
|
|