Конфигурация Сервера для Navision

[Drug]

Здравствуйте уважаемые посетители.

После полного перехода компании на Navision, появились ТОРМАЗА в базе.
После прочтения родственных тем и книг по SQL, проведены тесты Производительности на сервере, многие показатели выше номинальных. Поручили предоставить конфигурацию нового сервера, для приобритения.
В кратце информация: Navision 3.6. База поднята на MSSQL, раздута до 10GB. Log вырастает очень сильно ~ 100gb и более.
Сервак: p4-3g, 2g ram, 2 * (250g sata2 mirrored array). Понимаю что слабый.
Проблема: При учете/резерве документов, порядка 1000 строк, блокируются/тормазит работа других пользователей с темже функционалаом. Ключи учетных/журнальных таблиц не менялись и не добавлялись. Все доработки в основном идут с карточными таблицами и новый функционал и покрупному пользовательский интерфейс. Сейчас хотят филиалы переводить на Navision.

Подскажите какую конфигурацию приобритать. И какие у Вас "объем базы"/"хар-ки сервера"/производительность.

[mazzy]

Цитата:

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

Navision 3.6. База поднята на MSSQL, раздута до 10GB. Log вырастает очень сильно ~ 100gb и более.

а за какой период у вас так сильно лог растет?

[EDVard_imported]

Цитата:

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

При учете/резерве документов, порядка 1000 строк, блокируются/тормазит работа других пользователей с темже функционалаом.

Поставьте учет на ночное задание.
Ну а логи чистить нужно.
На одном из внедрений база была 100Гб и работала нормально.
При этом было почти 100 одновременных юзеров.
Но учет и все процедуры, очень уж задевающие книги операций переносили на ночные задания.

[Drug]

Цитата:

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

Цитата:

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

При учете/резерве документов, порядка 1000 строк, блокируются/тормазит работа других пользователей с темже функционалаом.

Поставьте учет на ночное задание.
Ну а логи чистить нужно.
На одном из внедрений база была 100Гб и работала нормально.
При этом было почти 100 одновременных юзеров.
Но учет и все процедуры, очень уж задевающие книги операций переносили на ночные задания.

Так если необходимо видеть постоянно актуальные остаки. Как быть? А про сервер что скажите?

Цитата:

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

Цитата:

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

Navision 3.6. База поднята на MSSQL, раздута до 10GB. Log вырастает очень сильно ~ 100gb и более.

а за какой период у вас так сильно лог растет?

Рос раньше, после оптимизация ок стало. Но теперь опять тормаза. Я смотрел Производительность, а тут не всё так хорошо, как в книжках.

[Drug]

Пол года мы сервак не трогали, было всё Ок. Где-то в июне, запусти отделы продаж, финансы (закупки были). Появились жуткие тормаза, посмотрели Лог всё место съел, в течении месяца ситуация повторилась. Тогда сжали базу, почистили ключи, код оптимизировали. Shrink на сервере по заданию поставили. Стало лучше. Сейчам лог не раздувается. Но при учетах тормазит функционал. И при крупных расчетах, понижается существенно производительность.
Хотелось бы узнать, как критична конфигурация сервера на объёмы базы.

[konrad_imported]

Сервер у нас старый, 4 год ему пошел.
Проц - 2 шт Р4 1500 Мгц
4 гига мозгов.
Аппаратный SCSI RAID-5, диски 36 Гб, 7200 рм
Файлы SQL-базы разнесены по разным дискам.
Раз в неделю пересобираются все индексы, в том числе и суммовые.
По ночам делается только бекап и обрезание лога.
Навижн - 3.70
Учет 8300 коротких проводок - 11 минут.
Блокировок пользователей нет.
Одновременно работает 40-50 юзеров.
Но у нас от Навижн один цветочек с главного меню нетронутый остался - остальное все переделано напрочь. Немодифицированные объекты - только те, что не входят в лицензию.
Без полной кастомизации учетного механизма ничего хорошего у Вас не получится.

[Drug]

Цитата:

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

Сервер у нас старый, 4 год ему пошел.
Проц - 2 шт Р4 1500 Мгц
4 гига мозгов.
Аппаратный SCSI RAID-5, диски 36 Гб, 7200 рм
Файлы SQL-базы разнесены по разным дискам.
Раз в неделю пересобираются все индексы, в том числе и суммовые.
По ночам делается только бекап и обрезание лога.
Навижн - 3.70
Учет 8300 коротких проводок - 11 минут.
Блокировок пользователей нет.
Одновременно работает 40-50 юзеров.
Но у нас от Навижн один цветочек с главного меню нетронутый остался - остальное все переделано напрочь. Немодифицированные объекты - только те, что не входят в лицензию.
Без полной кастомизации учетного механизма ничего хорошего у Вас не получится.

Спасибо за конструктив. А можно как-нибудь выявить узкие места в коде. Вроде как в 1С, замер производительности или что-то такое.

[konrad_imported]

Ну во первых, есть для Навижн очень хорошая штука - монитор клиента. Используемая нами версия - DEBUGW13.10.01, еще от 3.10 осталась. Работает поверх штатного.
Далее - недавно на mibuso.com выложили анализатор ключей Unused Keys 3.0 (beta). Очень полезная штука, жаль поздно попалась. Но только лишний раз показала, что ключи у нас правильные и лишних нет.

[Drug]

Насколько я понял, для увеленчения производительности:
Переколбасить все ключи в Navision, настроить на SQL сервере переформирование индексов, сжатие базы, логов. Ну и для героев переаписать по возможности учёт. А аппаратная часть может и не дать прироста.
Жалко мануала нету, типа шаг 1 и т.д. ...

[konrad_imported]

Цитата:

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

Насколько я понял, для увеленчения производительности:
Переколбасить все ключи в Navision, настроить на SQL сервере переформирование индексов, сжатие базы, логов. Ну и для героев переаписать по возможности учёт. А аппаратная часть может и не дать прироста.
Жалко мануала нету, типа шаг 1 и т.д. ...

1. На SQL-сервере корректно суммовые ключи не перестроишь. Точнее, процедуру перестроения их писать устанешь. И потом - чуть ключ поменялся - меняй процедуру. Потому у нас по простому - тяжелые таблицы типа 17, 14821, 12401, 50*** и т.д - перестраиваются средствами Навижн (оптимизация индексов) по выходным. Сотрудник заходит через терминальный сервер в выходной и запускает процедуру оптимизации.
2. Сжатием базы особо не увлекайтесь - потом сервер на ее раздутие ресурс сьест, причем есть начнет в самый неподходящий момент. Лучше лог очищать - при полном бекапе он у нас очищается. Да и потом еженедельные причесывания индексов хорошо добавляют свободного места в базу - т.е растет она не так резво, как без оптимизации.
3. Мануал есть, и даже в свое время - года полтора назад - я его на этот форум посылал.

[IGG]

А какую Recovery Model ВЫ устанавливали при создании базы - Simple, Bulk Logged или Full?

[konrad_imported]

Цитата:

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

А какую Recovery Model ВЫ устанавливали при создании базы - Simple, Bulk Logged или Full?

У нас стоит FULL. Раза 3-4 это спасало
Правда, недавно оптимизация не прошла - лог на диск не влез. Пришлось диск чистить.
Хотя логичнее бы было перед оптимизацией переключать на сервере модель в Simple, а потом обратно в FULL.

[Drug]

У нас Simple. А какой Model Recovery лучше установить?

[IGG]

Ой, я до такой степени не копал. Просто у меня сначала была Recovery Full и у меня стал лог расти бешеными темпами.
Ну я переключил в Simple и база стала очень маленькой
Help говорит так


Recovery Model

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

Имеются следующие параметры:

Bulk-Logged

Full

Simple

Bulk-Logged

В случае выбора варианта Bulk-Logged, файл журнала транзакций будет содержать ограниченную информацию о некоторых операциях, в которых задействован значительный объем данных (например, о копировании больших массивов). Модель восстановления Bulk-Logged обеспечивает защиту от сбоя носителя и более высокую производительность, а также минимальное потребление пространства регистрации для определённых широкомасштабных или массовых операций копирования.

Модель восстановления bulk-logged состоит из следующих компонентов:

Резервное копирование БД.

Дифференциальное резервирование (необязательный компонент).

Full

В случае выбора варианта Full в журнале транзакций хранится подробная информация о каждой транзакции; эта информация может использоваться при резервном копировании журнала транзакций. Полная модель позволяет создавать не только полные резервные копии БД, но и последовательные, промежуточные копии изменений, которые произошли, начиная с последнего, полного копирования. В случае повреждения одного или нескольких файлов данных процедура восстановления носителя информации позволяет восстановить все завершенные транзакции. Незавершенные транзакции при этом отменяются.

Модель полного восстановления позволяет восстановить то состояние базы данных, которое было непосредственно перед сбоем, а также ее состояние на любой заданный момент времени. Все операции, включая проведение массовых/групповых процедур, таких как SELECT INTO, CREATE INDEX, массовая загрузка информации, запротоколированы, благодаря чему гарантируется полное восстановление базы данных.

Модель восстановления Full (Полная) состоит из следующих элементов:

Резервное копирование БД.

Дифференциальное резервирование (необязательный компонент).

Резервное копирование журнала транзакций.

Модели восстановления Full и Bulk-Logged схожи между собой; многие пользователи, применяющие модель Full, время от времени используют модель Bulk-Logged.

Simple

В случае выбора варианта Simple можно восстановить состояние базы данных на момент последнего создания резервной копии. Однако, восстановить ее состояние на момент сбоя или на другой заданный момент времени невозможно. Для этого следует использовать модель восстановления Full или Bulk-Logged.

Модель восстановления Simple (Простая) состоит из следующих компонентов:

Резервное копирование БД.

Дифференциальное резервирование (необязательный компонент).

[Drug]

Уважаемые. Мучает проблема, вчём суть...

Есть репорт который создаёт резерв по строкам документа отгрузки. Два документа по 1000 позиций каждый. Открываю 2 finsql.exe. Открываю каждый документ, запускаю репорт (почти параллельно ручками) создать резерв по докуметам. ПОЧЕМУ, пока в первой базе репорт не отрабатает, не выполняется во второй? Почему процессы не выполняется одновременно?

[konrad_imported]

Скорее всего, вместо темповых таблиц при построении отчета используются реальные, которые блокируются до окончания его построения.

[Drug]

Цитата:

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

Скорее всего, вместо темповых таблиц при построении отчета используются реальные, которые блокируются до окончания его построения.

Есть штука оптимистическая блокировка. Хотелось узнать, работает это в Navision?

Вопросик. А можно как-нибудь изменить вид блокировки для таблиц? Допустим для одних, один тип, для других соответствующий.

[Drug]

[quote=Ivan;353086]

Цитата:

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

Скорее всего, вместо темповых таблиц при построении отчета используются реальные, которые блокируются до окончания его построения.

Есть штука оптимистическая блокировка. Хотелось узнать, работает это в Navision?

Вопросик. А можно как-нибудь изменить вид блокировки для таблиц? Допустим для одних, один тип, для других соответствующий.

konrad ты писал выше, что учет 8000 проводок 12 минут, а в этот момент другие пользователи могут учитывать свои проводки?

[Drug]

Можно закрыть тему. Изучил материалы на форумах. Понял, что Navision и MSSQL это не продуманная MS связка двух продуктов.

[konrad_imported]

1. Другие пользователи учитывать могут. Но скорость учета в таком случае падает в количество раз, пропорциональное учитывающим пользователям.
2. Механизм блокировки поменять нельзя.
3. Абсолютно верно. В 4.1 вроде интеграция получше, но не принципиально.