Файловые базы *. 1. CD. Физическая структура. Восстановление. Техническое описание внутреннего устройства опубликовано мной в статье Краткое описание формата файлов *.
Просмотр полной версии : Ошибка 1С. Отсутствует файл базы данных. В любом случае попробуйте поиском найти файл 1Cv8.1CD на компьютере. [Реклама удалена]..
- . В новой версии 1С можно создавать БД прямо из оснастки (не прибегая. Ровно эти же файлы лежат на http:// и оно найдено в базе данных, но для имени отсутствуют связанные с. 3. chown usr1cv81.usr1cv81 /opt/1C, cd /opt/1C, chown -R usr1cv81.usr1cv81.
- Установка 1С путем копирования базы данных. Для 8.1 это: В результате Вы получите файл 1cv8.cf или 1cv8.dt (см. выше раздел.
- Ошибка режима доступа к файлу — означает, что программа 1С находит файл 1cv8.1cd, но не может либо считать, либо записать данные в этот файл. Самый простой случай — после переноса данных..
- В сервер СУБД установить аппаратный RAID10 ( файлы БД резервированы, а объём. ПАТЧИ для обеспечения совместимости с сервером 1С: Предприятия 8.1 и 1С: Предприятия 8.2). В процессе установке компонент сервера 1C : Предприятия 8 создается cd /opt/ 1c /v8.2/i386./webinst.
- Ошибка режима доступа к файлу базы данных 1cv8.1cd. являются хранилищем некоторого набора файлов, и имеют Exception=Database Exception8, Descr=' Отсутствует файл базы данных ' Путь КБазе/1Cv8tmp.1CD'' Файл не обнаружен ' Spr Scnd Info' и некоторые другие.
CD (файловых баз 1. Сv. 8). Однако она достаточно сумбурна, плоха для восприятия, поэтому здесь я попытаюсь описать формат немного более популярно. Чтобы не было путаницы с термином «файл», сразу замечу, что когда я буду иметь в виду файл базы *.
CD, я буду говорить «файл базы», когда же я буду говорить про внутренние файлы, содержащиеся внутри базы, я буду употреблять просто термин «файл». На самом нижнем уровне файл базы данных 1. CD состоит из страниц размером 4 килобайт (0x. По сути, весь файл базы состоит из массива четырехкилобайтных страниц. Каждая страница имеет свой номер (индекс).
Здесь и далее каждый прямоугольник с красной рамкой обозначает одну страницу. На более высоком уровне находятся файлы.
. Достаточно часто можем услышать жалобы на то, что программа неожиданно "сломалась" и не запускается как в режиме "1С: . Отсутствует файл базы данных 1с 8.2 Программы: 1C 8.0, 8.1, 8.2, 8.3.
Файл состоит из одной или более страниц. У каждого файла есть ровно одна заголовочная страница, в которой размещается массив номеров страниц размещения. В каждой странице размещения, в свою очередь, находится массив номеров страниц данных. Заголовочная страница и страницы размещения – это служебные страницы, которые нужны только для хранения служебных данных (сигнатура, длина файла, версия) и для нахождения страниц данных.
Собственно содержимое файла хранится в страницах данных. Файл адресуется с помощью номера его заголовочной страницы. Страницы, принадлежащие одному файлу, совсем не обязаны следовать друг за другом, они могут быть разбросаны по всей базе. Если файл имеют нулевую длину, то у него есть только заголовочная страница.
Если же файл содержит хотя бы 1 байт данных (имеет длину 1), у файла уже есть три страницы – заголовочная, одна страница размещения и одна страница данных, в которой и записан это байт. Ну, а на самом высоком уровне находятся таблицы.
Каждая таблица состоит из нескольких файлов: Файл описания таблицы DESCR содержит текстовое описание таблицы – имя таблицы, состав полей и индексов. А также файл DESCR содержит номера файлов DATA, INDEX и BLOB. Таблица адресуется с помощью файла описания таблицы. Структуру файлов таблиц мы в данной статье рассматривать не будем, подробности можно узнать из моей статьи, ссылку на которую я приводил выше. Файл индексов может отсутствовать, если в таблице нет ни одного индекса. Файл данных неограниченной длины тоже может отсутствовать, если в таблице нет ни одного поля с данными неограниченной длины. Повторим еще раз.
База состоит из таблиц. Таблицы, в свою очередь, состоят из файлов. И наконец, файлы состоят из страниц. Адресом страницы является ее порядковый номер (индекс) в файле базы. Адресом файла является номер его заголовочной страницы. Адресом таблицы является адрес ее файла описания, а значит, номер заголовочной страницы файла описания.
Т. е. о каком бы объекте мы бы не говорили – странице, файле или таблице, адресом объекта всегда является просто номер страницы. Но каким образом найти нужную нам таблицу или файл? Как узнать их адрес?
В базе есть предопределенные объекты с адресами 0, 1 и 2. Нулевая страница (страница с адресом 0) располагается в самом начале файла базы. Нулевая страница не принадлежит никакому файлу или таблице. Она содержит сигнатуру базы, версию структуры базы и длину базы в страницах. Предопределенный объект с адресом 1 – это специальный файл, содержащий все свободные страницы базы.
Файл свободных страниц не принадлежит никакой таблице. И наконец, предопределенный объект с адресом 2 – это корневой файл. В корневом файле содержатся код локализации, количество таблиц в базе и список адресов всех таблиц. Корневой файл также не принадлежит никакой таблице. Теперь мы можем ответить на вопрос, каков минимальный объем базы?
Если база абсолютно пуста и в ней нет ни одной таблицы, то в файле базы все равно есть предопределенные объекты: Итого 5 страниц по 4 килобайта – 2. Именно такой размер мы получили в эксперименте с chdbfl. Структура информационной базы 1.
СТеперь рассмотрим вкратце, что нам надо знать про логическую структуру базы 1. С. Определимся сначала с терминологией. Информационная база 1. С (файл 1. Cv. 8.
CD) является файловой базой. Но не всякая файловая база является информационной базой 1. С. Например, хранилище конфигураций (файл 1.
Cv. 8ddb. 1. CD), тоже является файловой базой, но не является информационной базой 1. С. Проще говоря, файловая база – это любой файл с расширением 1. CD, а информационная база 1. С – это частный случай файловой базы (с именем 1.
Cv. 8. 1. CD), в которой содержатся конфигурация и бизнес- данные. Тем не менее, когда говорят, что упала файловая база, практически всегда имеют в виду именно информационную базу. Источников информации о составе таблиц информационной базы и их назначении довольно много. Довольно подробно этот вопрос освещен в книге Профессиональная разработка в системе 1.
С: Предприятие 8, краткую информацию можно, например, посмотреть в статье Структура и название таблиц использыемых для хранения данных в БД 1. С 8. х. Поэтому остановимся только на аспектах, впрямую относящихся к теме статьи. Все таблицы информационной базы делятся на 2 категории – системные таблицы и таблицы данных.
Системные таблицы хранят служебную информацию, их состав и структура примерно одинаковы во всех базах (в зависимости от версии платформы 1. С). Таблицы данных хранят бизнес- данные. Их состав в разных базах может сильно различаться. Основа базы – это конфигурация, а конкретно конфигурация базы данных. От нее зависит, сколько в базе будет таблиц данных, какая у них будет структура. Конфигурация базы данных хранится в системной таблице CONFIG. Основная (разрабатываемая) конфигурация целиком в базе не хранится.
В таблице CONFIGSAVE хранятся только отличия основной конфигурации от конфигурации базы данных. В рабочих базах, как правило, таблица CONFIGSAVE пустая (кроме момента обновления конфигурации базы). К основным системным таблицам относятся также таблицы FILES, PARAMS и DBSCHEMA. Таблицы CONFIG, CONFIGSAVE, FILES и PARAMS имеют идентичную структуру и, по сути, являются хранилищами файлов.
Таблица DBSCHEMA всегда имеет одно поле и одну запись, хранящую текстовый файл. При обновлении конфигурации базы данных происходит реструктуризация - процесс создания или изменения таблиц данных, полей и индексов. Но каким образом 1. С создает имена таблиц, полей и индексов? Все объекты конфигурации, хранимые в БД, в процессе реструктуризации получают порядковый номер. Если объект конфигурации существовал до реструктуризации, то он сохраняет свой номер, а новые объекты получают номера по порядку, начиная с некоего хранимого максимального номера.
Процесс нумерации новых объектов при реструктуризации немного похож на процесс автоматической нумерации документов, когда хранится последний использованный номер, и каждый следующий документ получает номер на единицу больше. Соответствие объектов конфигурации их порядковым номерам хранится в записи DBNames таблицы PARAMS.
Приведу для примера кусочек этой записи из одной из баз: {dde. Reference",2. 63.
Fld",1. 29. 6},{3d. Fld",1. 29. 7},{6e. Document",8. 3},{3d.
Fld",1. 29. 8},{3d. Fld",1. 29. 9},{3d. Fld",1. 30. 0},{3d. By. Field",1. 32.
Fld",6. 51},{fcb. Fld",8. 18},{3d. 44. Fld",1. 30. 1},{6e.
Enum",1. 13}. Каждый объект конфигурации имеет свой внутренний уникальный идентификатор, который и используется в записи DBNames. Также здесь указывается тип хранимого объекта и тот самый порядковый номер объекта. Имя объекта в базе формируется как символ подчеркивания плюс тип и плюс номер. Например, таблицы, которые описаны в приведенном примере, будут иметь имена «_Reference. Document. 83» и «_Enum. By. Field. 13. 22».
Вообще, по имени типа объекта можно понять, что это – поле, индекс, или таблица. Полями являются типы «Fld», «Line. No», «Turnover», «Turnover. Dt», «Turnover. Ct». Имена типов индексов начинаются на «By» («By. Field», «By. Owner.
Field», «By. Parent. Field», «By. Property», «By.
Prop. Recorder», «By. Resource», «By. Dim», «By. Dims», «By. Dimension», «By. Dimensions», «By. Dim. Recorder»). Остальные типы являются таблицами.
Причем типы «VT» и «Ext. Dim» являются подчиненными таблицами (табличными частями), и для получения полных имен этих таблиц надо впереди еще добавить имя таблицы объекта владельца, например «_Document. VT5. 17. 2». Дополнительно, в DBNames хранятся строки, относящиеся к некоторым системным таблицам{0.
System. Settings",2. Common. Settings",2. Rep. Settings",2. Rep. Var. Settings",2. Frm. Dt. Settings",2. Users. Work. History",2. Уникальный идентификатор в таких строках пустой, т.
Имена таблиц при этом не содержат порядковый номер, т. SYSTEMSETTINGS», «_USERSWORKHISTORY» и т. Таким образом, все системные таблицы можно условно разделить на основные системные таблицы, их имена не начинаются с символа подчеркивания и они не описаны в DBNames, и дополнительные системные таблицы, имена которых начинаются с символа подчеркивания, и они описаны в DBNames. По этому признаку к основным таблицам можно отнести таблицы «IBVERSION» и «V8. USERS». Но в реальности эти 2 таблицы не обязательны, и 1. С вполне может запуститься без них.
Тот факт, что нумерация существующих объектов сохраняется при реструктуризации, приводит к тому, что в базах с одной и той же конфигурацией имена таблиц и полей одних и тех же объектов конфигурации могут быть разными. Рассмотрим простейший пример. Например, мы создали новую конфигурацию, в ней создали один справочник с одним реквизитом. После обновления конфигурации БД получаем такую картину (я не привожу все записи, остальные записи – это системные таблицы): {3a. Reference",7},{a. Fld",8},Теперь добавим еще один справочник с одним реквизитом, обновим: {3a.
Reference",7},{a. Fld",8},{d. 76fc. Reference",1. 0},{7. Fld",1. 1}А теперь выгрузим конфигурацию, и загрузим ее в новую базу.
После обновления в новой базе: {3a. Reference",7},{d.
Reference",8},{a. Fld",9},{7. 52. 2b. Fld",1. 0},Как видим, номера одних и тех же объектов разные.
Все из- за разного порядка обновлений. Также следует заметить, что в записи DBNames содержатся только нумерованные объекты.
Восстановление работоспособности файловой базы. Обследование. Продолжение. Предыдущие этапы: 0. Введение. Этап 1. Обследование, определение проблемных мест. Итак, перед нами "мёртвая" файловая база.
Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex- редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой- нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex- редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению. А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1. С предоставляет, как минимум, два штатных способа.
Рассмотрим их поподробнее. Утилита chdbfl. exe из поставки 1. С: Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки". Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой- то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких- то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой. Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex- просмотрщику или редактору, если в начале файла сигнатура 1. CDBMSV8 на месте, значит, проблема только в поле длины).
Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее. 2. Технологический журнал (ТЖ) 1.
С: Предприятие. Прекрасная возможность узнать, на каком месте "спотыкается" платформа, если она "зависает", "падает", или выдаёт загадочное сообщение "Ошибка формата потока" (причём сама ошибка может быть где угодно, в любом из файлов системных таблиц). Закрываем все сеансы 1. С, чтобы они нам не мешались, и настраиваем запись ТЖ. Для этого идём в папку "bin", где лежат исполняемые файлы текущей плафтормы "1cv.
ТЖ "logcfg. xml" примерно следующего содержания (исходный текст файла настройки есть в прикреплённом архиве): Вместо "C: 1cv. Подробнее про настройку ТЖ можно почитать, например, здесь: http: //help. Далее, запускаем нашу проблемную базу в режиме конфигуратора, дожидаемся вывода окошка с ошибкой, или краха приложения, и сразу же идём изучать содержимое записанного лога (он будет в файле "1cv. PIDМетка. Даты. log"). На следующие события и ошибки не обращаем внимания (их наличие является нормальным): Exception=Net. Data. Exchange. Exception,Descr='server_addr=any: port_num descr=Ошибка сетевого доступа к серверу..
Exception=Database. Exception. 8,Descr="Отсутствует файл базы данных 'Путь.
КБазе/1. Cv. 8tmp. CD'"Файл не обнаружен 'Spr. Scnd. Info'и некоторые другие. Собственно, мы даже можем не увидеть там нужного нам сообщения об ошибке, но зато мы увидим, при работе с каким объектом (таблицей или внутренным файлом таблицы) происходит ошибка. С: Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются: V8. USERS - таблица с данными пользователей (для баз версий 8.
DBSCHEMA - схема (структура) БД_USERSWORKHISTORY - история работы пользователей_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроека также системные таблицы- каталоги: PARAMS - содержит файлы с параметрами БДFILES - содержит прочие системные (служебные) файлы. CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID. GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной). CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы- каталоги являются, по сути, аналогами каталога в обычной файловой системе, т. FILENAME - имя файла. CREATION/MODIFIED - дата создания/изменения. ATTRIBUTES - атрибуты.
DATASIZE - размер файла. BINARYDATA - содержимое файла (двоичные данные)В случае полного отсутствия какой- либо системной таблицы (не путать с наличием пустой таблицы) 1. С при старте базы выдаст сообщение "База данных полностью разрушена". Теперь мы понимаем, что записи в ТЖ типа. DBV8. DBEng,2,process=1cv. Trans=0,Func=select.
File. Name,File. Name=ibparams. DBV8. DBEng,1,process=1cv. Trans=0,Func=read.
File,Cat. Name=Params,File. Name=ibparams. infозначают чтение файла "ibparams. PARAMS. Итак, анализируем файл лога. Например, если происходит "Ошибка формата потока", а в конце файла лога мы видим примерно следующее: 4. DBV8. DBEng,2,process=1cv. Usr=Админ,Trans=0,Func=restore. Object,table. Name=DBChanges.
DBV8. DBEng,2,process=1cv. Usr=Админ,Trans=0,Func=restore. Object,table. Name=DBSchema. SDBL,1,process=1cv.
Usr=Админ,Trans=0,Sdbl=GET NGENERATIONS4. SESN,1,process=1cv. Func=Attach,IB=Путь. КБазе,Nmb=2,ID=GUID4. SESN,1,process=1cv.
Func=Finish,IB=Путь. КБазе,Nmb=2,ID=GUIDто можно заключить, что ошибка формата потока возникла при работе с содержимым таблицы "DBSchema", следовательно, содержимое этой таблицы нужно будет изучить поподробнее. Ещё, если в наличии есть какой- нибудь старый бэкап, можно применить такой приём: записать ТЖ при его старте, и сравнить его с ТЖ при старте проблемной базы, чтобы понять, какими сообщениями об исключениях можно пренебречь, а также, какие этапы при старте проблемной базы проходят нормально, а до каких дело не доходит. По окончании данной процедуры файл "logcfg.
Открываем нашу базу при помощи утилиты Tool_1. CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т. BLOB- полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при Ти. И или реструктуризации (в процессе выполнения этих операций 1.
С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы. При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ". БД. Также утилита позволяет сохранить конфигурацию БД в cf- файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации. Открываем базу при помощи компоненты 1.
CDLib. Информация из п. Вашему вниманию представлены два скрипта (являющихся внешними обработками для режима управляемого приложения 1. С: Предприятие 8. Обработка "Save. All. Tables. epf" позволяет сохранить данные всех таблиц в виде структуры вложенных папок и файлов в папке "Objects" (создаётся там же, где находится файл базы), и далее их можно изучать при помощи обычного файлового менеджера. Также, после сохранения всех таблиц, полезно изучить содержимое лога "logdb.
Если сообщения об ошибках в нём отсутствуют, то можно сказать, что физических ошибок в структуре хранения таблиц в файле базы нет, и проблемы уже либо в отсутствии каких- то таблиц, либо в их некорректном содержимом. Обработка "View. Records. BLOB- данные (файлы создаются в папках с именами соответствующих таблиц), предназначена, в первую очередь, для полуавтоматического анализа содержимого системных таблиц (хотя с помощью неё можно просмотреть и другие таблицы). В случае ошибок при извлечении BLOB- данных, или при их распаковке (если содержимым BLOB- поля являются запакованные по алгоритму Deflate данные), выводятся соответствующие сообщения. Загрузка базы в систему восстановления баз 1.
С restoration- base- 1c. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1. С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 2.
Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1. С, то все данные исходной базы загружаются также в базу 1. С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из- за ограничений формата).