Configsave 1c где найти
Для сохранения конфигурации из 1С в формат CF или в иерархическое дерево исходников в платформе предусмотрен запуск из командной строки. Можно ли сохранить конфигурацию минуя конфигуратор? Можно. Конфигурации находятся в отдельных таблицах SQL-базы.
Что понадобится
Кроме 1С будем использовать OneScript (начиная с версии 1.0.16), PowerShell (версии по умолчанию достаточно) и планировщик запуска.
Безусловно, нам нужны права на доступ к SQL-серверу. К нашим конкретным базам данных. Хотя бы на чтение. Исследование будет проводиться на MS SQL-серверах. Для операций будет использован Microsoft SQL Server Management Studio версии 14.0.17119.0 (хотя версия не принципиальна).
Для визуального мониторинга нам потребуется git на сервере, где будет происходить разбор на исходники и учетка в системе контроля версий.
Специальные предложения
А чо, весело и задорно! Хотя, заявленные задачи я бы решал другими средствами, но пусть расцветает сто цветов!
(2) Начнем с того, что не все организационные проблемы надо решать техническими средствами. Организационные меры тоже работают. Одна из лучших мер - отобрать у разработчиков админский доступ к боевой системе. Доступ как в ядерное хранилище - под роспись со сканированием сетчатки и анализом мочи от участкового врача.
Больше подробностей по пунктам задач:
Вы хотите знать наверняка, когда и какие изменения внесены в рабочую базу и почему рабочая база не совпадает с конфигурацией хранилища (хотя и должна).
Боевая база в режиме "поддержки" с замочками, как типовая. Изменения в ней исключены. Обновление боевой системы выполняет сервер CI с помощью утилиты deployka, а не человек. А если уж человек заходил и изменения в конфигурацию внесены, то есть "конфигурация поставщика", с которой можно сравнить и понять - что изменено. А если сняли с поддержки совсем, так что и "конфигурация поставщика" исчезла - то смотрим журнал доступа и устраиваем показательную казнь.
Не понял тезис и задачу. Как выглядит "Оперативных контроль изменений" и что именно решает?
Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)
Организационный момент. Доступ в боевой конфигуратор выдается только человеку, отвечающему головой за систему. Он под своим присмотром может пустить туда разработчика на короткий срок решения авралов. Текущая разработка задач, ведущаяся на боевой системе должна быть исключена. И техническими средствами это не решить.
Теперь по контр-тезисам:
Да, и более того - это совсем не больно. Нет ни одной причины совсем не использовать хранилище в разработке на 1С (если вы не Евгений Сосна, но он использует GIT вместо хранилища, а это не совсем одно и то же, что и вообще без версионирования)
Да, иначе бардак, Адъ и Израиль. Но бывают авральные хотфиксы, которые потом спокойно и не спеша вносятся в хранилище. Для этого и нужен "режим поддержки" для контроля отличий (см. выше)
Хотфиксы не проходят тесты, ибо это ХОТ-фиксы, когда пожар и у всех подгорает. Не до тестов.
Вносят. но это тоже авральный режим. Так не должно быть всегда и инструмент, приведенный в статье здесь непонятно каким боком.
База не подключена, она стоит на поддержке и за счет этого "неизменна". Включение режима изменений только для авралов. Полное снятие с поддержки - показательная казнь.
Доступ в боевой конфигуратор человеку (а не серверу CI) только после справки от врача (и желательно с другой машины). Тут сложно перепутать.
При сравнении/объединении с новым релизом не бывает ошибки, связанной с неверным выбором файла релиза. Или альтернативное утверждение: новые релизы всегда устанавливаются из файлов поставки.
Сервер CI не ошибается с выбором файла релиза.
Администраторы базы данных никогда не ошибались с восстановлением БД из других баз данных или бекапов.
И как здесь поможет инструмент, предлагаемый в статье?
Мы все одна команда, у нас нет сотрудников, не разделяющих ценности компании, мы уверены, что никто по неведению или злому умыслу не внесет изменений, которые нарушат работу нашей системы.
NoRazum; nvv1970; artbear; Mahon83; support; amon_ra; Ko1t; vvst; Dementor; Vladimir Litvinenko; IgorS; freddy121; kuntashov; antonj; GreenDragon; jif; kraynev-navi; 1cWin; Bronislav; Berckk; user774630; kalyaka; NeviD; AlexandrUng; JohnyDeath; + 25 – Ответить
(3) Очень хороший, годный комментарий. И прямо просит столь же развернутого ответа.
Сразу скажу, что Андрей Овсянкин (Evil Beaver) прав. Нет, ПРАВ. На 150%.
И примерно так выглядит наша цель. Цель, к которой мы идем не первый год. Можно прямо брать пост и рисовать RoadMap.
Целью является «Волшебный Мир»с единорогами и розовыми пони. Теми самыми, которые питаются леденцами и какают бабочками. Кто-то уже сумел построить такой мир, кто-то нашел его и переселился. И это здорово, это дарит надежду. Что и остальные из «Злого Леса» могут со временем выбраться в дивный новый мир.
Действительно здорово. Смотришь, например, Infostart Event, и понимаешь, что сообщество растет. То, что когда-то воспринималось как ересь отчаянных гиков, идущих против системы, становится понемногу если не стандартом, то Best Practics.
Есть и плохая новость (на самом деле – не новость). Не везде так здорово. Не всем повезло жить в мире Полудня или НИИ ЧАВО Стругацких. Многие живут в грустном антиутопичном мире, который хорошо описан, например, в цикле статей Ивана Белокаменцева.
https://infostart.ru/profile/73629/
Да и в Gitter есть немало постов про то, что не все гладко.
https://gitter.im/EvilBeaver/oscript-library
И ведь знаешь, как правильно надо делать… Вот и идем мы отсюда – туда, в волшебный мир.
Анекдот про социализм.
http://anekdotov.me/sovetskie/51683-odnoj-nogoj-my-stoim-v-socializme-a-drugoj-uzhe.html
За рамками статьи – много боли. Озера и моря.
Каждый тезис можно развернуть если не в книгу, то в большую статью с примерами из жизни, кульминацией и развязкой.
Собственно, описанный в статье кейс, является решением вполне конкретной жизненной задачи. Кейс этот получил весьма интересное и перспективное развитие. Об этом будет следующая статья.
По поводу «Организационный момент», «показательная казнь», «Сервер CI не ошибается»
У нас холдинговая структура. И, мягко говоря, не всегда можно насадить свое мнение.
Т.е. есть очень уважаемый в организации программист. И незаменимый. То, что незаменимость эта следствие некомпетентности или специально выстроенная ситуация – оставляем за кадром. Так есть. Это реальность, данная нам в ощущениях.
Главное – он полезный. И текущие потребности организации закрывает. И все довольны. А хранилище и регламенты ему не интересны. И даже будут мешать. А вокруг степь на сотни километров и другого все равно не найдем.
И тут какие-то пи… Нет, безусловно, очень умные и грамотные люди из Москвы. К сожалению, оторванные от реальности и не знающие местной специфики, начинают рассказывать, что все не так. Уважаемый человек, на самом деле - вредитель. А то, что раньше делалось за день, будет делаться неделю.
Более того, над людьми (внутренними заказчиками) будет совершаться самое страшное насилие. Их будут заставлять думать. Думать, что же они хотят. Зачем им это надо. Как они будут проверять, что все работает, как они хотели. И, внезапно, появится контроль того, как они используют то что им сделали из того, что они хотели. И апофигеем – анализ достижения целей, которые декларировались, как приоритетные, при аргументации необходимости разработки.
И вот этому «уважаемому человеку» мы собираемся устроить «показательную казнь».
Очень серьезный политический шаг. И за «базар» придется отвечать.
А программист говорит - «мамой клянусь, ничего такого не делал, это все они».
И разговор это очень быстрый. Потом можно долго бегать как в фильме «О чем говорят мужчины» https://www.youtube.com/watch?v=2wcIEybNscs&feature=youtu.be&t=1394
Нужна доказательная база. Вот эту доказательную базу мы и получаем. Да, были изменения в рабочей конфигурации. А в хранилище не было. И задачи на хотфикс не было. Ну как так-то? Ай-яй-яй. Это предметный разговор.
Но, в общем случае, приводить удаленное подразделение к «общему знаменателю» стратегически правильно, но не всегда своевременно и экономически оправданно.
Да и нам это тоже не очень надо. У нас есть маленький кусочек конфигурации, отвечающий за интеграцию. И мы хотим, чтобы он был реализован, работал и не изменялся без нашего ведома.
А вопрос с сопровождением отдельно взятой маленькой недружественной организацией может решиться и естественным путем (например, ее продадут или сократят). Ну да, мы не за идею работаем, тупо за деньги.
Кстати, в волшебном мире такой контроль тоже полезен. На всякий случай. Только в штатной ситуации такое изменение рабочей ИБ должно быть привязано к задаче на деплоймент (в том числе, к автоматической задаче). И это не так сложно промониторить. Определение повода для «показательной казни» тоже можно автоматизировать.
Мне очень нравится идея включить подобный функционал в репозиторий OneScript,но PowerShell тоже имеет аргументы на параллельное существование. Его можно через PsExec запустить удаленно в недружественной среде.
Если нельзя сделать все сразу хорошо – ведь это не значит, что не нужно делать вообще ничего.
Не ожидал, что это скажу, но надо использовать то, что работает.
И вообще, это только кусочек мозаики, паззла. Где есть и безопасность, и мониторинг, и бэкапы, и управление требованиями, и управление задачами, и регламенты, и обучение, и методология, и Framework, и инфраструктура, и организационные изменения, и многое другое.
Еще раз повторю. В комментарии коллеги – все правильно. Просто многих пугает, как жить в переходный период. А здесь работает простое правило бойскаута.
https://plus.google.com/+SergeyTeplyakov/posts/ZaxnrarBvKS
Если каждый день делать немного лучше – в результате неизбежно станет хорошо. Главное, не останавливаться.
mikeA; nvv1970; support; mr.lynx; Berckk; farukshin; kraynev-navi; tsukanov; Evil Beaver; + 9 – Ответить
(16) Спасибо за камент. Если что - никого не хотел обидеть. Я написал, что статья хорошая, просто я бы решал по-другому, но я не истина в последней инстанции, напротив, мы тут все делимся опытом и каждый делает для себя выжимки из чужого опыта, приправляя своим. Главное потом - не забыть поделиться результатом, чтобы в сообществе было больше разных знаний и опытов. "Пусть расцветает сто цветов" из моего первого комментария - это как раз об этом.
Данные, которые определяют логику функционирования системы на базе 1С:Предприятия, относятся к информационной базе. Хранение информационной базы осуществляется в базе данных с виде набора таблиц, для чего 1С:Предприятие 8.1 может использовать одну из четырех систем управления базами данных (СУБД):
* Встроенную в 1С:Предприятие 8.1 (файловый вариант информационной базы). В этом случае все данные информационной базы хранятся в файле с именем 1Cv8.1CD. Этот файл имеет двоичный формат и по сути является базой данных для встроенной в 1С:Предприятие 8.1 СУБД.
* Microsoft SQL Server (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных Microsoft SQL Server.
* PostgreSQL (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных PostgreSQL.
* IBM DB2 (клиент-серверный вариант информационной базы). Все данные информационной базы хранятся в базе данных IBM DB2.
На уровне объектов базы данных (таблиц, полей, индексов и т. п.) как файловый так и клиент-серверный вариант информационной базы имеют сходный формат (отличающийся несущественными деталями). Некоторая информация об этом формате содержится ниже.
Вся информационная база представляется в базе данных в виде набора таблиц. Среди них есть несколько таблиц, которые обязательно присутствуют в представлении любой информационной базы:
* Config - основная конфигурация информационной базы. Эта конфигурация соответствует реальной структуре данных и используется 1С:Предприятием 8.0 в режиме Предприятия.
* ConfigSave - конфигурация, редактируемая Конфигуратором. Конфигурация из ConfigSave переписывается в Config при выполнении "Обновления конфигурации базы данных" в Конфигураторе, а наоборот - при выполнении в Конфигураторе операции "Конфигурация - Конфигурация базы данных - Вернуться к конфигурации БД".
* Files содержит служебную информацию, например, о работе с хранилищем конфигурации.
* Params содержит параметры информационной базы. Среди них:
=> Список пользователей информационной базы.
=> Национальные настройки информационной базы.
=> Таблица соответствия объектов метаданных и объектов базы данных (таблиц, полей, индексов).
=> Некоторая другая информация.
* _YearOffset - смещение дат в базе данных. Эта таблица создается только при использовании Microsoft SQL Server.
* DBSchema содержит информацию о структуре базы данных 1С:Предприятия и определяет другие объекты базы данных, используемые данной информационной базой.
Перечень и структура других таблиц базы данных определяется конкретной конфигурацией, а именно, определенными в ней объектами метаданных. Имя каждой таблицы состоит из буквенного префикса и следующего за ним номера. Префикс определяет назначение таблицы, а номер позволяет различать таблицы одинакового назначения, относящиеся к разным объектам метаданных. Если в качестве СУБД используется IBM DB2, то описанную структуру имеют не имена таблиц, а их псевдонимы.
Если в конфигурации определен хотя бы один план обмена с установленным флагом "Распределенная информационная база", то будут созданы следующие таблицы:
* _ConfigChangeRec - таблица регистрации изменений объектов конфигурации.
* _ConfigChangeRec_ExtProps - таблица имен файлов измененных внешних свойств объектов конфигурации.
Ниже перечислены различные объекты метаданных, которым могут соответствовать те или иные таблицы.
* Константы
=> _Consts содержит текущие значения всех констант, определенных в конфигурации.
=> _ConstsChangeRec - таблица регистрации изменений констант. Создается, если хотя бы одна константа участвует хотя бы в одном плане обмена.
* Планы обмена
=> _Node - таблица плана обмена.
=> _Node_VT - табличная часть плана обмена, создается для каждой табличной части.
* Справочники
=> _Reference - таблица справочника.
=> _Reference_VT - табличная часть справочника - для каждой табличной части.
=> _ReferenceChangeRec - таблица регистрации изменений справочника. Создается, если справочник участвует хотя бы в одном плане обмена.
* Документы
=> _Document - таблица документов для каждого объекта метаданных "документ".
=> _Document_VT - табличная часть документа - для каждой табличной части каждого документа.
=> _DocumentChangeRec - таблица регистрации изменений объекта метаданных типа "документ". Создается для каждого объекта метаданных типа "документ", если он участвует хотя бы в одном плане обмена.
* Последовательности документов
=> _Sequence - таблица регистрации документов - для каждой последовательности.
=> _SequenceBoundary - таблица границ последовательности - для каждой последовательности.
=> _SequenceChangeRec - таблица регистрации изменений последовательности. Создается для каждой последовательности, которая участвует хотя бы в одном плане обмена.
* Журналы документов.
=> _DocumentJournal - таблица журнала документов, создается для каждого журнала документов.
* Перечисления
=> _Enum - таблица перечисления - по одной для каждого перечисления.
* Планы видов характеристик
=> _Chrc - основная таблица плана видов характеристик.
=> _Chrc_VT - табличная часть плана видов характеристик - для каждой табличной части.
=> _ChrcChangeRec - таблица регистрации изменений плана видов характеристик. Создается, если план видов характеристик участвует хотя бы в одном плане обмена.
* Планы счетов
=> _Acc - основная таблица плана счетов.
=> _Acc_ExtDim - таблица видов субконто плана счетов, создается для плана счетов в том случае, если максимальное количество субконто больше нуля.
=> _Acc_VT - табличная часть плана счетов, создается для каждой табличной части плана счетов.
=> _AccChangeRec - таблица регистрации изменений плана счетов. Создается, если план счетов участвует хотя бы в одном плане обмена.
* Планы видов расчета
=> _CalcKind - основная таблица плана видов расчета.
=> _CalcKind_BaseCK - таблица базовых видов расчета, создается для плана видов расчета в случае, если его свойство "Зависимость от базы" имеет значение, отличное от "Не зависит".
=> _CalcKind_DisplacedCK - таблица вытесняемых видов расчета, создается для плана видов расчета в случае, если у него установлен флаг "Использует период действия".
=> _CalcKind_LeadingCK - таблица ведущих видов расчета - для каждого плана видов расчета.
=> _CalcKindDN - вспомогательная таблица для порядка вытеснения, создается, если у плана видов расчета установлен флаг "Использует период действия".
=> _CalcKind_VT - табличная часть плана видов расчета, создается для каждой табличной части.
=> _CalcKindChangeRec - таблица регистрации изменений плана видов расчета. Создается, если план видов расчета участвует хотя бы в одном плане обмена.
* Регистры сведений
=> _InfoReg - таблица движений регистра сведений.
=> _InfoRegChangeRec - таблица регистрации изменений регистра сведений. Создается, если регистр сведений участвует хотя бы в одном плане обмена.
* Регистры накопления
=> _AccumReg - таблица движений регистра накопления.
=> _AccumRegTotals - таблица итогов регистра накопления, если регистр поддерживает остатки.
=> _AccumRegTurnovers - таблица оборотов регистра накопления, если регистр поддерживает обороты.
=> _AccumRegChangeRec - таблица регистрации изменений регистра накопления. Создается, если регистр накопления участвует хотя бы в одном плане обмена.
=> _AccumRegOptions - таблица настроек хранения итогов регистров накопления одна на все регистры накопления.
* Регистры бухгалтерии
=> _AccntReg - таблица движений регистра бухгалтерии.
=> _AccntRegED - таблица значений субконто регистра бухгалтерии, создается в том случае, если он ссылается на план счетов, у которого максимальное количество субконто больше нуля.
=> _AccTtl0 - таблица итогов по счету.
=> _AccTtl - где i от 1 до максимального количества субконто. Таблица итогов по счету с количеством видов субконто равным i.
=> _AccTtlC - таблица итогов оборотов между счетами, только для регистра бухгалтерии поддерживающего корреспонденцию.
=> _AccntRegChangeRec - таблица регистрации изменений регистра бухгалтерии. Создается, если регистр бухгалтерии участвует хотя бы в одном плане обмена.
=> _AccntRegOptions - таблица настроек хранения итогов одна на все регистры бухгалтерии.
* Регистры расчета
=> _CalcReg - таблица движений регистра расчета.
=> _CalcRegActPer - таблица фактических периодов действия для регистра расчета, создается, если у регистра расчета установлен флаг "Период действия".
=> _CalcRegChangeRec - таблица регистрации изменений регистра расчета. Создается для каждого регистра расчета, участвующего хотя бы в одном плане обмена.
=> _CalcRegRecalc - таблица перерасчета регистра расчета, создается для каждого перерасчета.
=> _CalcRegRecalcChangeRec - таблица регистрации изменений перерасчета. Создается, если перерасчет участвует хотя бы в одном плане обмена.
* Бизнес-процессы
=> _BPRoutePoint - таблица точек маршрута бизнес-процесса для каждого бизнес-процесса.
=> _BusinessProcess - основная таблица бизнес-процесса.
=> _BusinessProcess_VT - табличная часть бизнес-процесса для каждой табличной части.
=> _BusinessProcessChangeRec - таблица регистрации изменений бизнес-процесса. Создается для каждого бизнес-процесса, участвующего хотя бы в одном плане обмена.
* Задачи
=> _Task - основная таблица задачи.
=> _Task_VT - табличная часть задачи для каждой табличной части.
=> _TaskChangeRec - таблица регистрации изменений в задачах. Создается для каждого объекта метаданных типа "задача", который участвует хотя бы в одном плане обмена.
При использовании IBM DB2 префиксы псевдонимов таблиц начинаются не с символа подчеркивания, а сразу с буквенной части.
Количество этих таблиц зависит от функциональности конфигурации и может быть достаточно большим. В штатном режиме 1С:Предприятие не выполняет проверку их наличия, а также целостности и непротиворечивости содержащихся в них данных. Поэтому важно, чтобы база данных, в которой размещена информационная база 1С:Предприятия 8.1, была защищена от несанкционированного доступа и ее модификация выполнялась только средствами 1С:Предприятия. Для проверки необходимо использовать функцию "Администрирование - Тестирование и исправление", встроенную в конфигуратор.
Важно также, чтобы резервное копирование и восстановление базы данных, хранящей информационную базу, выполнялось только целиком. С этой целью рекомендуется использование средств резервного копирования баз данных, встроенных в в используемую СУБД. Резервное сохранение файлового варианта информационной базы может быть выполнено копированием файла 1Cv8.1CD.
В конфигураторе есть специальная функция: Администрирование - Выгрузить информационную базу. С ее помощью можно выгрузить в указанный файл (файл выгрузки) все данные, относящиеся к информационной базе, и больше никакие. Обратная ей функция "Загрузить информационную базу" позволяет в текущую информационную базу вместо существующих загрузить все данные из файла выгрузки. Эти функции также можно использовать для резервного копирования данных информационной базы как в файловом так и в клиент-серверном варианте.
Как просмотреть структуру таблиц информационной базы?
Профайлы содержат информацию, не оказывающую влияния на логику функционирования системы на базе 1С:Предприятия 8.1. Такая информация не является необходимой, но ее сохранение может, например, повысить комфортность работы пользователя. В профайлах можно хранить формат и расположение окон и диалогов, настройки шрифтов, цветов, отборов и т. п. Потеря такой информации НЕ может привести к нарушению работоспособности системы.
Профайлы различаются по принадлежности хранимой в них информации. Примеры хранимых данных и их расположение:
- Настройки текстового редактора.
/1C/1Cv81/1Cv8.pfl, например: C:/Documents and Settings/User/Application Data/1C/1Cv81/1Cv8.pfl
Информационная база - Режим аутентификации при старте 1С:Предприятия из отладчика.
- Каталог последнего сохранения хранилища конфигурации в файл.
Таблица files базы данных, в которой размешена информационная база.
Информационная база и пользователь - Настройки динамических списков.
- Настройки отборов по журналу регистрации.
Таблица files базы данных, в которой размешена информационная база.
Компьютер и информационная база - Настройки сравнения файлов конфигураций.
- Настройки глобального поиска по текстам конфигурации.
/1C/1Cv81//1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/ 4129dbdb-b495-41cb-99ea-ef315060a03e/1Cv8.pfl
Компьютер, информационная база и пользователь - Расположение окна синтакс - помощника.
- Список переменных для быстрого просмотра в отладчике.
/1C/1Cv81///1Cv8.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/ 4129dbdb-b495-41cb-99ea-ef315060a03e/ E8D87DA4-A087-4145-95E7-D613E0F7CB64/1Cv8.pfl
1С:Предприятие 8.1 в режиме Конфигуратора - Расположение окон конфигуратора.
- Цвета редактора модулей в конфигураторе.
/1C/1Cv81/1Cv8cmn.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/1Cv8cmn.pfl
1С:Предприятие 8.1 в режиме Предприятия - Расположение окон конфигуратора.
- Цвета редактора модулей в конфигураторе.
/1C/1Cv81///1Cv8cmn.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/ 4129dbdb-b495-41cb-99ea-ef315060a03e/ E8D87DA4-A087-4145-95E7-D613E0F7CB64/1Cv8cmn.pfl
Диалог запуска 1С:Предприятия 8.1 - Размеры и расположение диалога запуска.
- Настройки диалогов установки параметров информационных баз.
/1C/1Cv81/1Cv8strt.pfl, например:
C:/Documents and Settings/User/Application Data/1C/1Cv81/1Cv8strt.pfl
Данные из профайлов читаются при старте 1С:Предприятия 8.1 и записываются при его штатном завершении. По этой причине в случае нештатного завершения некоторые пользовательские настройки могут не сохраниться.
Наряду с профайлами в каталоге данных приложения могут содержаться и другие файлы с информацией, сохранение которой делает работу пользователей с 1С:Предприятием 8.1 более удобной. Среди них:
Временные данные нужны только в течение нескольких пересекающихся во времени или одного сеанса 1С:Предприятия.
К нескольким пересекающимся во времени сеансам относятся данные совместного использования, которые относятся к файловой информационной базе в целом и нужны, в частности, для реализации блокировок данных информационной базы. Такие данные хранятся в том же каталоге, что и файл информационной базы.
* Файл 1Cv8.1cl является носителем блокировок объектов базы данных, расположенной в файле 1Cv8.1cd.
* Файл 1Cv8Tmp.1cd хранит служебную сеансовую информацию, в частности список активных пользователей.
* Файл 1Cv8Tmp.1cl является носителем блокировок данных, расположенных в файле 1Cv8Tmp.1cd.
Для хранилища конфигурации 1С:Предприятие 8.х в режиме Конфигуратора создает временные файлы аналогичного назначения, расположенные в каталоге хранилища конфигурации:
* Файл 1Cv8ddb.1cl является носителем блокировок данных из хранилища конфигурации.
* Файл 1Cv8dtmp.1cd хранит служебную сеансовую информацию, в частности список активных пользователей хранилища конфигурации.
* Файл 1Cv8dtmp.1cl является носителем блокировок данных, расположенных в файле 1Cv8ddb.1cd.
Данные, используемые только в течение одного сеанса 1С:Предприятия, размещаются во временных файлах, создаваемых в каталоге, определенном в системе Microsoft Windows как каталог временных файлов. При этом для клиентского приложения используется каталог временных файлов текущего пользователя Windows, например, C:\Documents and Settings\User\Local Settings\Temp. Для сервера 1С:Предприятия используется или системный каталог временных файлов или каталог данных приложений пользователя, от имени которого запускаются рабочие процесса сервера 1С:Предприятия, например, C:\WINNT\Temp.
Как очистить кэш 1С?
Системная база данных TEMPDB участвует в работе пользователей, подключённых ко всем пользовательским базам данных сервера СУБД.
TEMPDB используется при работе с временными таблицами и процедурами, в ней создаются внутренние (internal) и пользовательские объекты (user objects) промежуточных результатов запросов и т.п..
При запуске сервера, TEMPDB создаётся заново, если TEMPDB по каким то причинам не может быть создана, то сервер СУБД не запуститься. По умолчанию размер этой базы данных неограничен и увеличение его осуществляется при необходимости автоматически, порциями по 10% от текущего размера TEMPDB, однако эти параметры могут быть переопределены пользователем. По умолчанию, минимальный размер этой базы данных, который устанавливается при старте Microsoft SQL Server, определяется размером системной базы данных MODEL. Очистка журнала транзакций в этой базе данных производится автоматически, при этом удаляются только неактивные записи журнала транзакций.
При работе 1С:Предприятия 8 в режиме клиент-сервер широко используются временные таблицы. Кроме того, TEMPDB используется Microsoft SQL Server при выполнении запросов, использующих операторы GROUP BY, ORDER BY, UNION, SORT, DISTINCT и т.п.
Наиболее частой проблемой, с которой сталкиваются пользователи, является значительное увеличение размера базы TEMPDB. Причиной увеличения размера базы данных TEMPDB, как правило, является невозможность автоматической очистки журнала транзакций и повторного использования свободного пространства в TEMPDB из-за наличия активных транзакций, использующих объекты этой базы данных.
Какие могут быть решения данной проблемы:
1. Перезапустить MS SQL Server. В этом случае размер базы данных TEMPDB будет установлен по умолчанию.
2. Сжать базу данных TEMPDB. Для этого нужно в Query Analyzer выполнить следующую команду: DBCC SHRINKDATABASE (TEMPDB).
3. Уменьшить размер отдельных файлов. Для этого нужно в Query Analyzer выполнить команды:
DBCC SHRINKFILE (Логическое_Имя_Файла_Данных, Желаемый_Размер_Файла_Данных_В_Мегабайтах)
go
DBCC SHRINKFILE (Логическое_Имя_Файла_Журнала_Транзакций,
Желаемый_Размер_Файла_Журнала_Транзакций_В_Мегабайтах)
go
Пример.
Уменьшение размера файлов базу TEMPDB до 20 мегабайт
USE TempDB
DBCC SHRINKFILE (tempdev, 20)
go
DBCC SHRINKFILE (templog,20)
go
Пункты 2 и з также можно выполнить с помощью Management Studio
4. Переместить базу данных TEMPDB нас диск большего размера. Изменить месторасположение файлов базы данных TEMPDB можно с помощью команды ALTER DATABASE. Для этого нужно в Query Analyzer выполнить следующую последовательность команд и перезапустить сервер СУБД:
USE master
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = tempdev, FILENAME = ‘Новый_Диск:\Новый_Каталог\tempdb.mdf’)
GO
ALTER DATABASE tempdb
MODIFY FILE (NAME = templog, FILENAME = ‘Новый_Диск:\Новый_Каталог\templog.ldf’)
GO
В завершении еще парочка советов по работе с базой TEMPDB:
1. Для оптимизации работы базы данных TEMPDB рекомендуется ее вынесение на отдельный жёсткий диск или RAM-диск и разбиение MDF файла на части (одинакового размера) по числу процессоров (ядер): если процессоров < 8, то количество файлов = количество процессоров; если процессоров >8, то количество файлов для начала 8, а затем добавлять по мере необходимости.
2. При использовании временных таблиц используется кеширование, но это не относится к операциям создания индексов, сортировки, группировки и т.п. Например: создали таблицу, построили индекс (что разумно с точки зрения построения плана), то данная таблица кешироваться не будет. Но если таблица очень маленькая и почти наверняка она SQL-сервером будет сканироваться и создается она очень часто, то возможно имеет смыл операцию создания индекса опустить, в этом случае за счет кеширования таблица будет создаваться быстрее.
А зачем это нужно?
Зачем же может понадобиться сохранять конфигурацию столь необычным способом?
- Вы хотите знать наверняка, когда и какие изменения внесены в рабочую базу и почему рабочая база не совпадает с конфигурацией хранилища (хотя и должна).
- Оперативный визуальный контроль внесенных изменений без запуска конфигуратора.
- Не часто встречающийся случай. Конфигуратор банально занят другим разработчиком, а CF-ник «дозарезу» нужен. (Сказать разработчику «Ей, Вася, а выгрузи-ка мне CF-ник» вы не можете по нескольким причинам: другой сотрудник не сидит рядом, или отошел на часок, или, возможно, он работает в другом часовом поясе, или вы даже не знаете кто он, а может быть он даже совсем из другой организации-подрядчика и вам сложно найти его контакты через менеджеров.)
Возможно, вы скажете, что причины надуманы и в вашей организации все процессы развертывания совершенны или близки к идеалам. А следующие утверждения иллюстрируют это и всегда (т.е. без исключений!) верны:
- Ваши разработчики ведут разработку в хранилище.
- Хотфиксы появляются в рабочей базе только из хранилища.
- Хотфиксы всегда проходят тесты (ах, да, тесты!)
- Никто никогда не вносит изменения в рабочую базу динамически.
- Если рабочая база подключена к хранилищу ее никогда не отключали по ошибке
- Никто никогда не спутал рабочий конфигуратор и не накатил туда что-то не то.
- При сравнении/объединении с новым релизом не бывает ошибки, связанной с неверным выбором файла релиза. Или альтернативное утверждение: новые релизы всегда устанавливаются из файлов поставки.
- Администраторы базы данных никогда не ошибались с восстановлением БД из других баз данных или бекапов.
- Мы все одна команда, у нас нет сотрудников, не разделяющих ценности компании, мы уверены, что никто по неведению или злому умыслу не внесет изменений, которые нарушат работу нашей системы.
Возможно, читая этот список, вы вспомнили несколько неприятных моментов, когда все было на волоске или даже хуже. Наверняка, есть еще варианты, которые вы сами можете добавить в этот перечень.
Увы, нельзя утверждать наверняка, что проблемы, связанные с изменениями конфигурации в будущем нас не коснутся, поэтому в любом случае еще один способ мониторинга изменений продуктивных баз вряд ли повредит.
Использование System Monitor для диагностирования проблем в производительности
Рано или поздно мы все сталкиваемся с проблемой производительности. Поэтому для своевременного обнаружения узких мест в оборудовании необходимо проводить регулярный мониторинг загруженности всех основных аппаратных компонентов системы. К ним в первую очередь относятся:
- Все рабочие сервера кластера 1С:Предприятия
- Сервер СУБД
- Клиентские рабочие станции, работающие под большой нагрузкой
Для каждого из этих компьютеров необходимо настроить постоянный сбор информации по загруженности оборудования.
Для этого можно использовать System Monitor. System Monitor представляет собой стандартное средство для диагностики проблем производительности операционной системы, различных компонент приложений и используемого оборудования. С его помощью можно измерять производительность как локального компьютера, так и других компьютеров в сети. System Monitor является основным инструментом для идентификации узких мест в системе.
Компоненты анализируемой системы интерпретируются как объекты, параметры которых представляются в виде набора счетчиков, при этом для каждого объекта определен свой набор счетчиков. Некоторые приложения в процессе установки расширяют системный набор своими, специфическими объектами и счетчиками, характеризующими производительность этого приложения. Например, при установке Microsoft SQL Server к стандартному набору объектов и счётчиков операционной системы добавляются специфические объекты и счётчики сервера баз данных.
Узкие места, которые могут оказать наибольшее влияние на производительность:
Память
- Недостаток объема оперативной памяти, установленной на компьютере, оказывает негативное влияние на производительность всех компонент 1С:Предприятия 8 и Microsoft SQL Server.
- При увеличении количества пользователей и объема информационной базы требования к этому ресурсу со стороны сервера 1С:Предприятия 8 и Microsoft SQL Server возрастают.
- Нехватка памяти приводит к увеличению интенсивности страничного обмена между файлом подкачки и физической памятью, что существенно снижает производительность системы.
Процессоры
- Недостаточная производительность или количество процессоров может стать узким местом при увеличении нагрузки на систему, связанной с увеличением количества пользователей.
- Эффект от увеличения количества процессоров в многопользовательской системе, как правило, существенно выше, чем от увеличения их быстродействия.
Дисковые операции
- Производительность дисковой подсистемы является одним из решающих факторов, определяющих производительность Microsoft SQL Server.
- На производительность сервера 1С:Предприятия 8 влияния, как правило, не оказывает.
Конфликты блокировок Microsoft SQL Server
- Один из основных факторов снижения производительности в многопользовательском режиме
- Вероятность возникновения конфликтов блокировок можно снизить за счет доработки прикладного решения
Перечень основных объектов и счетчиков, используемых при анализе
проблем с производительностью.
Перед динамическим обновлением, чтобы не рисковать потерять базу данных (крайне редко, но случается) копирует таблицы Config и ConfigSave из вашей базы данных в базу master, добавляя к имени таблицы имя база данных, так как наверняка на вашем SQL-сервере не одна база.
В случае сбоя, копирует таблицы обратно. Копирование таблиц занимает секунды, сохраняет огромное количество времени.
Если база данных была подключена к Хранилищу, то после восстановления, думается, лучше переподключить базу к Хранилищу.
Динамическое обновление больше не страшно! Сохранение таблицы Config перед динамическим обновлением.:
Разбираем на исходники
Для начала надо сохранить данные на диск. Здесь и далее используются powershell-скрипты. Разбираем двоичные данные, они представляют собой файла заголовка и собственно данные (.header, .data):
Для конфигураций на платформе 8.3 скрипт чуть усложняется за счет сбора файлов из нескольких записей.
В итоге получили папку полную запакованных файлов. С ними уже можно работать при помощи магического и всем известного v8unpack.exe (версия Сергея Батанова)
Следующая команда приводит наши файлы к готовому CF-нику:
Первая часть сделана. Мы получили CF-файл.
На выходе мы получаем готовый к помещению во внешний репозиторий комплект исходников:
Делаем git push в заранее подготовленный репозиторий и можем смотреть на то, что изменилось за последнее время. Вот так выглядит типичный коммит после разбора очередного релиза:
Механизм получения исходников рабочей конфигурации из SQL у нас готов.
Результирующий скрипт с измененным gitsync-ом можно поставить на автозапуск обычным планировщиком с некоторым интервалом (например, раз в час). Команда запуска выглядит так:
При наличии изменений в файлах-исходниках git сам «решит», что требуется помещение и сделает его.
В таком виде мы использовали этот механизм для мониторинга изменений рабочих конфигураций. Но есть, что и улучшить!
Продолжаем автоматизацию
А что если, изменения вносятся не раз в час, а чаще? Или, наоборот, раз в день. Фиксированное время запуска будет помехой. Когда же нужно запускать скрипт? Очевидно, когда база была изменена. А как узнать, что база была изменена? На SQL-базу нужно поставить соответствующий SQL-триггер, который будет инициировать выгрузку в какую-то папку или другую базу и уже потом разбираться.
Кстати, триггер позволит точно ответить на вопрос когда изменилась конфигурация с точностью до секунд.
Но если баз для мониторинга много, наверняка, может возникнуть ситуация, когда за полчаса будет запущено много скриптов разбора и сервер просто не справится с нагрузкой. Неплохо было бы сделать очередь разбора рабочих конфигураций, балансируя нагрузку между важными конфигурациями и не очень.
Резервное копирования баз данных MS SQL Server на сетевой диск
При использовании клиент-серверного варианта «1С Предприятие 8» появляется возможность создания резервной копии базы средствами СУБД. Например MS SQL Server позволяет выполнять резервное копирование в то время, когда база данных находится в многопользовательском режиме.
При резервном копирования стандартными средствами Enterprise Manager для MS SQL 2000 и SSMS для MS SQL 2005 (2008R2) невозможно создать устройство резервного копирования, расположенное на сетевом диске, поскольку они видят только локальные, физически подключенные диски. Поэтому выполнение резервного копирования возможно только на локальные диски компьютера, на котором установлен Microsoft SQL Server. Использование этого варианта организации резервного копирования существенно снижает надежность, поскольку в случае выхода компьютера из строя становится недоступной как рабочая база данных, так и резервная копия.
Одним из способов решить эту проблему является создание сетевого устройства резервного копирования с помощью системной процедуры SP_ADDUMPDEVICE. Для этого нужно в Query Analyzer выполнить следующую команду:
USE master
GO
EXEC SP_ADDUMPDEVICE ‘disk’,
‘Логическое_Имя_Сетевого_Устройства_Резервного_Копирования’,
‘\\Имя_Компьютера\Имя_Каталога\Имя_Файла.bak’
Следующий пример иллюстрирует добавление удаленного дискового устройства резервного копирования с именем ‘AdvWorksData’ и создание резервной копии базы ‘TestData’. Необходимым условием использования сетевого устройства резервного копирования является запуск Microsoft SQL Server с использованием доменной учетной записи.
USE master
GO
EXEC sp_addumpdevice ‘disk’, ‘AdvWorksData’,
‘\\server-sql1\sqlbackup\Test5.bak’;
GO
BACKUP DATABASE TestData
TO AdvWorksData
WITH FORMAT;
GO
Как хранится конфигурация в SQL
В базе данных есть как минимум две таблицы, отвечающие за хранение конфигурации: [Config], [ConfigSave]. По факту их может быть больше (рисунок из БД на MSSQL)
[Config]- конфигурация БД
[ConfigSave] – сохраненная конфигурация
[ConfigCASSave] – сохраненное системное хранилище конфигураций расширений
[ConfigCAS] –системное хранилище конфигураций расширений
Содержимое таблицы Config
Что же внутри Config? Выбрав первые несколько строк и взглянув на названия столбцов убеждаемся, что перед нами двоичные данные:
В процессе исследования мы выяснили, что от версии к версии платформы формат данной таблицы менялся. Для платформы 8.2 таблица имеет следующие столбцы
В платформе 8.3 добавился столбец PartNo, который позволил размещать данные неограниченно больших размеров
Специальные предложения
Не очень понятно как воспользоваться обработкой для восстановления, если база валится и при запуске в пользовательском режиме.
=============================
Кажется дошло, её можно запустить из под любой другой живой базы.
Как мне кажется минус в том, что требуется делать бэкапы вручную. По любому именно при падении базы и поймешь, что забыл об этом.
Резервное копирование, все таки должно быть автоматическим. И желательно хранить несколько последних копий, а не только крайнюю.
У меня каждые 20 минут на SQL-сервере выполняется задание, которое копирует конфу в специальную базу.
Ночью эта база очищается, чтобы не разрасталась:
В случае неудачного демонического обновления база восстанавливается за 30 секунд:
Таким образом получается автоматическое резервное копирование таблицы с конфигурацией каждые 20 минут. Больше 20 минут работы не потеряешь.
Обработка - задумка хорошая, только её бы расширить немного, чтобы умела настраивать на SQL-сервере автоматическое резервное копирование.
Grigoripal; megatrend; den1049; cleaner_it; корум; dour-dead; KroVladS; kondrat230386; + 8 – Ответить
Читайте также: