Nav - SQL

[djime]

Добрый день!

Есть необходимость перевести одного нашего клиента с Nav DB на SQL 2005.

В связи с чем возникает так же много вопросов:

1. Возможно ли Конвертация базы? Если да, то какими средствами?
2. В связи с тем что у клиента стали появляться филиалы, меня так же интересует как можно организовать средствами SQL (или иными средствами) режимы работы On-line/Off-line?
3. Какие образом в этом случае будет распределена БД, формат репликации и с какой периодичностью?
4. Какова надежность распределенной бд, ее отказаустойчивость?
5. Как можно организовать backup в филиалах в случае обрушения системы либо некорректного ввода данных/
6. Какие в этом случае будут требования к каналам связи: пропусная способность, надежность?
7. Безопасность передачи реплицируемых данных (формат передачи, шифрование)

[Forward]

1. Возможна. Сделайте бекап, потом запустите Microsoft SQL Server Option, создайте БД, разверните бекап. Подробнее можно посмотреть в доках по инсталляции и конфигурации.
2. Можно и средствами SQL, но намучаетесь. Есть 2 (известных мне) решения по репликации для Nav - это Smart Retail Suite и Landstainer. Это что касается движения документов и всего что с ними связано (српавочников и т.д.), если нужно видеть просто обороты по счетам, то есть консолидация.
3. Зависит от решения.
4. Непонятен критерий оценки. Ненадежно все что есть на земле, самолеты бьются, поезда сходят с рельсов, башни обрушаются.
5. Стандартными средствами, либо если работаете на SQL - средствами sql.
6. Если говорить о двух решениях которые я упоминал выше - то треботвания к каналам вполне демократичные.
7. Формат - бинарный файл. В Smart Retail Suite можно шифровать PGP. Только вот боюсь что даже незашифрованный файл никому не нужен.

[Fordewind]

Честно говоря, страшно слышать такие вопросы из уст сотрудника внедряющей компании...

[djime]

Согласен, работаем не давно, и опыта с nav - БД SQL не было

Цитата:

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

Честно говоря, страшно слышать такие вопросы из уст сотрудника внедряющей компании...

Насколько я правильно подобные форумы, для этого и нужны, помогать молодым, делиться опытом и проч...

[Fordewind]

Цитата:

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

Согласен, работаем не давно, и опыта с nav - БД SQL не было



Насколько я правильно подобные форумы, для этого и нужны, помогать молодым, делиться опытом и проч...

Вы абсолюьно правильно понимаете цель таких форумов

Но я и не говорил, что такие вопросы тут нельзя задавать. Я имел в виду, что клиент доверяет вашей компании внедрение системы, как профессионалам... Т.е. вы не имеете права быть "зеленым" в Navision...

Кстати, по вашему вопросу. Для филиалов можно использовать удаленный доступ к серваку через CITRIX или обычный удаленный рабочий стол. При этом SQL нипричем, а работа идет on-line. Основной вопрос в скорости доступа в инет у филиалов и кол-ве одновременных пользователей в базе... Здесь это не раз обсуждалось.

[djime]

Цитата:

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

Вы абсолюьно правильно понимаете цель таких форумов

Но я и не говорил, что такие вопросы тут нельзя задавать. Я имел в виду, что клиент доверяет вашей компании внедрение системы, как профессионалам... Т.е. вы не имеете права быть "зеленым" в Navision...

Кстати, по вашему вопросу. Для филиалов можно использовать удаленный доступ к серваку через CITRIX или обычный удаленный рабочий стол. При этом SQL нипричем, а работа идет on-line. Основной вопрос в скорости доступа в инет у филиалов и кол-ве одновременных пользователей в базе... Здесь это не раз обсуждалось.

Это вариант мы обдумывали..., и этот вариант был реализован в другом проекте, вот мы там набили себе шишек с этим on-line.
Деятельность компании предполагает синхронизацию данных раз в сутки. Поэтому вариант с Citrix откинули сразу, за дороговизну и проблемность
Но все равно спасибо!

[RedFox]

Цитата:

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

Добрый день!

Есть необходимость перевести одного нашего клиента с Nav DB на SQL 2005.

В связи с чем возникает так же много вопросов:
1. Возможно ли Конвертация базы? Если да, то какими средствами?
2. В связи с тем что у клиента стали появляться филиалы, меня так же интересует как можно организовать средствами SQL (или иными средствами) режимы работы On-line/Off-line?

2. Средствами SQL можно сделать, но нужно нелохо разбираться в репликации 2005. При этом нужно знать небольшой подводный камень - перенос TINESTAMP- полей должен осуществляться как "image".
Кроме LS & SRS есть еще решения по репликации на рынке (вевсь список не пишу, так как могут "обвинить" в неполноте), но эти просто сильно распространены и хорошо изучены.

Цитата:

3. Какие образом в этом случае будет распределена БД, формат репликации и с какой периодичностью?
4. Какова надежность распределенной бд, ее отказаустойчивость?

Периодичность репликации определяете Вы исходя из Ваших возможностей и потребностей в обновлении информации.
Надежность распределенных систем больше, чем одной, так как вероятность утери всей информации ниже. Так же снижается влияние человеческого фактора на всю систему вцелом. Термин "Отказоустойчивость" более правильно применять к оборудованию и хранилищу данных (мое мнение - отказоустойчивость SQL выше, чем Native, но сложность работы больше).

Цитата:

5. Как можно организовать backup в филиалах в случае обрушения системы либо некорректного ввода данных/

Ну ут Вам уже решать в зависимости от того как и на чем (Hardware structure, Native & SQL) Вы построите распределенную систему.

Цитата:

6. Какие в этом случае будут требования к каналам связи: пропусная способность, надежность?
7. Безопасность передачи реплицируемых данных (формат передачи, шифрование)

Ответы на последние 2 вопроса можно будет получить, определившись с топологией сети и методами передачи данных. Еще раз пишу, что каналы связи зависят от метода и способа передачи (уточняю, что это разные понятия). А вот формат и шифрование это уже производные из пункта 6 и системы безапасности, принятой на Предприятии.

P.S. Вы случайно не статью какую пишите или Технико-Экономическое Обоснование?

[djime]

Цитата:

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

P.S. Вы случайно не статью какую пишите или Технико-Экономическое Обоснование?

Скорее второе, надо все предусмотреть и просчитать для начала.

[yes]

Тестирую переход на SQL Server 2005. БД Navision 4.0 SP3. В развернутом виде БД(fdb) весит 46GB (из них данными занято 37 GB), в бэкапленном виде(fbk) занимает примерно 20GB. После восстановления на движке SQL файлы mdf и ndf в сумме занимали 21GB а файл ldf весил аж 65GB. Врезультате БД выросла в размере в два с лишком раза. Что сделал неверно?

[RedFox]

Цитата:

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

Тестирую переход на SQL Server 2005. БД Navision 4.0 SP3. В развернутом виде БД(fdb) весит 46GB (из них данными занято 37 GB), в бэкапленном виде(fbk) занимает примерно 20GB. После восстановления на движке SQL файлы mdf и ndf в сумме занимали 21GB а файл ldf весил аж 65GB. Врезультате БД выросла в размере в два с лишком раза. Что сделал неверно?

1. Тестируйте сразу переход под SQL 2008.
2. При востановлении БД используйте Recovery model Simple, а не Full. После восстановления (и советую сделать оптимизацию) поменяете с Simple на Full.
3. Установите Auto Shrink

Цитата:

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

P.S. Касательно увеличения размера БД. Вот как раз пример платформенной реализации работы с SQL сервером (в данном случае - технологии SIFT). На 5 клиенте, например, она реализована с использованием View, а не физических таблиц, как, например, в 3 или 4.

Мне кажется, что верно будет уточнение по SIFT: кол-во данных не СИЛЬНО изменилось, а только "трансформировалось". До 5.0 SP1 W1 (она же 5.0 RU) были таблицы согласно ключей, после - View (так как SQL Server 2005 позволяет делать их по аналогии с таблицами и быстро полкучать данные). Сравните 2 инсталляции по кол-ву таблиц, в том числе и SIFT-таблиц.

Цитата:

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

Есть ли разница для Navision какой SQL Server использовать - 2005 vs 2008 ?

Если поднять с native до версии 5.0, то я бы ставил уже SQL Server 2008, так как с него проще будет перейти на след. "версию", которую как обычно хотя под R2 того же 2008 замаскировать..

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

[RedFox]

Цитата:

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

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

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

Цитата:

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

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

[rmv]

Yes Вы все сделали верно.
Размер базы вырос из-за особенностей реализации технологии SIFT в SQL версии Навижна

[yes]

А я тихнечко лелеял надежду что при переходе на SQL база хоть чуть-чуть, но уменьшится

[yes]

удалил за ненадобностью

[yes]

Есть ли разница для Navision какой SQL Server использовать - 2005 vs 2008 ?

[foxsoft2005]

Цитата:

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

Есть ли разница для Navision какой SQL Server использовать - 2005 vs 2008 ?

Вообще разница в версии SQL сервере есть, но не стоит рассматривать в данном контексте SQL сервер "сам по себе". Он идет только в купе с конкретной версией клиента NAV, так как есть еще некая платформенная реализация, зашитая, как раз, в клиенте.

Раз Вы говорите минимум о 2005 сервере - видимо у Вас минимум 4 клиент.. Так?

P.S. Касательно увеличения размера БД. Вот как раз пример платформенной реализации работы с SQL сервером (в данном случае - технологии SIFT). На 5 клиенте, например, она реализована с использованием View, а не физических таблиц, как, например, в 3 или 4.

[Thrice]

Цитата:

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

Вообще разница в версии SQL сервере есть, но не стоит рассматривать в данном контексте SQL сервер "сам по себе". Он идет только в купе с конкретной версией клиента NAV, так как есть еще некая платформенная реализация, зашитая, как раз, в клиенте.

Раз Вы говорите минимум о 2005 сервере - видимо у Вас минимум 4 клиент.. Так?

P.S. Касательно увеличения размера БД. Вот как раз пример платформенной реализации работы с SQL сервером (в данном случае - технологии SIFT). На 5 клиенте, например, она реализована с использованием View, а не физических таблиц, как, например, в 3 или 4.

именно так, сейчас стоит Navision 4.0 SP3, что посоветуете под него? и какова будет сложность перехода на более новые платформы NAV'a, при выборе например 2005 сервера?

про размер БД: специалисты из microsoft для уменьшения LOG файла, посоветовали использовать функцию ShrinkFile (можно уменьшить размер файла к примеру до 800 мб), но еще до этого мы столкнулись с проблемой, размер развернутой БД в SQL'е занимает больше чем есть места на винчестере рабочего сервера. Есть ли возможность как то ограничить размер LOG файла в процессе восстановления из бэкапа?

[Thrice]

Добрый день!
Тестируем переход БД с Native сервера на SQL.
Развернули базу и т.д. по инстркуции востанволения. Теперь пытаюсь запустить App Server, установил службу, добавил пользователя в БД (логин для App Server) с аунтификацией Windows, дал ему права SUPER, после чего запускаю службу. После чего пользователь NAS не появляется в списке активных сессий, а в логах винды появляются ошибки:

Event Type: Warning
Event Source: SQL
Event Category: None
Event ID: 20010
Date: 14.05.2009
Time: 15:44:23
User: N/A
Computer: SERVER
Description:
The Navision Application Server SQL could not initialize properly.
The server will attempt to initialize every 30 seconds until this is successful.


и


Event Type: Warning
Event Source: SQL
Event Category: None
Event ID: 20010
Date: 14.05.2009
Time: 15:44:23
User: N/A
Computer: SERVER
Description:
The definition of the field User ID was changed after the object was saved.

Old type: Code
New type: Text

в чем моя ошибка?

команда с помощью которой создаю APP SERVER: nassql.exe appservername=SQL, servername=SERVER, database=CRONUS, company=ООО "Кронус", startupparameter=GO_PRICING, installasservice

[foxsoft2005]

Цитата:

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

Добрый день!
...
в чем моя ошибка?

команда с помощью которой создаю APP SERVER: nassql.exe appservername=SQL, servername=SERVER, database=CRONUS, company=ООО "Кронус", startupparameter=GO_PRICING, installasservice

Ошибки в настройке нет, тут другое.

Ошибка связана со свойством SingleInstance кодюнита 1 и изменением объектов, которые в нем исользуются (например, табл. User).
Сделайте следующее:

1. Стопим NAS.
2. Заходим обычным(!) клиентом.
3. Компилим (F11) кодюнит 1.
4. Закрываем обычный клиент.
5. Стартуем NAS.