Nav - SQL

[Thrice]

Цитата:

Сообщение от 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 база начинает значительно подтормаживать, так ли это?

[yes]

Нужен совет - хватит ли для SQL Server (используя для navision 4/0) сервера с следующей конфигурацией:
CPU - Intel Xeon 3.4 GHz (двухядерный)
Ram - 2GB
Исходя из кол-ва пользователей - 35.

[RedFox]

Цитата:

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

Нужен совет - хватит ли для SQL Server (используя для navision 4/0) сервера с следующей конфигурацией:
CPU - Intel Xeon 3.4 GHz (двухядерный)
Ram - 2GB
Исходя из кол-ва пользователей - 35.

Недавно видел документ, который показывает расчет Сервера в зависимости от пользовательской нагрузки. Сейчас нет возможности поискать.
Может старшие товарищи помогут???

[RedFox]

Цитата:

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

советы про Recovery model постараюсь протестить в ближайшее время, а смена с Simple на Full тоже понятна, остается маленький (может и глупый) вопрос:
что именно вы советуете оптимизировать?
всю базу целиком (полная оптимизация займет не один день...)? если да, то смену Simple на Full делать только полной оптимизации или можно перед началом?

Не путайте смену модели и оптимизации БД для увеличения производительности.
Что именно оптимизировать удаленно не могу сказать парочкой предложений, так как есть куча статей, книг и мнений на эту тему.

Цитата:

и еще такой вопрос, пытался установить Auto Shrink во время востановления БД на SQLе, получал ошибку о том что LOG файл переполнен, есть ли какая то возможность использовать что то подобное во время востановления? и в какой то из тем, говорилось что при выставление флага Auto Shrink база начинает значительно подтормаживать, так ли это?

Я пока не видел надобности сразу ставить этот флаг.

[RedFox]

Цитата:

Сообщение от 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 - пишите в личку

[apanko]

Прям на сайте MS висит. Причем на русском:
http://www.microsoft.com/Rus/dynamics/nav/useful.mspx
Аппаратные требования Microsoft Dynamics NAV 5.0

[yes]

Этотт документ я находил. Мне же нужно для 4.0. Хотя, если требования одинаковы, тогда вопросов больше нет.

[apanko]

Цитата:

Сообщение от 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

[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 - возможно ли ускорить учет документов?

[RedFox]

Цитата:

Сообщение от 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 - возможно ли ускорить учет документов?

Для начала можете посмотреть сколько выполняются отдельные операции, чтобы потом именно это оптимизировать (а не искать на абум)?

[rmv]

Цитата:

Сообщение от 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.

[yes]

Цитата:

Для начала можете посмотреть сколько выполняются отдельные операции, чтобы потом именно это оптимизировать (а не искать на абум)?

Самыми долгими получились операции Insert в таблицы Item Ledger Entry и Valuw Entry (1500959 и 2380428 записей соответственно) - от 203мс до 1200мс

[yes]

Цитата:

Время увеличилось из-за заполнения сифтов на учетных таблицах. В Native DB они физически хранятся вместе с индексами, SQL версии до 5.0 - в таблицах и заполняются на триггерах SQL, начиная с 5.0 сделали индексированные view.
Не думаю что сильно поможет, но все же попробуйте пранализировать индексы и поотключать галки "Maintain Sift Index" на ненужных уровнях. Лучший результат даст перевод на клиента 5.0 и сервер SQL не ниже 2005.

SQL стоит 2008 Standart. По поводу отключения "Maintain Sift Index"... Как определить, в каком ключе он нужен, а в каком не нужен?

[Cheb]

Цитата:

Сообщение от 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.". Если же ключ имеет высокую селективность, то сифты не нужны, СКЛ-сервер посчитает все даже быстрее, чем если бы они были.

[zo_dor]

сорри! ни в ту темку написала(((