AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 17.03.2007, 11:13   #1  
Blog bot is offline
Blog bot
Участник
 
25,475 / 846 (79) +++++++
Регистрация: 28.10.2006
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  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Blog bot Посмотреть сообщение
* Данные на RAID 10, что гораздо более эффективно, чем использование секционирования.
Эх, самое интересное автор обошел одним прделожением.
Очень хотелось бы получить более развернутое обоснование этого утвержения.
__________________
полезное на axForum, github, vk, coub.
Старый 19.03.2007, 09:36   #3  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Thumbs down
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Если рассматривать пути увеличения производительности и использование для этого секционирования, то получение эффекта от секционирования не очевидно.
..
Лучше рассматривать стандартные пути увеличения производительности:
статья ни о чем
- секционирование объявляем "нестандартным способом" (то-то разработчики удивятся)
- логические конструкции вида "RAID10 вместо секционирования"
- нет цифр, подтверждающих эти утверждения
и т.д.
__________________
-ТСЯ или -ТЬСЯ ?
Старый 25.03.2007, 21:30   #4  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Blog bot Посмотреть сообщение
Лучше рассматривать стандартные пути увеличения производительности:
* TempDb на разных устройствах. Файловая группа для базы данных tempdb должна содержать несколько идентичных файлов одинакового размера; количество файлов должно определяться числом процессоров сервера (логических процессоров при гипертрейдинге, или физических при использовании процессоров с несколькими ядрами). Желательно разместить файлы на разных физических дисках, использующие разные контроллеры.
Вот это что-то новое Интересно, есть ли ссылки на такую информацию в документации?
Цитата:
* Журналы на отдельном от данных устройстве с RAID 10.
Serge Kotov в своей статье пишет немного другое:
Цитата:
Некоторые рекомендации по применению RAID массивов для баз данных Axapta:
  • Файлы данных: обязательно RAID 10 (0+1) для рабочей базы данных, допустимо RAID 5 для вспомогательных баз
  • Лог транзакций: RAID 1 (зеркало)
  • Temp DB: RAID1 (зеркало)
Интересно, в исходном сообщении рекомендации RAID10 для транзакционных логов - объективная необходимость или просто "чтобы было"?
Старый 26.03.2007, 10:48   #5  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,631 / 1849 (69) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Вот это что-то новое Интересно, есть ли ссылки на такую информацию в документации?
этой "новости" года два

с выходом SP4 для MSSQL 2000 уже не критично, но актуально
__________________
-ТСЯ или -ТЬСЯ ?
За это сообщение автора поблагодарили: gl00mie (3).
Старый 27.03.2007, 09:37   #6  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Не согласен с автором. Секционирование может быть полезно и при размещении секций на одном физическом диске (рэйд массиве). Разделение таблицы на секции можно воспринимать, как второй "кластерный" индекс. "Кластерный" специально пишу в кавычках. Одно из преимуществ кластерного индекса перед простым заключается в том, что оптимизатор может использовать его при выборке в запросе большого массива данных (>15-20% результирующих строк запроса от общего кол-ва строк в таблице). Применительно к Аксапте например, на мой взгляд, было бы полезно секционировать таблицу бух. проводок (LedgerTrans) по полю даты (TransDate), если конечно кластерный индекс не создан или не содержит это поле первым (вторым после DataAreaId).

PS. Максимальная отдача от секционирования, на мой взгляд, может быть получена при использовании прямых SQL запросов
PS2. Это пока только теория, конкретных цифирок у меня нет
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Dynamics AX Sustained Engineering: SQL Server 2005 sp3 & SQL Server 2008 with Dynamics AX Blog bot DAX Blogs 0 12.02.2009 06:08
Dynamics AX: Looking into SQL Server 2008 Blog bot DAX Blogs 0 16.01.2009 05:06
aEremenko: Как сопоставить пользователя DAX и сессию в Microsoft SQL? Blog bot DAX Blogs 2 04.10.2007 20:08
Сергей Герасимов: О совместимости Microsoft SQL Server 2005 и Microsoft Dynamics AX 3.0 Blog bot DAX Blogs 0 26.02.2007 12:40
SQL Server 2005 Features Comparison George Nordic DAX: Администрирование 1 17.01.2007 14:45

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 09:03.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.