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

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 07.06.2009, 20:32   #21  
Thrice is offline
Thrice
Участник
Аватар для Thrice
 
46 / 10 (1) +
Регистрация: 09.07.2008
Цитата:
Сообщение от RedFox Посмотреть сообщение
1. Тестируйте сразу переход под SQL 2008.
2. При востановлении БД используйте Recovery model Simple, а не Full. После восстановления (и советую сделать оптимизацию) поменяете с Simple на Full.
3. Установите Auto Shrink
советы про Recovery model постараюсь протестить в ближайшее время, а смена с Simple на Full тоже понятна, остается маленький (может и глупый) вопрос:
что именно вы советуете оптимизировать?
всю базу целиком (полная оптимизация займет не один день...)? если да, то смену Simple на Full делать только полной оптимизации или можно перед началом?

и еще такой вопрос, пытался установить Auto Shrink во время востановления БД на SQLе, получал ошибку о том что LOG файл переполнен, есть ли какая то возможность использовать что то подобное во время востановления? и в какой то из тем, говорилось что при выставление флага Auto Shrink база начинает значительно подтормаживать, так ли это?
Старый 08.06.2009, 11:12   #22  
yes is offline
yes
Участник
 
53 / 10 (1) +
Регистрация: 08.07.2008
Нужен совет - хватит ли для SQL Server (используя для navision 4/0) сервера с следующей конфигурацией:
CPU - Intel Xeon 3.4 GHz (двухядерный)
Ram - 2GB
Исходя из кол-ва пользователей - 35.
Старый 10.06.2009, 19:39   #23  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от yes Посмотреть сообщение
Нужен совет - хватит ли для SQL Server (используя для navision 4/0) сервера с следующей конфигурацией:
CPU - Intel Xeon 3.4 GHz (двухядерный)
Ram - 2GB
Исходя из кол-ва пользователей - 35.
Недавно видел документ, который показывает расчет Сервера в зависимости от пользовательской нагрузки. Сейчас нет возможности поискать.
Может старшие товарищи помогут???
Старый 10.06.2009, 19:43   #24  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от Thrice Посмотреть сообщение
советы про Recovery model постараюсь протестить в ближайшее время, а смена с Simple на Full тоже понятна, остается маленький (может и глупый) вопрос:
что именно вы советуете оптимизировать?
всю базу целиком (полная оптимизация займет не один день...)? если да, то смену Simple на Full делать только полной оптимизации или можно перед началом?
Не путайте смену модели и оптимизации БД для увеличения производительности.
Что именно оптимизировать удаленно не могу сказать парочкой предложений, так как есть куча статей, книг и мнений на эту тему.

Цитата:
и еще такой вопрос, пытался установить Auto Shrink во время востановления БД на SQLе, получал ошибку о том что LOG файл переполнен, есть ли какая то возможность использовать что то подобное во время востановления? и в какой то из тем, говорилось что при выставление флага Auto Shrink база начинает значительно подтормаживать, так ли это?
Я пока не видел надобности сразу ставить этот флаг.
Старый 29.06.2009, 19:17   #25  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от yes Посмотреть сообщение
Нужен совет - хватит ли для SQL Server (используя для navision 4/0) сервера с следующей конфигурацией:
CPU - Intel Xeon 3.4 GHz (двухядерный)
Ram - 2GB
Исходя из кол-ва пользователей - 35.
Нашёл ДОКУ. Hardware Guide for Dynamics – NAV называется. ТАм есть запись:

Цитата:
Sizing Formula for Dynamics – NAV clients and Windows Terminal Services†
10-15 Dynamics – NAV users per processor core depending on work load 64 MB of Memory per Dynamics – NAV user (assumes an object cache of 32 MB) 1 GB of Memory for the Operating System Internal SCSI or SAS RAID 1 10 – 15K RPM with 500 MB of disk space available for each user 1 Gigabit Ethernet connection † These recommendations assume that Microsoft Dynamics – NAV will be the only application running on under Windows Terminal Services. If Microsoft Office or other application will be deployed on Windows Terminal Services in addition to the Dynamics – NAV client the hardware recommendations will need to be taken into account in addition to those the Microsoft Dynamics – NAV client. Example 100 Dynamics – NAV users; CPU 100 users / 10 users per processor core = 10 cores†† or 100 users / 15 users per core = 6.67 cores which really equates to 8 cores††
For this example, a 4-way dual core or 2-way quad core server would be the recommended choice. Because Dynamics – NAV is utilizing client side cursors you may consider more smaller Terminal Servers for better network bandwidth such as 2 2-way dual core or 2 1-way quad core servers. RAM (100 users X 64 MB per user) + 1 GB for the OS = 7400 MB which equates to 8 GB of RAM For this example if you deployed a 4 way dual core server all 8 GB of RAM would installed on the that server and the same holds true the 2 way quad core machines. If you deploy multiple Terminal Servers the RAM calculation is a little different as we must figure in the 1 GB or RAM for the OS on each server. (50 users X 64 MB per user) + 1 GB for the OS = 4200 (4 or 6 GB of RAM)
In this example, you will need to take into account workload and activity to decide whether the 4 GB will be sufficient or you will need to scale up to 6 GB DISK 100 users X 500 MB per user = 50000 MB or 50 GB For this example we would recommend two internal 146 GB 15K RPM SCSI or SAS drives in a RAID 1 configuration to hold the Dynamics – NAV temp files, OS and program files, page file, and anything else installed on the Terminal Server. †† It is recommended that you use both calculations to find a feasible recommendation that can be applied to currently available hardware.
Если нужно по остальным деталям, таким как Storage, OS, Intel and AMD processors, Dual Core and Quad Core processors and Windows Terminal Services - пишите в личку
Старый 06.07.2009, 16:05   #27  
yes is offline
yes
Участник
 
53 / 10 (1) +
Регистрация: 08.07.2008
Этотт документ я находил. Мне же нужно для 4.0. Хотя, если требования одинаковы, тогда вопросов больше нет.
Старый 06.07.2009, 16:31   #28  
apanko is offline
apanko
MCTS
MCBMSS
Лучший по профессии 2009
 
1,164 / 139 (7) +++++
Регистрация: 24.02.2005
Цитата:
Сообщение от yes Посмотреть сообщение
Этотт документ я находил. Мне же нужно для 4.0. Хотя, если требования одинаковы, тогда вопросов больше нет.
Так далеко назад не читал. Извините.

Но для четверки есть. Правда на английском.

Вот ссылка на CustomerSource (нужен пароль). https://mbs.microsoft.com/Cms/Templates/doc...B-A4978C0913FA}
или он же но через PartnerSource https://mbs.microsoft.com/Cms/Templates/doc...B-A4978C0913FA} - с их ссылками не разобраться.

Вот ссылка в общем доступе. http://www.abc-computers.com/Support/Docum...0Whitepaper.pdf



UPD. И кто бы мог подумать Оборудование для Navision
Старый 15.01.2010, 12:31   #29  
yes is offline
yes
Участник
 
53 / 10 (1) +
Регистрация: 08.07.2008
Перевели Nav с Native на SQL. Navision 4.0 SP3. файл БД лежит на одном Raid 5 (SCSI), лог лежит на Raid 1 (SCSI). Сервер - 1 CPU Intel Xeon 3.4 Ghz, Ram - 3 Gb Win Server Rs Standart SP2.
Из видимых пользователями плюсов получили значительное ускорение выполнения различных "тяжелых" отчетов. Из видимых минусов - счета-накладные покупки-продаж стали учитываться медленнее. На глаз коэффициент замедления учета составил 1.3 - 1.4.
Вопроc - возможно ли ускорить учет документов?
Старый 15.01.2010, 12:51   #30  
RedFox is offline
RedFox
Участник
 
1,441 / 10 (0) +
Регистрация: 28.12.2004
Адрес: Киев
Цитата:
Сообщение от yes Посмотреть сообщение
Перевели Nav с Native на SQL. Navision 4.0 SP3. файл БД лежит на одном Raid 5 (SCSI), лог лежит на Raid 1 (SCSI). Сервер - 1 CPU Intel Xeon 3.4 Ghz, Ram - 3 Gb Win Server Rs Standart SP2.
Из видимых пользователями плюсов получили значительное ускорение выполнения различных "тяжелых" отчетов. Из видимых минусов - счета-накладные покупки-продаж стали учитываться медленнее. На глаз коэффициент замедления учета составил 1.3 - 1.4.
Вопроc - возможно ли ускорить учет документов?
Для начала можете посмотреть сколько выполняются отдельные операции, чтобы потом именно это оптимизировать (а не искать на абум)?
Старый 15.01.2010, 16:38   #31  
rmv is offline
rmv
Участник
 
481 / 11 (1) +
Регистрация: 15.02.2005
Цитата:
Сообщение от yes Посмотреть сообщение
Перевели Nav с Native на SQL. Navision 4.0 SP3. файл БД лежит на одном Raid 5 (SCSI), лог лежит на Raid 1 (SCSI). Сервер - 1 CPU Intel Xeon 3.4 Ghz, Ram - 3 Gb Win Server Rs Standart SP2.
Из видимых пользователями плюсов получили значительное ускорение выполнения различных "тяжелых" отчетов. Из видимых минусов - счета-накладные покупки-продаж стали учитываться медленнее. На глаз коэффициент замедления учета составил 1.3 - 1.4.
Вопроc - возможно ли ускорить учет документов?
Время увеличилось из-за заполнения сифтов на учетных таблицах. В Native DB они физически хранятся вместе с индексами, SQL версии до 5.0 - в таблицах и заполняются на триггерах SQL, начиная с 5.0 сделали индексированные view.
Не думаю что сильно поможет, но все же попробуйте пранализировать индексы и поотключать галки "Maintain Sift Index" на ненужных уровнях. Лучший результат даст перевод на клиента 5.0 и сервер SQL не ниже 2005.
Старый 22.01.2010, 14:49   #32  
yes is offline
yes
Участник
 
53 / 10 (1) +
Регистрация: 08.07.2008
Цитата:
Для начала можете посмотреть сколько выполняются отдельные операции, чтобы потом именно это оптимизировать (а не искать на абум)?
Самыми долгими получились операции Insert в таблицы Item Ledger Entry и Valuw Entry (1500959 и 2380428 записей соответственно) - от 203мс до 1200мс
Старый 22.01.2010, 14:53   #33  
yes is offline
yes
Участник
 
53 / 10 (1) +
Регистрация: 08.07.2008
Цитата:
Время увеличилось из-за заполнения сифтов на учетных таблицах. В Native DB они физически хранятся вместе с индексами, SQL версии до 5.0 - в таблицах и заполняются на триггерах SQL, начиная с 5.0 сделали индексированные view.
Не думаю что сильно поможет, но все же попробуйте пранализировать индексы и поотключать галки "Maintain Sift Index" на ненужных уровнях. Лучший результат даст перевод на клиента 5.0 и сервер SQL не ниже 2005.
SQL стоит 2008 Standart. По поводу отключения "Maintain Sift Index"... Как определить, в каком ключе он нужен, а в каком не нужен?
Старый 22.01.2010, 16:47   #34  
Cheb is offline
Cheb
Участник
Лучший по профессии 2017
 
138 / 13 (1) ++
Регистрация: 22.09.2002
Адрес: Ростов-на-Дону -> Москва
Цитата:
Сообщение от yes Посмотреть сообщение
Цитата:
Время увеличилось из-за заполнения сифтов на учетных таблицах. В Native DB они физически хранятся вместе с индексами, SQL версии до 5.0 - в таблицах и заполняются на триггерах SQL, начиная с 5.0 сделали индексированные view.
Не думаю что сильно поможет, но все же попробуйте пранализировать индексы и поотключать галки "Maintain Sift Index" на ненужных уровнях. Лучший результат даст перевод на клиента 5.0 и сервер SQL не ниже 2005.
SQL стоит 2008 Standart. По поводу отключения "Maintain Sift Index"... Как определить, в каком ключе он нужен, а в каком не нужен?
Да смело отключайте на всех ключах. Потом включите по необходимости, если где-то будет из-за этого падение производительности. В целом, сифты нужны на небольших ключах, в которых первые поля имеют сравнительно небольшое число значений, т.е. низкую селективность. Например, в таблице 17, это ключ, начинающийся с "G/L Account No.". Если же ключ имеет высокую селективность, то сифты не нужны, СКЛ-сервер посчитает все даже быстрее, чем если бы они были.
Старый 13.05.2010, 11:59   #35  
zo_dor is offline
zo_dor
Участник
 
14 / 10 (1) +
Регистрация: 05.11.2009
сорри! ни в ту темку написала(((
 

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

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

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

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

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