1с длина таблицы не кратна длине записи

Обновлено: 04.07.2024

Описание формата приведено в терминах языка C. Размер типа char – 1 байт, размер типа short int – 2 байта, размер типа int и unsigned int – 4 байта. Префиксом 0x обозначаются шестнадцатеричные числа.

Файлы баз *.1CD состоят из блоков длиной 4096 байт (0x1000). Соответственно, длина файла всегда кратна 4096.

Блок 0

char sig[8]; // сигнатура “1CDBMSV8”

unsigned int length;

Первые 8 байт – сигнатура базы «1CDBMSV8».

Следующие 4 байта - это версия базы. На данный момент мне встречались только версия «8.0.5.0» (ver1 = 8, ver2 = 0, ver3 = 5, ver4 = 0) – это базы 1Cv8.0 и версия «8.1.0.0» (ver1 = 8, ver2 = 1, ver3 = 0, ver4 = 0) – это базы 1Cv8.1 и 1Cv8.2.

Следующие 4 байт – длина базы (файла) в блоках.

Предназначение поля unknown неизвестно, всегда содержит 1.

Объекты

Вся остальная информация в базе хранится в объектах (файлах базы). Каждый объект состоит из одного или более блоков. У каждого объекта есть один заголовочный блок, блоки с таблицей размещения, и собственно данные. Второе и третье может отсутствовать.

Структура первого блока каждого объекта такова:

char sig[8]; // сигнатура “1CDBOBV8”

int length; // длина содержимого объекта

unsigned int version;

unsigned int blocks[1018];

Первые 8 байт – сигнатура базы «1CDBOBV8».

Есть 2 типа объектов.

Блок 1. Таблица свободных блоков

Первый тип объекта – это таблица свободных блоков. Признаком этого блока является поле version равное 0. Такой объект в базе всегда один, и его заголовочный блок располагается всегда в блоке со смещением 1 (т.е. по адресу 0x1000). Длина данных такого объекта равна (length * 4) байт.

В blocks содержатся номера блоков, в которых собственно и находится содержимое таблицы свободных блоков. Значащими являются ненулевые значения в массиве blocks. Содержимое таблицы свободных блоков – это просто массив номеров свободных блоков:

unsigned int free_blocks[length];

Таким образом, в базе содержатся ровно length свободных блоков.

Когда системе требуется новый блок для данных, то она берет последний свободный блок из массива free_blocks и уменьшает length на 1. Если свободных блоков нет, то он создается в конце файла базы. Блоки, содержащиеся в массиве blocks, не являются свободными, а принадлежат объекту – таблице свободных блоков. В blocks может содержаться больше блоков, чем необходимо для хранения массива free_blocks.

Остальные объекты

Второй тип объектов характеризуется ненулевым значением поля version. Вся информация в базе, кроме блока 0 и таблицы свободных блоков хранится именно в таких объектах.

В поле length содержится длина в байтах данных объекта.

В массиве blocks находятся индексы блоков, содержащих таблицу размещения данных объекта. Каждый блок, указанный в blocks, и являющийся частью таблицы размещения, имеет следующую структуру:

unsigned int datablocks[1023];

Поле numblocks указывает количество реальных значений в datablocks (от 1 до 1023). В datablocks содержатся индексы блоков, в которых находится собственно содержимое объекта (данные). Так как в одном блоке таблицы размещения может быть указано максимум 1023 блока с данными, то соответственно, максимальная длина данных, указанных в одном блоке таблицы размещения равна 1023 * 4096 = 4190208 байт (0x3ff * 0x1000 = 0x3ff000). Таким образом, из длины содержимого объекта length мы можем определить количество фактических значений в blocks. Если length равен 0, то в blocks нет значащих данных, иначе количество значений в blocks равно (length - 1) / 0x3ff000 + 1 (деление целочисленное, без остатка). А также можно вычислить максимальную длину данных одного объекта: 4190208 * 1018 = 4265631744 байт (1018 – максимальное количество значений в массиве blocks), это совсем немного меньше 4х гигабайт.

Повторим, в заголовочном блоке объекта находится массив blocks, содержащий индексы блоков с таблицей размещения. А в таблице размещения находятся блоки, содержащие сами данные.

Блок 2. Корневой объект

Последним объектом с предопределенным расположением является корневой объект. Заголовочный блок корневого объекта располагается в блоке с индексом 2. Все остальные объекты базы могут быть получены через корневой объект. Структура данных этого объекта зависит от версии базы, хотя и различается несильно. Для версии базы «8.0.5.0» эта структура выглядит так:

Для версии «8.1.0.0» структура выглядит так:

Т.е. различаются эти структуры только длиной поля lang. В поле lang содержится код языка базы. Код языка базы представляет собой строку в ANSI-кодировке. Мне встречались только базы с кодами «ru_RU» и «en». На что влияют эти коды языка, я не знаю, возможно, на порядок сортировки строк при построении индексов.

В поле numblocks содержится количество элементов в массиве tableblocks. В массиве же tableblocks содержатся индексы объектов, содержащих все таблицы данных. Т.е. таблиц в базе ровно numblocks.

Объект таблицы

Каждый объект таблицы, указанный в корневом объекте, содержит просто текстовое описание таблицы в Unicode. Вот пример описания таблицы:

Как видно из этого примера, здесь присутствуют имя таблицы (_Reference4), раздел описания полей таблицы (Fields), раздел описания индексов (Indexes), параметр Recordlock и раздел Files.

В разделе Files всегда содержатся три числа, которые содержат индексы заголовочных блоков объектов (по порядку) с записями таблицы, Blob-данными (строки неограниченной длины и двоичные данные) и индексами. Если какого-либо объекта у таблицы нет, то соответствующее число равно нулю.

В разделе Fields содержатся описания полей таблицы. Описание каждого поля содержит (по порядку): имя поля (FieldName), тип поля (FieldType), признак использования NULL (NullExists), длину (FieldLength), точность (FieldPrecision) и признак регистрочувствительности (FieldCaseSensitive).

Сколько байт занимает каждое поле в записи, и как его интерпретировать, зависит от параметров поля. Во-первых, если NullExists у поля равен 1, то первый байт поля является признаком NULL. Значение 0 этого байта означает, что поле не содержит значение (т.е. содержит NULL). В противном случае, поле содержит значение. Если же NullExists равен 0, то такого байта в поле нет.

Далее, размер и формат поля зависит от типа поля. Типы поля бывают такими:

«B» - двоичные данные. Длина поля равна FieldLength байт.
«L» - булево. Длина поля 1 байт. Нулевое значение байта означает Ложь, иначе Истина.
«N» - число. Длина поля в байтах равна Цел((FieldLength + 2) / 2). Числа хранятся в двоично-десятичном виде. Первый полубайт означает знак числа. 0 – число отрицательное, 1 – положительное. Каждый следующий полубайт соответствует одной десятичной цифре. Всего цифр FieldLength. Десятичная точка находится в FieldPrecision цифрах справа. Например, FieldLength = 5, FieldPrecision = 3. Байты 0x18, 0x47, 0x23 означают число 84.723, а байты 0x00, 0x00, 0x91 представляют число -0.091.
«NC» - строка фиксированной длины. Длина поля равна FieldLength * 2 байт. Представляет собой строку в формате Unicode (каждый символ занимает 2 байта).
«NVC» - строка переменной длины. Длина поля равна FieldLength * 2 + 2 байт. Первые 2 байта содержат длину строки (максимум FieldLength). Оставшиеся байты представляет собой строку в формате Unicode (каждый символ занимает 2 байта).
«RV» - версия. Длина поля 16 байт. Предположительно содержит четыре числа int.
«NT» - строка неограниченной длины. Длина поля 8 байт. Первые четыре байта содержат начальный индекс блока в объекте Blob таблицы, вторые четыре – длину данных в объекте Blob. В объекте Blob содержится строка в формате Unicode.
«I» - двоичные данные неограниченной длины. Длина поля 8 байт. Первые четыре байта содержат начальный индекс блока в объекте Blob таблицы, вторые четыре – длину данных в объекте Blob.
«DT» - дата-время. Длина поля 7 байт. Содержит данные в двоично-десятичном виде. Первые 2 байта содержат четыре цифры года, третий байт – две цифры месяца, четвертый байт – день, пятый – часы, шестой – минуты и седьмой – секунды, все также по 2 цифры.

Объект записей таблицы

Содержимое объекта записей таблицы содержит просто массив записей. Таким образом, длина данных этого объекта всегда кратна длине одной записи. Первая (точнее нулевая) запись всегда помечена как свободная, она содержит индекс следующей свободной записи (или 0, если таких нет). Т.е. с нее начинается цепочка свободных записей таблицы.

Объект Blob таблицы

Объект содержит Blob-данные таблицы (строки неограниченной длины и двоичные данные неограниченной длины). Содержимое этого объекта состоит из блоков (не путать с блоками, из которых состоит файл 1CD) длиной 256 байт (0x100). Т.е. это просто массив блоков длиной 256 каждый. Поэтому длина данных объекта всегда кратна 256. Структура каждого блока объекта такова:

unsigned int nextblock;

short int length;

Поле nextblock содержит индекс следующего блока, содержащего продолжение данных, или 0, если следующего блока нет. Поле length содержит длину данных в этом блоке (максимум 250). Поле data содержит сами данные. Нулевой блок всегда считается свободным, в поле nextblock он содержит индекс следующего свободного блока. Таким образом, с нулевого блока начинается цепочка свободных блоков.

В записях таблицы в полях с типом «NT» и «I» содержится индекс первого блока, с которого начинаются данные, относящиеся к этому полю данной записи.

Описание проблемы: при открытии базы, как в режиме Конфигуратора, так и в режиме Предприятия возникает "Ошибка потока формата" с предложением закрыть или перезапустить. Информационная база файловая, находится на локальном диске, версия платформы 8.2.18.109.

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

Подобная ситуация ("Ошибка формата потока") подробно и неоднократно описана на многих ресурсах, в том числе на инфостарте, так что в первую очередь были опробованы "простые" способы решения: удаление/добавление базы из списка, перенос на другую машину, прогон chdbfl, которые ни к чему не привели, chdbfl выявляла ошибку

"Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы 'CONFIGSAVE'> Повреждены данные таблицы 'FILES'"

, при попытке исправления которой chdbfl выкидывала из базы около 100 Мб, писала что ошибок не обнаружено, но проблему не исправляла.

Попробовал следующий вариант, через "Tool1c" выгрузил конфигурацию БД и загрузил ее в пустую информационную базу, база открылась без проблем (что говорит о том что повреждения не в системных таблицах, хотя могу ошибаться), потом из испорченной базы сделал Экспорт таблиц данных и импортировал их в пустую базу в которую была загружена конфа из поврежденной базы. Так же в базу была подгружена таблица V8USERS.
После этих действий при попытке загрузить базу в режиме предприятия появляется ошибка

"Ошибка СУБД:
Файл базы данных поврежден 'C:\Documents and Settings\admin\Мои документы\InfoBase1/1Cv8.1CD'
по причине: Файл базы данных поврежден 'C:\Documents and Settings\admin\Мои документы\InfoBase1/1Cv8.1CD'"

В конфигуратор заходит, но при попытке сделать Тестирование и исправления возникает та же ошибка (Ошибка СУБД), а при реструктуризации таблиц возникает

"В процессе обновления информационной базы произошла критическая ошибка. по причине: Ошибка СУБД: Ошибка SQL: Поле не найдено 'T1._Fld747'по причине:Ошибка SQL: Поле не найдено 'T1._Fld747'"

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

Некоторые особенности устройства и работы файловой базы данных «1С:Предприятия 8»

В данном разделе рассматриваются некоторые особенности внутреннего устройства и работы механизмов файловой базы данных «1С:Предприятия 8», которые не освещены в документации, но могут быть интересны пользователям и разработчикам прикладных решений на платформе «1С:Предприятие 8». Приведенное описание соответствует платформе «1С:Предприятие» версии 8.3.4.

Устройство файла *.1CD

На самом нижнем уровне файл *.1CD или файл базы данных содержит внутри своего рода файловую систему, включающую в себя так называемые внутренние файлы. Файл *.1CD имеет страничную организацию, то есть состоит из страниц размером 4096 байт (4 К). Размер файла *.1CD всегда кратен 4 К.

Каждая из остальных страниц может либо принадлежать какому-либо из внутренних файлов, либо находиться в списке свободных страниц.

Внутренние файлы

корневая страница,
индексные страницы,
страницы данных.

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

Корневая страница содержит служебную информацию внутреннего файла, такую как длина файла, номер версии данных файла и т. п. Кроме того, на корневой странице содержится до 1018 номеров индексных страниц.

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

Из сказанного выше следует, что внутренний файл может включать не более чем 1 041 414 (1018 * 1023) страниц данных. Следовательно, максимальный размер внутреннего файла не может превышать 4 265 631 744 (1018 * 1023 * 4096) байта. Для адресации отдельных байтов внутреннего файла используются 4-байтовые целые числа без знака.

Для представления внутреннего файла нулевой длины достаточно одной только корневой страницы. Если размер внутреннего файла составляет от 1 до 4096, то он представляется тремя страницами: одной корневой, одной индексной и одной страницей данных. При дальнейшем росте размера файла добавляются новые страницы данных, и их номера помещаются в индексную страницу. Как только индексная страница перестает вмещать номера страниц данных, добавляется новая индексная страница и ее номер добавляется в корневую страницу. И так далее.

Внутренние файлы не имеют имен. Для идентификации внутренних файлов используются номера их корневых страниц.

Список свободных страниц

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

Устройство базы данных

Внутренние файлы в конечном счете предназначены для хранения базы данных. База данных представляет собой совокупность таблиц. Каждой таблице может соответствовать от двух до четырех внутренних файлов:

файл описания таблицы,
файл данных,
файл индексов,
файл данных неограниченной длины.

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

Кроме того, имеется файл описания базы данных. Данный файл содержит информацию о локали базы данных, а также номера корневых страниц внутренних файлов описания для каждой из таблиц базы данных.

Таблицы

Файл описания таблицы

Файл описания таблицы содержит полное описание таблицы, которое включает:

имя таблицы;
перечень колонок таблицы, включая их имена и типы;
перечень индексов таблицы, включая их имена и индексируемые колонки;
номера корневых страниц внутренних файлов данных, индексов и данных неограниченной длины.

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

Файл данных

Файл данных содержит записи таблицы. Каждая запись содержит значения всех колонок таблицы, кроме значений колонок неограниченной длины. Записи имеют фиксированную длину. Поэтому адрес записи может быть легко вычислен по номеру записи (N) и длине (L) как N * L .

Номера записи представлены 4-байтовыми целыми числами. Запись с номером 0 используется для служебных целей. Номера «настоящих» записей начинаются с 1.

Длина записи может быть вычислена как сумма длин всех колонок плюс от 1 до 17 байт служебной информации. Ограничений на длину записи не накладывается.

Ниже приведена информация о типах данных и соответствующем размере колонок:

Десятичное число с фиксированной точкой. Хранится в десятичном виде по две десятичные цифры на один байт. Зарезервировано место для знака. Размер может быть вычислен по формуле:

(p + 1) / 2 + ( p + 1) % 2

Строка фиксированной длины, состоящая из n однобайтовых символов. Размер колонки равен n .

Строка Unicode фиксированной длины, состоящая из n символов в кодировке UTF-16. Размер колонки равен n * 2 .

Двоичные данные фиксированной длины. Размер колонки равен n .

Строка переменной длины, состоящая не более чем из n однобайтовых символов. Размер колонки равен n + 2 байта. Дополнительные 2 байта используются для хранения фактической длины.

Строка Unicode переменной длины, состоящая не более чем из n символов в кодировке UTF-16. Размер колонки равен n * 2 + 2 . Дополнительные 2 байта используются для хранения фактической длины.

Двоичные данные переменной длины не более n байт. Размер колонки равен n + 2 байта. Дополнительные 2 байта используются для хранения фактической длины.

Значение логического типа (true или false). Размер колонки равен одному байту.

Дата без времени. Размер колонки – 4 байта.

Дата и время. Размер колонки – 7 байт.

Текст неограниченной длины, состоящий из однобайтовых символов. В структуре записи колонка занимает два 4-байтовых целых числа: фактическая длина значения и адрес в файле данных неограниченной длины. Фактические значения хранятся в файле данных неограниченной длины.

Текст Unicode неограниченной длины, состоящий из символов в кодировке UTF-16. В структуре записи колонка занимает два 4-байтовых целых числа: фактическая длина значения и адрес в файле данных неограниченной длины. Фактические значения хранятся в файле данных неограниченной длины.

Двоичные данные неограниченной длины. В структуре записи колонка занимает два 4-байтовых целых числа: фактическая длина значения и адрес в файле данных неограниченной длины. Фактические значения хранятся в файле данных неограниченной длины.

Кроме того, к размеру колонок, которые могут содержать NULL, добавляется еще один байт.

Файл индексов

В файле индексов находятся все индексы, определенные для таблицы. Детальное рассмотрение структуры индексов не входит в цели данной статьи. Отметим только, что индекс представляет собой сбалансированное дерево. С точки зрения использования файловой базы данных важным является то, что, в отличие от размера записи, на длину ключа индекса наложено ограничение: длина не может превышать 1920 байт. Ключ представляет собой конкатенацию значений всех индексируемых колонок записи плюс 4-байтовый номер записи.

Индексироваться могут колонки типов Numeric, Char, NChar, Binary, VarChar, NVarChar, VarBinary, Logical, Date и DateTime. Значение каждой из индексируемых колонок типов Numeric, Binary, VarBinary, Logical, Date и DateTime помещается в ключ как есть. Соответственно, каждая из таких колонок добавляет к длине ключа свой собственный размер. А вот для колонок типов Char, NChar, VarChar и NVarChar вместо самой строки в ключ помещается ее ключ сортировки (collation key). Поэтому вклад колонок указанных типов в длину ключа определяется как n * 3 + 2 для колонок, не чувствительных к регистру букв. И n * 4 + 3 для колонок, чувствительных к регистру.

Файл данных неограниченной длины

В файле данных неограниченной длины хранятся фактические значения колонок типов Text, NText и Image. Для хранения таких значений файл организован как набор блоков длиной 256 байт. Каждое значение хранится как односвязный список блоков. В каждом блоке содержатся:

адрес следующего блока (4 байта);
число используемых байт данных в данном блоке (2 байта);
полезные данные (250 байт).

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

Работа с базой данных

Чтение данных

Следует различать чтение данных, выполняемое вне транзакции, и чтение в рамках транзакции. Операция чтения (например, SQL-запрос SELECT), выполняемая вне транзакции, получает данные, соответствующие состоянию базы данных на момент выполнения операции. При использовании SELECT вне транзакции поведение файловой базы данных подобно поведению версионных СУБД, таких как Oracle. То есть все данные, полученные запросом SELECT, относятся к одному согласованному состоянию базы данных, имевшему место на начало выполнения операции. Чтение данных не может быть заблокировано никакой другой операцией чтения или записи. Но нужно понимать, что состояние, имевшее место на начало чтения, может быть изменено. Соответственно, считываемые данные могут оказаться устаревшими.

Если чтение выполняется в рамках транзакции, то гарантируется, что считанные данные не могут быть изменены никем другим до завершения транзакции. Для обеспечения этой неизменности используется механизм транзакционных блокировок. При первом обращении к таблице на чтение в рамках транзакции на таблицу накладывается Read-блокировка. И эта блокировка не снимается до завершения транзакции.

Запись данных

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

Если на таблицу уже была наложена Read-блокировка, то выполняется ее эскалация до Write-блокировки.

Операции записи данных, выполняемые в рамках транзакции, не приводят к немедленной записи изменений в файл *.1CD. Изменения, вызванные операциями записи, накапливаются в кеше модифицированных страниц и сбрасываются в файл базы данных при фиксации (commit) транзакции.

Таким образом, если в процессе выполнения транзакции, до ее фиксации, произойдет сбой и/или падение приложения, то все изменения, произведенные в транзакции, окажутся потерянными и файл базы данных останется в неизмененном состоянии.

Кеширование данных

Кеш считанных страниц

Для повышения эффективности операций чтения механизмы файловой базы данных стараются кешировать считанные данные и тем самым минимизировать число физических операций чтения из файла базы данных. Кеш считанных страниц содержит прочитанные страницы данных внутренних файлов. Общий размер кеша для каждого из соединений с файловой базой данных является ограниченным и может в зависимости от различных условий составлять от 2 до 200 Мбайт. Кеш наибольшего размера создается при работе с файлом базы данных, расположенным на сетевом диске.

Кеш организован по принципу LRU. То есть страницы, к которым дольше всего не было обращений, могут быть вытеснены из кеша вновь считанными страницами.

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

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

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

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

Еще одной причиной для исключения страницы из кеша считанных страниц является попадание страницы в кеш модифицированных страниц.

Модификация данных и кеш модифицированных страниц

При запросе на чтение данных из внутреннего файла соответствующая страница сначала ищется в кеше модифицированных страниц. Если не найдена, то производится поиск в кеше считанных страниц. И если не найдена там, то производится считывание страницы из файла с помещением в кеш считанных страниц.

Сброс кеша модифицированных страниц в файл производится только при выполнении фиксации (commit) транзакции. При фиксации транзакции все измененные страницы всех внутренних файлов собираются в общий массив, упорядоченный по номерам страниц в файле базы данных, и запись в файл базы данных производится от больших номеров страниц к меньшим. Это делается из следующих соображений:

Если запись страницы с самым большим номером должна привести к увеличению файла базы данных, а на диске недостаточно места, то эта операция завершится аварийно. Таким образом, ни одно изменение не будет записано, транзакция будет отменена и файл *.1CD останется в неизмененном состоянии.
При записи от больших номеров страниц к меньшим статистически сначала будут записываться изменения в страницах данных, затем изменения в индексных страницах и только потом изменения в корневых страницах внутренних файлов. В результате минимизируется риск фатальных разрушений во внутренней структуре файла базы данных, если успешно завершится только часть операций записи.

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

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

Блокировки

Для обеспечения согласованности и целостности данных при разделенном режиме доступа к базе используются блокировки. Так как механика файловой базы данных работает в режиме файл-сервер, то есть отсутствует выделенный сервер баз данных, то блокировки в базе данных реализованы с использованием функций блокировки участков файла. Для блокировок используется файл с расширением .1CL.

Транзакционные блокировки

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

Read-блокировки не конфликтуют между собой, но конфликтуют с Write-блокировками. Write-блокировки конфликтуют с любыми блокировками: Read и Write. Единицей блокировки является таблица. Единица довольно крупная, особенно с учетом того, что в большинстве современных СУБД поддерживаются блокировки на уровне записи. Однако реализация блокировки на уровне записи потребовала бы большого числа файловых блокировок, что привело бы к существенному снижению производительности.

Транзакционные блокировки накладываются с ожиданием. По умолчанию время ожидания транзакционной блокировки равно 20 сек.

Блокировки фиксации состояния

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

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

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

(292) azrak, у KIS'а недавно апдейт вышел - рушит файловые базы 1С, несмотря на исключения и проч. Отключение НЕ помогает.

Рекомендую таки на всякий случай взять базку и на компе БЕЗ kis'а проверить

Попробую, однако проблема описаная с касперским существует для версии 11. У меня 12. Но сейчас попробую найти компьютер без касперыча.

если не получится своими силами - пишите, я скинул Вам свой контакт

Установил на компьютере с чистой новой виндой. Та же проблема.

1cv8c.exe
8.2.18.61
514b6c6b
backend.dll
8.2.18.61
514b7d81
c0000005
00043b48
13ac
01ce40429ee4ee62
C:\1cv82\8.2.18.61\bin\1cv8c.exe
C:\1cv82\8.2.18.61\bin\backend.dll
e7640cc7-ac35-11e2-be96-002522b1f65d

Большое спасибо andrewks за восстановленную базу. Я уже планировал на майские праздники в ручную перебивать 2 года работы. Всё работает отлично. Добрый день!
Если еще занимаетесь восстановлением баз, можно обратиться за помощью. Уважаемый awa можно Вам присалть базу для восставновления. База запускается но при попытке открыть справочник контрагентов или документ событие вылетает chdbfl.exe или восстановление копии базы, тут без вариантов! а вот если копий нет это проблема.

Всем привет.
В момент обновления конфигурации базы отключили свет, сейчас не получается зайти не в конфигуратор, не в предприятие.
Размер базы небольшой 400 Мб, после проверки chdbfl.exe размер уменьшается до 230 Мб и выходят ошибки:
Повреждена таблица размещения внутреннего файла <Данные таблицы 'CONFIG'>
Повреждена таблица размещения внутреннего файла <Данные неограниченной длины таблицы 'CONFIG'>
Повреждены данные таблицы 'CONFIG'. Восстановлено 20379 из 20604 записей.

После этого при запуске 1С вылетает ошибка "Ошибка формата потока".

Как-то можно реанимировать базу?

Валерий, есть база весит 198 мегов,бри запуске базы или конфигуратора пишет Несовместимая версия файла базы данных, Tool_1cd пишет про длину файла базы не кратна длине блока. Куда можно выслать базу? (303) Выложите на любой файлообменник, и напишите ссылку в личку.

awa , помогите, пожалуйста!

В момент сохранения конфигурации рубанули свет.
Результат: при запуске как предприятия, так и конфигуратора после авторизации: "Ошибка формата потока"

Как обычно бывает, ближайший архив двухмесячной давности.

chdbfl ошибок не видит, Tool_1CD базу загружает без ошибок, конфигурации выгружает, но при попытке их загрузить в пустую новую базу выдает ошибку "Ошибка формата потока"

Платформа: 8.2.17.143
Конфигурация: УНФ+доработки
База файловая 370Метров

Направьте, подскажите, что делать?

awa , надежда только на вас

в hex шарю слабо, но все же
1. подстрока c.o.n.f.i.g. нашлась на смещении 0000F000 (а не 00009000 как многие пишут) и в битой, и в целой базе
2. в битой базе c.o.n.f.i.g.s.a.v.e. на смещении аж 10984000, т.е. длина (от конфига) аж 1097500, а не C000 как в целой. Это означает, что между конфигом и конфигсейвом что-то есть? судя по tool_1cd они идут подряд
3. замещал таблицу конфиг из целой базы (все недостающие до смещения конфигсейва данные забивал 00) - база уменьшалась с 370М до 100М - получается что-то действительно там есть
4. на смещении 4020 (где, судя по форуму, заголовки) следующие данные:
целая 56 04 00 00 05 00 00 00 0B 00 00 00 17 00 00 00
битая 69 04 00 00 05 00 00 00 0B 00 00 00 80 09 01 00

пробовал замещать - не помогает

Пллиз Хелп! Что я не так делаю?

Меня, например, удивляет, когда люди пишут "Помогите! Хелп!", а потом через пару постов "Спасибо! Проблема решилась". КАК?! Всех интересует КАК РЕШИЛАСЬ?

Так вот, спасибо, проблема решилась :)

Нашел выход из положения следующий:

Там 1С обработка+dll, обработка чисто для демонстрации возможностей компоненты
т.е. она читает 1cd, выгружает таблицы в спейцпапки, чистит таблицы, загружает из этих спецпапок (путь нельзя указывать, запоминает при выгрузке)
следовательно либо надо менять обработку либо то, что сделал я

2. Читаем обработкой целый 1cd
3. Извлекаем только таблицы config и configsave (в папке, где файл, создается подпапка Objects[timestamp] - там наши выгруженные, целенькие конфигурации)
4. Подгружаем обработкой битый 1cd и читаем его
5. Извлекаем только таблицы config и configsave, удаляем их-же
6. Подменяем содержимое папок Objects[timestamp] из целой в битую
7. Загружаем таблицы (подмененные) в битый 1cd и он перестает быть битым

Мне помогло, надеюсь и вам пригодится!

Добрый день!
тул сд пишет что не найдена таблица DBSCHEMA.
как ее добавить, чтобы потом как в (309) заменить на другую из целого 1cd? (awa) Добрый день, та же проблема с базой, перебрал ее через Tool1CD и RestorationBaseV8, результатов непринесло. В личку отправил вам ссылку на базу, если будет минутка, помогите пожалуйста. Сегодня клиент потерял день работы - файл базы бухии поврежден так , что утилитой Tool_1CD вообще не читается (скрин 2), сама утилита выдает ошибку (скрин 1), штатная проверка пишет, что поврежден заголовок. С базой зарплаты еще интереснее - ее просто нет, вместо нее файл 1cv8.1cd.codet , что за файл не узнал - в инете инфы совсем нет, опасаюсь рецидива, поэтому, если кто-то что-то знает о таком - будьте добры, отпишитесь здесь.
(Бухия 2.0, платформа 8.2.18.61 , Win2008R2) (315) m-serg74, в той ветке вроде бы в личку рассылали расшифровщик, но потом прикрыли. Я восстановил базу из предыдущей копии. (316) Alister, ну если не столетняя копия была это замечательно, а то обычно когда какая нить беда случается, то как назло или архив старый, или еще какая нить печаль, ну рад что хоть как то решилась проблема (317) m-serg74, копия за предыдущий день, так что не так страшно, но эта гадость еще и архивы может шифровать, тогда только образ всего диска (но это для меня больше заморочно - никогда еще не пробовал диск восстанавливать. и надеюсь, что не понадобится, ттт). но эта гадость еще и архивы может шифровать, тогда только образ всего диска
на всякий случай поэтому лучше архив куда нить на другой комп, который не подключен к инету, или вообще на диск, к которому у одного пользователя есть право записи. это еще надежнее Помогите восстановить базу, есть архив папки.
Во время обновления выключили электросеть, и архив не был сделан до обновления.
Ни в конфигураторе, ни обычном режиме не открывается.
Ошибка формата потока.
chdbfl - не помог.
Бухгалтерия государственного учреждения, редакция 1.0 (1.0.20.6)

Добрый вечер!
Зарплата и кадры 2.5
Повреждение произошло во время обновления. Вывалилась ошибка про повреждение БД. Проверка chdbfl сказала, что исправлено 0 из 1 записи. Пользователь не помнит какой таблицы.
При запуске ругается: Ошибка SDBL: Разрушена структура базы данных 1С.
Может здесь есть умельцы?

Резервных копий нет.

(327) green35, Зачем плодить темы? Тем более поднимать старые темы. Вам непременно и так ответят))) (328) К сожалению, это не рухнувшая база - это огрызок базы, слишком мал размер, там нечего восстанавливать. Nickolas Спасибо большое. все получилось подменил Save,CONFIGSAVE и PARAMS очистил кеш, удалил из списка баз, добавил снова и все получилось. Удалили базу полтора месяца назад. С помощью R-Studio восстановил файл *.1CD, но база не запускается. Не открывается даже в Tool_1CD Может кто-нибудь за деньги восстановить базу? Очень срочно и важно! Добрый день! Подскажите что это за таблица и к какому справочнику принадлежит - InfoRgChngR8909 (334) Это что, конкурс "Угадай конфигурацию"? Какой призовой фонд? (336) Не знаю, чем вам и помочь: в типовой 2.0.58.6 вообще нет таблицы с таким именем.

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

p.s. Технический язык понимаю, конфигурация точно типовая БП.

Забыл добавить сразу лог chdbfl.exe.

Повреждены данные таблицы 'PARAMS'
Обнаружено рассогласование между данными и индексами таблицы 'PARAMS'
Повреждены данные таблицы 'FILES'
Обнаружено рассогласование между данными и индексами таблицы 'FILES'
Повреждены данные таблицы '_ACCRG562'
Обнаружено рассогласование между данными и индексами таблицы '_ACCRG562'
Повреждены данные таблицы '_ACCRGED598'
Обнаружено рассогласование между данными и индексами таблицы '_ACCRGED598'
Повреждены данные таблицы '_DOCUMENTJOURNAL7719'
Обнаружено рассогласование между данными и индексами таблицы '_DOCUMENTJOURNAL7719'
Повреждены данные таблицы '_DOCUMENTJOURNAL7748'
Обнаружено рассогласование между данными и индексами таблицы '_DOCUMENTJOURNAL7748'
Повреждены данные таблицы '_INFORG8141'
Обнаружено рассогласование между данными и индексами таблицы '_INFORG8141'
Повреждены данные таблицы '_INFORG8780'
Обнаружено рассогласование между данными и индексами таблицы '_INFORG8780'
Поврежден заголовок внутреннего файла <Данные таблицы '_ACCUMRGTN9976'>
Повреждена таблица размещения внутреннего файла <Описание таблицы ''>
Повреждены данные таблицы '_ACCUMRG10317'
Обнаружено рассогласование между данными и индексами таблицы '_ACCUMRG10317'
Поврежден список удаленных записей таблицы '_ACCUMRG10317'
Поврежден заголовок внутреннего файла <Описание таблицы ''>
Повреждена таблица размещения внутреннего файла <Описание таблицы ''>
Повреждена таблица размещения внутреннего файла <Описание таблицы ''>
Обнаружено рассогласование между данными и индексами таблицы '_SEQ10486'

Если сделать chdbfl.exe с исправлением ошибок - база не открывается.
Изначально битая база весит 318 738 432 байт.
Лог исправления копии битой базы такой:
Повреждены данные таблицы 'PARAMS'. Восстановлено 20 из 22 записей.
Повреждены данные таблицы 'FILES'. Восстановлено 6 из 8 записей.. Потеряно 2 значений полей неограниченной длины
Повреждены данные таблицы '_ACCRG562'. Восстановлено 15767 из 15770 записей.
Повреждены данные таблицы '_ACCRGED598'. Восстановлено 50516 из 50518 записей.
Повреждены данные таблицы '_DOCUMENTJOURNAL7719'. Восстановлено 708 из 709 записей.
Повреждены данные таблицы '_DOCUMENTJOURNAL7748'. Восстановлено 1457 из 1458 записей.
Повреждены данные таблицы '_INFORG8141'. Восстановлено 1465 из 1471 записей.
Повреждены данные таблицы '_INFORG8780'. Восстановлено 5 из 6 записей.
Поврежден заголовок внутреннего файла <Данные таблицы '_ACCUMRGTN9976'>
Данные таблицы не могут быть восстановлены '_ACCUMRGTN9976'
Повреждена таблица размещения внутреннего файла <Описание таблицы ''>
Повреждены данные таблицы '_ACCUMRG10317'. Восстановлено 9538 из 9539 записей.
Поврежден заголовок внутреннего файла <Описание таблицы ''>
Повреждена таблица размещения внутреннего файла <Описание таблицы ''>
Повреждена таблица размещения внутреннего файла <Описание таблицы ''>

В результате chdbfl.exe пишет, что "обнаруженные ошибки исправлены".
Размер базы уменьшился после этого - 309 485 568 байт. Подозреваю, что примерно 10 мб это все-таки многовато "удалено".
При запуске в режиме предприятия выскакивает ошибка "Тип не определен '0eda3711. '.
В режиме конфигуратора база запускается, но "Тестирование и исправление" до конца не доходит - 1с выдает ошибку:
Таблица не найдена _AccumRgChngR10197

Сильно все грустно или шанс есть? Спасибо за любой ответ. Финансовой заинтересованности в помощи у меня нет, просто хочу помочь человеку. Но если по результатам получится воскресить базу, смогу потребовать какое-то денежное вознаграждение тому, кто сможет помочь.

Читайте также: