Была файловая БД конфигурации Производство+Услуги+Бухгалтерия. Перешли на SQL платформу и конвертировали БД под SQL. Несколько отчетов перестали работать. Пришлось допиливать эти отчеты, точнее добавлять *.ВключитьSQL(0). Далее столкнулись с проблемой при восстановлении последовательности. Документы проводятся не все, они как будто перескакивают. Короче месяц не закрывается. Что делать не знаю... может кто-то сталкивался с такой проблемой?
По теме из базы знаний
- PostgreSQL на Windows – реальная альтернатива для высоконагруженных систем на базе 1С
- Почему PostgreSQL не лучше MS SQL
- Мигрируем с MS SQL на PostgreSQL
- Переход на Linux+PostgreSQL для информационной базы 2 Tb
- Высокие риски и неопределенность: успешный перевод всей инфраструктуры 1С Авито на PostgreSQL+Linux
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Отчеты кстати были типовые - "Отгрузка покупателям" и "Поступление от поставщиков".))) Но дело не в отчетах, а в закрытии месяца. Восстанавливаю последовательность документов. Проводится несколько документов от 01.11.15, потом начинает проводиться документ от 25.11.15. Как будто перескакивает. Хотя документов в этом промежутке (01.11.15-25.11.15) - очень много.
Ну уже писали же выше. Хотелось бы услышать версию Sql сервера на который вы перешли. Ну и неплохо бы, так просто, для информирования общественности , уточнить причины перехода :). Может тогда и советы будут более дельными...
(7) Elected, Ну 2 гб. размер небольшой. Конечно надо смотреть размеры отдельных таблиц (файлов) в дбф версии что бы давать конкретные рекомендации по переходу. А так вопрос сразу по поводу перехода. Каким образом "дружили" 1с7.7 с 2005 SQL? Через секретный релиз или патчили семерку? Если через секретный релиз то проблем вроде как и не должно быть. А вот если через патч
то есть нюансы в работе связки 1с7.7 - 2005SQL. Первое, что приходит на ум это - подчиненные документы.
то есть нюансы в работе связки 1с7.7 - 2005SQL. Первое, что приходит на ум это - подчиненные документы.
Ничего не патчили. Конвертировали базу данных под SQL2005. Установили платформу - "1Cv_77_27_Unisetup.exe" компонента SQL 2005 версия и всё заработало. Единственно что пришлось допиливать, в двух типовых отчетах применить ВключитьSQL(0). Меня интересует следующее. Почему при восстановлении последовательности не все документы перепроводятся?
(10) Elected,
Вопрос достаточно общий, поэтому соответствующий ответ: не все виды документы входят в восстанавливаемую последовательность.
Если по делу, то нужны уточнения:
1. Доходит до определенного документа, и больше не перепроводит?
2. Не проводится часть документов? Например: 1 декабря перепровелся, 2 декабря - не перепровелся, 3 декабря - снова перепровелся.
Вообщем, разверните вопрос.
Почему при восстановлении последовательности не все документы перепроводятся?
Вопрос достаточно общий, поэтому соответствующий ответ: не все виды документы входят в восстанавливаемую последовательность.
Если по делу, то нужны уточнения:
1. Доходит до определенного документа, и больше не перепроводит?
2. Не проводится часть документов? Например: 1 декабря перепровелся, 2 декабря - не перепровелся, 3 декабря - снова перепровелся.
Вообщем, разверните вопрос.
(11) l_user, выполняем восстановление последовательности, документы за 01.11.15 проводятся, потом дата резко перескакивает на 25.11.15. И начинает дальше проводится. По окончанию восстановления, когда оборотную ведомость формирую, то вижу, что документы "Выпуск продукции" не перепровелись. Причём часть проведена, а часть нет.
(15) Elected, Рискну предположить (гуру меня подправят если что не так) проблема в том, что нужные документы "выпали" из последовательности документов. То есть нужно "рисовать" отчет, который выведет список документов, входящих в последовательность.
Вопросик вдогонку: пробовали "вручную" записать и провести документ из "выпадающего" периода? Как в этом случае ведет себя последовательность?
Вопросик вдогонку: пробовали "вручную" записать и провести документ из "выпадающего" периода? Как в этом случае ведет себя последовательность?
(10) Elected,
Возможно ваша платформа - не лучшее решение для SQL2005. Возьмите "секретный релиз". У меня он без проблем проработал на SQL2005 и сейчас на SQL2012 работает.
Установили платформу - "1Cv_77_27_Unisetup.exe" компонента SQL 2005 версия и всё заработало.
Возможно ваша платформа - не лучшее решение для SQL2005. Возьмите "секретный релиз". У меня он без проблем проработал на SQL2005 и сейчас на SQL2012 работает.
(10) Elected, 1Cv_77_27_Unisetup.exe содержит уже пропатченую версию bkend.dll. Но все равно как-то странно... У вас должно было ругаться на неверную версию скуль драйверов. Хотя может ваш установщик и дрова нужные подлаживает. Но я бы вам советовал с вашей нагрузкой (до 30 пользователей и размером базы ~ 2гб) как и (13), поставить родную не патченую 1с и использовать секретный релиз.
ПУБ под SQL-версию жутко тормозит при перепроведении документов. В DBF-версии перепроведение документов за 1 месяц занимало 15 минут, а под SQL-версию больше 1 часа. В чём причина таких тормозов?
P.S. Платформа 7.70.027, Конфигурация "Производство+Услуги+Бухгалтерия" (релиз 7.70.367), SQL 2005.
P.S. Платформа 7.70.027, Конфигурация "Производство+Услуги+Бухгалтерия" (релиз 7.70.367), SQL 2005.
(17) Elected, Возможно дело в настройках SQL, сети и сервера. И в самом оборудовании.
У меня был такой опыт в начале века:
ПУБ стоял на древнем серваке с парой гигов оперативы и довольно медленными винтами. Сетка тоже была не ахти. До размера базы в 300-400 мегабайт DBF работал быстрее. Дальше уже выигрывал SQL.
Универсального ответа на ваш вопрос нет. В зависимости от размера базы, количества пользователей, количества памяти, скорости сети и дисков, режима работы 1С (сеть/терминал) и разных прочих подробностей, ситуация может менять кардинально.
У меня был такой опыт в начале века:
ПУБ стоял на древнем серваке с парой гигов оперативы и довольно медленными винтами. Сетка тоже была не ахти. До размера базы в 300-400 мегабайт DBF работал быстрее. Дальше уже выигрывал SQL.
Универсального ответа на ваш вопрос нет. В зависимости от размера базы, количества пользователей, количества памяти, скорости сети и дисков, режима работы 1С (сеть/терминал) и разных прочих подробностей, ситуация может менять кардинально.
Сервер DEPO Storm 3400C3 приобретен в декабре 2015 года. В декабре и перешли с ПУБ DBF на SQL. Размер базы почти 1 гигабайт. Количество пользователей максимальное число работающих - 24 человека, но в основном работают ежедневно 13 человек. Памяти на сервере - 192 гигабайт: 12 x 16гигабайт DDR4-2133 ECC REG, у пользователей на рабочих станциях по 2 гигабайта оперативной памяти. Скорость сети - 100 Мбит, скорость дисков - 7200rpm (8 x 3000GB SAS2 hard drive). Режим работы 1С - терминал.
(19) Elected,
Зачем перешли? Гиговая база, это копейки, недостойные перевода на SQL. На таких детских размерах, да еще в терминале, SQL не даст никаких преимуществ.
Собственно говоря, при таких размерах и неудивительно, что SQL работает в заметно медленней, чем DBF.
И за какой период эти полтора десятка человек наработали базу в гигабайт? Каждый год обрезаете, что ли?
Выглядит все прилично. Зачем только это всё для гиговой базы?
Ну если хотите, позанимайтесь оптимизацией.
Проверьте загрузку процессора
Проверьте состояния ожидания sql
Посмотрите штатным виндовым "Производительностью" на загрузку сети, дисков, процессоров и т.д.
Кстати, возможно виноват не SQL, а сервер. Вы сравнивали скорость DBF и SQL на одном сервере? В 7.7 есть занятный парадокс - чем более крутой и навороченный сервер, тем медленнее на нём работает 7.7.
Сервер DEPO Storm 3400C3 приобретен в декабре 2015 года. В декабре и перешли с ПУБ DBF на SQL. Размер базы почти 1 гигабайт.
Зачем перешли? Гиговая база, это копейки, недостойные перевода на SQL. На таких детских размерах, да еще в терминале, SQL не даст никаких преимуществ.
Собственно говоря, при таких размерах и неудивительно, что SQL работает в заметно медленней, чем DBF.
Количество пользователей максимальное число работающих - 24 человека, но в основном работают ежедневно 13 человек.
И за какой период эти полтора десятка человек наработали базу в гигабайт? Каждый год обрезаете, что ли?
Памяти на сервере - 192 гигабайт: 12 x 16гигабайт DDR4-2133 ECC REG, у пользователей на рабочих станциях по 2 гигабайта оперативной памяти. Скорость сети - 100 Мбит, скорость дисков - 7200rpm (8 x 3000GB SAS2 hard drive). Режим работы 1С - терминал.
Выглядит все прилично. Зачем только это всё для гиговой базы?
Ну если хотите, позанимайтесь оптимизацией.
Проверьте загрузку процессора
Проверьте состояния ожидания sql
Посмотрите штатным виндовым "Производительностью" на загрузку сети, дисков, процессоров и т.д.
Кстати, возможно виноват не SQL, а сервер. Вы сравнивали скорость DBF и SQL на одном сервере? В 7.7 есть занятный парадокс - чем более крутой и навороченный сервер, тем медленнее на нём работает 7.7.
(20) vcv, да выглядит даже занатто... просто вот если проц базовый то это всего лишь 1.6ГГц, и если для скуля это вполне себе норм, то вот для терминала на котором крутится 1с это мягко говоря не очень. И в более менее нагруженных системах желательно разделять скуль и терминал по разным машинам, т.к. достаточно разные требования к железу для терминала и sql сервера. Хотя в данном случае с 10+ пользователями, при приведенной конфигурации сервера, все должно работать и достаточно резво. Вопрос явно в настройках рейда/операционной системы/sql сервера. Ну или как вариант смотреть саму конфу, может там какие грабли.
Зачем перешли?
У нас не только ПУБ, ещё есть 8.х - Управление торговлей, Бухгалтерия предприятия. На сервере работают не только наши бухгалтера, ещё и другие организации входящие в холдинг.
И за какой период эти полтора десятка человек наработали базу в гигабайт? Каждый год обрезаете, что ли?
Ничего не обрезали, пять лет работы и база получилась гигабайт.
Зачем только это всё для гиговой базы?
Повторюсь - это всё не для ПУБ покупалось, а для всех. На сервере работает больше 60 пользователей.
P.S. Обязательно проверим производительность, загрузку сети, процессоров и дисков. SQL-сервер несколько раз падал, так что начинались тормоза даже при работе, а не проведении документов в монопольном режиме. Может и SQL виноват.
Вы сравнивали скорость DBF и SQL на одном сервере?
Да. DBF-версия на этом сервере в два раза шустрее проводит документы за месяц.
В 7.7 есть занятный парадокс - чем более крутой и навороченный сервер, тем медленнее на нём работает 7.7.
Вот и я начинаю в этот парадокс верить.
Elected, я так понимаю у вас терминал и sql на этом сервере и крутятся?
Да. На сервере крутятся и терминал, и SQL на одной машинке.
(24) Elected, при такой конфигурации железа и приведенной нагрузке все должно работать очень быстро. Какой рейд собран? Как разбит? Что за контролер стоит? Поддерживает ли рейд контролер виртуальные диски?
Да и советовал бы посмотреть настройки sql сервера. Включен ли Shared Memory протокол? Если нет, в вашем случае обязательно включить, и приоритет ему 1.
Да Процессор 2x Intel Xeon E5-2620 v3 [6-core, 2.4GHz, 15Mb, 8.0GT/s, 1866MHz] вполне хорош, хотя как известно для 1с самое важное частота, поэтому я всегда для терминала беру с максимально возможной частотой (исходя из бюджета). Ну и исходя из среднестатистической работы обычного пользователя, по моему опыту 4-5 пользователей на ядро при частоте 3,5 ГГц вполне себе хватает даже с избытком. В вашем же случае, количество ядер аж 12 штук, при ваших 10 + пользователях, я бы вам советовал выделить 2 ядра чисто на SQL, остальные 10 пусть делят терминальные пользователи и система.
Да и советовал бы посмотреть настройки sql сервера. Включен ли Shared Memory протокол? Если нет, в вашем случае обязательно включить, и приоритет ему 1.
Да Процессор 2x Intel Xeon E5-2620 v3 [6-core, 2.4GHz, 15Mb, 8.0GT/s, 1866MHz] вполне хорош, хотя как известно для 1с самое важное частота, поэтому я всегда для терминала беру с максимально возможной частотой (исходя из бюджета). Ну и исходя из среднестатистической работы обычного пользователя, по моему опыту 4-5 пользователей на ядро при частоте 3,5 ГГц вполне себе хватает даже с избытком. В вашем же случае, количество ядер аж 12 штук, при ваших 10 + пользователях, я бы вам советовал выделить 2 ядра чисто на SQL, остальные 10 пусть делят терминальные пользователи и система.
Ну в таком случае я бы вам посоветовал сделать 10 рейд и разбить на 4 виртуальных диска. 100 Гб на систему. 10 гб для temp для скуля. Ну и оставшееся место разбить на 2 диска для хранения файлов данных и файлов транзакций. По размеру последних 2-ух разделов рекомендации давать сложно. Вы уж сами смотрите, многое зависит от того в каком режиме будут работать базы Full или Simple. Если в симпл режиме то для лога транзакция, при правильной настройке процедур обслуживания баз данных размер раздела может быть минимальным, если же режим фулл то все зависит от от того как много транзакций в день проходит через серер и как часто вы будете делать бекапы. Ну размер раздела для баз данных тут я думаю все понятно.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот