AXForum  
Вернуться   AXForum > Microsoft Dynamics NAV > NAV: Администрирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 14.09.2006, 14:34   #1  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Здравствуйте уважаемые посетители.

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

Подскажите какую конфигурацию приобритать. И какие у Вас "объем базы"/"хар-ки сервера"/производительность.
Старый 14.09.2006, 14:41   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Ivan Посмотреть сообщение
Navision 3.6. База поднята на MSSQL, раздута до 10GB. Log вырастает очень сильно ~ 100gb и более.
а за какой период у вас так сильно лог растет?
__________________
полезное на axForum, github, vk, coub.
Старый 14.09.2006, 14:51   #3  
EDVard_imported is offline
EDVard_imported
Участник
 
49 / 10 (1) +
Регистрация: 22.07.2004
Цитата:
Сообщение от Ivan Посмотреть сообщение
При учете/резерве документов, порядка 1000 строк, блокируются/тормазит работа других пользователей с темже функционалаом.
Поставьте учет на ночное задание.
Ну а логи чистить нужно.
На одном из внедрений база была 100Гб и работала нормально.
При этом было почти 100 одновременных юзеров.
Но учет и все процедуры, очень уж задевающие книги операций переносили на ночные задания.
Старый 14.09.2006, 14:59   #4  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Пол года мы сервак не трогали, было всё Ок. Где-то в июне, запусти отделы продаж, финансы (закупки были). Появились жуткие тормаза, посмотрели Лог всё место съел, в течении месяца ситуация повторилась. Тогда сжали базу, почистили ключи, код оптимизировали. Shrink на сервере по заданию поставили. Стало лучше. Сейчам лог не раздувается. Но при учетах тормазит функционал. И при крупных расчетах, понижается существенно производительность.
Хотелось бы узнать, как критична конфигурация сервера на объёмы базы.
Старый 14.09.2006, 15:17   #5  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Цитата:
Сообщение от EDVard Посмотреть сообщение
Цитата:
Сообщение от Ivan Посмотреть сообщение
При учете/резерве документов, порядка 1000 строк, блокируются/тормазит работа других пользователей с темже функционалаом.
Поставьте учет на ночное задание.
Ну а логи чистить нужно.
На одном из внедрений база была 100Гб и работала нормально.
При этом было почти 100 одновременных юзеров.
Но учет и все процедуры, очень уж задевающие книги операций переносили на ночные задания.
Так если необходимо видеть постоянно актуальные остаки. Как быть? А про сервер что скажите?

Цитата:
Сообщение от mazzy Посмотреть сообщение
Цитата:
Сообщение от Ivan Посмотреть сообщение
Navision 3.6. База поднята на MSSQL, раздута до 10GB. Log вырастает очень сильно ~ 100gb и более.
а за какой период у вас так сильно лог растет?
Рос раньше, после оптимизация ок стало. Но теперь опять тормаза. Я смотрел Производительность, а тут не всё так хорошо, как в книжках.
Старый 14.09.2006, 15:24   #6  
konrad_imported is offline
konrad_imported
Участник
 
183 / 10 (1) +
Регистрация: 25.11.2004
Сервер у нас старый, 4 год ему пошел.
Проц - 2 шт Р4 1500 Мгц
4 гига мозгов.
Аппаратный SCSI RAID-5, диски 36 Гб, 7200 рм
Файлы SQL-базы разнесены по разным дискам.
Раз в неделю пересобираются все индексы, в том числе и суммовые.
По ночам делается только бекап и обрезание лога.
Навижн - 3.70
Учет 8300 коротких проводок - 11 минут.
Блокировок пользователей нет.
Одновременно работает 40-50 юзеров.
Но у нас от Навижн один цветочек с главного меню нетронутый остался - остальное все переделано напрочь. Немодифицированные объекты - только те, что не входят в лицензию.
Без полной кастомизации учетного механизма ничего хорошего у Вас не получится.
Старый 14.09.2006, 15:29   #7  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Цитата:
Сообщение от konrad Посмотреть сообщение
Сервер у нас старый, 4 год ему пошел.
Проц - 2 шт Р4 1500 Мгц
4 гига мозгов.
Аппаратный SCSI RAID-5, диски 36 Гб, 7200 рм
Файлы SQL-базы разнесены по разным дискам.
Раз в неделю пересобираются все индексы, в том числе и суммовые.
По ночам делается только бекап и обрезание лога.
Навижн - 3.70
Учет 8300 коротких проводок - 11 минут.
Блокировок пользователей нет.
Одновременно работает 40-50 юзеров.
Но у нас от Навижн один цветочек с главного меню нетронутый остался - остальное все переделано напрочь. Немодифицированные объекты - только те, что не входят в лицензию.
Без полной кастомизации учетного механизма ничего хорошего у Вас не получится.
Спасибо за конструктив. А можно как-нибудь выявить узкие места в коде. Вроде как в 1С, замер производительности или что-то такое.
Старый 14.09.2006, 15:41   #8  
konrad_imported is offline
konrad_imported
Участник
 
183 / 10 (1) +
Регистрация: 25.11.2004
Ну во первых, есть для Навижн очень хорошая штука - монитор клиента. Используемая нами версия - DEBUGW13.10.01, еще от 3.10 осталась. Работает поверх штатного.
Далее - недавно на mibuso.com выложили анализатор ключей Unused Keys 3.0 (beta). Очень полезная штука, жаль поздно попалась. Но только лишний раз показала, что ключи у нас правильные и лишних нет.
Старый 14.09.2006, 16:08   #9  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Насколько я понял, для увеленчения производительности:
Переколбасить все ключи в Navision, настроить на SQL сервере переформирование индексов, сжатие базы, логов. Ну и для героев переаписать по возможности учёт. А аппаратная часть может и не дать прироста.
Жалко мануала нету, типа шаг 1 и т.д. ...
Старый 14.09.2006, 17:03   #10  
konrad_imported is offline
konrad_imported
Участник
 
183 / 10 (1) +
Регистрация: 25.11.2004
Цитата:
Сообщение от Ivan Посмотреть сообщение
Насколько я понял, для увеленчения производительности:
Переколбасить все ключи в Navision, настроить на SQL сервере переформирование индексов, сжатие базы, логов. Ну и для героев переаписать по возможности учёт. А аппаратная часть может и не дать прироста.
Жалко мануала нету, типа шаг 1 и т.д. ...
1. На SQL-сервере корректно суммовые ключи не перестроишь. Точнее, процедуру перестроения их писать устанешь. И потом - чуть ключ поменялся - меняй процедуру. Потому у нас по простому - тяжелые таблицы типа 17, 14821, 12401, 50*** и т.д - перестраиваются средствами Навижн (оптимизация индексов) по выходным. Сотрудник заходит через терминальный сервер в выходной и запускает процедуру оптимизации.
2. Сжатием базы особо не увлекайтесь - потом сервер на ее раздутие ресурс сьест, причем есть начнет в самый неподходящий момент. Лучше лог очищать - при полном бекапе он у нас очищается. Да и потом еженедельные причесывания индексов хорошо добавляют свободного места в базу - т.е растет она не так резво, как без оптимизации.
3. Мануал есть, и даже в свое время - года полтора назад - я его на этот форум посылал.
Старый 14.09.2006, 17:15   #11  
IGG is offline
IGG
Участник
 
665 / 29 (2) +++
Регистрация: 24.08.2005
Адрес: СПб/Москва
А какую Recovery Model ВЫ устанавливали при создании базы - Simple, Bulk Logged или Full?
Старый 14.09.2006, 17:29   #12  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
У нас Simple. А какой Model Recovery лучше установить?
Старый 14.09.2006, 18:20   #13  
konrad_imported is offline
konrad_imported
Участник
 
183 / 10 (1) +
Регистрация: 25.11.2004
Цитата:
Сообщение от IGHG Посмотреть сообщение
А какую Recovery Model ВЫ устанавливали при создании базы - Simple, Bulk Logged или Full?
У нас стоит FULL. Раза 3-4 это спасало
Правда, недавно оптимизация не прошла - лог на диск не влез. Пришлось диск чистить.
Хотя логичнее бы было перед оптимизацией переключать на сервере модель в Simple, а потом обратно в FULL.
Старый 14.09.2006, 18:29   #14  
IGG is offline
IGG
Участник
 
665 / 29 (2) +++
Регистрация: 24.08.2005
Адрес: СПб/Москва
Ой, я до такой степени не копал. Просто у меня сначала была 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 (Простая) состоит из следующих компонентов:

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

Дифференциальное резервирование (необязательный компонент).
Старый 14.09.2006, 20:15   #15  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Уважаемые. Мучает проблема, вчём суть...

Есть репорт который создаёт резерв по строкам документа отгрузки. Два документа по 1000 позиций каждый. Открываю 2 finsql.exe. Открываю каждый документ, запускаю репорт (почти параллельно ручками) создать резерв по докуметам. ПОЧЕМУ, пока в первой базе репорт не отрабатает, не выполняется во второй? Почему процессы не выполняется одновременно?
Старый 15.09.2006, 10:16   #16  
konrad_imported is offline
konrad_imported
Участник
 
183 / 10 (1) +
Регистрация: 25.11.2004
Скорее всего, вместо темповых таблиц при построении отчета используются реальные, которые блокируются до окончания его построения.
Старый 15.09.2006, 10:30   #17  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Цитата:
Сообщение от konrad Посмотреть сообщение
Скорее всего, вместо темповых таблиц при построении отчета используются реальные, которые блокируются до окончания его построения.
Есть штука оптимистическая блокировка. Хотелось узнать, работает это в Navision?

Вопросик. А можно как-нибудь изменить вид блокировки для таблиц? Допустим для одних, один тип, для других соответствующий.
Старый 15.09.2006, 11:33   #18  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
[quote=Ivan;353086]
Цитата:
Сообщение от konrad Посмотреть сообщение
Скорее всего, вместо темповых таблиц при построении отчета используются реальные, которые блокируются до окончания его построения.
Есть штука оптимистическая блокировка. Хотелось узнать, работает это в Navision?

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

konrad ты писал выше, что учет 8000 проводок 12 минут, а в этот момент другие пользователи могут учитывать свои проводки?
Старый 15.09.2006, 12:59   #19  
Drug is offline
Drug
Участник
 
67 / 14 (1) ++
Регистрация: 13.12.2005
Можно закрыть тему. Изучил материалы на форумах. Понял, что Navision и MSSQL это не продуманная MS связка двух продуктов.
Старый 15.09.2006, 13:27   #20  
konrad_imported is offline
konrad_imported
Участник
 
183 / 10 (1) +
Регистрация: 25.11.2004
1. Другие пользователи учитывать могут. Но скорость учета в таком случае падает в количество раз, пропорциональное учитывающим пользователям.
2. Механизм блокировки поменять нельзя.
3. Абсолютно верно. В 4.1 вроде интеграция получше, но не принципиально.
 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

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

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