|
17.05.2007, 13:19 | #1 |
Участник
|
Здравствуйте!
Внедрили навижн 4.0 СП1, торговля и склад. Есть база центральная (4.0 SQL) и удаленные (4.0 Nav). База находится на сервере с операционкой Win2k Advanced Server. Репликация проходит средствами разработанными Ландштайнером и прогерами IBS (задействован NAS-Navision Application Server). Так вот, очень часто НАС падает и по этой причине планировщик не работает и репликация не проходит. В журнале приложений выскакивает ошибка: Internal error 2 in module 5. Contact your dealer if you need assistance. или Internal error 2 in module 7. Contact your dealer if you need assistance. Наши интеграторы думают, что все это из-за СП1 и предлагают перейти на СП3, мол, все проблемы с НАС-ом пропадут (переход будет ТОЛЬКО в ЦБ, удаленные базы не будут переходить) 1-й вопрос: Действительно переход на СП3 может решить данную проблему? Т.к. придется проделать огромную работу по переходу с СП1 на СП3 (бэкап, установка клиентов ЦБ, настройки и т.д.) и если нет смысла, то зачем заморачиваться... 2-й вопрос: если переходить на СП3, какие подводные камни могут встретиться на пути?... Спасибо заранее! |
|
17.05.2007, 13:43 | #2 |
Участник
|
Цитата:
Сообщение от Daemon
Здравствуйте!
Внедрили навижн 4.0 СП1, торговля и склад. Есть база центральная (4.0 SQL) и удаленные (4.0 Nav). База находится на сервере с операционкой Win2k Advanced Server. Репликация проходит средствами разработанными Ландштайнером и прогерами IBS (задействован NAS-Navision Application Server). Так вот, очень часто НАС падает и по этой причине планировщик не работает и репликация не проходит. В журнале приложений выскакивает ошибка: Internal error 2 in module 5. Contact your dealer if you need assistance. или Internal error 2 in module 7. Contact your dealer if you need assistance. Наши интеграторы думают, что все это из-за СП1 и предлагают перейти на СП3, мол, все проблемы с НАС-ом пропадут (переход будет ТОЛЬКО в ЦБ, удаленные базы не будут переходить) 1-й вопрос: Действительно переход на СП3 может решить данную проблему? Т.к. придется проделать огромную работу по переходу с СП1 на СП3 (бэкап, установка клиентов ЦБ, настройки и т.д.) и если нет смысла, то зачем заморачиваться... 2-й вопрос: если переходить на СП3, какие подводные камни могут встретиться на пути?... Спасибо заранее! Может что-то прогерами IBS намучено (задействованный NAS обычно используется только, чтобы сервис запускать периодически), поэтому и падает... |
|
17.05.2007, 14:12 | #3 |
Участник
|
То есть, НАС не падает?..
NAS установлен как служба, запускается под логином винды..Частенько что-то обновляют в базе, в частности добавляют поля в таблицах или репорты/кодюниты меняют. NAS запускает исключительно кодюниты репликации (выгрузка/загрузка файлов *.pkg).. И еще: синхронизация логинов..Часто слетает синхронизация, и потом приходится либо синхронизировать все логины (во время работы пользователей практически невозможно, т.к. лочат таблицы), либо синхронизировать по одному логину.. Почему может слетать синхронизация? |
|
17.05.2007, 14:36 | #4 |
Участник
|
Цитата:
Цитата:
И еще: синхронизация логинов..Часто слетает синхронизация, и потом приходится либо синхронизировать все логины (во время работы пользователей практически невозможно, т.к. лочат таблицы), либо синхронизировать по одному логину.. Почему может слетать синхронизация?
|
|
17.05.2007, 16:36 | #5 |
Moderator
|
NAS не умеет перечитывать измененные объекты в кэш. Так что ошибка может из-за этого возникать. Сам на это натыкался не раз.
Попробуйте перезапускать его после изменений объектов (естественно только таблицы и кодеюниты, ну может еще репорты). И еще, можете заменить екзешник и библиотеки на SP3 - кое что там исправили, но только в нерабочее время, а то там аутентификацию изменили. |
|
17.05.2007, 17:16 | #6 |
Участник
|
А NAS не должен это делать - функции у него другие. Это может делать Data Director (если прогеры IBS этот продукт Вам поставили). По крайней мере я видел такой функционал у него, но не настраивал (не нужно было).
|
|
18.05.2007, 09:07 | #7 |
Участник
|
Dzemon говорил не о распространении объектов в распределенной базе, а о том, что если NAS запустил какой-либо объект, то этот объект попадает в кэш NAS, и если после этого объект изменить, NAS не обновит его в кэше и будет работать со старой версией. Data Director тут не поможет.
|
|
18.05.2007, 10:44 | #8 |
Участник
|
базах
Цитата:
а о том, что если NAS запустил какой-либо объект, то этот объект попадает в кэш NAS, и если после этого объект изменить, NAS не обновит его в кэше и будет работать со старой версией. Data Director тут не поможет.
2. Я пишу из собственного проблемного опыта (в том числе и по ДД), а Вам решать поможет это или нет. У меня менялось куча объектов (в том числе и 1), которые нужно было переносить на другие удаленные базЫ. Но из-за этого NAS не отваливался ни разу и работал стабильно. Для переноса видел функционал в Data Director. |
|
22.05.2007, 17:48 | #9 |
Участник
|
Цитата:
1-й вопрос: Действительно переход на СП3 может решить данную проблему? Т.к. придется проделать огромную работу по переходу с СП1 на СП3 (бэкап, установка клиентов ЦБ, настройки и т.д.) и если нет смысла, то зачем заморачиваться...
Файлы с диска Nav SP3. ЗЫ Второй загрузить места не хватает, но думаю этого будет достаточно... |
|
04.05.2008, 10:26 | #10 |
Участник
|
Ребяты, всем спасибо!
У меня есть СП3, и доки по нему. Пока на тестовом серваке пробую. Такой вопросец: Если разворачиваю бэкап скл2000 на 2005-й скл, цепляюсь клиентом сп3, он конвертит базу (предлагает сразу), потом делаю бэкап навиком, создаю пустую базу в скл2005 и восстанавливаю, он статистику считай собрал или нет? Наблюдение следующее: Запускали прогеры свои обработки, работал шустренько, потом начал тормозить (это просто делал восстановление бэкапа скл2000 на 2005-й, потом конвертация клиентом). Я так понимаю, тормозить начал, т.к. собирать статистику пошел. Так вот они запустили оптимизацию таблиц и зашустрило опять. Оптимизация таблиц - делает сбор статистики? Другими словами, как лучше проделать чтоб быстрее статистику собрать? А то крики пойдут недетские, 3 дня тормозов, сами понимаете |
|
05.05.2008, 12:39 | #11 |
Участник
|
Цитата:
Цитата:
Наблюдение следующее: Запускали прогеры свои обработки, работал шустренько, потом начал тормозить (это просто делал восстановление бэкапа скл2000 на 2005-й, потом конвертация клиентом). Я так понимаю, тормозить начал, т.к. собирать статистику пошел. Так вот они запустили оптимизацию таблиц и зашустрило опять.
Что такие - оптимизация табли в Вашем понимании не очень понял (может быть оптимизация содержимого таблиц иликода Нава), поэтому лучше уточнить у этих спецов. Цитата:
Оптимизация таблиц - делает сбор статистики?
Другими словами, как лучше проделать чтоб быстрее статистику собрать? А то крики пойдут недетские, 3 дня тормозов, сами понимаете + SQL admin should keep on checking the scan density on tables by running DBCC SHOWCONTIG (+DBCC INDEXDEFRAG, DBCC DBREINDEX ), (on SQL 2000) and + sys.dm_db_index_physical_stats (on SQL 2005). If the scan density on a table is less than 75%, then we need to rebuild of indexes of that table (http://msdn.microsoft.com/en-us/library/ms188796.aspx). (3) Key usage statistics - Time to time SQL admin should keep on checking the key usage statistics on table.Those keys which are not or rarely usaged should be dropped. |
|