База БП в файловом варианте весит 320 мб, заведомо есть косяки в данных, обусловленные регулярным кривым переносом из внешней базы блока розницы, пытаюсь оттестировать уже третьи сутки(((( добралась до раздела "проверка логической целостности.Регистр бухгалтерии хозрасчетный" . Проверку уникальности записей проходит, хотя и медленно (16000 в 2 мин), а затем зависает намертво...
Может быть кто-нибудь знает, как это пробить? Вариант ручного выявления ошибок в документах не подходит, - документооборот большой, основная масса документов как раз относится к розничной торговле
Может быть кто-нибудь знает, как это пробить? Вариант ручного выявления ошибок в документах не подходит, - документооборот большой, основная масса документов как раз относится к розничной торговле
По теме из базы знаний
- "Распил" базы БП 3.0. Удаление организации из базы со всеми связанными данными
- Тестирование и исправление ключей аналитики раздельного учета НДС в БП 3.0
- Синхронизация и обмен для ERP 2.5, КА 2.5, УТ 11.5 БП 3.0, Розница, УНФ и других с EnterpriseData (универсальный формат обмена), правила обмена
- Исправление ошибок признака учета. БП 3.0
- Бухгалтерия 3.0 + Windows 10. Зависание при сохранении бухгалтерского баланса
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) tat_star, переведите на файловую (это вы уже сделали), сначала тестим chkdbfl, потом удаляем помеченые объекты, очищаем адресный классификатор, регистр соответствий, потом делаем тестирование в конфигураторе с флагом сжатия и реструктуризации, потом делаем опять тестирование со всеми галками.... а на хозрасчетном тупит потому что там движений очень очень много видимо.
Если у вас основная масса документов реализация, то надо попробывать отменить их проведение, потестировать, а потом провести заного, но это возможно только когда учет не велся задним числом и не делалось ручных корректировок, чтобы себестоимость не слетела...
Если у вас основная масса документов реализация, то надо попробывать отменить их проведение, потестировать, а потом провести заного, но это возможно только когда учет не велся задним числом и не делалось ручных корректировок, чтобы себестоимость не слетела...
База БП в файловом варианте весит 320 мб, заведомо есть косяки в данных, обусловленные регулярным кривым переносом из внешней базы блока розницы, пытаюсь оттестировать уже третьи сутки(((( добралась до раздела "проверка логической целостности.Регистр бухгалтерии хозрасчетный" . Проверку уникальности записей проходит, хотя и медленно (16000 в 2 мин), а затем зависает намертво...
Может быть кто-нибудь знает, как это пробить? Вариант ручного выявления ошибок в документах не подходит, - документооборот большой, основная масса документов как раз относится к розничной торговле
Может быть кто-нибудь знает, как это пробить? Вариант ручного выявления ошибок в документах не подходит, - документооборот большой, основная масса документов как раз относится к розничной торговле
Тестируете на основной машине, на той, где сама база расположена или по сети?
платформа последняя, 18.104 (на 17 тоже самое было), релиз пробовала и 3_0_19 и 3_0_22 - одинаково
на SQL вообще мертво висит, хотя другие базы и в клиент-серверном и в файловом тестятся влет
поэтому развернула в файловый, отключила все фоновые и регламентные задания, - так немного хоть двигается, но до конца процесс так и не дошел, - такое впечатление, что где-то зацикливается, а вот на чем, - не видно((
на чем может зацикливаться "проверка логической целостности.Регистр бухгалтерии хозрасчетный" ???
тестирую копию на сервере по сети
el-gamberro, можно поподробнее про профайлер, может я чего не знаю, - как посмотреть что делается в конкретный момент?
на SQL вообще мертво висит, хотя другие базы и в клиент-серверном и в файловом тестятся влет
поэтому развернула в файловый, отключила все фоновые и регламентные задания, - так немного хоть двигается, но до конца процесс так и не дошел, - такое впечатление, что где-то зацикливается, а вот на чем, - не видно((
на чем может зацикливаться "проверка логической целостности.Регистр бухгалтерии хозрасчетный" ???
тестирую копию на сервере по сети
el-gamberro, можно поподробнее про профайлер, может я чего не знаю, - как посмотреть что делается в конкретный момент?
(5) tat_star, Приложение Microsoft Приложение SQL Server Profiler — это графический пользовательский интерфейс для трассировки SQL, с помощью которого можно наблюдать за экземпляром компонента Компонент Database Engine или службами Analysis Services. Приложение позволяет собирать и сохранять данные о каждом событии в файле или в таблице для последующего анализа. Например, с помощью приложения можно следить за производственной средой, чтобы определить, какие хранимые процедуры снижают производительность из-за того, что выполняются слишком медленно. Приложение SQL Server Profiler используется для следующих действий:
- пошаговое выполнение проблемных запросов для поиска источника проблемы;
- выявление и диагностика медленно работающих запросов;
- перехват серии инструкций Transact-SQL, ведущих к проблеме. Сохраненную трассировку затем можно использовать для моделирования и диагностики проблемы на тестовом сервере;
- контроль производительности SQL Server для настройки рабочих нагрузок. Дополнительные сведения о настройке физической структуры базы данных для рабочих нагрузок см. в разделе Помощник по настройке ядра СУБД;
- Анализ счетчиков производительности для диагностики проблем.
У меня база маленькая 2.5 Гб, в файловом варианте.
До перехода на 3.0 тестирование и справление занимало не более 30 минут.
После перехода тоже сначала думал, что тестирование зависло: прошло 4-5 часов, а она все на регистре бухгалтерии хозрасчетный. Но подождал еше пару часов - заметил, процент исполнения перескочил...
Короче единственным вариантом сделать тестирвоание и справление явилось перенесение базы на локальный комп (она была на сетевом хранилище) и запуск на нем. Все заняло около 10 часов.
Крайне расстроен - но полагаю это фитча 3.0 :-(
В принципе при тестировании и справлени можно задавать, чтобы оно прервалось через заданное время. А птом продолжить с прерванного места. Не пробовал, но наверное это выход, когда базу надо отдать в работу в начале рабочего дня.
До перехода на 3.0 тестирование и справление занимало не более 30 минут.
После перехода тоже сначала думал, что тестирование зависло: прошло 4-5 часов, а она все на регистре бухгалтерии хозрасчетный. Но подождал еше пару часов - заметил, процент исполнения перескочил...
Короче единственным вариантом сделать тестирвоание и справление явилось перенесение базы на локальный комп (она была на сетевом хранилище) и запуск на нем. Все заняло около 10 часов.
Крайне расстроен - но полагаю это фитча 3.0 :-(
В принципе при тестировании и справлени можно задавать, чтобы оно прервалось через заданное время. А птом продолжить с прерванного места. Не пробовал, но наверное это выход, когда базу надо отдать в работу в начале рабочего дня.
На дворе 2018, а проблемы те же.
Интересно, за 4 года появилось какое-нибудь решение?
У меня база 6,5 Гб. Файловая. Останавливается на "Регистры бухгалтерии. Хозрасчетный 5%".
Работаю на ts. Платформа 8.3.10.2667, конфа БП 3.0.57.10
Единственный тут реальный совет - запустить на локальной. В выходные попробую.
Интересно, за 4 года появилось какое-нибудь решение?
У меня база 6,5 Гб. Файловая. Останавливается на "Регистры бухгалтерии. Хозрасчетный 5%".
Работаю на ts. Платформа 8.3.10.2667, конфа БП 3.0.57.10
Единственный тут реальный совет - запустить на локальной. В выходные попробую.
Могу только поделиться, что тестирование базы 2.0 на локальном компе с твердотельными дисками и 16 Гбайтами ОП не завершилось ЗА МЕСЯЦ. Прервали и проблемы лечили локально обработками. Спасибо 1С, разбить тестирование на отдельные блоки они просто не в состоянии. С другой стороны, мы от безработицы застрахованы.
(14)Была такая же ситуация. На платформе 8.3.11.2899, режим работы файловый, выполнялось тестирование и исправление базы данных. Процесс зависал надолго на регистре сведений версии объектов. В регистре 250 тыс. записей (первоначально было 746 тыс.). Тестирование выполнялось 2 дня. На 746 тыс. записей тестирование продолжалось несколько дней и не заканчивалось. На платформе 8.3.10 тестирование завершалось за несколько часов.
Обратились в 1С:
Ответ от разработчиков:
1С:Предприятие 8.3 (8.3.11.3133)
Проверка логической и ссылочной целостности выполнилась за 3 часа
Обратились в 1С:
Ответ от разработчиков:
1С:Предприятие 8.3 (8.3.11.3133)
Проверка логической и ссылочной целостности выполнилась за 3 часа
Оставлю тут для потомков:
Столкнулся с аналогичной проблемой на платформе 8.3.18 и конфиге ТСЖ 3.0.82 (на базе БП 3.0). Объем базы около 7Гб.
В файловой базе расположенной на SSD процесс не удалось провести за время более суток.
Так же зависало на "Субконто регистров бухгалтерии. Хозрасчетный".
Загрузив в 1С сервер х64 + MS SQL Server 2012 база на SSD - тест прошел менее чем за час.
Как объяснить - не знаю...
Столкнулся с аналогичной проблемой на платформе 8.3.18 и конфиге ТСЖ 3.0.82 (на базе БП 3.0). Объем базы около 7Гб.
В файловой базе расположенной на SSD процесс не удалось провести за время более суток.
Так же зависало на "Субконто регистров бухгалтерии. Хозрасчетный".
Загрузив в 1С сервер х64 + MS SQL Server 2012 база на SSD - тест прошел менее чем за час.
Как объяснить - не знаю...
(17)
По сути, при выгрузке вы сделали ТиИ самым варварским методом - грубо и безвозвратно отсекли все ошибочные данные.
Проверить это несложно: загрузите полученный dt в новую файловую базу и проведите ее тестирование. Предварительно сравните объем полученной "копии" с объемом оригинала - думаю, разница будет.
Загрузив в 1С сервер х64 + MS SQL Server 2012 база на SSD - тест прошел менее чем за час.
Как объяснить - не знаю...
Думаю, что это очевидно: перед загрузкой в SQL вы выгрузили базу в dt. А хорошо известно, что при выгрузке в dt сбойные данные не выгружаются - от слова "совсем", именно поэтому сама 1С не рекомендует dt как средство резервного копирования баз.
Как объяснить - не знаю...
По сути, при выгрузке вы сделали ТиИ самым варварским методом - грубо и безвозвратно отсекли все ошибочные данные.
Проверить это несложно: загрузите полученный dt в новую файловую базу и проведите ее тестирование. Предварительно сравните объем полученной "копии" с объемом оригинала - думаю, разница будет.
(18) Проверено - не помогает.
Перенос через dt не лечил проблему.
Проверю сейчас после теста в SQL выгрузить в файловую и проверю ее еще раз.
Более того - источник проблем был понятен изначально - были неуникальные записи в субконто и они переносились через dt.
Документ, который генерил их сейчас распроведен. Но это не мешало файловой базе "виснуть" на этом шаге теста, а sql база прошла.
ЗЫ: про то что при выгрузке в dt могут быть проблемы - понимаю.
Перенос через dt не лечил проблему.
Проверю сейчас после теста в SQL выгрузить в файловую и проверю ее еще раз.
Более того - источник проблем был понятен изначально - были неуникальные записи в субконто и они переносились через dt.
Документ, который генерил их сейчас распроведен. Но это не мешало файловой базе "виснуть" на этом шаге теста, а sql база прошла.
ЗЫ: про то что при выгрузке в dt могут быть проблемы - понимаю.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот