Добрый день,
не могу произвести свертку 1 с базы, месяц назад все получалось а теперь выкидывает ошибку, есть ли у кого опыт с такой ошибкой?
Платформа на которой были успешные свертки не менялась, т.е на этой платфоре (1С:Предприятие 8.3 (8.3.18.1208) ) раньше свертка работала.
-
Вопрос заданболее года назад
-
337 просмотров
«Неисправимая ошибка» при свертке базы |
Я |
16.01.20 — 15:40
Платформа 8.3.13.1690, конфа УТАП 11.4.9.83
При свертке базы во время выполнения второго пункта 1С отваливается с ошибкой: «Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm по причине:» и всё на этом.а
1 — 16.01.20 — 15:44
База весит 100Гб, оперативной памяти на сервере 64Гб, в настройках кластера снимал ограничение(-1) про максимальный объем памяти, не помогло.
2 — 16.01.20 — 16:21
… может тех. журнал глянуть ?
3 — 16.01.20 — 16:49
(2) смотрел, никаких подробностей
4 — 18.01.20 — 17:52
up. Попробовал обновить сервер и платформу до 8.3.14.1976, не помогло, та же самая ошибка.
5 — 18.01.20 — 20:25
(4) но памяти не хватает.
Может у тебя клиент, с которого свертку запускаешь, она на 32-бит, т.е. ошибка не на сервере, а на клиенте?
6 — 18.01.20 — 21:06
а зачем свертка http запросы делает ?
7 — 19.01.20 — 03:00
(5) Всё x64, свертку запускаю прямо на сервере. Есть подозрение конечно, что тупо памяти не хватает, в процессах рождаются rphost в количестве 7 штук, один основной отъедает 1,4Гб оперативы, другие по 300-500Мб, разрешено памяти на один процесс до 20Гб, после какого-то времени 1С падает с ошибкой и эти процессы сокращаются.
8 — 19.01.20 — 10:00
(7) А есть статистика, что этот рпхост перед падением доходит до предела памяти?
Понятно, что ошибка сформулирована именно в таком сообщении, которое отсылает к проверке памяти, но действительно ли в памяти проблема…
Тут как бы возникает специфический вопрос. На фоне террабайтных дисков для установки во всякие там компы, которые можно купить в розницу за относительно небольшие деньги,
получается, что 100 гб в базе вроде бы и не так много. Однако, процессы с таким размером памяти работать не хотят.
А может быть, с учетом того, что базу надо изнасиловать, обеспечить этому событию абсолютную монопольность на сервере?
Ну и убрать при этом любые ограничения на использование памяти, конечно.
Вообще, Заказчику в подобной ситуации нужно понимать, что одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
И если КОРП версию 1С покупать по стоимости просто неадекватно, то может быть имеет смысл купить просто еще одну лицензию на сервер 1С
и запускать всякие системные и сервисные вопросы на дополнительном компьютере.
Например, этот дополнительный сервер можно поставить на линукс платформе (это такой ненавязчивый намек)
9 — 20.01.20 — 02:37
(8) Дело в том, что при свертке базы, наблюдая за статистикой я увидел нагрузку на память всего 15%, проц sql сервером отъедался на 35% максимум. Полная монополия была обеспечена для этого дела. Так же игрался с параметрами кластера и сервера 1С, убирая любые ограничения по памяти, устанавливая перезапуск процессов чаще, ничего не помогло. Сегодня попробую выгрузить базу в файл и сделать свертку. По поводу дополнительного сервера это было бы замечательно, но руководство у нас очень сложное на выделение средств.
10 — 20.01.20 — 08:48
(9) ненавязчивых намеков не понимаем? ну тогда ладно.
11 — 20.01.20 — 08:55
(10) да понимаем, другое дело, что это требует достаточно больших временных затрат, а нужно сейчас, а лучше вчера )))
12 — 20.01.20 — 09:05
(11) а пробовал в порядке проверки работоспособности свертки, как обработки, запустить на короткий период? Т.е. на первые два года работы базы, а не весь период, который решили свернуть?
Кстати, как-то очень давно уже не приходилось проверять на практике, что получается со свертками, если их делать по каждому году, а не сразу за большой период — будут они поддерживать корректно наличие последовательности предыдущих сверток.
13 — 20.01.20 — 09:10
(12) Не поверишь, но это один из вариантов, который мне сегодня утром пришел на ум. Так же есть еще одна задумка. У нас в базе по алкоголю хранится очень большое количество сканов сопроводительной документации, которая распечатывается при реализации товара. Не знаю сработает ли это, сработает ли правильно, но, что если попробовать выпилить эти сканы из базы? ну и соответственно подчистить ссылки на все эти изображения? Я сам не программист, но есть возможность озадачить человека написать обработку под это дело.
14 — 20.01.20 — 09:32
(9) А загрузку диска смотрел?
15 — 20.01.20 — 09:42
(14) Диск тоже не сильно напрягался.
16 — 20.01.20 — 09:45
(8) >> одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
Странное утверждение. У нас работают базы и по 150ГБ и даже больше, и не по одной штуке на одном(!) сервере, и 24/7.
По-моему, размер базы — это отнюдь не единственный параметр, на который следует опираться, делая подобные заявления.
17 — 20.01.20 — 09:47
(0) Автор. А нафига вообще вам свёртка?
Тупой конечно же вопрос, но на всякий случай спрошу. А перед запуском свёртки тестирование и исправление базы и конфигурации делали? Уверены, что в базе действительно нет ошибок?
18 — 20.01.20 — 09:49
(9) >> игрался с параметрами кластера и сервера 1С, … устанавливая перезапуск процессов чаще.
В чём смысл этого действа?
В чём смысл вообще установки перезапуска процессов?
Уверены, что проблема не связана с тем, что рабочий процесс по вашей же настройке перезапускается и теряет связь с реальностью (длительная незавершенная транзакция падает)?
19 — 20.01.20 — 09:52
(7) >> разрешено памяти на один процесс до 20Гб
Для чего установлено это ограничение? В чём смысл?
20 — 20.01.20 — 09:53
(17) Свёрка нужна для уменьшения объема базы в первую очередь, есть в этом нужда, да и в любом случае тот период, который подвергается свёртке полностью закрыт и давно забыт. ТиИ делалось.
(18) Пробовал и с большим временем до перезапуска процесса, проблема не решилась.
(19) оно было установлено изначально, когда я пришел работать. Ограничения снимались для выполнения свёртки.
21 — 20.01.20 — 09:53
Складывается впечатление, что вы понастроили кругом заборов и теперь пытаетесь понять какой именно из них мешает приложению.
22 — 20.01.20 — 09:54
(21) Еще раз повторюсь, что так называемые «заборы» были убраны полностью, когда столкнулись с проблемой указанной в самом начале, но это не спасло ситуацию.
23 — 20.01.20 — 09:55
(20) >> Свёрка нужна для уменьшения объема базы
Более идиотскую потребность придумать сложно. Я бы ещё понял, если бы база была в несколько терабайтов. Но ради 100Гб устроить себе такой геморрой… Успехов.
24 — 20.01.20 — 09:56
(23) +100500
25 — 20.01.20 — 09:57
(0) поделку для свертки где хоть взяли то? И она прям для утапа написана? )
26 — 20.01.20 — 09:58
+ к (23) И не удивляетесь, когда поймёте, что база сократилась только на 15-20%% вместо ожидаемых 50-70%% (или сколько вы там планируете).
Следующие вопросы автора будут — что делать с неудалившимися, но помеченными на удаление объектами, и почему размер базы почти не изменился.
27 — 20.01.20 — 09:59
А так, посмотреть базопузомером, что там место занимает и выкосить лишнее и свертка не нужна будет. Если еще и сжатие в скуле включмть и реструктуризовать таблички в скуле..она еще похудеет в разы
28 — 20.01.20 — 10:18
(23) нет возможности работать с таким объемом данных комфортно, ресурсов маловато серверных и расширить их в ближайшее время не представляется возможным.
29 — 20.01.20 — 10:54
(28) >> нет возможности работать с таким объемом данных комфортно
С таким — это с каким? Какой ожидается объём?
Вы отдаёте себе отчет в том, что никакой разницы по комфорту работы между 100Гб и 50Гб не будет? Не боитесь, что наобещав пользователям манну небесную, устроив им ад на земле со сверкой начальных остатков их выверкой и исправлением всех косяков свёртки, вы будете ими прокляты, когда они поймут, что никакого обещанного комфорта нет? Кроме мифической экономии дискового места для бекапов никакого толку от свёртки нет. И это надо чётко понимать.
И что же поменяется, когда вместо 100Гб база будет весить, например, 80, а через год — снова 100?
>> ресурсов маловато серверных.
Каких именно?
30 — 20.01.20 — 10:55
Есть конторки которые за сотку другую свернут остатки скульным скриптом.
31 — 20.01.20 — 10:56
(28)
Ё.. вам нужен базопузомер, а не свёртка. Тем более, в утапе.
Там поди ни разу никто всякие регсведения типа запросыегаис/запрросы и ответы егаис и т.д не чистил никогда
32 — 20.01.20 — 11:05
(31) поделитесь ссылкой?
И да, никто никогда ничего не чистил.
(29) когда база весила 50Гб, работала она заметно быстрее. Да можно говорить за усталость оборудования, но нет, все проверки по железу проходят на ура, реиндексация и ребилд индексов делается регулярно по расписанию.
33 — 20.01.20 — 11:12
(32) та любую с нимфостарта, хоть такую
http://catalog.mista.ru/public/251332/
34 — 20.01.20 — 11:12
(32) кеши чистите? И еще настройки вариатов отчетов. Со временем могут занимать гигабайты. И реиндексацией вы их нифига не удалите
35 — 20.01.20 — 11:13
(34) Да, кеши чистим тоже регулярно. А про настройки вариантов отчетом можно подробнее, куда копать?
36 — 20.01.20 — 11:19
(32) SQL И 1С на одном сервере? (в (9) есть намек на это). А то про ограничение 1С на память прочитал, а SQL вообще может под себя всю память забрать.
37 — 20.01.20 — 11:22
(36) Да, всё крутится на одном сервере, в настройках SQL стоит ограничение до 25Гб потребляемой памяти, т.к. уже сталкивался с тем, что он кушает как не в себя )
38 — 21.01.20 — 03:52
Взяли период свертки один первый год, чуть дольше попытался поработать, но в итоге все равно отвалился с той же ошибкой.
39 — 21.01.20 — 04:39
(34) и форм бывает тоже
40 — 21.01.20 — 05:07
Короче самая жирнота это регистр сведений «Двоичные данные файлов » со сканами сопроводительных документов… только они весят почти 65Гб…
41 — 21.01.20 — 06:22
(40) вынеси во внешнее хранение и сожми РС
42 — 21.01.20 — 06:37
(41) Не будет ли от этого медленнее проходить работа с этими файлами? Опять же, как это скажется на надежности?
43 — 21.01.20 — 06:42
(42) копать молотить!!! Если адекватно разместишь — будет быстрее!
44 — 21.01.20 — 06:53
(43) Спасибо!
45 — 21.01.20 — 08:53
(32) >> когда база весила 50Гб, работала она заметно быстрее.
Во-первых, уменьшения в два раза вы не получите.
Во-вторых, я уверен на 99%, что это утверждение явно ничем не подкреплено, кроме субъективных утверждений. Потому что чудес не бывает. Ибо скорость работы клиент-серверной базы мало зависит от её объёма (во всяком случае, когда речь идёт о 100Гб).
В-третьих, даже если реально имеет место снижение скорости (что, по-моему, не факт), то причина, скорее всего, не в объёме, а либо в самой конфигурации, либо в данных (какие-то регистры не закрываются). Не исключено, что и в железе или кривой настройке SQL.
46 — 21.01.20 — 14:50
(45) спасибо за Ваши ответы, непременно буду изучать все моменты. Я далеко не программист, а средней руки сисадмин, прогера наняли только пару дней назад, так, что пока только «въезжает в тему».
47 — 21.01.20 — 14:53
(43) можно еще вопрос? после переноса файлов на том, они всё еще остаются в базе, как их вычистить? не разу не пользовался функционалом хранения файлов на томе, подумал, что после переноса файлов во внешнее хранилище они из базы потрутся сами.
48 — 21.01.20 — 15:39
(47) 1.В РС добавляешь Реквизит в котором указываешь полный путь к файлу, устанавливаешь значение этого реквизита попутно сохраняя файлы на диск, удаляешь реквизит типа ХранилищеЗначений.
Фрэнки
49 — 21.01.20 — 15:42
(48) но база автоматом не сожмется, наверное? шринки там какие-то… процедуры в админке СУБД надо бы…
«Неисправимая ошибка» при свертке базы |
Я |
soulectro
16.01.20 — 15:40
Платформа 8.3.13.1690, конфа УТАП 11.4.9.83
При свертке базы во время выполнения второго пункта 1С отваливается с ошибкой: «Невосстановимая ошибка Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm по причине:» и всё на этом.а
soulectro
1 — 16.01.20 — 15:44
База весит 100Гб, оперативной памяти на сервере 64Гб, в настройках кластера снимал ограничение(-1) про максимальный объем памяти, не помогло.
Очевидно
2 — 16.01.20 — 16:21
… может тех. журнал глянуть ?
soulectro
3 — 16.01.20 — 16:49
(2) смотрел, никаких подробностей
soulectro
4 — 18.01.20 — 17:52
up. Попробовал обновить сервер и платформу до 8.3.14.1976, не помогло, та же самая ошибка.
Фрэнки
5 — 18.01.20 — 20:25
(4) но памяти не хватает.
Может у тебя клиент, с которого свертку запускаешь, она на 32-бит, т.е. ошибка не на сервере, а на клиенте?
AAA
6 — 18.01.20 — 21:06
а зачем свертка http запросы делает ?
soulectro
7 — 19.01.20 — 03:00
(5) Всё x64, свертку запускаю прямо на сервере. Есть подозрение конечно, что тупо памяти не хватает, в процессах рождаются rphost в количестве 7 штук, один основной отъедает 1,4Гб оперативы, другие по 300-500Мб, разрешено памяти на один процесс до 20Гб, после какого-то времени 1С падает с ошибкой и эти процессы сокращаются.
Фрэнки
8 — 19.01.20 — 10:00
(7) А есть статистика, что этот рпхост перед падением доходит до предела памяти?
Понятно, что ошибка сформулирована именно в таком сообщении, которое отсылает к проверке памяти, но действительно ли в памяти проблема…
Тут как бы возникает специфический вопрос. На фоне террабайтных дисков для установки во всякие там компы, которые можно купить в розницу за относительно небольшие деньги,
получается, что 100 гб в базе вроде бы и не так много. Однако, процессы с таким размером памяти работать не хотят.
А может быть, с учетом того, что базу надо изнасиловать, обеспечить этому событию абсолютную монопольность на сервере?
Ну и убрать при этом любые ограничения на использование памяти, конечно.
Вообще, Заказчику в подобной ситуации нужно понимать, что одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
И если КОРП версию 1С покупать по стоимости просто неадекватно, то может быть имеет смысл купить просто еще одну лицензию на сервер 1С
и запускать всякие системные и сервисные вопросы на дополнительном компьютере.
Например, этот дополнительный сервер можно поставить на линукс платформе (это такой ненавязчивый намек)
soulectro
9 — 20.01.20 — 02:37
(8) Дело в том, что при свертке базы, наблюдая за статистикой я увидел нагрузку на память всего 15%, проц sql сервером отъедался на 35% максимум. Полная монополия была обеспечена для этого дела. Так же игрался с параметрами кластера и сервера 1С, убирая любые ограничения по памяти, устанавливая перезапуск процессов чаще, ничего не помогло. Сегодня попробую выгрузить базу в файл и сделать свертку. По поводу дополнительного сервера это было бы замечательно, но руководство у нас очень сложное на выделение средств.
Фрэнки
10 — 20.01.20 — 08:48
(9) ненавязчивых намеков не понимаем? ну тогда ладно.
soulectro
11 — 20.01.20 — 08:55
(10) да понимаем, другое дело, что это требует достаточно больших временных затрат, а нужно сейчас, а лучше вчера )))
Фрэнки
12 — 20.01.20 — 09:05
(11) а пробовал в порядке проверки работоспособности свертки, как обработки, запустить на короткий период? Т.е. на первые два года работы базы, а не весь период, который решили свернуть?
Кстати, как-то очень давно уже не приходилось проверять на практике, что получается со свертками, если их делать по каждому году, а не сразу за большой период — будут они поддерживать корректно наличие последовательности предыдущих сверток.
soulectro
13 — 20.01.20 — 09:10
(12) Не поверишь, но это один из вариантов, который мне сегодня утром пришел на ум. Так же есть еще одна задумка. У нас в базе по алкоголю хранится очень большое количество сканов сопроводительной документации, которая распечатывается при реализации товара. Не знаю сработает ли это, сработает ли правильно, но, что если попробовать выпилить эти сканы из базы? ну и соответственно подчистить ссылки на все эти изображения? Я сам не программист, но есть возможность озадачить человека написать обработку под это дело.
Масянька
14 — 20.01.20 — 09:32
(9) А загрузку диска смотрел?
soulectro
15 — 20.01.20 — 09:42
(14) Диск тоже не сильно напрягался.
unregistered
16 — 20.01.20 — 09:45
(8) >> одного сервера для нормальной работы в режиме 24/7 при таком размере баз и процессов уже не хватит.
Странное утверждение. У нас работают базы и по 150ГБ и даже больше, и не по одной штуке на одном(!) сервере, и 24/7.
По-моему, размер базы — это отнюдь не единственный параметр, на который следует опираться, делая подобные заявления.
unregistered
17 — 20.01.20 — 09:47
(0) Автор. А нафига вообще вам свёртка?
Тупой конечно же вопрос, но на всякий случай спрошу. А перед запуском свёртки тестирование и исправление базы и конфигурации делали? Уверены, что в базе действительно нет ошибок?
unregistered
18 — 20.01.20 — 09:49
(9) >> игрался с параметрами кластера и сервера 1С, … устанавливая перезапуск процессов чаще.
В чём смысл этого действа?
В чём смысл вообще установки перезапуска процессов?
Уверены, что проблема не связана с тем, что рабочий процесс по вашей же настройке перезапускается и теряет связь с реальностью (длительная незавершенная транзакция падает)?
unregistered
19 — 20.01.20 — 09:52
(7) >> разрешено памяти на один процесс до 20Гб
Для чего установлено это ограничение? В чём смысл?
soulectro
20 — 20.01.20 — 09:53
(17) Свёрка нужна для уменьшения объема базы в первую очередь, есть в этом нужда, да и в любом случае тот период, который подвергается свёртке полностью закрыт и давно забыт. ТиИ делалось.
(18) Пробовал и с большим временем до перезапуска процесса, проблема не решилась.
(19) оно было установлено изначально, когда я пришел работать. Ограничения снимались для выполнения свёртки.
unregistered
21 — 20.01.20 — 09:53
Складывается впечатление, что вы понастроили кругом заборов и теперь пытаетесь понять какой именно из них мешает приложению.
soulectro
22 — 20.01.20 — 09:54
(21) Еще раз повторюсь, что так называемые «заборы» были убраны полностью, когда столкнулись с проблемой указанной в самом начале, но это не спасло ситуацию.
unregistered
23 — 20.01.20 — 09:55
(20) >> Свёрка нужна для уменьшения объема базы
Более идиотскую потребность придумать сложно. Я бы ещё понял, если бы база была в несколько терабайтов. Но ради 100Гб устроить себе такой геморрой… Успехов.
Vstur
24 — 20.01.20 — 09:56
(23) +100500
Ёпрст
25 — 20.01.20 — 09:57
(0) поделку для свертки где хоть взяли то? И она прям для утапа написана? )
unregistered
26 — 20.01.20 — 09:58
+ к (23) И не удивляетесь, когда поймёте, что база сократилась только на 15-20%% вместо ожидаемых 50-70%% (или сколько вы там планируете).
Следующие вопросы автора будут — что делать с неудалившимися, но помеченными на удаление объектами, и почему размер базы почти не изменился.
Ёпрст
27 — 20.01.20 — 09:59
А так, посмотреть базопузомером, что там место занимает и выкосить лишнее и свертка не нужна будет. Если еще и сжатие в скуле включмть и реструктуризовать таблички в скуле..она еще похудеет в разы
soulectro
28 — 20.01.20 — 10:18
(23) нет возможности работать с таким объемом данных комфортно, ресурсов маловато серверных и расширить их в ближайшее время не представляется возможным.
unregistered
29 — 20.01.20 — 10:54
(28) >> нет возможности работать с таким объемом данных комфортно
С таким — это с каким? Какой ожидается объём?
Вы отдаёте себе отчет в том, что никакой разницы по комфорту работы между 100Гб и 50Гб не будет? Не боитесь, что наобещав пользователям манну небесную, устроив им ад на земле со сверкой начальных остатков их выверкой и исправлением всех косяков свёртки, вы будете ими прокляты, когда они поймут, что никакого обещанного комфорта нет? Кроме мифической экономии дискового места для бекапов никакого толку от свёртки нет. И это надо чётко понимать.
И что же поменяется, когда вместо 100Гб база будет весить, например, 80, а через год — снова 100?
>> ресурсов маловато серверных.
Каких именно?
palsergeich
30 — 20.01.20 — 10:55
Есть конторки которые за сотку другую свернут остатки скульным скриптом.
Ёпрст
31 — 20.01.20 — 10:56
(28)
Ё.. вам нужен базопузомер, а не свёртка. Тем более, в утапе.
Там поди ни разу никто всякие регсведения типа запросыегаис/запрросы и ответы егаис и т.д не чистил никогда
soulectro
32 — 20.01.20 — 11:05
(31) поделитесь ссылкой?
И да, никто никогда ничего не чистил.
(29) когда база весила 50Гб, работала она заметно быстрее. Да можно говорить за усталость оборудования, но нет, все проверки по железу проходят на ура, реиндексация и ребилд индексов делается регулярно по расписанию.
Ёпрст
33 — 20.01.20 — 11:12
(32) та любую с нимфостарта, хоть такую
http://catalog.mista.ru/public/251332/
hhhh
34 — 20.01.20 — 11:12
(32) кеши чистите? И еще настройки вариатов отчетов. Со временем могут занимать гигабайты. И реиндексацией вы их нифига не удалите
soulectro
35 — 20.01.20 — 11:13
(34) Да, кеши чистим тоже регулярно. А про настройки вариантов отчетом можно подробнее, куда копать?
ZDenis
36 — 20.01.20 — 11:19
(32) SQL И 1С на одном сервере? (в (9) есть намек на это). А то про ограничение 1С на память прочитал, а SQL вообще может под себя всю память забрать.
soulectro
37 — 20.01.20 — 11:22
(36) Да, всё крутится на одном сервере, в настройках SQL стоит ограничение до 25Гб потребляемой памяти, т.к. уже сталкивался с тем, что он кушает как не в себя )
soulectro
38 — 21.01.20 — 03:52
Взяли период свертки один первый год, чуть дольше попытался поработать, но в итоге все равно отвалился с той же ошибкой.
rphosts
39 — 21.01.20 — 04:39
(34) и форм бывает тоже
soulectro
40 — 21.01.20 — 05:07
Короче самая жирнота это регистр сведений «Двоичные данные файлов » со сканами сопроводительных документов… только они весят почти 65Гб…
rphosts
41 — 21.01.20 — 06:22
(40) вынеси во внешнее хранение и сожми РС
soulectro
42 — 21.01.20 — 06:37
(41) Не будет ли от этого медленнее проходить работа с этими файлами? Опять же, как это скажется на надежности?
rphosts
43 — 21.01.20 — 06:42
(42) копать молотить!!! Если адекватно разместишь — будет быстрее!
soulectro
44 — 21.01.20 — 06:53
(43) Спасибо!
unregistered
45 — 21.01.20 — 08:53
(32) >> когда база весила 50Гб, работала она заметно быстрее.
Во-первых, уменьшения в два раза вы не получите.
Во-вторых, я уверен на 99%, что это утверждение явно ничем не подкреплено, кроме субъективных утверждений. Потому что чудес не бывает. Ибо скорость работы клиент-серверной базы мало зависит от её объёма (во всяком случае, когда речь идёт о 100Гб).
В-третьих, даже если реально имеет место снижение скорости (что, по-моему, не факт), то причина, скорее всего, не в объёме, а либо в самой конфигурации, либо в данных (какие-то регистры не закрываются). Не исключено, что и в железе или кривой настройке SQL.
soulectro
46 — 21.01.20 — 14:50
(45) спасибо за Ваши ответы, непременно буду изучать все моменты. Я далеко не программист, а средней руки сисадмин, прогера наняли только пару дней назад, так, что пока только «въезжает в тему».
soulectro
47 — 21.01.20 — 14:53
(43) можно еще вопрос? после переноса файлов на том, они всё еще остаются в базе, как их вычистить? не разу не пользовался функционалом хранения файлов на томе, подумал, что после переноса файлов во внешнее хранилище они из базы потрутся сами.
rphosts
48 — 21.01.20 — 15:39
(47) 1.В РС добавляешь Реквизит в котором указываешь полный путь к файлу, устанавливаешь значение этого реквизита попутно сохраняя файлы на диск, удаляешь реквизит типа ХранилищеЗначений.
Фрэнки
49 — 21.01.20 — 15:42
(48) но база автоматом не сожмется, наверное? шринки там какие-то… процедуры в админке СУБД надо бы…
Распределенная информационная база (РИБ) широко применяется в инфраструктуре 1С:Предприятия несмотря на наличие иных, более современных методов доступа. Одно из главных преимуществ РИБ — полная автономность подчиненной базы, а обмен информации с центральной базой происходит при помощи синхронизации. Но есть и минусы, как любая другая информационная база 1С РИБ имеет свойство расти и работать все медленнее и медленнее, особенно на слабых ПК. Поэтому рекомендуется регулярно проводить процедуру свертки, но данный процесс содержит столько подводных камней, что многие шарахаются от нее, как черт от ладана.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Как всегда, начнем с постановки проблемы. В нашем случае будет рассматриваться РИБ по магазину 1С:Розница, как наиболее типичный случай, но механизм синхронизации в современных конфигурациях 1С стандартизован и все сказанное ниже с небольшими поправками можно применить к любой конфигурации.
Классическая конфигурация предполагает, что у нас есть центральная информационная база, чаще всего в клиент-серверном варианте, в которой консолидируется все информация торговой сети. С ней же работают менеджеры в центральном офисе. Для каждого из магазинов создается отдельная РИБ по магазину, которая работает в файловом варианте и располагается на POS-терминале магазина, в роли которого выступает достаточно маломощный компьютер, так популярные моноблоки АТОЛ содержат обычно Intel Celeron J1900.
Это хорошая, зарекомендовавшая себя платформа, но большие объемы данных — это не ее конек. Поэтому по мере работы и роста базы замедление работы становится все более ощутимо и заметно невооруженным глазом. Кассиры начинаются жаловаться на производительность и нужно что-то делать. Для уменьшения размера базы и количества документов в ней у 1С предусмотрен штатный механизм — свертка.
У многих сейчас задергается глаз и появится непреодолимое желание кого-нибудь стукнуть. Их эмоции вполне можно понять, потому что штатный механизм свертки имеет такое количество подводных камней, что, попробовав один раз можно получить негативного опыта на долгое время вперед. Почему? Давайте посмотрим.
Что предлагает нам 1С? С их стороны все просто, заходим в настройки синхронизации узла и меняем дату свертки, система сформирует документ ввода начальных остатков на эту дату, а более ранние документы будут впоследствии удалены из подчиненной информационной базы. На первый взгляд все выглядит неплохо: поменял дату и выполнил синхронизацию.
Предупреждаем — никогда так не делайте! Потому что это верный способ остановить торговую точку на неопределенный период времени без возможности быстро исправить ситуацию. Ну и получить массу сопутствующих проблем в ближайшем будущем.
Почему? Да потому что после свертки 1С зарегистрирует к обмену все документы за сворачиваемый период, в нашем случае их оказалось около 4,5 млн за 1,5 года. Одна только выгрузка такого объема займет более нескольких часов и вам очень повезет, если вы по техническим причинам выгрузить данные все-таки не сможете.
Иначе эта выгрузка попадет на POS-терминал, который начнет старательно ее обрабатывать и удалять из базы старые документы, растянуться этот процесс может очень и очень надолго: часы, десятки часов, сутки. База при этом будет работать, но плохо: с сильными тормозами и регулярными конфликтами блокировок. А дальше становится очень весело.
То, что касса висит, тормозит и в магазине очередь как в мавзолей — это самое малое зло, проблемы кроются глубже. Покупатель оплачивает картой, платеж проходит, но в далее система виснет и вовремя не получает от терминала статус оплаты. Покупатель уже ушел, а чек пробить невозможно, система не увидела оплату и требует ее повторно. Либо увидела оплату, но не смогла пробить чек, посчитала ситуацию аварийной и требует сделать сторно. А покупателя нет, давно ушел. Прибавим сюда крепкое спиртное, которое отдельно списывается через ЕГАИС, маркированную продукцию и т.д. и т.п.
Мы не хотим сгущать краски, но, когда вы поймете масштаб проблемы — на торговой точке воцарится хаос. Мало того, что ничего не работает, так и нарушено все, что можно нарушить и впоследствии всплывет куча проблем с алкоголем и маркированным товаром. И никакие бекапы вас здесь не спасут.
Поэтому, один раз получив такой опыт многие шарахаются не только от сверки, но и от розницы и 1С вообще. И самое смешное, хотя смех тут сквозь слезы, что действовал специалист строго по инструкции к программе, но кого это будет волновать, если предприятие несет вполне ощутимые и измеряемые рублями убытки?
В общем и целом, проблему можно сформулировать так: современные объемы данных и мощности торгового оборудования не позволяют выполнить штатный механизм свертки за приемлемое для бизнеса время. Поэтому мы будем сворачивать базу другим методом, позволяющим не только значительно сократить время свертки и ее влияние на работу торговой точки, но и выполнить ее даже в том случае, если технологического окна все равно будет не хватать.
Подготовка ИБ к свертке
Сразу напомним одну вещь, которую технические специалисты часто забывают: перед нами учетная система и основным признаком успешности операции будет сохранение правильных значений учетных данных. Проще говоря, после выполнения операции остатки поплыть не должны! Поэтому, прежде чем приступать к любым операциям с базой снимите отчеты по текущим остаткам товаров и денежных средств (для Розницы) и обязательно сохраните их.
Почему обязательно сохранить? Это поможет вам, если во время выполнения всех операций по свертке в базу будут внесены изменения задним числом, сохраненный отчет поможет понять, что остатки поплыли не по причине свертки и искать проблему нужно в другом месте. Чаще всего ничего страшного в этом нет и все изменения придут в свернутую базу с ближайшим обменом.
Теперь перейдем к сугубо техническим вещам, для успешного завершения процесса свертки по нашему методу требуется чтобы был правильно заполнен справочник Идентификаторы объектов метаданных, в противном случае в самом конце процесса вы получите на свернутом узле вот такую ошибку:
А это означает, что вся многочасовая работа пошла насмарку и нужно начинать заново. Поэтому заранее подстелем соломки. Откроем регистр сведений Версии подсистем и изменим версию подсистемы Розница, на какую — не важно, главное изменить. Сохраним сведения и перезапустим программу.
При перезапуске заново отработают все обработчики, запускаемые при обновлении, что гарантирует правильное заполнение необходимых справочников.
Свертка ИБ
Следующим шагом убеждаемся, что все данные из подчиненного узла переданы в центральный и отсутствуют зарегистрированные объекты для обмена. После чего выключаем синхронизацию с центральной базой и принимаем все меры для того, чтобы в базу никто не внес никаких изменений. Лучше всего переименовать папку с базой, это даст гарантию того, что к базе не смогут подключиться не только пользователи, но и скрипты или внешние приложения.
Возвращаемся в центральную базу, принимаем все сообщения от подчиненного узла и также выключаем автоматическую синхронизацию с этим узлом. Затем заходим в настройки синхронизации по магазину и сворачиваем базу на нужную дату штатным способом. В зависимости от периода свертки процесс может занять определенное время.
Подождите, скажет внимательный читатель, вы же только что говорили, что так делать не надо? Действительно, штатный механизм свертки использовать не надо, да мы и не будем, но полностью отказываться от штатных механизмов не стоит. В процессе выполнения свертки будет сформирован документ начальных остатков на дату свертки и выполнена регистрация объектов для обмена. Первый нам пригодится, а вот с регистрацией поступим по-своему.
Откроем обработку Регистрация изменений для обмена и отменим регистрацию всех объектов для подчиненного узла, заодно обратим внимание на то, какое количество их зарегистрировала штатная свертка.
И, пока мы здесь, обнулим счетчики полученных и отправленных сообщений.
Теперь вернемся в настройки синхронизации узла и выполним создание нового начального образа. Именно в этом и заключается основной смысл предлагаемого метода. Начальный образ формируется на дату свертки и происходит это гораздо быстрее, чем свертка подчиненной базы. Но приготовьтесь к тому, что образ будет формироваться продолжительное время, возможно несколько часов.
Чтобы ускорить процесс можно пойти на небольшую хитрость. Каждый, кто работает с 1С знает, что на одном и том же оборудовании файловая базе будет работать быстрее. Поэтому выгружаем ИБ в файловый вариант и формируем начальный образ в нем. Можно даже перенести копию базы на более мощный ПК и выполнить операцию там.
Важно! Убедитесь, что база загружена в режиме копии и все внешние обмены данными отключены, либо отключите их на всякий случай вручную!
Результатом создания нового начального образа будет папка с информационной базой подчиненного узла, которой нам потребуется заменить старую на магазине.
Настройка новой свернутой ИБ в магазине
При первом запуске свернутой ИБ вам потребуется заново настроить параметры синхронизации, этот процесс знаком каждому, кто разворачивал распределенные информационные базы. Однако на этапе Настройки правил отправки и получения данных вы можете получить сообщение о том, что в данной транзакции уже происходили ошибки.
Ничего страшного, сразу переходите к документам ввода начальных остатков, где вы увидите что поле Узел созданного при свертке документа содержит надпись — Объект не найден. При помощи любой обработки для изменения реквизитов установите в поле Узел документа текущий узел РИБ. Мы, например, используем следующую обработку:
Универсальные подбор и обработка объектов (управляемое и обычное приложение), 256 КБ
После чего проведите документ ввода начальных остатков и завершите настройку синхронизации.
Теперь сформируем отчеты по складским остаткам и денежным средствам в кассах с той же самой датой и временем, с которыми мы формировали отчеты перед началом свертки и убедимся, что все цифры совпадают, это означает что свертка проведена успешно.
Убедившись в правильности свертки не забудьте выполнить первоначальную настройку новой подчиненной базы: подключите торговое оборудование, выполните настройки РМК, добавьте пользователей.
Закончив с настройками, выполните синхронизацию, сначала в подчинённой базе, затем в центральном узле и убедившись, что все нормально снова включите автоматическую синхронизацию.
Как быть, если технологического окна не хватает?
В процессе свертки и выгрузки нового начального образа может получиться так, что технологического окна все-таки не хватает для успешного завершения операции. Ничего страшного, базу свернуть все равно можно. Выполните все описанные выше действия вплоть до начала выгрузки нового начального образа.
Теперь мы должны исключить любую возможность синхронизации между центральным и подчиненным узлами. Отключите с обоих сторон автоматическую синхронизацию и на всякий случай в настройках измените параметры подключения на обмен через локальную папку. Теперь мы можем продолжать работать с подчиненной базой, все созданные вновь и измененные документы будут регистрироваться для обмена, но сам обмен происходить не будет. Точно также в центральном узле будут продолжать накапливаться данные для выгрузки в базу магазина. После чего спокойно выгружаем начальный образ, предупредив всех, что обмена с узлом временно не будет.
Выгрузив новую подчиненную базу, запустите ее и, сравнив остатки, убедитесь, что свертка выполнена правильно. Теперь нам нужно перенести из старой базы в новую все те данные, которые там успели наработать. Убедитесь, что кассовая смена в старой базе закрыта и откройте Регистрацию изменений для обмена и посмотрите какие именно документы и справочники зарегистрированы к обмену и за какой промежуток времени.
Не стоит лениться, просмотрите все документы, может оказаться так, что некоторые из них были изменены задним числом. Изменения в регистрах нас не интересуют, так как все движения формируются документами и будут созданы автоматически после проведения их в новой базе. Теперь берем штатную обработку Выгрузка и загрузка данных XML и выгружаем указанные в регистрации изменений документы и справочники за указанный период.
Не бойтесь зацепить лишнего, дублей в новой базе не появится, а уже существующие документы будут перезаписаны только в случае различия в содержимом, это как раз тот случай, когда существующий документ изменили задним числом. Затем этой же обработкой загрузите изменения в новую базу.
Выгрузка и загрузка данных XML, 53 КБ
Теперь сформируем отчеты по остаткам в старой и новой периферийных базах и сравним их. Остатки должны совпадать. Если это не так, то еще раз проанализируйте измененные документы и выполните выгрузку-загрузку еще раз, при этом можете расширить временные рамки выгрузки.
После того, как вы выровняли остатки выполните обмен сначала в новой периферийной базе, затем в центральной и включите автоматический обмен. Теперь уберите старую базу и выполните первоначальную настройку новой.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Добрый день!
Испоьзуем 1С-Рарус: Управление рестораном, редакция 2 (02.0.14.01). Попробовал сделать Свертку ИБ.Программа выдала ошибку:
В процессе выполнения свертки возникли следующие ошибки:
{Обработка.СверткаИБ(1133)}: Ошибка при вызове метода контекста (Записать): Ошибка при выполнении обработчика — ‘{Документ.СписаниеТоваров(1418)}: Ошибка при вызове метода контекста (Записать): Операция не выполнена!’
Выполнение свертки прервано!!!
Подскажите как исправить!
Изменено: Тигран Калустян — 07.02.2012 14:35:37
Показывать по
10
20
40
сообщений
Новая тема
Ответить
ZNW
Дата регистрации: 17.11.2009
Сообщений: 4
«Добрый день.<br>При выполнении свертки выдает ошибку:<br><br>{ВнешняяОбработка.СверткаБазы(611)}: Ошибка при вызове метода контекста (Записать): Ошибка записи! Не установлен отбор по регистратору (Регистр накопления: НДС расчеты с покупателями)<br> НаборЗаписей.Записать();<br><br>Что это может быть? Если ошибка в внесенных данных, то как ее диагностировать?<br>Заранее спасибо.<br>»
Тракторист
Дата регистрации: 07.10.2009
Сообщений: 592
А обработка «свёртка» для этой конфы предназначена?<br>
Tanya
Дата регистрации: 03.12.2001
Сообщений: 8412
А что у вас в 24 релизе есть регистр накопления «НДС расчеты с покупателями»? Вы читаете доп.информацию во время объновления?
ZNW
Дата регистрации: 17.11.2009
Сообщений: 4
Да, у меня в 24 релизе есть такой регистр.<br>Какую именно информацию Вы имеете в виду?
ZNW
Дата регистрации: 17.11.2009
Сообщений: 4
Из описания:<br>»Внешняя обработка «Свертка информационной базы» предназначена для выполнения операции свертки информационных баз, построенных на основе одной из типовых конфигураций:<br> * Управление производственным предприятием, редакция 1.2.<br>….»<br><br>И все было бы хорошо, но.<br><br><br><br>
Tanya
Дата регистрации: 03.12.2001
Сообщений: 8412
Во время обновлении показывается окно с доп.информацией.<br>Сейчас<br>Справка- дополнение к описанию — релиз 24<br>»Удалены регистры учета расчетов для целей НДС <br>- НДС расчеты с поставщиками<br>- НДС расчеты с покупателями<br>- НДС учет распределенных оплат покупателей<br>Регистр «НДС учет распределенных оплат поставщикам» используется только для хранения информации о расчетах с бюджетом при исполнении обязанностей налогового агента и при начислении НДС по строительно-монтажным работам для собственного потребления.<br>В иных случаях, для целей НДС, где это требуется, используются данные регистров «Расчеты по приобретению (бухгалтерский учет)» и «Расчеты по реализации (бухгалтерский учет)».»
ZNW
Дата регистрации: 17.11.2009
Сообщений: 4
Фокус в том, что формально все эти регистры у меня в конфигурации. Разве что без движений с определенных чисел.<br>Но Вы натолкнули меня на мысль попробовать отключить их обработку. Спасибо 
Tanya
Дата регистрации: 03.12.2001
Сообщений: 8412
В том и дело что теперь и формально этих регистров нет в конфигурации.<br>
Показывать по
10
20
40
сообщений
Читают тему: