Файл не обнаружен files sprscndinfo

Обновлено: 03.07.2024

Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.

1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".

Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.

1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)

Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.

3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).

При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.

5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.

Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:

а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:

Просмотр записей таблиц, к сожалению, не реализован.

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

Анализ причин роста сеансовых данных

Платформа "1С:Предприятие" в своей работе постоянно использует механизм, называемый "сеансовые данные". В этих данных хранится служебная информация, необходимая для работы сеанса "1С:Предприятия". Например, все, что введено в поля ввода на форме, при серверных вызовах сбрасывается в сеансовые данные.

При вызове методов: ПоместитьВоВременноеХранилище, ПоместитьФайл, НачатьПомещениеФайла, значения указанные в параметрах, записываются в сеансовые данные.

При фоновом исполнении отчетов СКД, результат отчета помещается в сеансовые данные, а затем передается в клиентскую часть.

С точки зрения операционной системы, сеансовые данные представляют собой файлы в каталоге …\srvinfo\reg_<номер порта>\snccntx<GUID>.

С точки зрения внутренней структуры - это noSQL база данных (key-value storage).

Особенности работы платформы с сеансовыми данными

За работу с сеансовыми данными отвечает менеджер кластера – rmngr.exe Если в кластере несколько рабочих серверов, то сеансовые данные будут расположены в соответствии с требованиями назначения функциональности.

Если требования не заданы, то сеансовые данные распределятся равномерно по всем рабочим серверам.

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

Для обеспечения скорости работы, платформа всегда пишет новые данные в конец, аналогично transaction log в СУБД. Таким образом, размер сеансовых данных постоянно растет. Во всем объеме сеансовых данных, существуют как актуальные, так и устаревшие данные. Актуальность данных определяется способом их помещения:

Если сеансовые данные помещены из формы и в качестве идентификатора передается идентификатор формы (ЭтаФорма.УникальныйИдентификатор), то данные считаются актуальными, пока открыта форма.
Если в качестве идентификатора передан УникальныйИдентификатор, не являющийся уникальным идентификатором формы (Новый УникальныйИдентификатор), то значение перестанет быть актуальным после завершения сеанса пользователя.
Если ничего не передано, то значение перестанет быть актуальным при любом следующем серверном вызове.

Перед выделением следующего блока на диске, проверяется, прошло ли 5 секунд с момента выделения предыдущего блока. Если 5 секунд прошло, то запускается "сборщик мусора" (key value garbage collector). Сборщик оценивает процент актуальных сеансовых данных в общем объеме. Если актуальные данные занимают менее 25% от общего объема, то все актуальные данные копируются в новые файлы, а затем все старые файлы сеансовых данных удаляются.

Так как каждый сеанс (клиенты, фоновые задания, web-сервисы) в своей работе постоянно пишет информацию в сеансовые данные, то при большом количестве пользователей, скорость дисковой подсистемы, на которой расположены файлы сеансовых данных, играет очень важную роль. При большом количестве пользователей, рекомендуется располагать файлы сеансовых данных на максимально быстрых дисках. Желательно RAM-drive. Отказоустойчивость дисков не важна, т.к. при потере сеансовых данных, никакой важной информации утеряно не будет.

Следует отметить порядок размещения сеансовых данных. Если поместить во временное хранилище двоичные данные или файл, то эти данные пройдут в качестве потока байт через rphost, затем в rmngr, который сбросит этот поток на диск. Если же, в качестве помещаемого значения, будет выступать коллекция (таблица значений, результат запроса, массив…), то сначала вся эта коллекция разместиться в памяти rphost, а только затем преобразуется в поток байт и будет передана в rmngr.

Размещение сеансовых данных в памяти

При работе кластера "1С:Предприятия", файлы сеансовых данных отображаются в память (mapping). Подробнее см. статью.

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

Однако, в операционной системе Windows, отображенные в память файлы, влияют на счетчик Memory\Available Mbytes. При сильном росте сеансовых данных можно увидеть следующую картину:

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

Размер памяти, указанный в колонке Standby – это неиспользуемая память (фактически свободная). При запросе памяти любым процессом, ему будет выделена память из этой области.

Следует учитывать данную особенность счетчика Memory\Available Mbytes при построении систем мониторинга или приложений, которые опираются на объем доступной оперативной памяти.

Для косвенной оценки эффективности работы операционной системы с сеансовыми данными, можно использовать счетчик Memory\Page Faults/sec, который показывает на сколько часто процессы обращаются за страницами в память, но не находят их там и подгружают с диска.

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

Проблемы сеансовых данных

Ошибка совместного доступа к файлу snccntx.dat

При появлении данной ошибки необходимо действовать по алгоритму:

1. Проверить права на папку сеансовых данных для пользователя, от которого запущена служба сервера "1С:Предприятия". Должны быть полные права.

2. Открыть на рабочем сервере диспетчер задач, установить видимость колонки "Командная строка"

3. Необходимо найти процессы rmngr.exe с одинаковым значением параметра –pid.

4. Открыть консоль кластера. Развернуть ветку кластера, порт которого соответствует параметру –regport , найденных rmngr.exe с одинаковым значением параметра –pid

5. Сопоставить PID из диспетчера задач с PID в консоли кластера. Тот процесс rmngr.exe, которого нет в консоли – принудительно завершить.

Закончилось место на диске, где расположены сеансовые данные

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

Не следует размещать файлы технологических журналов на одном диске с сеансовыми данными.

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

Так же, необходимо следить за размером самих сеансовых данных. Если периодически их размер становится существенным, то необходимо обратить на это особое внимание. Следует помнить, что при срабатывании "сборки мусора" необходимо наличие свободного места на диске, в размере 25% от общего объема сеансовых данных. Если этих 25% не будет, то кластер завершит свою работу аварийно.

Изменить расположение сеансовых данных, можно указав параметр –d в строке запуска службы агента сервера.

В данном каталоге, также расположены: реестр кластера, индекс полнотекстового поиска и журнал регистрации.

Влияние циклических ссылок на рост сеансовых данных

Чаще всего при выполнении процедуры ПоместитьВоВременноеХранилище, указывается идентификатор формы (ЭтаФорма.УникальныйИдентификатор). Как написано в документации, при указании идентификатора формы данные перестают считаться актуальными после того как форма будет закрыта.

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

данные формы остаются в памяти
сеансовые данные, выделенные для формы, считаются актуальными, пока не будет завершен сеанс

Чтобы избежать данной ситуации, необходимо исключить все циклические ссылки в форме (см. статью).

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

Методика анализа роста сеансовых данных

Сбор данных

Необходимо собрать технологический журнал:

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

После того, как технологический журнал будет собран, необходимо провести "парсинг" и выгрузить его данные в файлы csv формата:

На основании данных, которые собраны в папках rmngr_*, необходимо сформировать csv файл вида:

<файл ТЖ> – имя файла технологического журнала,
<CallID> – значение свойства CallID,
<InBytes> - значение свойства InBytes.

В файле …/rmngr_7188/ 15063011. log есть строка:

Данная строка должна быть преобразована в строку:

Необходимо исключить из итогового файла строки с InBytes=0, т.к. они не представляют интереса, но занимают значительный объем.

На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:

<процесс>– имя папки рабочего процесса,
<файл ТЖ> – имя файла технологического журнала,
<t:clientID> – значение свойства t:clientID,
<CallID> – значение свойства CallID.

В файле …/ rphost_1352 / 15063011 .log есть строка:

Данная строка должна быть преобразована в строку:

На основании данных, которые собраны в папках rphost_*, необходимо сформировать csv файл вида:

<процесс> – имя папки рабочего процесса,
<t:clientID> – значение свойства t:clientID,
<Usr> – Имя пользователя из свойства Usr.

В файле …/ rphost_1352 /15063011.log есть строка:

Данная строка должна быть преобразована в строку:

В итоге должно получиться 3 файла: scall.csv, call.csv, conn.csv

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

Создание базы данных для анализа

Необходимо создать пустую базу данных (MS SQL Server), в которую добавить таблицы:

Затем, в эти таблицы необходимо загрузить данные из соответствующих csv файлов. Сделать это можно с помощью SQL Server Integration Services

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

Анализ работы с сеансовыми данными

TOP – 10 пользователей в разрезе процессов и времени

Запрос покажет топ-10 пользователей, которые поместили больше всего сеансовых данных в час. Затем необходимо разобраться с самым верхним (в текущем случае):

Т.е. в процессе rphost_1352 за час с 11-00 по 12-00 пользователь с идентификатором 518 записал в сеансовые данные 2 046 616 858 байт (2Гб).

Далее, необходимо найти все идентификаторы вызовов, которые записывал сеанс 518:

Описание ошибки:
Обнаружена при разработке обработки для изменения содержимого файла формата XML в серверной базе 1С 8 в режиме управляемого приложения. При тестировании на сервере ошибка не возникала. Проявила себя при работе на рабочем месте пользователя.

По факту ошибка возникала при выполнении метода "Прочитать()" для объекта "ТекстовыйДокумент". Как было отмечено, при тестировании работы обработки непосредственно на сервере данной ошибки не возникало. Она проявила себя уже при попытке работы на другом рабочем месте. Обработка разрабатывалась для конфигурации 1С: Комплексная автоматизация 8, ред. 2, которая работает в режиме управляемого приложения - это необходимо отметить. Т.к. это проясняет причины возникновения проблемы.

По привычке разместил операции по чтению содержимого текстового файла и извлечению его содержимого на стороне сервера - см. "&НаСервере" перед процедурой "ОбрабткаНаСервере()". Клиент-серверная архитектура платформы 1С: Предприятие 8.3, казалось бы, к этому обязывала.

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

Но, как оказалось позже - конструктор "Новый ТекстовыйДокумент", методы "Прочитать()", "ПолучитьТекст()" - все они доступны не только на стороне сервера, но и на стороне тонкого и толстого клиента. Поэтому замена директивы "&НаСервере" на "&НаКлиенте" решила проблему.

Для запуска 1С в клиент-серверном режиме нужно ДВЕ лицензии: одна серверная для запуска сервера 1С:Предприятия, вторая клиентская для запуска клиентского приложения (а для запуска файловой базы нужна только клиентская лицензия, а серверную устанавливать не нужно вовсе) .

Судя по данному тексту вы получили лицензию на СЕРВЕР.

Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!

Данный текст говорит о том, что 1С не видит лицензию на запуск КЛИЕНТА.

Файл программной лицензии не предусматривает возможность запуска клиентских приложений 1С:Предприятия или внешних соединений:
file://C:/ProgramData/1C/licenses/ХХХХХХХХ.lic

100% что это файл той самой лицензии на сервер 1С, который вы только что получили.
Уточнить можно открыв файл лицензии текстовым редактором, например, блокнотом - в конце файла будет информация о лицензии в человекочитаемом виде.

Т.е для работы вам теперь ещё надо получить клиентскую лицензию.
Для полного понимания советую почитать инструкцию по повторному получению лицензии 1С с разборами ошибок и примерами (кстати, ваш случай там тоже есть)
Как восстановить программную лицензию 1С:Предприятие 8

P. S.
Кстати имя файла затерли совершенно зря - оно представляет собой дату и время получения лицензии, никакой уникальной идентифицирующей информации в имени файла нет, например, активированная сегодня лицензия будет вида 202110131012345.lic, где первые 8 цифр - это дата 2021.10.13, а следующие 6 цифр - это время ЧЧ.ММ.СС.

Добавлю еще один момент - активировать многопользовательскую программную лицензию на сервере имеет смысл только в трех случаях:

1. Если будут клиент-серверные базы под SQL, в этом случае лицензии клиентам будет выдавать сервер 1С:Предприятия;
2. Если базы опубликованы на веб-сервере (Apache или IIS), в этом случае лицензии будет раздавать модуль веб-сервера;
3. Если сервер терминальный, в этом случае клиенты при подключении по RDP/RemoteApp смогут получить лицензии из файла сами.

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

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