Всем привет.
Возникает проблема время от времени.
Это сильно усложняет жизнь. Хочется найти правильное решение и применить его для защиты самого себя от случайностей.

В общем хочется поднять вопрос о разного рода восстановлениях базы 1С (в частности файла 1Cv8.1CD ), после любых сбоев.
У меня уже третий случай за месяц. Происходит чаще всего так.
Есть распределенные базы. Центральная (OF) и 7 узлов.
Когда вносятся изменения в конфигурацию базы OF, эти изменения с обменом идут в узлы. Там возникает загрузка и порой динамическое обновление конфигурации.
Уже третий раз за месяц у меня возникла ситуация, когда при обновлении узла, что-то происходит с базой. У пользователя появляется сообщение, что файл 1Cv8.1CD поврежден и дальнейшая работа не возможно. Предлагается Закрыть 1С, перезапустить, Подробно.
В подробно вижу тот же текст - типо файл поврежден, дальше никак нельзя работать.
Два раза из трех случаев утилита chdbfl.exe помогла. Но есть и другой результат, что очень плохо для меня. Работать и знать, что может быть результат 50/50, как-то настораживает.

И так вот случай, база после обмена при применении изменения в узле зависла. Пользователь заметив, что комп подвис, перезагрузил машину. После чего не смог войти в программу. Проверка базы утилитой (chdbfl.exe) показала, что ошибок не обнаружено.
При попытке входа, появляется сообщение, что при последней попытке обновления, была произведена реструктуризация базы данных. Повторите попытку обновления конфигурации.
При этом не представляется возможным открыть конфигуратор или 1С-ку в режиме предприятия. Что с базой делать? Увы не знаю. Узел умер.

Кто из вас сталкивался с разными падениями базы. Поделитесь опытом пожалуйста, расскажите о методах восстановления базы. Очень нужно знать, как можно вернуть базу к жизни после любого падения.
Может есть известные вам сторонние программы и утилиты для проверки файла 1Cv8.1CD. Может его можно как-от открыть и ручками подправить?

И сюда же наверное, раз у меня узлы дохнут, как мухи, опишите пошагово альтернативный способ создания узла РИБ. В интее читал много способов, пока не получилось сделать хоть бы один. Все как специально, чего-то не договаривают в статьях.

На сегодня я сделал простое резервное копирование на клиенте всей базы, каждый день с утра. Но это не дало результата. При падении узла, вернуть базу из копии не вышло. Она не принимает данные из центральной базы. Пишет, что не соответствие конфигурации, ожидается другие данные. На этом полный пипец. Есть копии в которых в лучшем случае можно просто данные глянуть.

Спасибо заранее всем откликнувшимся.
---
Еще бы найти действительно работающий альтернативный способ создания нового узла из центральной базы

http://infostart.ru/public/65830/
---
CERBER, Совет простой - не пользоваться динамическим обновлением. Никогда. Ну и бэкапы раз в сутки.
---
А ещё иногда помогает очистка кэша.
---
CERBER, какое конфигурации компов в узлах? Есть закономенрность между конфигураиями "железа" и падением?
---
tolyan_ekb,
Нет закономерности нет.
Машинки примерно по 2 гига оперативы, процы от 2 до 2,5 Ггц.
Винты все SATA емкость не имеет значение, но все же от 160 Гб и выше.
материнки в основном интеловые.
Компы:
HP Compaq dc7100 Small Form Factor PC
HP Compaq dc7600 Small Form Factor PC
HP Compaq dc7700 Small Form Factor PC
HP Compaq 500B Microtower PC

Как видно не самосборка.
---
помнится - приходилось заново делать узел.
и 2-й вариант - конфигурацию загрузить и ЦБ (с отключением признака периферийного узла).

всего этого много и в инете и у техподдержки.
---
Ну и если узел подчиненный сдох проще сделать новый слепок (если нет времени повозиться с восстановлением).
---
Не совсем понятно, что вы хотите в итоге? Чтобы не ломалось? Или иметь возможность восстановить ВСЕГДА?
Ну так сохраняйте файл до махинаций, упала база, выгнали юзеров, заменили файлик и ок.
Ну и как выше заметили: "Совет простой - не пользоваться динамическим обновлением. Никогда. Ну и бэкапы раз в сутки."
Это ещё хорошо если подчиненный узел, взял да инициировал заного, ну что-то потерялось, после обмена...
---
"Совет простой - не пользоваться динамическим обновлением. Никогда." - довольно часто пользуюсь динамическим обновлением в течении года, все OK.
---
MONOMOTO1, учитывая, что динамическим обновлением можно пользоваться на типовых конфигурациях, и то рекомендуется постоянно бекапиться.
---
MONOMOTO1, РИБ используешь? Видимо нет
---
ZergKRSK, Действительно не использую, даже не знаю, что это.
---
CERBER, вообще я для MONOMOTO1 писал, он хвастается что нет проблем с динамическим обновление. У меня когда РИБ не было тоже пользовался динамическим обновлением без опаски.
---
http://infostart.ru/public/174806/
http://infostart.ru/public/175344/
http://infostart.ru/public/182845/
http://infostart.ru/public/182889/
---
andrewks, Спасибо большое за ссылки, замечательные статьи. Прочитал пока, что поверхностно, но уже многое становиться ясным.

Еще бы найти действительно работающий альтернативный способ создания нового узла из центральной базы.
---
Увы база сейчас активно дорабатывается. Пользователей в среднем около 30. Если мне каждые час-полтора потребуется вносить изменения и я буду всех выгонять. Да меня через пару дней все пристрелят. Потому не могу я отказаться от динамического обновления.
Например изменил слово на ценнике, ради такой мелочи выгонять всех - не пойдет такое дело.

Про бекапы раз в сутки уже писал выше. Делаются исправно. Результат - плохой.
Бекап узла при подключении вместо умершей базы выдает или не соответствие конфигураций, или обмен в обще не стартует.
Все базы узлы созданы из центральной - путем создания начального образа узла РИБ. Другие способы не применяются.
В итоге сейчас не могу заново создать узел, база 4 гига, а при создании, то ей памяти мало, то вылетает с какой-нибудь ошибкой, да и в момент создания надо всех выгонять.

....и ЦБ (с отключением признака периферийного узла).
всего этого много и в инете и у техподдержки.
а ссылочками можете помочь. Киньте пару достойных.

За очистку кэша могу сказать лишь то, что помогает для пользователя. У меня бывало у пользователя некоторые кнопки становились не активными. Кто их знает чего это происходит. Но удаление кэша в виндовом каталоге пользователя возвращает к работе все функции 1С.

Хочу чтобы хоть, как-то стабильно работало. Чтобы не ломалось - такого не бывает с 1С. А вот возможность всегда восстановить любую информацию, базу, обмен и др. Это ДА, стоит на первом месте.

Видимо придется в обработку обмена дописать ручками создание букапа, перед обновлением.
Бедные компы и винты. За месяц сотни гигов будет. Придется писать скрипты убивающие бэкапы старше недели например. Опять городить забор и подпирать его костылями. Почему фирма 1С, сама не предусмотрит все эти пункты. Впечатление, что они с сами никогда не работали. куча фантозеров девелоперов сидит, пишут новые баги, а народ их исправляет.

И все же люди поделитесь ссылками на качественные статьи, на те по которым вы сами делали новые узлы для РИБ. И на способы восстановления файлов 1Сv8.1CD.
---
Еще бы найти действительно работающий альтернативный способ создания нового узла из центральной базы

http://infostart.ru/public/65830/
---
kievgorez, Спасибо большое за ссылочку. Она действительно мне помогла. Сделать снова узлы. Благодарю.
---
Ребята, подскажите пожалуйста.
Значит чтобы сделать новый узел или восстановить старый путем копирования. Я использовал обработку, скаченную по ссылочке http://infostart.ru/public/65830/. Все замечательно, но и та обработка в моей базе не с первого раза отработала до конца.
Выясняя возможные причины, увидел у себя в базе ошибки. Сделал тестирование и исправление. Конфигурация вывалила кучу ссылок на объекты которых она не нашла и далее все прошло нормально.
Повторное тестирование прошло гладко.
При этом база имеет размер 4 гига. На моем компе 3 гига оперативы. При выполнении очистки данных по обменам между базами, обработка не могла завершить работу. Вываливалась с сообщением "Не достаточно памяти". Проблему решил путем создания новой базы на сервере PostgreSQL загрузки в нее .dt файла выгрузки базы и только там она отработала быстро и четко.

А вот стандартной обработкой по созданию нового узла обнаружил ошибку, выдаваемую базой, но видимо ее сам PostgreSQL передает 1С-ке.
"Попытка вставки не уникального значения в уникальный индекс:" (кстати забавно в 1С-ке слово "неуникального" написано слитно :) а должно быть раздельно с НЕ).
ERROR: null value in column "_period" violates not-null constraint
Ошибку можно увидеть на прикрепленной картинке.
И так получается 1С-ка при вставке данных в таблицу не может записать не уникальное значение в столбец имеющий уникальные записи.

Делал выгрузку базы в .dt файл и загрузку ее в новую базу, для проверки, что будет если. В итоге отработала 1С-ка все красиво и быстро, ошибок не выдала, сам сервак Postgre не ругался. Почему при полной выгрузке и загрузке эти не уникальные данные нормально пишутся, а при создании нового узла база спотыкается на них?

И вот вопрос - как мне найти это место в 1С-ке в базе и исправить???
Приму любые советы: SQL скриптом в PostgreSQL или как-то может быть можно самой 1С-кой.
Для PostgreSQL Servera использую "pgAdmin III".
---
2 Гига, 3 Гига - не кажется Вам, что это маловато для современности?
---
Martinian, С чего-то все начинали. Пройдет время и у меня она будет большая, а пока я рад, что не приходится делать бекапы по 100 гиг. А то бы пришлось винты покупать большого объема.
На сервачке крутятся под PostgreSQL 7 баз по 4 гига максимум. Понемногу растут.
Сервачок справляется, места хватает, оперативы тоже. Пользователя слава богу не размножаются, как китайцы. В общем какая-то стабильность есть. И вот наконец-то все узлы восстановлены. Обмен даже, как часики стал ходить. Появилось время чаю выпить.

А про мой вопрос об ошибочке (ERROR: null value in column "_period" violates not-null constraint )
смотрю знатоков нет. Печально. Впечатление, что у всех 1С-ка на какое-то удивление работает стабильно и даже хорошо.
---
Добрый день, прошу помочь облазил все, что можно в какой то момент база перестала запускаться и выдавала ошибку база повреждена.
1. Проверка (chdbfl.exe) восстанавливает с потерей данных с начала года.
2. Тестирование и исправление вообще сразу пишет ошибку.
3. Была возможность запустить без обработки каких либо событий, но часть документы не доступны через запрос сразу выскакивает ошибка и база закрывается.
получается, что надо использовать HEX редактор, но тут можно сказать вообще не разбираюсь, но у меня есть копия рабочей базы 30.09, а база сломалась 02.10 2,5 дня потеряно, какие документы там делались непонятно т.к. заносился квартал и документы сразу убирались в папки, это можно выявить только после актов сверок, а есть текущие документы которые ни как не отражены в бумажном виде.
В HEX редакторе видно что таблица смещена или как то записана неправильно:
В приложении картинки HEX где выделено красным это нерабочая база, видно что конец рабочей базы не совпадает с теми же строками, незнаю правда должны ли они совпадать? Вообщем если у кого то мысли как починить эту штуку буду очень признателен и даже готов вознаградить. Спасибо
---
выкладывайте не рабочую базу и архив
---
получается, что надо использовать HEX редактор Это - последнее средство, есть и более интеллектуальные инструменты - например, Tool_1CD.
Вообщем если у кого то мысли как починить эту штуку буду очень признателен и даже готов вознаградить. Мысль стандартная: заархивируйте битую базу, выложите куда-нибудь на файлообменник, а ссылку или дайте тем, кто заинтересуется, или просто опубликуйте тут - желающих поковыряться в этом случае найдется больше.

Очень хорошо, что есть свежий бэкап - весьма вероятно, что он потребуется, если дело дойдет до экспорта-импорта таблиц при помощи названной выше Tool_1CD.

P.S. Награды пока не требуется. :)
---
в Tool_1CD, режим только для чтения редактировать нельзя при форматирование в другую версию 8.2.14 выдает ошибку база повреждена.
---
Недавно была такая ситуация (тема ) когда нельзя было конвертировать данные , правда геморно, проще из архива восстановить и за 2 дня добить доки

еще конечно вариант их Hex- редактора скопировать поехавшую таблицу
---
В том то и дело не понятно, что забивать уже документы в папки сложили, а некоторые документы которые только в программе занесены так вообще непонятно откуда брать, те же счета звонить клиентам спрашивать пришлите счет который мы вам выставляли, можно конечно но очень глупо получится.

 Проблема в том, что данные которые хранятся в таблицах даже Tool не может прочитать, есть таблица счетов когда я ее пытаюсь открыть то программа пишет кучу ошибок и зависает такой метод как перенос таблиц не подойдет т.к. таблица походу разрушена

А вот со смещением, если подробнее объясните как сделать, я что то не догоняю.
1. как я понял в первой строчке указан размер базы и при открытии он считывает размер базы в заголовке с реальностью и если лишнюю строчку добавить то все база не откроется. (или не так?)
2. У меня появилась какая то таблица "SCHEMASTORAGE" в поломаной базе, в рабочей базе я такую таблицу не видел. Для чего она нужна вообще?
---
1. Если у вас формат 8.3.8 то вроде из заголовка убрали реальный размер базы, там теперь вроде лежит размер страницы 4К , 8К и т.д. Главное что бы размер файла был кратен размеру страницы и если вы добавляете строку , то можно в конце файла прописать недостающие байты
2. На счёт этой таблицы я не в курсе можно посмотреть на www.its.1c. ru описания таблиц или прошерстить в интернете

Вообще трудно что-то сказать не видя базу поэтому и прошу скинуть архив