Проверить dt файл на ошибки
Пытаюсь развернуть DT рабочей базы на тестовой машине.
DT весит 9 Гб, а сама база примерно 110 Гб. База клиент-серверная, сервер на debian, стоит postgresql 9.6 и сервер 1С 8.3.13.1513 х64. Клиентская терминальная машина на Windows, на ней стоит 8.3.13.1513 х64.
Запускаю загрузку базы из DT, проходит 5 минут, база начинает весить 2,3 Гб и всё, выходит ошибка "В информационную базу загружены не все данные 1с. Ошибка формата потока"
Пробовал загрузить 4 разных DT-файла. Все вылетают с такой ошибкой.
В чем может быть проблема? Почистить кэш не предлагать))
(3) точно. DT был сделан с базы под платформой 1513 и разворачивается тоже на 1513, только на другом компе
(7) NAME TYPE SIZE USED PRIO
none virtual 6G 0B 0
Как понять сколько нужно?
(9) ТиИ не делал в источнике, надо чтобы все вышли часов на 8, а это проблематично.
Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается
Если в базе есть ошибки, то она не загрузится из dt'ника
Все кто делает резервные копии - dt'никами сильно рискуют остаться без базы.
(12)[Все 4 файла сделаны с одной базы, в разные дни. Но с базой вроде пока проблем не наблюдается]
это тебе кажется
а что только я один не понимаю, зачем ему эту всю хрень нужно затащить на клиентскую машину, если ее можно и нужно развернуть как лишнюю базу на том же сервере и в нем тестить все себе интересное на сервере?
(33) а им не похрен где тестить? чего такого страшного в запуске теста на отдельной базе, ну пускай даже на том же сервере?
Вот соседняя ветка, уверяла Переход с Микрософта на Линукс что с postgres проблем нет, особенно с бекапами.
(36) я бы, пока суть да дело, а если есть готовые ДТ, то проверил бы из них загрузку в соседнюю базу на том же сервере, чтоб лобовым способом проверить, что проблемы в ДТ нету.
(35) Можно случайно перепутать тестовую базу и боевую. Можно неосторожним движением уронить процесс сервера 1С:Предприятия или SQL-сервера.
(39) (37) А что за отладчикофобия? Проверял специально, влияние параметра включенной отладки на сервере на производительность влияет на уровне погрешности. Конечно, когда процесс трассируется с подключенным отладчиком, это другое дело. Но повторяю, сам по себе признак разрешения отладки не мешает работе.
(47) Да, на самом деле оказался битый dt. Все 4 dt-шника, которые я пробовал загружать были сделаны скриптами. И все оказались битые. Выгрузил вручную через конфигуратор и загрузил без ошибок
(43) >> А что за отладчикофобия?
Это тема отдельно холивара. И даже если считать, что включение отладки не влияет на производительность (ну или пренебречь этим влиянием), остаётся проблема, когда разработчик начинает отлаживать процесс в боевых базах на продуктивном rphost-е. А этим грешат 99.9% разработчиков, где включена отладка на продуктиве.
(48) DT - не является резервной копией для клиент-серверных баз. Это аксиома. А зачем было доказывать аксиому.
(50) ну как бы у него аксиома получилась двоякая - ДТ вручную Конфигуратором работает, а хз откуда взятые скрипты создавали ДТ битый.
з.ы. И зачем нужно было годами делать как бы архивы, которые никто никогда не тестил на загружаемость ?
(49) точно! Если включил отладчик на продуктиве, то значит рано или поздно, так или иначе, но пользоваться им начнешь :-)
(52) Продуктив продуктиву рознь. В 90% случаев это допустимо. Более того, часто даже необходимо подключиться отладкой к пользовательскому сеансу, чтобы выяснить что там у него не так.
Я однажды sql profiler на рабочей базе включил и забыл закрыть. Полдня не могли понять, почему всё медленнее вдвое стало :)
(53) Для этого надо отдельную тему создавать. Из SQL база никак не хотела разворачиваться. Я выгружал бэкап рабочей базы через pgadmin, создавал новую базу в pgadmin на тестовом сервере, восстанавливал данные из бэкапа в эту новую базу, и через какое-то время pgadmin писал ошибку, что не удалось загрузить данные и большой список ошибок. Пробовал через pgadmin сделать копию 100% рабочей базы на том же тестовом сервере и восстановить её в другую базу на этом же сервере - те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип). Долго разбирался с кодировками и прочей хренью на линуксе, но всё было ок, русские локали работали и пустая база создавалась с русской кодировкой. Решил обновить postgresql с 9.6 на 10, но хрен там. У версии debian, которая установлена на серваке какие-то проблемы с новым 10-ым postgresql из-за библиотеки libssl.so
Короче понял, что без админов в линукс лучше не лезть, откатил всё обратно, попробовал вручную сделать бэкап рабочей базы и развернуть его. Чудом всё получилось. Дальше буду с админами разбираться что не так с бэкапами postgresql
(57) Что-то мне помнится, что для восстановления бэкапа постгреса надо сначала базу создать из 1с, а потом уже восстанавливать бэкап поверх существующей базы. Что-то там с определяемыми типами, которые создаются в контексте базы, и эти определения не сохраняются в бэкапе.
(57)[ те же самые ошибки (что то там про то, что не создан какой то оператор и какой-то не верный тип)]
дык это 100500 раз описано, да есть фичи
Ситуация: БГУ 17,5. Перед обновлением сделан архив. Во время обновления произошла ошибка, база "слетела" с полутора гигов до 100 mb.
Пробуем восстановиться из архива, при попытке выскакивает ошибка: "Неверный формат файла для загрузки информационной базы
Ошибка формата потока
по причине:
Ошибка формата потока"
Больше архивов нет. Только битый .dt. Есть ли возможность восстановить данные из него?
ПРОБЛЕМА РЕШЕНА.
Развернули .dt через PostgreSQL, почистили пару таблиц, свернули.
Все нормально загрузилось.
Всем спасибо за участие и внимание.
DarkDaemon; starihok; Gang031; alex-223; bobold; Vitalyi28; audion; tatoshka0403; Bukaska; иуыывщк; + 10 – Ответить
(2) andrewks, а что тогда используют для создания резервной копии ИБ?
Всегда дт-шки грузил перед обновлениями например.
(12) утюгчеловек, в случае файловой базы - копирование/архивирование .1CD, в случае серверной базы - бэкап средствами СУБД
(16) kasper076, с Вас ссылка на официальную позицию 1С, где она рекомендует выгрузку в dt для резервного копирования
(18) andrewks, 1С не исключает возможности делать резервную копию через выгрузку базы, но указывает на некоторые ограничения этого метода (одно из которых уже имеющиеся ошибки в базе). Вот выдержка с ИТС:
Иногда этот режим используют, также, для создания резервной копии информационной базы, однако такой вариант его использования обладает рядом недостатков. Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо.
В зависимости от варианта работы 1С:Предприятия (файловый или клиент-серверный), можно рекомендовать следующие способы создания резервной копии информационной базы:
При использовании файлового варианта 1С:Предприятия 8 можно организовать процесс создания резервной копии информационной базы путем простого копирования файла 1CV8.1CD в отдельный каталог или с использованием программного обеспечения для резервного копирования и восстановления данных. Следует учитывать, что для обеспечения целостности и согласованности данных во время создания резервной копии, работа пользователей с информационной базой должна быть запрещена, однако время, необходимое на создание резервной копии существенно меньше, чем при использовании выгрузки информационной базы в файл.
При использовании клиент-серверного варианта 1С:Предприятия 8 появляется возможность создания резервной копии информационной базы средствами СУБД. Например, SQL Server позволяет выполнять резервное копирование данных в то время, когда база данных находится в многопользовательском режиме и доступна для всех пользователей.
Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных.
(21) DKiguin, и я не исключаю. но лишь как в дополнение к бэкапам средствами СУБД.
а, впрочем, насильно никого заставлять не собираюсь, если и эта ветка Вас не убеждает, и на прямое указание на недостатки этого метода со стороны 1С - в конце концов, дело Ваше, Вам решать, и Вам устранять возможные последствия, в случае чего
(18) andrewks, 1cv8upd.htm "Порядок обновления конфигурации. " "Независимо от используемого варианта 1С:Предприятия 8, резервную копию можно создать, используя режим выгрузки информационной базы. Для этого:
запустите систему 1С:Предприятие в режиме «Конфигуратор»;
в меню «Администрирование» выберите пункт «Выгрузить информационную базу»;
в открывшемся диалоге укажите имя файла, в который будут записаны данные."
(24) kasper076, приводите полные цитаты
Резервную копию можно создать:
при использовании файлового варианта 1С:Предприятия 8 - путем копирования файла 1СV8.1CD в отдельный каталог;
при использовании клиент - серверного варианта 1С:Предприятия 8 - средствами SQL Server.
Независимо от используемого варианта 1С:Предприятия 8, резервную копию можно создать, используя режим выгрузки информационной базы. Для этого:
запустите систему 1С:Предприятие в режиме «Конфигуратор»;
в меню «Администрирование» выберите пункт «Выгрузить информационную базу»;
в открывшемся диалоге укажите имя файла, в который будут записаны данные.
перечисляются возможные способы. я и не отрицал, что такой способ имеет место быть. но, кстати, неспроста он (способ выгрузкой) на втором месте.
Рекомендации по организации резервного копирования информационной базы
1С:Предприятие поддерживает возможность загрузки/выгрузки информационной базы в файл. Этот механизм предназначен, прежде всего, для получения образа информационной базы независимо от способа хранения данных. Например, загрузка/выгрузка информационной базы в файл может быть использована для преобразования файлового варианта к клиент-серверному.
Иногда этот режим используют, также, для создания резервной копии информационной базы, однако такой вариант его использования обладает рядом недостатков. Основным недостатком такого способа создания резервной копии является необходимость использования однопользовательского режима для осуществления этой операции. При большом объеме информационной базы перерыв в работе пользователей может быть достаточно велик, что не всегда приемлемо.
В зависимости от варианта работы 1С:Предприятия (файловый или клиент-серверный), можно рекомендовать следующие способы создания резервной копии информационной базы:
При использовании файлового варианта 1С:Предприятия 8 можно организовать процесс создания резервной копии информационной базы путем простого копирования файла 1CV8.1CD в отдельный каталог или с использованием программного обеспечения для резервного копирования и восстановления данных. Следует учитывать, что для обеспечения целостности и согласованности данных во время создания резервной копии, работа пользователей с информационной базой должна быть запрещена, однако время, необходимое на создание резервной копии существенно меньше, чем при использовании выгрузки информационной базы в файл.
При использовании клиент-серверного варианта 1С:Предприятия 8 появляется возможность создания резервной копии информационной базы средствами СУБД. Например, SQL Server позволяет выполнять резервное копирование данных в то время, когда база данных находится в многопользовательском режиме и доступна для всех пользователей.
Использование этих способов дает максимально точную копию состояния информационной базы, что не всегда может быть получено при использовании режима загрузки/выгрузки информационной базы. Например, если в базе данных есть нарушения, то при выгрузке некоторая информация может быть не выгружена, в то время как при копировании будет сохранена вся информация, и после восстановления можно будет выполнить исправление базы данных.
Также существенно уменьшается время нахождения информационной базы в однопользовательском режиме в случае файлового варианта работы 1С:Предприятия 8, а в случае клиент-серверного варианта однопользовательский режим вообще не используется.
Кроме этого положительным моментом является то, что при использовании перечисленных способов, можно применять различные специализированные программные средства для создания резервных копий.
Есть небольшой сервер 1с. Windows 10, 1С - 8.3.11.3034 (64), Postgres 9.6.7-1.1C.
База Далион около 35 Гб.
Была произведена выгрузка серверной базы в dt - файл. Заново загрузить не получается никаким образом.
Выходит ошибка "Передача данных прервана по инициативе принимающей стороны".
При этом в файловую загружается без ошибок.
Какие были испробованы варианты:
1. Переустановка Postgres
2. Выгрузка из файловой (которая развернута из нашей dt-шки) и загрузка в серверную
3. Загрузка dt-ки из которой была развернута база пару месяцев назад
4. Чистил кеш 1с- сервера, и базы
5. Создавал базу серверную пустую заново и в неё пытался загрузить.
Ошибка одна и та же. Загрузка длится в среднем 6-7 часов.
З.Ы. Кластер 1с - параметры по умолчанию
Postgres - настройки по умолчанию
З.Ы.Ы Не пробовал только развернуть базу с пустой конфой и грузкой-загрузкой перетащить из файловой. Но т.к. данных на 35 Гб оставляю этот способ на самый край
(1) ИМХО- база данных содержит недопустимые данные ( строка длиной 500 или подобное) Postgres очень "трепетно относиться" к таким "наборам" данных. попробуйте на MS SQL.. он менее "чувствителен" или перед выгрузкой DT произведите тестирование и исправление ИБ. ( на файловой )
(4)Потому что данные были корректны :) Смущает что загрузка длиться "6-7 часов" :( не встречал за практику. даже ИБ на 200 ГБ грузиться из dt час
P/S ИБ на 35 ГБ великовато для файловой
(9) Тоже смущает время загрузки такое(
Поэтому и перевел на Postgres, и работало все замечательно, но вот случилось(
(9) Так я беру туже дт-ку которую тогда загружал (осталась лежать) и все равно не могу загрузить. Вот поэтому и встает вопрос, а точно дело в дт-ке если из неё один раз загрузилось все корректно!?
(14) значить проблемы в Postgres и его настройке. см.. лог Postgres что случилось? почему прервал? почему долго грузил? что помешало. и т.д.
Не было данных неприемлемых для сервера SQL.
Смотрите логи сервера: на чем он обламывается.
Еще как варианты сетевые проблемы (если загружаете по сети) или таймаут транзакции,
Если грузите по сети, то запустите параллельно при востановлении ИБ пинг к серверу, если есть потеряные пакеты, то "ой".
Попробуйте загрузить ИБ локально на сервере SQL.
(11)Гружу локально. Единственный вопрос, может ли быть проблема из-за того что клиент 32, а сервер 64?
Разрядность не должна влиять, единственно ограничение 32-х битного клиента это размер процесса в 2 ГБ. При востановлении данных он не должен сильно пухнуть.
Что в логах сервера SQL?
ИМХО не хватило памяти . сколько rphost взял в процесс? сколько в процессе у Postgres ? сколько памяти Всего?
P/S Попробуйте установить MS SQL Developer и загрузить
+ 8.3.11.3034 ( если не ошибаюсь можно вручную увеличить количество рабочих процессов rphost) - ошибаюсь :(
(27) Где бы мне такую информацию узнать?
MS SQL Developer - поди ограничение на 10 ГБ?
"Максимальный объем памяти для буферного пула на экземпляр Компонент SQL Server Database Engine Максимум, поддерживаемый операционной системой "
(34) Если я не ошибаюсь, это не обязательно. Т.к. эти настройки идут по умолчанию, раскомментить нужно, если я хочу изменить эти параметры.
и для загруки файла из дт - вообще нужно кое-что комментировать
(2) У меня как-то в SQL не загружалась база, так же из-за длин строк, если память не изменяет. Тестирование и исправление перед выгрузкой решило вопрос
Была произведена выгрузка серверной базы в dt - файл. Заново загрузить не получается никаким образом.
Есть небольшой сервер 1с. Windows 10, 1С - 8.3.11.3034 (64), Postgres 9.6.7-1.1C.
База Далион около 35 Гб.
Была произведена выгрузка серверной базы в dt - файл. Заново загрузить не получается никаким образом.
Выходит ошибка "Передача данных прервана по инициативе принимающей стороны".
При этом в файловую загружается без ошибок.
Проверьте лицензионный ли у вас сервер 1С:Предприятия.
В феврале этого года разбирались с этой проблемой, заходили слева, справа. Чего только не делали, оказалось - лицензия.
Долго выясняли, кто поставил битую 1С, так и не выяснили, зато информацию сервер исправно отправлял в 1С и пришло уведомление об отсутствии лицензии и срок до 15 марта на установку лицензии.
зато информацию сервер исправно отправлял в 1С и пришло уведомление об отсутствии лицензии и срок до 15 марта на установку лицензии.
В феврале этого года разбирались с этой проблемой, заходили слева, справа. Чего только не делали, оказалось - лицензия.
(1) В вашем варианте должен появиться файл дампа
Рассмотрим пример: в каталоге dumps появился файл: rphost_8.3.11.3034_7c938235_20131025162441_3348.mdmp.
Его можно отослать в 1С, если все в порядке с лицензией. Они опишут вам проблему, которая у вас возникла.
Иногда дамп создается с предупреждением, иногда сам собой.
Если проблемы с лицензией, то отсылать не советую.
Попробуй перед выгрузкой в dt провести реструктуризацию через конфигуратор и скульную проверку файла на ошибки.
(7) Реструктуризацию можно и в клиент-серверной базе провести. Скульная проверка это аналог DBCC CHECKDB из mssql. Как команда называется в постгресе не знаю.
И на всякий случай напомню, что расширение dt расшифровывается как Data Transfer (пруф в реестре ос). Этот формат предназначен исключительно для перехода с файлового режима работы на клиент-серверный и обратно. Использовать его для хранения бэкапов недопустимо (пруф на итс), т.к. платформа вообще не гарантирует, что выгруженная в DT файл база успешно загрузится обратно.
(6)Я, все же программист и администрированием приходится заниматься очень редко. Но за 14 лет работы не помню ни разу проблем с восстановлением из дт-шки. Но ваше замечание учту в дальнейшем.
сколько места на диске, где установлены базы Postgres ?
Postgres 9.6.7-1.1C хотя бы обновите от 10-й версии
(37)
посмотрите
настройки постгрес для ссд ( гугл )
- они оптимизированы под хдд
"EDT LOG could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied"
Поискал по этому поводу в интернете, не очень много информации, но вроде как есть. В основном все повторяется. Где-то написано что-то из-за большого объема этих файлов (файлы статистики), у меня они не более 10 КБ, из-за антивируса который сканирует файловую систему и занимает файл (нет антивира), а в этот момент postgres пытается к этому файлу обратиться (не нашел я как в винде отследить кто использует файл). Советы типа переместить в RAM память. Насколько я понял это делается легко в Linux, а вот в Windows там какие-то танцы с бубнами (ну не админю я почти, не мой профиль).
И решил я, а перемещу ка я этот файл (пропишу настройки в config) на другой физический диск (Операционка , Сервер 1с и postgres с базами находятся на C (raid1 из двух ssd), а еще есть HDD рядом).
В итоге, база загружалась 8 часов, раздулась в итоге до 65 гб (почему так??), но загрузилась. И работает нормально.
Что делать, если архив базы загружается в файловом варианте с ошибкой "Превышен максимально допустимый размер внутреннего файла", а загрузить очень надо? Постараюсь примерно описать технологию, которую нам удалось разработать при активном участии Виктора Сосновского из фирмы "1С" на партнерском форуме.
Предположим, вы сформировали архив базы и теперь пытаетесь загрузить его в файловом варианте. Сначала все идет хорошо, но в какой-то момент возникает ошибка:
"Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: Превышен максимально допустимый размер внутреннего файла 'D:\1CBASES\NewDB/1Cv8.1CD' "
Я лично потратил ОЧЕНЬ много времени на поиск решения этой проблемы и в итоге нашел его, что позволило нам создать файловую копию базы данных размером 18 Гб и в итоге сэкономило примерно неделю времени (могу в комментариях рассказать, как было дело, но сейчас речь не о том).
Итак, причин возникновения такой ошибки может быть несколько:
- Размер КАКОЙ-ЛИБО таблицы в базе данных превышает лимит для файловой версии (4 Гб). Если честно, во избежание подобных эксцессов мы проверяли размеры таблиц базы заранее с помощью обработки "SQL базомер" (или аналогов).
- Ошибка связана с глюком особенностями платформы, и вызвана определенной спецификой структуры метаданных выгружаемой конфигурации.
С первым случаем все понятно - если базомер показал превышение лимита по каким-то из таблиц базы, то эти таблицы необходимо почистить. Если речь идет о справочнике или непериодическом регистре сведений, то нужно постараться удалить оттуда ненужные элементы/записи. То же самое относится и к "тяжелым" документам с их табличными частями. В первую очередь следует заняться удалением помеченных объектов, конечно.
Регистры накопления - отдельная тема. Размеры таблиц итогов могут превышать размеры таблиц записей регистра, причем зачастую значительно. Иногда может помочь даже простой пересчет итогов.
Регистры остатков могут некорректно (не по всем измерениям) закрываться, что приводит к ОЧЕНЬ значительному и быстрому разрастанию таблиц итогов. Списание "зависших" остатков регистра накопления может при последующем пересчете итогов дать экономию до нескольких Гб, проверено на собственном опыте у "нерадивых" клиентов. ))
Что же делать, если каждая таблица вашей базы размером менее 4 Гб, но ошибка все равно возникает?
Это значит, что у вас второй случай - проблемная структура метаданных конфигурации. Вероятнее всего, ошибка возникает на этапе создания индексов.
В двух словах опишу ситуацию в целом, чтобы было понятно, словами Виктора Сосновского из 1С. Ниже цитата с партнерского форума:
"При загрузке информационной базы в файловом варианте сначала загружаются данные всех таблиц, а затем создаются индексы. Ошибка создания индекса приводит к тому, что индекс, созданный с ошибкой, и все последующие индексы не создаются. Если в базе много данных, то это приведет к существенному снижению производительности. Полноценная работа с такой базой будет невозможна."
Нужно узнать, какая именно таблица приводит к ошибке при создании индекса.
Включаем технологический журнал - в папку "С:\Program Files (x86)\1cv82\__НомерВерсииПлатформы__\bin\conf\" (или аналогичную, __НомерВерсииПлатформы__ подставьте свой) кладем файл logcfg.xml примерно следующего содержания:
Внимательно следим за тем, чтобы каталоги для дампов и логов:
- Существовали
- Различались
- Были доступны для чтения и записи тому пользователю Windows, от лица которого вы запускаете конфигуратор.
Перезапускаем конфигуратор (при этом включается технологический журнал) и заново пробуем загрузить наш .DT. После возникновения ошибки идем в каталог для логов, находим там файл лога, содержащий нашу ошибку, и внимательно читаем его.
Первое же вхождение EXCPCNTX в логе в моем случае указало на команду, которая вызвала ошибку: CREATE INDEX _Accum27148_ByDims_TRRRRRRRRRSSR (у вас название индекса будет другое).
По цифрам из названия индекса с помощью обработки "Структура хранения таблиц базы данных" (или аналогов, которые умеют показывать индексы) находим, какой таблице принадлежит данный индекс. У меня это оказалась таблица оборотов одного из нетиповых регистров накопления.
А дальше начинается самое интересное - нужно попытаться угадать, что именно в структуре вашей таблицы приводит к ошибке индексации.
В первую очередь следует смотреть, какие поля входят в индекс. Как выяснилось, платформа ОЧЕНЬ не любит, когда совокупный размер ключевых полей индекса становится значительным. В частности, она не любит индексировать длинные строки - так, в моем случае в индекс попадало измерение с типом СТРОКА (500) и оно вызывало ошибку. Другой представитель фирмы "1С" высказался на партнерском форуме еще в 2007 году:
" Если длина ключа оказывается близкой к 2К, то начинается резкий рост размера индексов с рядом неприятных последствий. "
И действительно, в 2013 году ничего не изменилось - в подобных случаях наблюдается лавинообразный рост размеров индекса на файловой базе. А когда таблица индекса превышает лимит в 4 Гб, загрузка .DT останавливается с ошибкой.
Лично мне помогло отключить для проблемного измерения флажок "Использование в итогах", т.к. в реальности итоги по нему не требовались. Оно перестало попадать в саму таблицу оборотов и, как следствие, в индекс таблицы оборотов. Есть и другие способы - более строго ограничить размер строки, например. Читал, что некоторым это помогало.
Эти изменения необходимо применить к информационной базе, при этом произойдет реструктуризация вашей таблицы.
Если изменения внесены на SQL-копии базы, то после этого нужно заново выгрузить .DT и попытаться перезагрузить его в файловой версии.
Кому особо не повезло и ошибка вылезла снова - тому следует повторить сначала всю процедуру, начиная с анализа логов. Возможно, проблемная таблица была не одна, или вам не удалось решить проблему с размерами полей, входящих в индекс.
Если в процессе работы в 1С:Бухгалтерия (8.3 редакция 3.0) возникают странные ошибки или она вообще перестала запускаться - базу нужно чинить.
Запускаем утилиту вручную
1. Для начала сделайте резервную копию имеющейся базы. Дело в том, что тестирование и исправление это необратимые операции над базой данных, которые почти всегда делают ситуацию лучше, но в очень небольшом проценте случаев могут все испортить. Вот на этот самый редкий случай мы и должны сначала сделать резервную копию.
2. Зайдите в папку, в которую у вас установлена 1С. Обычно это 'C:\Program Files\1cv8'. Здесь вы увидите папки в названии которых присутствуют цифры, обозначающие номера версий платформы. Выберите папку с самой старшей версией (в нашем случае 8.3.4.304):
3. Внутри этой папки вы найдете папку bin:
4. Зайдите в эту папку. Там много файлов. Найдите файл с названием chdbfl:
5. Запустите этот файл и перед вами откроется утилита для проверки физической целостности файла базы данных. Укажите имя файла базы данных, нажав кнопку с тремя точками:
6. Чтобы указать это имя зайдите внутрь папки той базы, которая не запускается и выберите там файл '1Cv8':
7. Поставьте галку 'Исправлять обнаруженные ошибки'. Бояться нечего, ведь у нас есть резервная копия. И нажмите кнопку 'Выполнить':
8. В зависимости от размера базы - проверка и исправление могут занять продолжительное время. Дождитесь окончания, закройте утилиту и запускайте базу - скорее всего она заработает.
Если исправление не помогло и стало только хуже - восстановите базу из резервной копии, которую мы сделали на первом этапе, а затем переходите к тестированию и исправлению базы через конфигуратор.
Запускаем утилиту через обновлятор
Для пользователей моего Обновлятора всё ещё проще.
Отметьте нужную базу в списке, а затем из пункта "Ещё" выберите пункт "6.16 Проверка физической целостности файла БД (chdbfl.exe)":
При этом обновлятор:
- сам заблокирует базу и выгонит работающих пользователей;
- сам создаст резервную копию базы;
- сам запустит утилиту chdbfl.exe и дождётся пока вы выполите в ней все необходимые проверки;
- сам пустит всех пользователей обратно после того как вы закроете утилиту chdbfl.exe.
При этом, если вам потребуется восстановить (откатить) базу на созданную резервную копию перед тестированием - отметьте базу галкой, а затем из пункта "Ещё" выберите вариант "6.01 Восстановить файл данных базы из zip, 7z, rar":
С уважением, Владимир Милькин (преподаватель школы 1С программистов и разработчик обновлятора).
Как помочь сайту: расскажите (кнопки поделиться ниже) о нём своим друзьям и коллегам. Сделайте это один раз и вы внесете существенный вклад в развитие сайта. На сайте нет рекламы, но чем больше людей им пользуются, тем больше сил у меня для его поддержки.
Читайте также: