Оптимизация SQL сервера под Аксапту.

[alxm]

Цитата:

Сообщение от Vadik

"Распределение" все делают - это сродни протиранию стекол и пинанию колес в машине. Полезный выхлоп от этого шаманства стремится к нулю (если только количество физических дисков на СХД не измеряется сотнями)

Звучит грустно. Может все-таки десятками дисков?
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом.
Вопрос о распределении встает в полный рост (

Хотя есть еще вариант - средствами windows из двух RAID сделать страйп.
Но насколько это будет надежно/производительно?
Кто-нибудь пробовал?

[Alexius]

Цитата:

Сообщение от alxm

Хотя есть еще вариант - средствами windows из двух RAID сделать страйп.

Софтовый рейд - инструмент для совсем бедных и ожидать от него лучшей производительности, чем от железного не стоит. Если нет железного, для MS SQL лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать.

PS. Кесарю - кесарево. Слесарю - слесарево

[alxm]

Цитата:

Сообщение от Alexius

Если нет железного, для MS SQL лучше наделать несколько файлов

Обратите внимание - железный есть ) Но массив не на несколько сотен дисков, а два массива по 12 дисков. (В моем случае).

[Alexius]

Цитата:

Сообщение от alxm

Обратите внимание - железный есть

Вопрос в чем ? Будет ли прирост производительности если сделать 2 файла ? На мой взгляд, если и будет, то незначительный. Если объединять в софтовый рейд боюсь можно и проиграть

[Vadik]

Цитата:

Сообщение от alxm

Звучит грустно. Может все-таки десятками дисков?
Ведь у многих младших-средних СХД (а что-то мне подсказывает, что инсталляции Аксапты чаще делаются на них) будет ограничение по количеству дисков в одной RAID группе. И из СХД на 50 дисков мы получим все равно несколько RAID по 12-16 дисков в каждом

Давайте, как говорится, отделять мух от котлет...
Что касается внутреннего устройства сиквела - мне кажется, ссылки на разъяснения от достаточно авторитетных (по крайней мере для меня ) товарищей я привел.
Что касается СХД.. Ограничения (скорее рекомендации вендора) на максимальное количество физических дисков в одной raid группе определяются соображениями не производительности, а удобства администрирования и надежности (с увеличением количества дисков в группе повышается вероятность выхода из строя одиночного диска, увеличивается время ее ребилда и т.д.). Так что в случае 50 дисков вопрос "делать или не делать несколько raid групп" просто не стоИт - да, у нас БУДЕТ несколько raid групп. Как мы презентуем их системе и сиквелу (отдельными LUN-ами, объединим в один meta LUN средствами СХД или в один том средствами ОС) - на производительности СХД это скорее всего не скажется никак, не факт что этих 50 дисков хватит чтобы загрузить даже один storage processor

Цитата:

Сообщение от Alexius

Софтовый рейд - инструмент для совсем бедных и ожидать от него лучшей производительности, чем от железного не стоит

Вы сильно удивитесь, если узнаете, что midrange SAN - они как бы не совсем "железные" - там внутри стоят как правило процессоры на одно поколение младше или аналогичные тем, что используются в серверах ? А старичок CX300 (по слухам) вообще на специальной версии Windows XP работает ? Так что объединение нескольких LUN-ов с SAN в софтовый raid - вполне себе легальный и жизнеспособный вариант

Цитата:

Если нет железного, для MS SQL лучше наделать несколько файлов (не путать с файловыми группами !) по числу выделенных винтов, он сам неплохо разбирается как это все оптимизировать

Если нет железного, надо его выбивать из начальства, пока не поздно

[somebody]

Цитата:

Сообщение от 3oppo

Есть ли смысл скажем в перенесении больших таблиц (таких как InventTrans, LedgerTrans ) в отдельный BD файл, на уровне SQL сервера

делали, помогало.

Цитата:

Сообщение от 3oppo

Ну или может кто ещё что посоветует?

Вообще, если вопрос в производительности, может, сначала посмотреть на саму Аксапту и АОСы? А именно:
- формы с большим кол-вом строк - ограничить число строк фильтрами
- формы с дисплейными методами - перевести на временные таблицы
- lookup'ы с перекрытым Lookup - упростить
- раскидать пользователей по АОСам (кластер, но лучше развести работающих с разными данными (кэш АОСа!))

И уже потом по SQL-серверу:
- отследить профайлером самые нагружающие запросы и оптимизировать (в частности, с помощью дополнительных индексов)
- аналогично, отследить с помощью sys.dm_db_missing_index_group_stats, каких индексов не хватает
- с помощью sys.dm_db_index_usage_stats отследить неиспользуемые индексы (т. е. отсутствующие в этом представлении), на поддержание к-рых тратятся ресурсы
(2 предыдущих пункта лучше за большой период времени работы сервера без перезагрузок)
- получить статистику по блокировкам/deadlock'ам, отследить и устранить причины (часто причина в кодах, либо связано со следующим пунктом)
- минимизировать внешнее влияние на работу Аксапты (конкурирующие SQL-задания/SSIS-пакеты, пользователи, подключающиеся к таблицам БД напрямую)
- отдельный standby-сервер для отчётов и пользователей, подключающихся к таблицам БД напрямую
- отдельные дисковые массивы для самых нагруженных таблиц
- убрать возможное влияние резервного копирования, в т. ч. Windows, и антивирусов
- увеличить autogrow, отключить autoshrink, включить автостатистику, регулярно перестраивать важные индексы
- тестировать и применять к инсталляции SQL-сервера совместимые сервис-паки и CU.

И т. д...
А вообще по оптимизации SQL - в конкретном случае надо смотреть очереди к дискам, навешивать другие счётчики, разбираться с ожиданиями. А может, причина проседания производительности - вообще сеть...

[somebody]

Да, ещё насчёт статистик. Можно их обновлять и вручную для отдельных таблиц с большим числом вставок/изменений, можно и отложенные автостатистики делать, можно для всех таблиц регулярно делать ручное обновление статистик (с отключёнными автостатистиками). Здесь нужно разбираться конкретно в каждом случае.

[somebody]

Забыл. Прежде чем разносить отдельные таблицы, всё-таки убедиться, что на уровне SQL-сервера физически разнесены данные, логи и tempdb...