Advantage Product Version Matrix:
http://devzone.advantagedatabase.com/dz/content.aspx?key=31
DBEng32 (6.0.4.2, Advantage 8.1/9.1) - клиент/серверное использование DBFной версии 1С:Предприятие 7.7
Разработка - Разработка внешних компонент
Аналогичная разработка: http://infostart.ru/projects/811/
Скачать файлы
Наименование | Файл | Версия | Размер | |||
---|---|---|---|---|---|---|
BIN_ADS_6042.ZIP
.ZIP 1,84Mb
531
|
.ZIP | 1,84Mb | 531 | Скачать бесплатно | ||
AddInExt_1008.zip
.zip 14,64Kb
186
|
.zip | 14,64Kb | 186 | Скачать бесплатно | ||
BIN_ADS_6040.ZIP
.ZIP 1,84Mb
235
|
.ZIP | 1,84Mb | 235 | Скачать бесплатно | ||
BIN_ADS_6038.ZIP
.ZIP 1,83Mb
114
|
.ZIP | 1,83Mb | 114 | Скачать бесплатно |
См. также
HTTP сервер 1С 7.7 + HTTP асинхронный клиент: внешние компоненты для 1С 7.7
Разработка внешних компонент WEB-интеграция Платформа 1С v7.7 Конфигурации 1cv7 Платные (руб)
Компонента HttpSrv7 позволяет создавать веб-сервисы в среде 1С 7.7 и даже, используя файлы HTML, несложные веб-сайты. С помощью нее можно обеспечить доступ к данным 1С 7.7 из браузера. Дополнительно используя компоненту HTTP_Async или синхронный клиент HTTP для 1С 7.7 (публикация № 1152364) можно наладить обмен данными между удаленными информационными базами. С помощью компоненты HTTP_Async можно параллельно посылать много запросов к сайтам, веб-сервисам (в т.ч. к HttpSrv7), а затем обрабатывать данные по мере их поступления.
2000 руб.
27.05.2022 7813 19 13
Компонента ExchangeStruc (Структура Обмена). Прямой обмен данными между потоками, сессиями и окнами.
Разработка внешних компонент Платформа 1С v7.7 Платформа 1С v8.3 Платформа 1C v8.2 Платформа 1С v8.1 Россия Платные (руб)
Аддон "Структура Обмена" (ExchangeStruc) - это компонента, которая обеспечивает доступ к разделяемым процессом структурам, аналогичным структурам 1С. Обеспечивает прозрачную передачу данных примитивных типов, в том числе Двоичных данных, в режиме Реального времени между разными контекстами (формами) или потоками одного процесса. В перспективе функционал будет расширен для обмена между процессами, даже разных версий платформ. Совместим с версиями Windows рабочих станций и серверов, с платформами 1С разных версий и релизов в режиме Native начиная с 8.2, и в режиме COM начиная с версий 7.7. По скорости чтения и записи лишь немногим уступает стандартной структуре 1С. НОВОЕ: Добавлен функционал регистрации компоненты COM в качестве OLE Auto (COMОбъект) для поддержки её работы в серверах старых версий 1С: 8.0 и 8.1, где работа с компонентами исключена. Теперь можно коммуникацию с Фоновыми заданиями на этих версиях проводить.
7200 руб.
19.04.2023 4802 1 0
Выбор из большого списка (для 1С 7.7)
Разработка внешних компонент Платформа 1С v7.7 Платные (руб)
Компонента для выбора значения из больших списков значений.
1200 руб.
02.12.2021 5779 2 19
Внешняя компонента для преобразования файлов из/в кодировку Base64 в 1С 7.7
Разработка внешних компонент Файловый обмен (TXT, XML, DBF), FTP Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)
Эта внешняя компонента Base64.dll предназначена для платформы 1С версии 7.7. Используется для преобразования файлов из/в кодировку Base64 из встроенного языка 1С Предприятие. Компонента тестировалась на базе конфигурации Бухгалтерский учет для Казахстана, редакции 7.70.257.
10 стартмани
06.04.2021 9452 14 softmaker 12
Криптография: внешняя компонента для 1С 7.7
Разработка внешних компонент Защита ПО и шифрование Платформа 1С v7.7 Абонемент ($m)
Цифровые подписи, шифрование, просмотр сертификатов ключей ЭЦП, работа с различными криптопровайдерами (в т.ч. КриптоПРО ГОСТ 2012) в 1С 7.7.
1 стартмани
08.06.2020 9053 27 mdbruyfn 10
Протокол UDP: внешняя компонента для 1С 7.7
Разработка внешних компонент Платформа 1С v7.7 Абонемент ($m)
Обмен сообщениями и небольшими файлами по протоколу UDP с 1С и внешними приложениями в локальной сети или сети VPN.
1 стартмани
23.05.2020 7318 5 mdbruyfn 0
JSON: Туда и Обратно
Внешние источники данных Платформа 1С v7.7 Конфигурации 1cv7 Украина Абонемент ($m)
Рабочий механизм чтения/записи строк в формате JSON для 1С 7.7. Тестировалось на релизах 7.70.25 и 27.
1 стартмани
16.12.2019 21955 60 Volvo32 33
Клиент HTTP(S): внешняя компонента для 1С 7.7
Разработка внешних компонент WEB-интеграция Платформа 1С v7.7 Абонемент ($m)
Компонента позволяет использовать различные веб-сервисы интернет-ресурсов, например работать с онлайн-кассой через API, предоставленное ее разработчиком. Тестировалась на платформе 1С релиза 7.70.027.
1 стартмани
14.11.2019 18144 88 mdbruyfn 82
"А как же получены замеры в ADS ?"
Замеры на базе, которую грузил в ADS из romix.dat, и прервал загрузку на этапе расчета итогов, когда пошли вторые сутки формирования БД. Результаты отчета "Анализ счета по субконто" (обороты, остатки) совпадают во всех трех тестах. То-же и для "Реестра документов"
"имеет смысл замерить время выполнение других задач и составить полную картину."
Хорошо, выложу результаты по другим тестам.
"выложу результаты по другим тестам"
И еще, пожалуйста, описание тестовой платформы.
(102)(kerya33)
"конфигурация перенесена из 1сSQL на 1сDBF-ную версию"
Если в "Анализ счета по субконто" используются запросы на штатном языке запросов, то, думаю, ускорить их выполнения можно путем установки "патча" для отключения FlushFileBuffers() на родную библиотеку DBEng33.dll (в нашем случае, именно - 33).
Или направить рабочий каталог на RAM диск большого размера. А в
"И еще, пожалуйста, описание тестовой платформы."
AMD Athlon 64 X2 Dual 2.4ГГц, 4Гб PC-2 6400 RAM, 320Гб SATA, MS Win Server 2003 Enterprise (видит только 3Гб ОЗУ, видео интегрированное и с PAE я пока не стал разбираться да и на тестах в однопользовательском режиме пиковая нагрузка на память не составляла больше 2Гб). MS SQL 2000, ADS 8.1, Codebase в ПДБД режиме из Вашего пакета.
Вторая машина в сети P IV 3ГГц, 512Мб DDR1 3200 RAM, 230Гб SATA, Debian Lenny, сетка 100Мбит. На ней ADS 7.1 и 1cSQL под wine@ethersoft SQL (1С как клиент для MS SQL 2000, который на первой машине). Результаты последних тестов только локальные, на первом компе, хотя выше писАл, что "Реестр документов" на ADS под Linux с клиентом на MS server 2003, выпоняется почти так-же шустро, как и под MS SQL 2000 на первой машине.
"отключения FlushFileBuffers()", "на RAM диск большого размера"
спасибо, буду пробовать.
Анализ счета по субконто
Codebase DBEng33.dll родная 176 сек
Codebase DBEng33.dll патченая 298 сек
ADS DBEng33.dll родная 577 сек
ADS DBEng33.dll патченая 457 сек
MS SQL 52 сек.
При работе Codebase c патченой dll идет активное обращение к HD, с родной - нет. Для ADS все наоборот. Ресурсов процессора и памяти задачи используют примерно одинаково, только для Codebase это 1cv7.exe, для ADS еще и процесс самого сервера. При запуске под MS SQL 1cv7.exe ресурсов процессора практически не использует, их юзает сервер.
20Гб БД на RAM диск положить возможности нет, даже при условии компрессии БД. Сильно подозреваю, что дело в формировании отчета, буду разбираться.
"При работе Codebase c патченой dll идет активное обращение к HD".
Если в процессе выполнения "Анализ счета по субконто" выполняется модификация БД, то время для CodeBase сильно зависит от режима запуска сессии 1С. Для разделенного режима надо обязательно класть файл транзакций на RAM диск. И "патч" никак не может влиять на скорость как "Для ADS все наоборот". Вы сессии запускаете в каком режиме? И всегда ли одинаково?
"сильно подозреваю, что дело в формировании отчета, буду разбираться."
Пришлите, пожалуйста, его и мне...
"20Гб БД на RAM диск положить возможности нет"
Естественно ;-) Я говорил, что положить на него имеет смысл файлы из рабочего (временного) каталога и файлы транзакций.
Пока только с платформами разными тыркался, как остановлюсь на чем то - буду тестировать конкретно. Вообще думал насчет терминального доступа, поэтому и хотел пробовать Codebase под ПДБД.
"However, client/server support does not work across different operating systems,"
Читал я это, но думал может под wine, что и получится. Если нет - попробую ADS под linux, терминал сервер под виндой, терминальные клиенты сейчас в основном тоже linux и дальше буду всех перетаскивать с винды. Если все пойдет нормально (тьфу-тьфу), буду пробовать в работе. В основном конечно волнует устойчивость, потому как переиндексация такой базы по любому займет не мало времени. Сейчас-то под ms 2003, SQL 2000 и виндовым терминал сервером проблем с базой не возникает ...
"причины краха базы ADS?"
Причины - выключился (сдохли батареи UPSа) компьютер (сервер) в момент выполнения транзакции. Далее, как я понял из переписки с Александром (wer_alex), предпринимались не совсем верные действия по реанимации базы данных. Мы с Александром связались уже после того как он восстановил базу данных из копии прошлого дня. А общие правила выхода из такой ситуации следующие:
0) До запуска сервера ADSа!!! Обязательно сделать резервную копию базы данных, файлов транзакций *.TPS, журналов сообщений ADS_ERR.*.
1) Удалить файл 1SxTTS.lck из каталога базы данных.
2) Запустить сервер ADS.
3) Запустить монопольно сессию 1Са на самом сервере (в смысле ЭВМ).
В момент выполнения пункта 2 и/или пункта 3 сервер ADS будет предпринимать попытку реанимировать базу данных. Это может выполняться долго, т.к. он выполняет реиндексацию битых CDXов и откат аварийных транзакций. У меня были случаи (при тестировании надежности системы), когда ему это не удавалось
сделать - сервер ADS зацикливался. Это надо осознать путем рассматривания поведения задачи в системном task менеджере и появления записей в журнале сообщений сервера ADS (файл ADS_ERR.ADT).
Если сервер ADS не может восстановить базу данных, то надо его остановить штатным способом (останавливаться он будет тоже долго) или свалить его в task менеджере и выполнить следующее:
0) Восстановить базу данных из резервной копии, сделанной в пункте #0 предыдущего абзаца.
1) Удалить файл 1SxTTS.lck из каталога базы данных.
2) Удалить файлы *.СDX.
3) Удалить файлы транзакций *.TPS.
4) Удалить файлы ADS_ERR.*.
5) Выполнить утилиту adtfix.exe.
6) Запустить сервер ADS.
7) Запустить монопольно сессию 1Са на самом сервере (в смысле ЭВМ) для реиндексации базы данных.
8) Если выполнялся ремонт таблиц в процессе выполнения утилиты adtfix.exe, то необходимо "глянуть" эту таблицу в "Advantage Data Architect 8.1".
p.s. Переприкрепил. К сожалению, в 1С я не очень богатым опытом обладаю, поэтому извините за столь очевидные, возможно на Ваш взгляд, вопросы.
p.p.s. База прогоняется сейчас утилитой adtfix. База здоровая, процесс идет медленно. Если можно, вышлете мне на nos@iptel.by Ваш адрес в скайпе.
Вот, придумал. ;-)
Пошлите мне файл 1CV7.DD и распечатку "dir *.dbf" каталога базы данных, на реальный мой почтовый адрес (он есть в конце файла DBEng32.doc). Возможно обойдемся пересчетом итогов в версии 6042 с предварительным пересозданием CDX-ов. Думаю, можно будет и не изменять размер страницы. Т.к. сбой, скорее всего, произошел из-за ошибки (проблемы) описанной в версии 6038.
(197)См. выше ответ на (194).
есть ли на Advantage скачанный с этой страницы ограничение на количество одновременных пользователей ? или ограничение состоит в триальности (т.е. работает некоторое время)
чем может помочь приведенная вами ссылка Advantage Product Version Matrix?
"чем может помочь приведенная вами ссылка" - позволяет скачать пробную версию.
"ограничение на..." - после установки сервера БД запустите "Advantage Configuration Utility". Нажмите кнопку "Start Service" и загляните в закладку "Installation Info". Там указаны ограничения по дате и количеству пользователей в пробной версии.
1) "можно ли в ADS как-то задать ограничение"
Уменьшить файл TPS нельзя, не изменив алгоритма проведения документа. Размещение файла TPS на RAM диске повышает скорость выполнения транзакций, но снижает надежность системы. Т.к. если заваливается сервер, то для реанимации базы данных ADSу потребуется этот файл. Для повышения скорости не в ущерб надежности системы, можно его разместить на другом диске. Если же файл транзакций размешать на RAM диске, то можно использовать вот этот продукт
2) "... время ... в монопольном режиме раза в три больше, чем в родных DBF."
Суть, прежде всего, не в монопольном режиме, а в локальном запуске сессии 1С. Вы так запускали сессию 1Са? Да, при использовании данной разработки скорости выполнения разных задач в разных режимах запуска сессии 1С могут улучшаться или ухудшаться по сравнению с родными DBFами.
3) "... нет ли возможности как-то ускорить ..."
Наверно - есть. Но т.к. в нашей системе нет "документа Реализация" и понятия "открытие периода", то мне сложно разбираться в причинах медленного выполнения данных алгоритмов. У нас на ADSе все алгоритмы во всех режимах запуска сессии 1Са работают либо быстрее, либо медленнее не более чем на 10% по сравнению с родными DBFами (кроме создания индексных файлов). Давайте разбираться с алгоритмами Вашей системы. Предлагайте тестовую платформу.
4) "Или лучше использовать CodeBase?"
Однозначного ответа нет. Разработка на CodeBase в локальном режиме (в ПДБД) работает значительно быстрее ADS и родных DBF на многих задачах. Но в сетевом режиме, при большом количестве пользователей значительно уступает ADSу.
2) Нет, монопольный запуск с другой машины
3) В данном случае речь идет о ТиС 9.2, полагаю, что это может быть связано с отключенным признаком "автоматическое удаление движений", на SQL тоже тормоза доводилось наблюдать по этой причине
4) Т.к. предполагается терминальное использование, то после вдумчивого чтения склоняюсь к ПДБД, да и пользователей, если верить имеющейся у меня информации, не более 3 (сетевая версия на 3 пользователя)
Спасибо за развернутый ответ!
1) "монопольный запуск с другой машины"
Для этого режима запуска сессии 1Са имеет смысл поставить в конце глобального модуля вызов операции #61 из РУСа для всех таблиц базы данных одним вызовом.
2) "открытие периода происходило весьма неспешно"
Открытие периода или таблиц базы данных? В ADSе первое открытие таблицы за сеанс работы сервера происходит ощутимо дольше, чем последующие открытия. Попробуйте на рабочей станции сначала запустить сессию в разделенном режиме, выйти из неё, затем запустить сессию для открытия периода. Если "неспешность" открытия периода исчезнет, то причина именно в этом.
1) 64-bit Windows and Linux Servers (улучшено кэширование на стороне сервера).
2) Dynamic Server Configuration (упрощена настройка сервера).
3) SQL Engine and AOF Performance Enhancements (затрагивает операцию #60 из РУСа).
4) Improved Transaction Performance (самое важное изменение).
НО есть кучка вопросов, ответы на которые не нашёл в руководстве и здесь, в обсуждении, а именно:
1. касаемо базы: как серверу codebase указать, какую базу он подхватить должен. Я интуитивно сделал в лоб: скопировал всё из папки BIN\CB в каталог базы 1С, помогло :))))))
2. касаемо исполняемых файлов (платформы): как повлияют манипуляции, основанные на kernel33.dll и kernel37.dll на работу оной в windows_vista.
3. как обеспечить работу на сервере нескольких баз. То есть, крутиться на codebase должна только одна база, с которой по сети работают юзеры, другие же базы исключительно локально.Проблема, понятно в том, что после изменений в папке Bin штатной 1С, попытка запустить немодифицированные базы неудаётся по очевидной причине (ошибке): не найден файл DBEng32.ini. Неужели придётся конвертировать и остальные базы то же?
Ответы по пунктам вопросов:
1) См. в файле DBEng32.doc, раздел "Установка", последний абзац.
2) Эти манипуляции решат "проблему 1 гигабайта" ;-) Я не проверял данное решение в "windows_vista". Но, т.к. "проблема 1 гигабайта" и её решение не зависит от версии Windows-а, то, думаю, проблем не возникнет. Если же возникнут - пишите мне, исправлю. Рекомендую проверить работоспособность этой разработки в "windows_vista" на тестовой базе данных (в локальном режиме) с помощью внешней обработки из Test.zip по ссылке
3) Решений два:
а) Воспользоваться текстом их DBEng32.doc, раздел "Настройка", пункт "Строка №8".
б) Использовать два каталога исполнительных файлов 1С и организовать для пользователей удобный выбор вызова 1cv7.exe из каталога соответствующего формату базы данных. Это решение - предпочтительно!
"В данных сообщениях не содержится ответа"
Содержится. ;-)
Вот текст из (79): "использовать штатные средства конфигуратора выгрузить/загрузить данные". Вопрос скорости и ограничения размеров DBF-ов см. первый абзац сообщения #98 и сообщение #100.
"чем это решение лучше чем бесплатный MS SQL Express 2005 ?"
1) Нет ограничения на размер базы данных.
2) Не требует переделки конфигурации под прямые запросы.
3) Стоит дешевле, чем "нормальный" MS SQL.
4) Требует меньше затрат на железо по сравнению с MS SQL.
5) Проше в изучении и эксплуатации.
6) На большинстве задач работает быстрее.
7) Работает в LINUX.
8) Имеются простые дополнительные средства работы с БД, минуя штатные 1С-овские средства.
Ну а если Ваши задачи можно эксплуатировать в "MS SQL Express 2005", то ничем не лучше.
"чем это решение лучше чем бесплатный MS SQL Express 2005 ?"
1) Нет ограничения на размер базы данных.
согласен, да MS SQl Express - 4GB ограничение на размер базы
2) Не требует переделки конфигурации под прямые запросы.
не всегда, большинство запросов работает коректно
3) Стоит дешевле, чем "нормальный" MS SQL.
MS SQL Express 2005 вобще бесплатный
4) Требует меньше затрат на железо по сравнению с MS SQL.
затрат на железо не требует работает на том же оборудовании что и dbf версия
5) Проше в изучении и эксплуатации.
когда переносил базу прочитал только документацию к поставке MS SQL Express
6) На большинстве задач работает быстрее.
Когда перенесли 2 GB базу на SQL заработало быстрее
7) Работает в LINUX.
да, но Linux версия также платная как и Windows.
smile8) Имеются простые дополнительные средства работы с БД, минуя штатные 1С-овские средства.
Допольнительных средств для SQL тоже много.
Ну а если Ваши задачи можно эксплуатировать в "MS SQL Express 2005", то ничем не лучше.
Согласен, перенесли Торговлю и склад из dbf. на SQL Express и все, устраивает.
Итого, для себя сделал вывод что весь плюс в неограниченном размере базы , но с накладными расходами на оплату лицензии. Значит совокупная стоимость владения и експлуатации больше. Еще, есть ли опыт работы на данной разработке с базами больше 4 GB . Знакомые админы говорят, что если хочешь спать спокойно, то надо переходить на МS SQL.
Извините за многословие, но перед тем как взять разработку на воружение , хотел выяснить все "за" и "против". Когда база будет около 4 GB думал переходить на MS SQL 2005, но прочитал про Вашу разработку и задумался.
Уточню по некоторым пунктам:
2) "не всегда, большинство запросов работает коректно" - я написал не "переделка" запросов, а переделка "под" (!) прямые запросы. Т.е. использовать SQL-ную СУБД в соответствии с тем как она задумывалось, а не как это делается в штатных возможностях 1С.
3) "MS SQL Express 2005 вобще бесплатный" - я написал "нормальный" MS SQL. Т.е. без ограничений и платный сервер БД.
4) "работает на том же оборудовании что и dbf версия" - у нас Advantage работает тоже на том же оборудовании, что и работала штатная DBF-ная версия 1С. У нас размер базы - 7.5 гигабайт (DBF) и 2 гигабайта (CDX). Активных пользователей - 50 штук. А у Вас? ;-)
5) "прочитал только документацию к поставке MS SQL Express" - некоторые вообще ничего не читают, а используют "интуитивно понятный интерфейс". ;-) На сайтах по Advantage есть сравнительные данные по этому вопросу.
6) "Когда перенесли 2 GB базу на SQL заработало быстрее" - я где-то читал рекомендацию, что MS SQL серверу желательно обеспечит размер оперативной памяти равный или больший размеру базы данных. Наверно у Вас такой случай. ;-)
7) "но Linux версия также платная как и Windows" - да. Зато сама ОС - бесплатная.
8) "Допольнительных средств для SQL тоже много" - я написал, что "простые", а не "много". В моей разработке "тремя" простейшими функциями можно повысить эффективность алгоритмов обработки информации в разы. Причем, не переделывать алгоритмы обработки информации, а добавить 1-2 оператора в алгоритм, написанный, на штатном языке. См.:
0) "для себя сделал вывод что весь плюс в неограниченном размере базы" - не правильный вывод. Если считать, что это "весь плюс", то, действительно лучше "спать спокойно"(с) и "надо переходить на МS SQL"(с). И не надо забивать себе голову данной разработкой - живите как все нормальные люди... ;-)
Ну, почти убедили :) . Да в своем класе Advantage лучшее решение.
Уже скачал триал сейчас тестю. Ответ на пункт 4 впечатлил, еще для успокоения души скажи сколько времени бесперебойной работы было под такой базой.
Ответ на 5 пункт все правильно, MS SQL быстро работает когда вся база может уместится в оперативную память( у нас Win2003server 4 Gb RAM, да
и клиенты подключены через терминальные сессии).
Осталось 5 % сомнения, подкинули идею перейти на 1Сv8.1+IBM DB2 Express server(бесплатен+неограничен в размерах базы). Мол это современное решение, итак рано или поздно 1С8 надо изучать, а Advantage+1Cv77 it's legacy.
"перейти на 1Сv8.1+IBM DB2 Express server"
И Вы еще размышляете? Если есть возможность перейти на это, то - переходите!
"сколько времени бесперебойной работы было под такой базой"
Это, смотря, что понимать под "бесперебойной работой". У нас не было срывов производственной деятельности нашей фирмы из-за программного обеспечения. Но это связано не только с использованием той или иной СУБД. У нас функционирует самописная система распределенных баз данных, которая позволяет переключать пользователей на другие серверы в случае отказа основного. И такое происходит не только из-за сбоев железа или электропитания, но и из-за, например, заливки новой версии конфигурации. Эта система успешно работала еще и на родных DBF-ах. А если говорить о самом сервере баз данных Advantage, то он ни разу не падал с момента начала его внедрения (вроде - год уже). Но мы его внедряли не на всех серверах сразу, т.е. некоторые продолжали (и продолжают) работать на родных DBF-ах.
"Ну, почти убедили"
Я Вас не убеждал! А наоборот - пытался разубедить от использования моей разработки. Ведь очень важно учитывать, что ВСЮ ответственность за базу данных Вам придется взять на себя при использовании мое разработки. А в случае внедрения легальных программных продуктов будет возможность (условно говоря) разделить ответственность с известными фирмам (производителями программного обеспечения).
Это очень много придется писать. ;-)
Но общая суть в том, что в конфигурации заменены все методы модификации БД на функции. Убраны элементы диалога, связанные с модификацией БД и сделаны, функционально аналогичные, кнопки диалога в которых вызываются, выше упомянутые функции (их диалоговый эквивалент). Внутри функций выполняются штатные действия, и присутствует алгоритм, который записывает объект в специальный файл (далее по тексту - СФ). Вместе с объектом в СФ записывается код операции (записать, провести, удалить и т.д.) и информация, описывающая источник (номер базы, имя пользователя, имя компьютера и т.д.). В простейшей схеме основной СФ один для всех распределенных БД. И каждая рабочая станция должна иметь доступ к своей распределенной БД и основному СФ. Допускается несколько СФ, и они синхронизируются между собой диспетчером. Диспетчер еще выполняет функции чтения объектов из СФ и помещением его в распределенную БД. В каждой распределенной БД запускается свой диспетчер, и он извлекает из СФ все объекты помещенный из других распределенных БД. Если доступ к СФ нарушается, то объекты записываются в резервный СФ. И при восстановлении доступа к СФ выполняется запись из резервного СФ в основной СФ.
1. т.е. объект все-таки пишется в текущую базу при интерактивном нажатии?
2. СФ и ваша система "распределенных" баз - только для "горячей" замены серверов, или это аналог УРБД? если аналог - то хотелось бы по-подробнее!!!
И вообще можно отдельной статьей организовать...очень интересует, например, Диспетчер - это сторонняя прога, или все сделано средствами 77?
Евгений (DOLLY_EV)
По пунктам Вашего сообщения:
1) Да.
2) Наша система не только для горячей замены сервера. Она больше похожа на УРБД, только обмен между базами происходит на уровне отдельных объектов (документ, элемент справочника и т.д) в "реальном масштабе времени". Т.е. это не "пакетный" обмен между распределенными БД. Пакет накапливается только в случае потери связи с сервером. А при возобновлении связи, пакет автоматически передаётся и обрабатывается на всех серверах.
Никаких серьёзных сторонних программ в этой "разработке" не используется. Всё написано на штатном языке 1Са. Единственное, что делается не на штатном языке - это работа с файлом обмена информацией. Это написано на FoxPro. В нем реализованы элементарные операции с файлом - открыть, записать, читать, создать файл и т.д. Этот файл не является файлом формата DBF. Т.е. можно было бы использовать и не FoxPro.
0) Про "отдельной статьей организовать" уже написано в (141) сообщении. Кроме этого, я не считаю это решение универсальным. А грузить читателя отдельными (частными) решениям, думаю, не имеет смысла. Есть такой продукт - МОД. Это более универсальное решение. И во многом моя разработка похожа на МОД...
Очень долго выполняется расчет остатков и функция РассчитатьРегистрыНа(). Пробовал то же на сервере ADS 8.1 - аналогично. Причем расчет регистров зависит от положения точки расчета в периоде сохранения остатков. В конце месяца вообще невозможно дождаться завершения расчета, приходится принудительно убивать процесс 1С. Может есть какая хитрость?
1) "Очень долго"
По сравнению с чем? Дайте, пожалуйста, описание режимов запуска сравниваемых систем и конкретные времена выполнения.
2) "Может есть какая хитрость?"
Простые хитрости:
Для операций чтения данных из БД использовать "операцию" #61 из РУСа.
Для операций обновления БД разнести файл транзакций и базу на разные диски.
Увеличить/уменьшить размер страницы индексных файлов.
Сложные хитрости:
Переписать алгоритм с использованием РУСа.
Выслать мне базу, чтобы я смог посмотреть трассировку I/O и, возможно, внести исправления в свою разработку. Или дать другие рекомендации.
P.S. Пункт #2 имеет смысл делать только после выполнения пункта #1 данного сообщения.
1) "Очень долго"
По сравнению с чем? Дайте, пожалуйста, описание режимов запуска сравниваемых систем и конкретные времена выполнения.
Сравнивали под терминалом WIN2003 ADS vs DBF
DBF под терминалом
Документ.РасходнаяНакладная.Модуль Документа 471 ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент()); 1 1.033811 35.28
Документ.РасходнаяНакладная.Модуль Документа 480 Если глПогашениеПартииТоваров(Контекст,ТаблицаДокумента,"Упр",,СписокИтого,СписокСтоимостей)=1 Тогда 1 0.934216 31.88
Глобальный модуль 9668 ВремРегистры.РассчитатьРегистрыНа(ДД); 1 0.859058 29.32
Документ.РасходнаяНакладная.Модуль Документа 247 Если глДвиженияРегистровНакладных(Контекст,ТаблицаДокумента)=1 Тогда 1 0.398913 13.61
Глобальный модуль 12640 ВремРегистры.РассчитатьРегистрыНа(Конт.ТекущийДокумент()); 1 0.380357 12.98
Документ.РасходнаяНакладная.Модуль Документа 180 Если Число(глЗапретитьОтгрузкуКлиенту(Контекст)) < 1 Тогда 1 0.166761 5.69
ADS под терминалом
Документ.РасходнаяНакладная.Модуль Документа 247 Если глДвиженияРегистровНакладных(Контекст,ТаблицаДокумента)=1 Тогда 1 19.786208 41.61
Глобальный модуль 12640 ВремРегистры.РассчитатьРегистрыНа(Конт.ТекущийДокумент()); 1 19.582809 41.18
Документ.РасходнаяНакладная.Модуль Документа 471 ВремРегистры.РассчитатьРегистрыНа(ТекущийДокумент()); 1 13.943721 29.32
Документ.РасходнаяНакладная.Модуль Документа 480 Если глПогашениеПартииТоваров(Контекст,ТаблицаДокумента,"Упр",,СписокИтого,СписокСтоимостей)=1 Тогда 1 12.647915 26.60
Глобальный модуль 9668 ВремРегистры.РассчитатьРегистрыНа(ДД); 1 12.405526 26.09
Документ.РасходнаяНакладная.Модуль Документа 180 Если Число(глЗапретитьОтгрузкуКлиенту(Контекст)) < 1 Тогда 1 0.246019 0.52
DBF - 0.380357 s ADS - 19.582809 в 50 раз !!!
Простые хитрости:
Для операций чтения данных из БД использовать "операцию" #61 из РУСа.
Процедура ПриНачалеРаботыСистемы() Экспорт
ЗагрузитьВнешнююКомпоненту("AddInExt.dll");
Ext=СоздатьОбъект("AddIn.AddInExt");
ИмяРег="Регистр ОстаткиТоваров";
Ext._(61,ИмяРег,10);
Уменьшило время до 15 сек
Для операций обновления БД разнести файл транзакций и базу на разные диски.
Эффект не заметен
Увеличить/уменьшить размер страницы индексных файлов.
При 512 - 16 сек при 4096 - 17 сек
Включение время и выключение перед расчетом
УстановитьЗначениеФильтра("Товар",СписокТоваров,2);
меняло время на 10-20% т.е. - 23 сек без фильтра
Мне кажется фильтр не работает :cry:
Замедления в отчетах на глаз не отмечено
А система очень понравилась и под Wine@etrsoft все замечательно работает на одном Linux терминале под RX@etersoft ADS 7.1
Как бы укротить РасчитатьРегистрыНа() ?
Владимир.
1) "Сравнивали под терминалом..." "DBF - ... s ADS - ... в 50 раз !!! "
- Сказано уже многократно, что "родные" DBF-ы в локальном режиме работают значительно быстрее, чем любая клиент-серверная СУБД.
2) "Для операций чтения данных из БД использовать "операцию" #61 из РУСа."
- Использование этой возможности, чаще, уменьшает нагрузку на сеть. Но не во всех алгоритмах выборки данных. В некоторых алгоритмах - снижает скорость. В Вашем случае сети нет.
3) "...разнести файл транзакций и базу на разные диски. Эффект не заметен"
- Скорость повышается для системы в целом, когда в ней работает несколько пользователей. Для одного пользователя эффект сильно ощущается при выполнении "отменить транзакцию", т.е. когда, например, документ не может провестись из-за нехватки товаров на складах.
4) "Увеличить/уменьшить размер страницы индексных файлов."
- Мы, пока, используем размер - 512 байт. Однако, при тестировании производительности, в сетевом режиме при нескольких пользователях, мы заметили ускорение чтения, особенно в версии 9.1 ADS-а.
5) "УстановитьЗначениеФильтра();" "Мне кажется фильтр не работает"
- В "родном" движке никаких фильтров не используется. Т.е. все условия проверяются на стороне "клиента". И, естественно, при использовании моей разработки аналогично. Для установки реального фильтра существует "операция" #60 из РУСа.
6) "Как бы укротить РасчитатьРегистрыНа() ?"
- В последних версиях данной разработки сделаны изменения в части повышения скорости выполнения этого метода. Но не думаю, что это ускорить работу системы "в 50 раз". ;-)
0) Посмотрите, пожалуйста, статейку
Конфа самописная.
Используется сервер терминалов (я знаю, что Вы не рекомендуете использовать на нем ADS, но иного выхода нет - нужно преодолеть предел 2Gb в некоторых таблицах).
Пробовал ADS в режиме Local Server. Результат аналогичный.
Пробовал вариант с Codebase в разных режимах. Аналогично.
Долго по сравнению с штатным dbf вариантом базы в том же терминале.
В модулях документов используются констукции вида
рег.ВременныйРасчет();
РассчитатьРегистрыНа(ТекДок);
В штатном варианте время проведения такого документа до 10 сек.
Под ADS - до 5 минут. Для нашей организации это критический показатель, так как документов очень много и они часто перепроводятся задним числом.
Кроме того есть аналогичное замедление в отчетах при использовании запросов
с остатками. "Расчет Остатков..." во время выполнения запроса идет на порядок медленнее и зависит от выбранного периода (начало или конец месяца).
Видимо 1С при расчете регистра за период посылает серверу ADS отдельные запросы по каждой суммируемой строке таблицы регистра :(
Я понимаю, что проведение документов можно оптимизировать, но разбиратся с каждым отчетом (их сотни) нет физической возможности.
1) "Используется сервер терминалов"
- Клиент-серверная СУБД никогда не сравнится по скорости с DBF-ами в терминальном режиме.
2) "Пробовал ADS в режиме Local Server"
- Использовать режим "Local Server" для ADS категорически нельзя. Испортится база данных! См. различия в документации по ADS. В "Local Server" не поддерживаются транзакции!
3) "Пробовал вариант с Codebase в разных режимах. Аналогично."
- Не верю ;-))) Вариант CodeBase в режиме ПДБД работает быстрее локального режима родных DBF-ов. В этом режиме нет ограничение на количество подключений и на размер файла в 2 гигабайта. При использовании ПДБД в "разделённом" режиме медленно работает запись в журнал транзакций. Его надо разместить на RAM диске или на HDD c включенными режимами "write caching" и "advanced performance". При использовании ПДБД в монопольном режиме для "регламентных" работ, типа - "Тестирование и исправление ИБД", использовать RAM диск не рекомендую. Т.к. при этих работах могут выполняться большие транзакции и RAM диска может не хватить.
4) "Видимо 1С при расчете регистра за период посылает серверу ADS отдельные запросы по каждой суммируемой строке таблицы регистра"
- Причина другая. Никаких запросов (в понимании Вашей фразы) из 1C серверу ADS не посылается.
Как я написал в сообщении #147, можно повысить скорость чтения с помощью "операции" РУСа #61. Для выяснения влияния этой "операции" на производительность системы, достаточно в глобальном модуле поставить вызовы метода для таблиц регистров. Т.е. строчек десять в одном месте конфигурации (в глобальном модуле после загрузки ВК). Провести тестирование (замеры скорости). И если это повысит скорость, то обсудим более "грамотную" расстановку вызовов этой "операции".
А если не повысит скорость до приемлемой, то пробуйте CodeBase в режиме ПДБД или переходите на SQL-ную версию 1Са с использованием прямых запросов.
Если же я запускаю клиента на другой машине – он не находит адвантаж.
Выдается сообщение о том что не может законектится с Advantage Database Server.
Я понимаю что вопрос пограничный. То ли нужны спецы по win2003, то ли спецы по с Advantage Database Server.
Но может чего посоветуете?
Теперь и мы столкнулись с этой проблемой. ;-)
Причина - на сервере более одной сетевой карты.
Надо сделать.
На сервере.
Add the following string value using the Registry Editor (REGEDIT.EXE) into the registry:
\\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Advan
На клиенте.
Создать в BIN каталоге (рядом с DBEng32.dll) файл ADS.INI с параметрами:
[SETTINGS]
ADS_SERVER_TYPE=2
[ИмяCервераADS]
LAN_IP=xxx.xxx.xxx.xxx
LAN_PORT=6262
Значение xxx.xxx.xxx.xxx - это IP адрес сетевой карты сервера ADS.
Подробнее см. документацию по ADS разделы:
1) LAN IP Address
2) ADS.INI File Support
в ответе 116 Вы описали порядок восстановления БД после краха. Нулевой пункт такой: "0) До запуска сервера ADSа!!! Обязательно сделать резервную копию базы данных, файлов транзакций *.TPS, журналов сообщений ADS_ERR.*". И потом "пляшем" от этих резервных копий.
Поскольку вопрос возможности корректного восстановления БД является оочень важным, хочется спросить: как выполнить этот пункт, если сервер ADS запускается автоматически? Это же нормально сделать ему автозапуск. Вот, например, питание отключили, UPS сдох, сервер выключился, а затем после подачи питания вновь включился. И сервер ADS тоже автоматически загрузился. Меня рядом может и не быть. И что тогда, можно БД и не восстановить? Нет ли ещё способов гарантированного восстановления без использования резервных копий (которые до запуска ADS-сервера)?
(То, что нужно сделать связь UPS-а с сервером - это понятно, но если этого нет и сервер упал).
Спасибо за Вашу разработку и ответы.
1) "...сервер ADS запускается автоматически?"
- Поставить запуск сервиса "Advantage Database Server" в "Manual" и для запуска сервера ADS использовать утилиту "Advantage Configuration Utility".
2) "Нет ли ещё способов гарантированного восстановления без использования резервных копий (которые до запуска ADS-сервера)?"
- А для этого и делается копия. Если сервер ADS не сможет восстановить БД, то остаётся шанс это сделать с помощью автора данной разработки. ;-) Но, по нашему опыту, он нормально восстанавливается...
3) "То, что нужно сделать связь UPS-а с сервером - это понятно..."
- Еще надо сделать оповещение пользователей от UPS.
4) "...но если этого нет и сервер упал"
- ЭТО должно быть!
в ответе 116 Вы описали порядок восстановления БД после краха. Нулевой пункт такой: "0) До запуска сервера ADSа!!! Обязательно сделать резервную копию базы данных, файлов транзакций *.TPS, журналов сообщений ADS_ERR.*". И потом "пляшем" от этих резервных копий.
Поскольку вопрос возможности корректного восстановления БД является оочень важным, хочется спросить: как выполнить этот пункт, если сервер ADS запускается автоматически? Это же нормально сделать железному серверу и серверу ADS автозапуск. Вот, например, питание отключили, UPS сдох, сервер выключился, а затем после подачи питания вновь включился. И сервер ADS тоже автоматически загрузился. Меня рядом может и не быть. И что тогда, можно БД и не восстановить? Нет ли ещё способов гарантированного восстановления без использования резервных копий (которые до запуска ADS-сервера)?
(То, что нужно сделать связь UPS-а с сервером - это понятно, но если этого нет и сервер упал).
Спасибо за Вашу разработку и ответы.
Можно коротко в двух словах объяснить почему все-таки не рекомендуется использовать эту разработку на сервере терминалов?
В настоящий момент я эксплуатирую систему 1С 7.7, релиз 27 Торговля и склад + MS SQL 2000 SP4. Размер несжатого бекапа базы SQL - 1400 Мб. Конфигурация довольно сильно переписана, но наш программист не владеет методами работы с MS SQL, поэтому в папке с базой активно плодятся мелкие *.dbf. То есть база получается не вполне SQL. Несмотря на то, что база не очень большая, в свое время от формата DBF отказались по причине многочисленных необъяснимых глюков. С переходом на SQL ситуация устаканилась.
В системе работают 20 пользователей, которые набивают заявки и скорость работы в подборе товаров довольно критична. Приемлемой производительности удалось добиться только в случае установки MS SQL и терминального сервера на одной машине Windows 2000 Server с четырехядерным Core i5. При разделении сервера терминалов и MS SQL по разным машинам и соединнения их сетью 1Гбит производительность была заметно ниже. Библиотеки 1С пропатчены для устранения эффекта 100% загрузки проца при ожидании 1С данных. Во время сильной нагрузки в диспетчере задач видно, что 25% отъедает процесс System, 25% отъедает процесс sqlservr.exe и остальное делят процессы 1С. Нагрузка на диски в perfmon минимальна. Кроме того, наблюдается эффект замедления базы к концу дня - помогает перезапуск SQL. Нагрузка на сервер довольно высокая - к концу дня после 10 часов работы типичное время работы процесса sqlservr.exe составляет 4,5 часа, процесса system - 5 часов.
Главный вопрос - если я заменю MS SQL на ADS получу ли я прирост производительности? Предполагается ADS разместится также на терминальном сервере.
1) "наш программист не владеет методами работы с MS SQL, поэтому..."
- Дело не в программисте. ;-)
2) "в папке с базой активно плодятся мелкие *.dbf."
- Думаю, это рабочие файлы.
3) "база получается не вполне SQL."
- Для 1С 7.7 - так не бывает. См. предыдущий пункт.
4) "если я заменю MS SQL на ADS получу ли я прирост производительности?"
- Зависит от задач. Надо проводить сравнительное тестирование. Но если Ваша система стабильно работает на MS SQL - думаю, переходить на ADS не имеет смысла.
5) "почему все-таки не рекомендуется использовать эту разработку на сервере терминалов?"
- Не так. На данную разработку не рекомендуется переходить с (уже эксплуатируемого) терминал-серверного режима DBF-ной версии. Т.к. DBF-ный локальный режим (терминал-сервер) работает значительно быстрее любой клиент-серверной СУБД. Естественно, при условии, что мощности железа хватает для одновременного обслуживания клиентских задач на одной машине. Но если система эксплуатируется в режиме файл-сервер (DBF-ная версия), то имеет смысл пробовать для перехода: терминал-сервер, MS SQL, ADS и т.д.
6) "Предполагается ADS разместится также на терминальном сервере"
- На наших задачах оптимальная схема - выделенный сервер под ADS и обычные рабочие станции. Т.е. никаких терминал-серверов... ;-) У нас планировалась задача удаленного доступа по медленным каналам связи с использованием терминал-серверного режима - одна машина на пять сессий (не более). Т.е. несколько терминал-серверных машин с доступом к одному, выделенному, серверу с ADS-ом. Но запускать клиентское приложение и клиент-серверную СУБД на одной машине и не помышляли. На мой взгляд, это очень странное решение и для MS SQL, и для ADS... Производительность железа это же не только количество ядер процессора. Да и надежность системы снижается. А при использовании железа на "четырехядерным Core i5"(с) - тем более. Извините, но на таком железе можно только в игры играть, а не запускать "20 пользователей"... :-(
"При разделении сервера терминалов и MS SQL по разным машинам и соединнения их сетью 1Гбит производительность была заметно ниже."
- Это, еще раз, подтверждает не эффективное использование клиент-серверных и "запросных" технологий в 1С 7.7. Частично это исправляется использованием "прямых запросов". Одна из целей моей разработки - иметь клиент-сервер, но не писать "прямых запросов"... ;-)
Другими словами, теоретически, я могу расчитывать на прирост производительности при разделении файл-сервера и сервера терминалов и перехода на ADS?
"Одна из целей моей разработки - иметь клиент-сервер, но не писать "прямых запросов"... ;-)"
Если я подниму отдельный файл сервер, то будет ли система с ADS по производительности сравнима с системой на базе MS SQL 2000?
"У нас планировалась задача удаленного доступа по медленным каналам связи с использованием терминал-серверного режима - одна машина на пять сессий (не более). Т.е. несколько терминал-серверных машин с доступом к одному, выделенному, серверу с ADS-ом"
-Очень интересно :) Ввиду экономии средств мы предпочитаем использовать несколько мощных персональных компов, чем один (или не один) мощный сервер. Проблемы надежности решаем многократным бекапом между "серверами". Наиболее требовательные к скорости клиенты (их 20) заходят на сервер терминалов на котором также исполняется MS SQL, однако есть и менее нагруженный сервер терминалов на базе Core 2 Quad котором работают менее требовательные пользователи, скорость работы которых заметно ниже, чем у тех кто работает на одном сервере с MS SQL. Скорость канала 1 Гбит. Реально при передаче файлов между серверами удается достичь стабильной скорости 25 Мб/сек (по данным Total Comander). Вопрос - какую нагрузку на сеть создает ваше решение. Желательно описать её в пропускной способности на одного клиента. Как она соотносится с той нагрузкой которую создает обычная SQL версия? Меня бы вполне устроило решение с выделенным сервером ADS и несколькими серверами терминалов. Однако может ли оно быть производительнее, чем вариант с выделенным MS-SQL?
1) "теоретически, я могу расчитывать на прирост производительности при разделении файл-сервера и сервера терминалов и перехода на ADS?"
- Не "файл-сервер", а "клиент-сервер". ;-) Теоретически - да. Практически - проверять надо.
2) "Если я подниму отдельный файл сервер, то будет ли система с ADS по производительности сравнима с системой на базе MS SQL 2000?"
- См. предыдущий пункт.
3) "Ввиду экономии средств мы предпочитаем использовать несколько мощных персональных компов, чем один (или не один) мощный сервер."
- ;-) Сервер отличается от персонального компьютера не только стоимостью и мощностью, но и достоверностью вычислений. У нас самый дорогой "сервер" стоит 2000-2500 американских рублей. При использовании ADS-а на выделенной машине не возникает высоких требований к мощности "сервера". Но схемы контроля достоверности должны быть - ECC и RAID 1. При этом можно не возлагать на RAID функций "ехать дальше" при отказе диска. Важно получить на живом диске корректное завершение транзакции.
4) "Проблемы надежности решаем многократным бекапом между "серверами""
- Если содержание базы данных искажено - не помогут никакие многократные копии. Мы её и не делаем лет восемь уже. ;-) Самодельный инструмент "репликации"...
5) "Вопрос - какую нагрузку на сеть создает ваше решение"
- На это вопрос нет однозначного ответа. У нас полностью переписанная конфигурация, включая инструмент регистров. От сервера до рабочих станций сеть 100 Мб/сек. Сервера связаны сетью 1 Гб/сек. Одновременно пользователей в сети около 50. Серверов 4-5. В "центральной" базе работает 20-30 пользователей. Базы серверов синхронизируются нашим инструментом "репликацией" на уровне обновления объектов 1С-а. И как оценивать нагрузку на сеть...
6) "Желательно описать её в пропускной способности на одного клиента"
- Загрузка от 0 до 100 процентов. ;-) Зависит от действий пользователя.
7) "Как она соотносится с той нагрузкой которую создает обычная SQL версия?"
- Я не сравнивал нагрузку сети для SQL против ADS в среде 1С-а.
8) "Меня бы вполне устроило решение с выделенным сервером ADS и несколькими серверами терминалов."
- Не вижу причин против использования такого решение. Ключевой текст - "выделенным сервером ADS".
9) "Однако может ли оно быть производительнее, чем вариант с выделенным MS-SQL?"
- Может. Однако, меня интересует какая разница производительности может явиться главным аргументом к применению разработки кустаря (меня) по сравнению с фирмой Microsoft? Быстрее в 2 раза, в 10, в 100...? Ну, не только же производительность определяет причины использования той или иной системы... :-(
Популярно, к пункту #3 сообщения #160:
У нас на фирме стоит достаточно мощный сервер и win2003 server, пользователи все работают в терминальном режиме, в 1с 7.7 Комплексная. формат базы данных dbf. Все прекрасно работало, 1с шустрила хоть и размер базы был около 10Гб. но при этом не один dbf файл не превышал 1 Гб (самый большой 800 Мб). У нас имеется еще 5 объектов не связанной с текущей базой, т.е. информации по продажам на этих объектах небыло. Месяца 3 назад начал делать обработку для обмена информации с этими объектами и постепенно грузить информацию в основную базу. где-то месяц назад было загружено уже 3 объекта, размер базы вырос до 13 Гб. 2 dbf файла имели размер чуть более 1,5 Гб, 1с продолжала стабильно работать еще недели 2, в этот период грузил 4 объект, не успев до конца его загрузить, реско начала постоянно вылетать ошибка #310. Начал рыскать в интернете, наткнулся на вашу разработку, за которую вам отдельное спасибо. благодаря ей уже на следующий день фирма смогла продолжить работу. Сначала думал поставил ads, и все проблемы решены, не тут то
было, полезли жуткие тормоза, сделал настройки, правда не все, только основные (сам advantage и добавил DBEng32.ini), большие тормоза пропали, но все равно остались. Проводится помедленее чем dbf, зато распроводит часами и отчеты формирует тоже очень долго. Остальные настройки не стал делать, по скольку прочитав комментарии, сделал вывод, что это особо скорости не прибавит в работе. Заметил, что если вечером сделать удаление cdx файлов и сделать переиндексацию, на следующий день 1с работает пошустрее, практически до вечера, а если не сделать, на следующий день будет долго думать. В итоге РЕШЕНО сделать свертку базы и вернуться в режим работы под dbf. Начав свертку на копии столкнулся с рядом проблем. Свертка висела более 2 суток (нужно было перезагрузить сервак, пришлось сбросить), но информация так и не свернулась. так же во время свертки вышло несколько ошибок ругающиеся на "регистр УчетОплатРасходовУСН - обнаружено пустое значение". незнаю может быть из-за этого свертка зависла. Потом нашел информацию что желательно сделать перед сверткой тестирование базы, параметры поставил как написано в описание по DBEng32.doc. На первом же действии "Реиндексация" выскочила ошибка "***Error*** #999 (Error 7010: Problem with Advantage server file read)" причем с заголовком окна "DBEng32 for Advantage 8.1 Database server", хотя я ставил 9.1 версию и Advantage и bin_ads. С данной ошибкой так и не разобрался. После этого решил перевести 1с на sql, что бы в ней попробовать сделать свертку. Поставил Microsoft SQL Server 2000 Enterprise Edition, попробовал перевести маленькую базу (300 Мб) под dbf на sql. немного потыкавшись с sql удачно перевел на sql. стал проделывать те же действия с текущей базой под ads в процесе загрузки выдает ошибку, которую можно посмотреть в прикрепленном файле.
В общем прошу помощи-совет, как мне поступить, что бы исправить описанные ошибки и сделать свертку базы. Так же приму другие советы. Заранее благодарен за помощь.
Артем.
1) "полезли жуткие тормоза"
Про скорость работы в сетевом, клиент-серверном, локальном (терминал сервер) режимах написано выше в данной теме.
2) "Свертка висела более 2 суток"
Если в Вашей конфигурации под управлением ADS медленно работает де-проведение документов, то сделать свертку, думаю, не удастся за разумное время.
3) "во время свертки вышло несколько ошибок"
Изначально "битая" база.
4) "нашел информацию что желательно сделать перед сверткой тестирование базы"
В описании данной разработки термин "свертка" не используется.
5) "параметры поставил как написано в описание по DBEng32.ddoc"
Исходя из пункта #4, возникает вопрос - какие настройки?
6) "выскочила ошибка "***Error*** #999 (Error 7010"
Такая ошибка выдаётся в случае обращении к таблицам НЕ формата ADS. Наиболее частая ошибка пользователя - обращение к ИБД родного формата DBF из DBEng32 настроенной на работу с в формате ADS. Или обращение к ИБД в формате ADS родным движком, а потом движком ADS-а. В таком случае еще выдаётся сообщение о файле "1SUSERS". В таком случае достаточно удалить 1SUSERS.DBF.
7) "причем с заголовком окна"
Это не существенно.
8) "в процесе загрузки выдает ошибку"
См. пункт #3.
9) "прошу помощи-совет, как мне поступить"
У Вас два варианта действий:
а) Взять копию ИБД до всех экспериментов в формате ADS. Сделать тестирование и исправление ИБД без пересчета служебных данных и итогов. Разобраться с ошибками. Починить базу. Выгрузить ИБД, возможно с применением
б) Связаться со мной по реальному электронному адресу и обсудить способ передачи мне базы данных для решения проблемы.
я сейчас решил пойти пока по первому варианту. эксперементов с рабочей базой не ставил, только с копиями :)
Сделал в общем копию текущей базы. удалил из неё файл 1SUSERS.DBF, поставил на тестирование, оставив только 2 галочки: Реиндексация и проверка логической целостности. На реиндексации вылетела теперь следующая ошибка: #999 (error 7041: File not Found/ Verify the specified path and file name is correct )
Только тестирование прошло с параметрами реиндексация и проверка логической целостности, с остальными параметрами точно не нужно делать тестирование?
Как теперь можно починить базу, или починка это и было тестирование ИБД?
Кстати. когда я перевел базу на ads, с копией базы в формате dbf делал выгрузку, загрузку в тот же формат, и после свертку. На свертке выскакивала ошибка #310. не вылетит ли она сейчас?
Артем.
1) "с остальными параметрами точно не нужно делать тестирование?"
Нужно. Но если сделать выгрузку/загрузку, то пересчет и так выполнится. Но под управлением ADS-а пересчет, думаю, на Вашей базе будет очень долго выполняться.
2) "Как теперь можно починить базу, или починка это и было тестирование ИБД?"
Чинить надо если при тестировании возникали ошибки.
3) "Кстати. ... На свертке выскакивала ошибка #310. не вылетит ли она сейчас?"
Хорошее - "кстати". ;-) Конечно выскочит. Сделайте выгрузку и загрузку в SQL-ную базу. Но, обязательно, учтите, что размер файла выгрузки может быть больше 2 гигабайта. Проверьте это. И используйте разработку от Романа (romix).
P.S. Печально, что многие люди жалуются на ошибку #310 в родном движке и медленное де-проведение документов в моей разработке. И ни один человек не захотел, вместе со мной разобраться с этими проблемами. И, возможно, исправить эти проблемы. Нет у меня базы данных, на которой можно промоделировать эти проблемы. А в реальной, нашей, базе ни ошибки #310 (пока работали на родных DBF-ах), ни де-проведения часами - не происходит.
Сделал замер, после тестирования базы, депровидения: маленький документ депроводится 30-40 сек., вместо 5-10 сек. на dbf, большой 30 минут депроводился вместо 2-3 минут в dbf. на проведение его же ушло 3 минуты. практически столько же как в dbf.
По поводу вместе разобраться с проблемами в 1с, я только за, готов принять участие и посодействовать в этом вопросе. Действительно такая проблема существует практически в каждой организации, которую я встречал.
Я вообще сторонник того, что пришло уже время чему то новому в системе учета, чем 1с и другим системам (слишком много в них недостатков не смотря на всё). По сему, после перелопачивания гор в 1с, мы с коллегой разработали концепцию новой программы по ведению учета, которая основным своим преимуществом будет изначально строиться на платформе хранения данных в sql; вторым преимуществом, то что будет очень проста в плане конфигурирования (например, создать с нуля подобие 1с-ой ТиС можно за 2-3 недели одному человеку); третьем преимуществом, это удобный современный интерфес, заточеный под каждого пользователя; ну и много других преимуществ. Огорчает лишь одно, что процесс разработки движется очень медленно, можно сказать, последние 4-5 месяцев совсем не двигается. :(
Артем.
1) "Кстати после тестирования вышли сообщения о документах и справочниках, которые создались новые, но абсолютно пустые. Это нормально?"
Второй раз, хорошее - "кстати". ;-) См. сообщение #170 пункт #2. Вам выдалась информация для починки базы данных.
2) "По поводу вместе разобраться с проблемами в 1с, я только за, готов принять участие и посодействовать в этом вопросе."
Ваше участие:
а) Тестовая платформа (база данных) с описанием действий пользователя приводящее (провоцирующее) ошибку #310.
б) Тестовая платформа (база данных) с информацией о моих действиях для получения на моей машине информации: "....документ депроводится 30-40 сек., вместо 5-10 сек. ...".
3) "...разработали концепцию новой программы по ведению учета, которая основным своим преимуществом будет изначально строиться на платформе хранения данных в sql;"
Именно эту цель и приследовали разработчики 1С. Очередной тупик. :-( Да еще, думаю, без мощной поддержки прикладных решений, как это делает 1С и не делают другие разработчики, которых уже нет...
По второму, напишите мне свой e-mail, я отправлю две БД с описанием. :)
По третьему пункту, не согласен на счет мощной поддержки от 1с, по скольку не встречал таковой :). К примеру, звонил года 2 назад во франчу, где покупали коробку с ТиС 7.7, нам дали 6 месяцев бесплатной консультации. Мне нужно было сделать учет в магазине ксерокопий и распечаток, чтоб на это пробивался чек через фискалку. Месяц звонил, они все обещали разобраться и сказать как можно это решить, потом сказали давайте мы вам специалиста пришлем, он в вашей базе поковыряется за 800 руб. в час, мож как нибудь решит этот вопрос. Я ответил спасибо не нужно (до этого тоже вызывали (по другим вопросам и с других контор), результат нулевой, только каждый день им отстегивали). В итоге, сел разобрался сам, допилил малость и все заработало. А про типичные ошибки, не доработки и прочее вообще молчу. Конечно, плати деньги, сделают без вопросов, только через сколько, как качественно, сколько при этом придется выложить и не придется ли за ними потом переделывать. Причем часто сталкивался, что многие конторы не в курсе, что им продают франчи, т.е. не то что нужно, а назад коробки уже не принимают, менеджерам главное развести народ как на коробки так и на выезд спеца. :) Да и почти каждый 1с продукт после покупки нужно допиливать.
По поводу нашей разработки, так уже многое продуманно про поддержку, вопрос только в том, чтоб написать прогу :)
"другие разработчики, которых уже нет..." - каких нет разработчиков, можете привести пример?
Артем.
1) "как с помощью выданной информации починить базу?"
а) Для объектов созданных по сообщению "Неразрешенная ссылка" написать обработку поиска объектов для которых конфигуратор создал "пустые" справочники/документы. Внимательно посмотреть на найденные объекты и принять решение - чего с ними делать.
б) Для документа "ЗаявкаПокупателя(DT2457. Запись 1482484)" надо посмотреть схему базы данных. По самому сообщению, сходу, ничего не могу сказать.
в) Про "Проверка уникальности" поступить как написано в сообщении. Именно из-за этой ошибки у Вас не получилась заливка в SQL-ную базу. Число 4HGH ничего не напоминает? Посмотрите картинку из Вашего сообщения #164.
2) "напишите мне свой e-mail, я отправлю две БД с описанием"
Мой e-mail есть в предпоследней строчке DBEng32.doc. ;-) Но, думаю, Вы не сможете запихнуть базу данных размером в 13 гигабайт в "мой" ящик. Лимит - 10 мегабайт.
3) Про поддержку и пр. - это долгий разговор. И, думаю, не совсем по теме данной разработки. Единственно, что сажу. Поддержка, о которой Вы пишете - это не та поддержка о которой я написал в сообщении #172. Я написал: "поддержки прикладных решений". Т.е. обучение, описания, консультации, новые версии и т.д. Т.е. всё то из-за чего "нет других разработчиков". Их на рынке учетных систем - нет. И, самое главное, эти решения реально существуют и востребованы массой пользователей. А по поводу "звонил года 2 назад во франчу" - скажу больше. Я, лет восемь назад, пытался общаться с самой 1С-ой от имени "франчи" - всё было хуже чем в Вашем случае... ;-)
б) и в) Давайте после того как я вам базу скину посмотрите и скажите. Вн. идентификатор 4HGH, я не знаю как до него долезть, а уж как исправить тем более.
2) по поводу e-mail'a пардон не заметил. А по поводу "запихнуть в ваш ящик базу" пожалуй смогу и не одну. На что все таки по вашему существуют архиваторы и файлообменники. ;) Надеюсь у вас безлимитный интернет 500 Мб принять сможете :)
3)Согласен, что не по данной теме разговор. но все же добавлю, что я понял про какие поддержки идет речь. Если это обучение, то здесь все просто: появится новая платформа, появятся и люди которые будут готовы сами ее изучить, что бы потом предоставлять за деньги обучение, писать книжки. Если это описание, то оно будет прилагаться вместе с программой в виде журнальчика, а не килограммовых томов макулатуры, которые ни кто даже в руки ни когда не берет. Если это консультации, это то же очень просто можно решить. А новые версии в данном случае естественно тоже будут, но не такие как у 1с (в каждой новой версии в основном исправление собственных ошибок и при этом умудряются их продавать, в целом за год, дороже самой конфигурации). Обновления должны быть оперативными, на изменение в различных областях законодательства. Например, помню незначительное, изменение 26 мая 2009 г. формы счет-фактуры, объявленное еще в апреле, привело к тому, что организации отказывались принимать старые формы, новые рисовали в ручную пару месецев, а у 1с в свежих обновлениях не было новых СФ, мне ее самому пришлось дописывать, как и многим организациям.
Артем.
1) По поводу пустых справочников/документов не верно рассуждаете. Дело не в этих "пустых" объектах, а в тех объектах для которых они созданы. Т.е., например, в базе существует нормальный документ. Он ссылается на контрагента. А этот контрагент в справочнике отсутствует. Тогда конфигуратор внесет в справочник "пустой" элемент и поставит на него ссылку из документа.
2) Из файлообменника приму любой объем. Высылать достаточно только DBF-ную базу без CDX-ов.
3) Давайте не будем обсуждать 1С и их продукты. Меня это совершенно не интересует. Я не использую их продукты. И не отношусь к поклонникам этих продуктов. Про тупик я написал в другом смысле. Ваше утверждение: "основным своим преимуществом будет изначально строиться на платформе хранения данных в sql" для меня - очень странное. Не буду повторять своё мнение по этому поводу. Если будет время и желание почитайте моё мнение в этом:
P.S. Шлите базу, лучше...
"... поставил ads ... полезли жуткие тормоза ... Проводится помедленее чем dbf, зато распроводит часами и отчеты формирует тоже очень долго."
У Артема использовалась DBF-ная версия в локальном режиме (терминал-сервер).
Я многократно говорил (писал), что любая клиент-серверная СУБД уступает по скорости работы локальному использованию DBF-ной системы. Моя разработка не предназначена для замены локальной (терминал-серверной) эксплуатации "1С 7.7".
Мне удалось провести замеры времен выполнения "задачи" Артема в различных режимах.
Комплексная конфигурация.
Документ "Отчет комиссионера".
Дата документа отстоит от текущей даты на 14 месяцев.
В документе 3735 строк товаров.
Документ "порождает" 9502 проводки.
Документ "содержит" 12061 движений.
=== Сетевое проведение:
DBF - 25 мин. Загрузка сети - 99 %.
ADS - 18 мин. Загрузка сети - 40%.
=== Сетевое депроведение:
DBF - 27 мин. Загрузка сети - 99 %.
ADS - 63 мин. Загрузка сети - 2 %.
=== Локальное проведение:
DBF - 6 мин. 35 сек.
ADS - 11 мин. 55 сек.
=== Локальное депроведение:
DBF - 5 мин. 12 сек.
ADS - 45 мин. 50 сек.
Сравнение скоростей чтения в сетевом режиме:
Точно не помню. Вроде, около месяца на 3-5 пользователей. Т.е. проверить производительность системы - реально. А проверять надо, сначала на одном пользователе. Выяснить "узкие места" (задачи), где может произойти значительное снижение скорости. Типа, как в замерах из #177 сообщения данной темы.
Цены, были, когда я смотрел, ниже чем при использовании SQL-ной версии 1С-а.
На вопрос, как ускорить выполнение отчета, смогу ответить только после анализа Вашей системы т.к. я провел замеры времени выполнения этого отчета на базе данных из (177) сообщения. И в локальном режиме ADS выполняется медленнее на 20-25 % чем в родных DBF-ах. В каком режиме на Вашей базе "ОЧЕНЬ долго формируется" отчет? Какие параметры запуска отчета? Какие времена выполнения в DBF и ADS?
И ещё! Не подскажите как выкрутиться в такой ситуации - есть база которая крутиться под ADS и обычная ДБФ! Как можно настроить чтобы можно было стартовать одновременно обе из под одной 1С?
1) Какое (конкретно) время выполнения этого отчета в ADS? Какое, примерно, было время выполнения в родных DBF-ах? Какое время выполнения в SQL-ной версии?
2) "Не подскажите как..."(с)
Файл "DBEng32.doc" из корневого каталога архива "BIN_ADS_60xx.ZIP".
Раздел "Настройка".
Пункт "Строка № 8".
Образец файла "DBEng32.ini" лежит в каталоге "DBF" архива "BIN_ADS_60xx.ZIP".
Но, лучше организовать два каталога EXE-шников 1С-а.
3) Про скорость ADS в локальном (терминальном) режиме см. сообщение (177) данной темы.
1) Вопрос "ОЧЕНЬ долго формируется"(с) - снимаем. Т.к. это - нормально и не долго... ;-)
2) Создать еще один каталог, это не означает - "организовать"(с). Вам надо обеспечить пользователям способ (правила) не давать вызывать EXE-шник не соответствующий формату базы данных. Т.к. если перепутать формат БД в режиме "1С:Предприятие", то при входе в систему первого пользователя, испортится файл 1SUSERS.DBF и вся работа застопорится. Чинится это легко - достаточно удалить этот файл. Но если запустить систему в режиме "1С:Конфигуратор", то испортится еще и файл 1SSYSTEM.DBF. Чинить это - сложнее...
Однако, использование файла DBEng32.ini тоже не может обеспечить защиты от перепутывания форматов БД относительно EXE-ника.... :-( Т.е. эксплуатация баз данных разных форматов требует хорошей организации системных (административных) вопросов в фирме.
Через ADS все работало без проблем около месяца, однако при выполнении операции по смене расчетного периода в 1С возникает следующая ситуация - начинаеся смена периода, через час-полтора процесс ads.exe постепенно разрастается в памяти до 1,6-1,8 Гб (видно в таскменеджере), и в этот момент вылезает ошибка нехватки памяти - *** Error *** #999 (Error 7001: No memory available.). Инфо в файле ads_err.dbf однозначно подтверждает, что ads сервер вышел за установленные пределы использования оперативной памяти.
Физической памяти на сервере 6 гб. Попытка менять что-либо в конфигурации ADS сервера через графическую утилиту ничего не дала, все равно процесс разрастается и через пару часов имеем эту ошибку. Как увеличить лимит памяти для ADS сервера путем настроек не нашел, хотя искал как мог. Без использования ADS этот процесс ранее занимал около 3-х часов (Xeon 3065 - 2,33 GHz, 6Gb RAM). Скажите пожалуйста, что может быть не так?
.....(sonirk).
1) Нехватка памяти для сервера - это следствие. Причину надо смотреть "выше" по журналу (файл ads_err.dbf). Упакуйте и прикрепите его к сообщению - посмотрю.
2) Чаще всего причина в нехватке места для файла транзакций. Это может возникать по двум (уже известным) причинам:
а) Действительно, его большой размер. ;-) При пересчете итогов. Надо воспользоваться рекомендациями из History.doc к версии 6.0.3.8. Или перейти на версию 6.0.4.2.
б) Маленький размер страницы индексного файла. Установите 1024 и сделайте реиндексацию путем удаления *.CDX.
3) В любом случае заваливание сервера активизирует (при повторном его запуске и/или входа в сессию 1С-а) алгоритм отката транзакций и реанимацию таблиц. Это часто выполняется долго. В Вашем случае это происходит успешно? И это надо сделать перед выполнением любых моих рекомендаций из текста выше. Или восстановить базу из копии.
P.S. Жду от Вас информацию.
Пока прикрепляю файл ошибок.
Теперь самое непонятное: 1С после краша сервера и перезапуска его открывается вроде бы нормально, ни на что не ругается. Поэтому я пробовал менять настройки адвантажа и опять запускал пересчет.
Сейчас вот самое интересное - последний раз получилось, что сервер упал, но 1С поеле перегрузки показывает, что смена периода прошла нормально, и вроде бы на вид все тоже как обычно. Но сервер - то упал. Терзают меня сомнения теперь, все ли в порядке с базой.
P.s. Сейчас вот воспользовался Вашими советами выше (изменил размер страниц индексного файла, переиндексировал базу + что написано в release notes). И запустил смену периода на другой базе, 1,7 гигабайта. В любом случае, судя по счетчику транзакций, сейчас работает на порядок быстрее, посмотрю, какой будет результат. Потом попробую потестировать на архивах большой базы.
.....(sonirk).
В журнале нет "первичной" информации. В настройках стоит маленький размер и он затирает предыдущие сообщения. Увеличьте размер.
С базой на 99.9% не всё хорошо. Думаю, он не сумел восстановиться после сбоя. Поэтому и показывает, что период открыт. Т.е. в базе находится "часть транзакции" (грубо говоря).
Вы проверяете на копии или на живой базе? Предлагайте способ передачи мне базы. Если можно откатиться на копию, то копию. Если - нет, то ту что ИСПОРЧЕНА.
Еще странно, почем Вы мне прислали журнал ошибок формата DBF. Должен быть файл с расширением ADT. Посмотрите, пожалуйста, сообщение (116) данной темы. Если мне предавать текущую (испорченную) базу, то надо подготовить всё, что написано в первой части сообщения (про копию).
P.S. Жду от Вас информацию.
Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот
№ 15211
Создание 28.10.07 06:07
Обновление 02.01.12 00:51
Просмотры 60247
Загрузки 1066
Рейтинг
69
Комментарии 215
Код открыт Не указано
Рубрики Внешние источники данных Разработка внешних компонент
Кому
Системный администратор
,
Программист
Тип файла Компонента, плагин (dll, vbs,..)
Платформа
Оперативный учет 7.7
,
Бухгалтерский учет 7.7
,
Расчет 7.7
Конфигурация Конфигурации 1cv7
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Бесплатно (free)
![Заявка принята](/bitrix/templates/adaptive/img/landing_page_ring/check_icon.png)