Файл cdx 1c что это

файловый вариант работы

«1С:Предприятие» поддерживает два варианта работы:
● файловый,
● клиент-серверный.

Файловый вариант работы с информационной базой рассчитан на персональную работу одного пользователя или работу небольшого количества пользователей в локальной сети. В этом варианте все данные информационной базы (конфигурация, база данных, административная информация) располагаются в одном файле.
Такой вариант работы обеспечивает легкость установки и эксплуатации автоматизированной системы. При этом для работы с информационной базой не требуются дополнительные программные средства, достаточно иметь операционную систему и «1С:Предприятие».
Файловый вариант «1С:Предприятия» обеспечивает высокую целостность информационной базы и простое создание резервных копий. Исключена ситуация, когда пользователь может по ошибке (например, при копировании информационной базы) перепутать различные файлы информационной базы и привести таким образом систему в неработоспособное состояние.
Кроме этого, резервное копирование может осуществляться на файловом уровне, путем простого копирования файла информационной базы.
Однако, несмотря на легкость и простоту использования, файловый вариант обладает некоторыми ограничениями. Также следует помнить о том, что использование файлового варианта с подключением через веб-сервер рекомендуется использовать для работы небольшого количества пользователей, при условии отсутствия длительных операций.

Ограничения файлового варианта

Особенности работы файлового варианта базы данных с файловой системой

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

Могут быть и другие причины. Таким образом, во всех случаях использования файловой базы данных следует:

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

Размещение данных 1С:Предприятия 8

Данные, которые 1С:Предприятие использует всегда, могут быть разделены на 5 групп в соответствии с их назначением и мерой их ответственности:

Работа с новым форматом файловой базы данных

Начиная с версии платформы “1С:Предприятие” 8.3.8 появилась поддержка нового формата файловых баз данных (включая работу в режиме совместимости с предыдущими версиями). Новый формат файловых баз данных предназначен для ускорения процесса открытия и работы с информационной базой, поэтому, начиная с версии платформы 8.3.9, новый формат используется по умолчанию при создании новых файловых баз данных.

В новом формате (версии “8.3.8″) появились следующие возможности:

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

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

Для преобразования формата файловой базы данных в комплектацию поставки платформы “1С:Предприятие” добавлена утилита CNVDBFL.EXE, которая должна находиться в папке “\bin” вашей установки “1С:Предприятие”. Например, полный путь к папке, где находится утилита, может быть “C:\Program Files (x86)\1cv8\8.3.9.1850\bin“, где “8.3.9.1850” – номер версии установленной платформы “1С:Предприятие”. В этой же папке находятся другие исполняемые файлы платформы, такие как, например, “1Cv8.exe”.

Если Вы не можете найти утилиту CNVDBFL.EXE в папке “\bin“, проверьте, что Вы используете версию “1С:Предприятие” 8.3.8 и выше.

Если Вы хотите проверить параметры Вашей файловой базы данных, используйте следующий вызов утилиты (указав в команде правильный путь к Вашей базе данных):

Утилита тестирования chdbfl

Утилита предназначена для автономной проверки и исправления файлов базы данных.

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

Для запуска утилиты в каталоге установки системы «1С:Предприятие» нужно запустить приложение chdbfl. На экран выводится окно (см. рис.1)

Утилита тестирования и исправления информационных баз

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

В поле Имя файла БД указать или выбрать имя файла информационной базы.

Установить флажок Исправлять обнаруженные ошибки, если требуется исправлять обнаруженные при проверке ошибки. Также этот флажок следует установить, если необходимо выполнить оптимизацию размещения служебной информации, ускоряющей открытие информационной базы

Источник

Удаление индексных файлов 1С 77 как метод «лечения»

P.S.Ногами не бить, играю на кнопках как могу.

Скачать файлы

Специальные предложения

Это программа из разряда : до чего же мне лень да и стыдно показывать

знаешь как в анекдоте:
Муж ходит в трусах по комнате

Обновление 03.02.10 00:00

Код открыт Не указано

См. также

Поиск ошибок в регистрах 7.7 Промо

Обработка позволяет найти ошибки в регистрах 7.7 в Вашей базе данных

04.05.2010 27863 427 _Z1 31

Внешняя универсальная обработка для автоматизированного исправления ошибок в БД типа «Проверка уникальности внутреннего идентификатора в справочнике. ….. Исправить вручную»

06.02.2018 10145 3 drako 0

Автоматическое восстановление индексов БД 1С 7.7 по регламенту, сервер терминалов

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

09.06.2016 14265 2 tux 1

23:59:59 Быстрое исправление одним нажатием без перепроведений!

17.09.2015 12102 26 PZh1753 3

Проверка информационной базы 7.7 на некорректные символы

Поиск спецсимволов непосредственно в текстовых полях информационной базы 7.7.

21.05.2015 12227 38 tedkuban 11

Глюки со временем документа в таблицах 1С (SQL Server)

При загрузке в монопольном режиме SQL ругается: SQL State: 23000 Native: 1505 Message: [Microsoft][ODBC SQL Server Driver][SQL Server]CREATE UNIQUE INDEX terminated because a duplicate key was found for index ID 2. Most significant primary key is ‘ 20MGJ ‘.

30.01.2015 14777 4 leoner61 4

Контроль алкогольных реквизитов номенклатуры в ТиС

Полнота заполнения «алкогольных» реквизитов справочника «Номенклатура» дает надежду на правильность алкогольной декларации! Трудности бухгалтеров в контроле этих реквизитов послужили причиной создания предлагаемой простой обработки.

04.10.2012 16468 20 BorisBelov 3

Контроль заполнения «алкогольных» реквизитов справочника Номенклатура

Полнота заполнения «алкогольных» реквизитов справочника «Номенклатура» дает надежду на правильность алкогольной декларации! Трудности бухгалтеров в контроле этих реквизитов послужили причиной создания предлагаемой простой обработки.

24.09.2012 16388 23 BorisBelov 4

Универсальная замена справочника

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

22.08.2012 10643 32 mic4 3

23.03.2012 14734 30 snegovik 4

Замена элементов справочников в конфигурации

Групповая замена одних элементов справочников на другие в реквизитах справочников, документов, операций документов (без перепроведения)

14.12.2011 11898 37 dimaster 3

Поиск и восстановление битых ссылок (объект не найден) в реквизитах документов с помощью УРБД 1с 7.7

Данная обработка выполняет два действия: 1. Ищет в реквизитах документов битые ссылки по фразе » » и записывает результаты в файл LostIn1c.txt на диск D. 2. С помощью данных в сохраненном файле в связанной через УРБД базе (предполагается, что в этой базе с данными все нормально) находит эти реквизиты и регистрирует их на выгрузку. Ну а дальше достаточно сделать обмен в УРБД между базами, чтобы ссылки восстановились.

30.11.2011 19498 93 roms6 5

Искатель v1.1: Поиск документов без проводок, без движений по регистрам 1C 7.7

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

22.11.2011 14994 53 Andruykha 12

Бухгалтерия не любит заполнять субконто?

Простая обработка для выявления незаполненных субконто в проводках.

15.11.2011 13172 43 brake71 7

Документ закрытие счетов. Может закрыть в 0 вообще все счета!

07.10.2011 20359 90 DDos76 16

Исправление баланса после неудачных корректировок * (7.7)

Если вы случайно сломали/перепровели/удалили или еще что-то сделали и у вас «уплыл» баланс, но есть архивная копия, то эта обработка поможет вам восстановить обороты без ручного труда.

27.09.2011 10330 22 andr2510 7

Универсальная обработка по перегрузке записей журналов расчета между двумя идентичными базами для 1С 7.7 через OLE-соединение

Универсальная обработка по перегрузке записей журналов расчета

20.09.2011 10409 31 headMade 7

Замена видов затрат в документах с перепроведением. Релиз 7.70.287

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

15.07.2011 9327 58 vligm 4

Исправление неправильного признака группового учета и отсутствия ОКОФ в справочнике «Основные средства» в «Бухгалтерии бюджетного учреждения 7.7 6.44» до переноса в «1С:Бухгалтерия госучреждения 8»

Обработка для исправления ошибок ведения учета в конфигурации «1С:Бухгалтерии для бюджетных учреждений 7.7» для корректного переноса данных в «Бухгалтерию бюджетных учреждений 8 (БУ8)».

08.06.2011 16658 360 Golub 7

ЗиК Замена старых счетов на новые

ЗиК Замена старых счетов на новые

07.06.2011 9017 169 FreeXer 3

Импорт адресных классификаторов без устаревших названий.

17.03.2011 11046 40 jack19 9

Проверка наложения позиций документов и Проверка режима включения проводок.

2 обработки: «ПроверкаРежимаВключенияПроводок» и «ПроверкаНаложенияПозицийДокументов», используемые мной уже долгое время; полагаю, будут интересны и полезны многим.

08.01.2011 11710 52 ondul 1

Синхронизация структуры справочников между базами

Обработка позволяет в текущей базе перестроить структуру справочников под структуру копии базы с такой же конфигурацией. Отслеживаются созданные и удаленные элементы, изменения в реквизитах «Код», «Наименование» и «Родитель». Можно сопоставлять элементы по коду или по внутреннему идентификатору. Мне потребовалась при консолидации Бухгалтерии с партнерской организацией.

27.12.2010 16076 175 DrAku1a 6

Проверка и исправление договоров в документах банка

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

19.11.2010 10969 18 Andruykha 1

Обработка для выявления отриц. остатков без проведения документов (для бух. 7.7 Украина)

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

13.07.2010 10870 100 crs 1

Поиск и замена дублей в ТИС v7.7

22.06.2010 15558 226 gosizo 5

Обработка для замены измерений регистра оперативного учета

Замена измерений регистра оперативного учета (v7.7) (Автоматическое заполнение документа «Движение регистра» для переноса остатков с одних измерений на другие).

Замена фирмы

Бывает появляется необходимость в документах заменить одну фирму на другую. Вот собственно это и делает моя внешняя обработка

04.05.2010 9312 73 yu_l_ya 25

Создание проводок с пустыми субконто

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

14.04.2010 11031 26 dedkov 1

Замена ссылок в SQL-базе без перепроведения документов.

09.03.2010 22066 199 Noy 25

Исправление «пустых» субконто

02.02.2010 17148 192 AnryMc 6

Перенос справочника Сотрудники из Камин Зарплата 2 в Бухгалтерию 7.7

13.01.2010 15326 132 mastakw 7

Обработка автоматической замены дублей в справочнике «Договоры» (На основе REPLVAL)

Обработка замены дублей в справочнике «Договоры» (На основе REPLVAL)

06.01.2010 15282 162 ulen 7

Замена одного элемента справочника, счета или перечисления другим

Обработка позволяющая заменить одно значение справочника, счета или перечисления на другое везде, где оно присутствует (реквизиты справочников, общие реквизиты, реквизиты шапки и реквизиты табличных частей документов, сменить владельца у подчиненных элементов справочников, ссылки в других справочниках,константах, и в проводках где может присутствовать в виде субконто). + Может изменять движения документа ( периодических реквизитов установленных в документах через УстановитьРеквизитСправочника(), а также регистров Оперативного учета ) После замены можно например удалить дубликаты справочников (для этого собственно данная обработка и писалась).

27.12.2009 9044 142 VladimirB 7

Источник

Взгляд в прошлое, или Способы оптимизации больших баз 1С 7.7 DBF.

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

Предвидя заранее такую реакцию части читателей, поясню, для чего задумывалась статья. Статья предназначена, в первую очередь, для тех ИТ-специалистов, которые вынуждены поддерживать базы на платформе 1С 7.7 DBF (решения действительно устаревшего). Во-вторую очередь, статья поможет тем ИТ-специалистам, которые хотят понять все недостатки платформы 1С 7.7, для аргументированного принятия решения о переходе на платформу 1С 8.2. В третью очередь, в статье будет предпринята попытка систематизировать и свести воедино основные существующие техники оптимизации и ускорения платформы 1С 7.7 DBF.

Итак, у Вас есть база на платформе 1С 7.7 DBF. Её размер (то есть совокупный размер всех файлов dbf и cdx) составляет 1 гигабайт, или даже 9-10 гигабайт (да, и такие базы DBF можно заставить нормально работать). Работа пользователей в вашей базе сопровождается ощутимым «торможением», «зависаниями», сообщениями о ошибке транзакций при попытке провести или записать документ. Что делают в этом случае ИТ–специалисты? Молодое поколение, то есть те, кто не работал (или почти не работал) с платформой 1С 7.7 – брезгливо пожимают плечами и заявляют о необходимости перехода на 1С 8.2. Специалисты постарше предпринимают попытки оптимизации, и в конечном итоге, начинают неохотно готовится к переходу на 1С 8.2.

Мы же попробуем оптимизировать скорость работы нашей базы, и заодно увидим все недостатки платформы 1С 7.7 DBF!

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

Советы по предварительной настройке программного окружения

Давайте вспомним, как работает платформа 1С 7.7 DBF. У каждого пользователя указан так называемый рабочий каталог, имя пользователя, полное имя пользователя. При старте платформа 1С проверяет, нет ли в рабочем каталоге пользователя файла *.lck (режим, когда рабочий каталог пользователя не указан – не рассматриваем, позже станет ясно — почему). Если файл lck есть – значит данный пользователь уже работает и 1С не пустит его в базу, выдав сообщение “каталог пользователя занят”. Если такого файла нет – пользователь начинает работу. При открытии пользователем экранных форм, содержащих реквизиты с сохраненными настройками, платформа 1С извлекает эти настройки из файла *.cfg, лежащего, конечно же, в рабочем каталоге пользователя. Замечу, что в данном файле со временем скапливается много мусора, причем файл может даже оказаться поврежденным. Во время работы пользователя, и соответственно, выполнения программного кода, платформа 1С выполняет некие действия, из которых нас интересует следующее: опишу на примере — когда пользователь запускает отчет, в котором выполняется запрос, состоящий, с точки зрения платформы 1С, из нескольких простых запросов – платформа 1С выполняет простые запросы по очереди, сохраняет результаты каждого простого запроса в виде файлов dbf в рабочем каталоге пользователя, после чего считывает их заново, и производит окончательное формирование результата запроса.

Правило №1:
1. Каждому пользователю должен быть назначен рабочий каталог. В этом случае настройки каждого пользователя, будут хранится в отдельном файле cfg, а не в одном файле cfg на всех пользователей. Временные файлы dbf также будут хранится в отдельных каталогах.
2. Размер файла cfg каждого пользователя не должен превышать нескольких сотен килобайт (и, тем более, не должен быть размером 1 мегабайт и более). Файл cfg размером 1 мегабайт (и больше) приводит к серьезному замедлению работы пользователя. Рекомендую безжалостно удалять cfg файл, если его размер больше чем 200-400 килобайт. Для профилактики, оптимизации, или устранения торможения 1С – удалите файлы cfg всех пользователей.
3. Тот факт, что 1С создает временные dbf файлы (не считая *.cfg, *.lck) в рабочем каталоге пользователя, определяет следующую идею оптимизации. Рабочие каталоги пользователей нужно располагать на самом быстром жестком диске сервера (нежелательно, чтобы на этом же диске была операционная система, или файл подкачки).

В объектной модели 1С существует только два вида объектов, которые может создавать интерактивно пользователь – это элемент справочника, и документ. Для оповещения всех работающих экземпляров 1С о том, что элемент справочника (либо документ) открыт (и значит недоступен для изменения), 1С применяет тот же способ — создание временных файлов. В случае документа, в каталоге информационной базы 1С создается файл 1sjourn.$lk, в котором блокировкой определенного байта фиксируется факт открытия экранной формы объекта пользователем. Для элементов справочников создается файл sс****.$lk, где **** — внутренний идентификатор справочника в конфигурации (идентификаторы всех объектов конфигурации можно узнать, открыв любым текстовым редактором файл 1cv7.dd). Подробнее об этом методе блокировки можно прочитать тут. Мы же можем только вздохнуть, и констатировать, что механизмы платформы 1С DBF 7.7 архаичны и используют методы “вековой давности”. Впрочем, последний релиз платформы 7.7 действительно выпущен в далеком 1999 году.

Знайте также, что платформа 1С 7.7 DBF, не ограничиваясь созданием временных файлов в рабочих каталогах пользователей и в каталоге базы, создает свои временные файлы и в специальном каталоге для временных файлов. Кстати, с помощью ключа командной строки \Т можно явно указать программе 1С, где ей следует создавать временные файлы. Например так: С:\1С77.ADM\1cv7.exe /TD:\ (задан каталог для временных файлов – D:)
Полагаю, перечисление всех типов временных файлов создаваемых 1С, заставило читателя вспомнить о “старом лекарстве от всех временных файлов” – драйвере RamDrive (или аналогах)? Не рекомендую его применять по ряду причин. В первую очередь по причине неэффективности способа.
Как же тогда ускорить работу большой базы 1С 7.7 в формате DBF? А вот как. Большинство из нас, полагаю, давно не пользовались утилитой дефрагментации диска (за ненадобностью). О вашей базе: если у вас большая база DBF, т.е. 1-10 гигабайт, то вам стоит запустить анализ фрагментации жесткого диска, на котором находится каталог с базой 1С. Если под базу 1С не выделен отдельный жесткий диск на сервере, и, соответственно, на жесткий диск часто пишутся и удаляются данные, то, в большинстве случаев, самые большие файлы базы 1С (это файлы регистра партий, регистра продаж, табличной части документа реализация и т.д.) фрагментированы на несколько тысяч частей.

Правило №3:
1. Не допускайте чрезмерной фрагментации файлов базы 1С (а большая DBF база на невыделенном жестком диске очень склонна к фрагментации). Приведу пример (совсем не редкий из практики): если у вас файлы регистра партий, регистра продаж, табличной части документа реализация фрагментированы на 3000 частей каждый, то дефрагментация диска ускорит работу вашей базы в разы. В зависимости от скорости роста фрагментации, рекомендую запускать автоматическую дефрагментацию раз в сутки (или раз в неделю). Для автоматической дефрагментации используйте запуск утилиты defrag.exe с параметром – именем жесткого диска. Например: defrag.exe D:

Выполнив эти мелкие, но полезные шаги по оптимизации, предпримем более серьезные действия. Начну издалека. Как известно, DBF база состоит из совокупности dbf и cdx файлов (прочие файлы служебного назначения в расчет не берем). Таких файлов обычно несколько тысяч. Совокупный размер этих файлов может достигать нескольких гигабайт. Попробуем оценить следующее — какой объем информации 1С нужно считать из файлов, расположенных на жестком диске, при простом действии — проведении документа РеализацияТМЦ? Например, в базе, с которой я сейчас работаю (речь идет о конфигурации Торговля и Склад 7.7), размер файла итогов регистра ОстаткиТМЦ — 30 мегабайт, размер файла итогов регистра ПартииНаличие — 60 мегабайт. Как мы знаем, при проведении документа реализация в коде модуля проведения анализируются итоги регистра ОстаткиТМЦ и ПартииНаличие. Значит, платформе 1С для анализа итогов этих регистров придется прочитать оба этих файла с диска, т.е. считать информацию размеров 90 мегабайт. Не будем забывать, что система 1С также должна будет считать с диска файл журнала документов, и многие другие файлы. Операции чтения с диска занимают некое время, и скорее всего, в случае большой базы — немалое. Поэтому, уделим пристальное внимание тонкой настройке серверной операционной системы в части её работы с жестким диском. Провести настройку нам поможет утилита тонкой настройки операционной системы сервера — ConfigNT.

Правило №4:
1. В оснастке администрирования сервера отключаем службу индексирования диска, если она у вас включена.
2. В оснастке администрирования отключаем службу теневого копирования тома.

Запускаем утилиту ConfigNT и выполняем следующие действия:

3. На закладке Logon устанавливаем галку в чекбоксе «AutoEndTasks». Установка данной опции сообщит операционной системе сервера о том, зависшие процессы необходимо завершать немедленно, не оповещая об этом пользователя.
4. Установливаем на закладке Memory Management галку в чекбоксе «Maximize Throughput for File Sharing». Тем самым мы дадим знать операционной системе сервера, что желаем, чтобы для использования файлов выделялся максимально доступный объем памяти. При данной настройке, операционная система не будет сбрасывать долго не используемые страницы оперативной памяти на диск, т.е. в виртуальную память.
5. Устанавливаем на той же закладке галку в чекбоксе «Use large system cache». Установка данной опции сообщит операционной системе сервера о том, что под кэширование дисков нужно выделить максимум оперативной памяти.
6. На закладке Other снимаем галку в чекбоксе «Update last access time on NTFS». Установка данной опции сообщит операционной системе сервера о том, что не следует обновлять время последнего доступа к файлам.

Также рекомендую в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Filesystem создать ключ NtfsDisable8dot3NameCreation с типом DWORD и значением равным 1. По умолчанию, файловая система NTFS создает и хранит таблицу всех имен файлов и папок на диске в формате MS-DOS (т.е. 8 символов для имени файла, и 3 символа для расширения). Это нужно для совместимости со старыми приложениями. Установкой значения 1 для параметра NtfsDisable8dot3NameCreation отключим эту особенность NTFS.

Для того чтобы параметры возымели действие — перезагрузите сервер.

И, последний совет — если конфигурация вашего сервера позволяет использовать SSD жесткий диск — очень желательно приобрести жесткий диск такого типа. Жесткие диски использующие технологию SSD, обеспечивают на порядок большую скорость чтения информации с жесткого диска, нежели у жестких дисков традиционного типа, что увеличивает скорость работы базы 1С 7.7 в формате DBF в разы. Подробней о технологии SSD можно почитать тут.

Советы по оптимизации конфигурации 1С 7.7 DBF

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

Рассмотрим работу платформы 1С 7.7 “изнутри”. Основными объектами для хранения информации о хозяйственных операциях в 1С являются справочники и документы, как мы уже выяснили. В принципе, оперируя лишь этими объектами, мы могли бы получить все необходимые нам данные. Но, разработчики программы 1С ввели в объектную модель дополнительные объекты, призванные агрегировать информацию (из справочников и документов) и предоставить возможность быстрого доступа к ней. Такие объекты – это регистры остатков, регистры оборотов и проводки. Указанные объекты обычно хранят информацию (причем учитывая хронологию событий во времени) о движении остатков товаров, денежных средств и т.п.

Неправильное проектирование регистров зачастую приводит к ощутимому торможению базы 1С.

Правило №1:
1. Не используйте галки “Отбор движений” и “Отбор итогов” для измерений регистра без крайней необходимости, так как это увеличивает размер индекса. Крайняя необходимость – тот случай, когда в программном коде необходимо использовать функции ВыбратьДвижения(), ВыбратьИтоги() с фильтром по искомому измерению.
3. При проектировании регистра учитывайте особенность платформы 1С 7.7. Дело в том, что платформа создает один составной индекс для всех измерений регистра. Поэтому, полезный совет – располагайте измерения в регистре в порядке убывания частоты использования измерения в отборах. Например для регистра ОстаткиТМЦ правильным будет порядок следования измерений: а)Номенклатура б)Склад в)Фирма г)ЦенаПрод. А вот такой порядок: а)Фирма б)Склад в)Номенклатура г)ЦенаПрод – приведет падению скорости выборки данных из регистра и увеличению размера индексного файла.
4. Не допускайте случаев “не закрывающихся” регистров.

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

Немного информации о блокировках, применяемых платформой 1С 7.7 DBF. Блокировки бывают “на чтение” и “на запись”. Я специально выбрал эти термины, т.к. уже по названию блокировки понятно, как платформа 1С выбирает, которую применить. Сейчас нас интересует лишь возможность одновременной установки блокировок. Итак, блокировка “на запись” исключает установку другой блокировки “на запись”, а также “на чтение”. Блокировка “на чтение” разрешает установку других блокировок “на чтение”, но запрещает установку блокировок “на запись”. Отсюда следует простой вывод – если в константу часто идет запись, то, часто возникающие блокировки «на запись» будут исключать установку блокировок обоих типов, что в высоконагруженной системе (40-70 пользователей), приведет к появлению сообщений о ошибке транзакции у пользователей программы. В случае же использования констант “по назначению”, т.е. когда значения из констант будут большей частью считываться – ошибок транзакций не возникнет, т.к. блокировки “на чтение” могут устанавливаться одновременно несколькими экземплярами 1С.

Правило №2:
1. Используйте константы по назначению. Недопустима, например, ситуация, когда при проведении каждого документа в некую константу записывается информация.

Таблица констант, к сожалению, не единственное “узкое” место в структуре таблиц, применяемых платформой 1С 7.7 для хранения данных. Еще одно узкое место – таблица документов. При сохранении или проведении документа, 1С блокирует данную таблицу для всех пользователей, кроме того, кто выполняет сохранение (проведение). В высоконагруженной системе блокировки таблицы документов будут неизбежно (и часто) вызывать ошибки транзакций у пользователей. Более того, лавина транзакций будет вызывать растущую загрузку процессора – вплоть до 100%.

Правило №3:
1. Установите данную разработку. Разработка позволяет снизить загрузку процессора во время ожидания блокировки таблицы до незаметных величин. Более того, за счет нехитрого, но эффективного алгоритма повторных попыток заблокировать таблицу, количество неудачных попыток заблокировать таблицу снизится, а значит, заметно уменьшиться количество транзакций.

Примечание: для платформы 1C 7.7 SQL существует более эффективный инструмент – “гибкие блокировки”, но в данной статье платформа 1C 7.7 SQL рассматриваться не будет.

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

Для этого можно применить, например, такие способы:
1. Для применения способа необходима установленная компонента УРБД. Создаем новую периферийную базу. Пользователей делим на 2 группы: а) пользователи, создающие документы текущей датой б) пользователи, формирующие отчеты, и создающие документы как текущей датой, так и «задним числом». Пользователи группы «а» работают в прежней базе. Пользователи группы «б» работают в периферийной базе. Для синхронизации данных между базами настраиваем автообмен.
2. Этот способ условно можно назвать — дублирование регистров. Суть способа состоит в том что в конфигурации заводятся новые регистры — дубли существующих. Выбирается день Х. На начало дня Х делается «снимок» итогов регистров остатков и заносится в соответствующие им дубли. В код конфигурации вносятся такие изменения, что все документы, начиная со дня Х проводятся по новым регистрам, программный код отчетов тоже изменяется — для отчетов по регистрам оборотов в код запросов просто дописывается второй регистр. Отчеты по регистрам остатков переписываются так, что до дня Х отчет формируется по старому регистру, со дня Х — по свежесозданному дублю этого регистра. Недостаток: Сформировать отчет с начальной даты = (ДеньХ-1 день) по конечную дату (ДеньХ+1) конечно же, нельзя.

На нескольких больших базах, пребывавших под моим наблюдением, был замечен следующий эффект: при выполнении обработкой массовой записи и проведения документов одинаковым временем, скажем — 08:00:00, при возникновении ошибки транзакции документ бесследно исчезал. Полагаю, читатель знаком с утверждением, что в 1С 7.7 (как впрочем и 1С 8) в пределах одной секунды можно записать достаточно большое число документов (1000-5000 например). Вышесказанное заставляет меня в этом усомниться (по крайней мере в случае большой базы формата DBF).

Думаю, читатель знаком и с утверждением, что позиция документа – это некая величина, зависящая от времени документа, и от порядка ввода документов в пределах одной секунды. Мои наблюдения на больших базах не подтверждают это утверждение. Типовой отчет “Остатки ТМЦ” (с детализацией по документам) выводит такие документы (имеющие одинаковое время, распределенные в пределах одной секунды) в порядке, отличающемся от порядка в журнале документов! Более того, путем определенных экспериментов было установлено, что при расчете остатков в модуле проведения такого документа, остатки выдавались неверные (в силу неверного определения позиции)!

Правило №4:
1. Т.к. вы работаете с информационной базой DBF, приближающейся к предельному объему, не искушайте судьбу – не используйте в ваших обработках массовую запись и проведение документов одинаковым временем. Документы должны записываться с шагом в 1 секунду.
2. Рекомендую иногда проверять размеры файлов 1sjourn.dbf и 1sjourn.cdx (журнал документов). В норме размер файла 1sjourn.cdx должен быть примерно в 1,5 раза больше размера файла 1sjourn.dbf. Если у вас соотношение размеров этих файлов кардинально другое (например файл 1sjourn.cdx меньше файла 1sjourn.dbf — чего быть никак не может) – то это один из признаков неисправности журнала документов.
3. Приблизительно такое же соотношение должно быть у размеров файлов 1scrdoc.dbf и 1scrdoc.cdx (перекрестные ссылки документов).

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

ГЛАВНАЯ ПРОБЛЕМА БОЛЬШИХ БАЗ 1С 7.7 DBF:

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

Правило №5:
1) Заблаговременно (до достижения самым большим файлом dbf размера в 1 гигабайт) установите данную разработку.
2) После установки разработки, удалите все индексные файлы в каталоге вашей базы 1С, и запустите 1С в монопольном режиме. Индексные файлы будут воссозданы заново.

Путем выполнения указанных в статье рекомендаций можно “вернуть форму” базе 1С 7.7 DBF даже большого размера (10-12 гигабайт), и получить с приемлемую скорость работы, с минимумом транзакций.

Надеюсь что из данной статьи смогли почерпнуть максимум информации все три категории читателей:
1) ИТ-специалисты, поддерживающие базы на платформе 1С 7.7 DBF.
2) ИТ-специалисты, которые хотят понять все недостатки платформы 1С 7.7, для аргументированного принятия решения о переходе на платформу 1С 8.2.
3) Все те читатели, кому хочется знать существующие техники оптимизации и ускорения платформы 1С 7.7 DBF.

Примечание:
Вдумчивый читатель, разумеется, заметил некий перекос в изложении способов оптимизации. Действительно, тщательная подготовка и оптимизация программного окружения описана гораздо подробней, чем способы оптимизации непосредственно конфигурации 1С. Такое положение дел объясняется опытом автора в эксплуатации и оптимизации баз 1С 7.7 DBF. Практика показывает, что главная причина возникающего с ростом размера базы «торможения», «зависаний», увеличивающейся длины транзакции, и, соответственно — ошибок транзакций — это то, что с ростом размера базы значительно увеличивается время, требующееся 1С для извлечения информации из нескольки тысяч dbf и cdx файлов хаотично разбросанных по жесткому диску, причем, значительно фрагментированных. Во многих случаях достаточно приобрести SSD жесткий диск, и получить ускорение работы конфигурации в разы. Тогда как можно пойти другим путем — последовательно применить несколько трудоемких техник по оптимизации самой конфигурации 1С и получить ускорение всего в 30%-50%

Источник