1c mdf что это
Обновлено: 04.07.2024
Системная база данных tempdb активно используется базами данных 1С:Предприятие 8.3 для хранения временных таблиц, промежуточных расчетов, версий строк при использовании режима версионирования и прочих временных данных. То есть для задач 1С:Предприятие интенсивность обращений к базе tempdb находится на высоком уровне, поэтому нужно подумать о размещении этой базы на выделенном быстром дисковом устройстве.Подходящими кандидатами на роль диска под tempdb будут выделенные быстрые дисковые RAID-группы уровня RAID1, выделенные накопители SSD или вообще RAM-диск.
В большинстве сценариев рекомендуется разбивать базу tempdb на несколько файлов данных с одинаковом начальным размером (Initial size) от 1GB и больше и увеличенным показателем прироста, например, в 512MB.
При определении количества файлов можно руководствоваться принципом: количество процессорных ядер = количество файлов данных tempdb, но при этом стоит помнить о том, что использование более 8 файлов (даже при количестве ядер более 8) далеко не всегда может иметь положительный эффект. Возможно по этой причине в инсталляторе SQL Server 2016 даже при большом количестве процессорных ядер по умолчанию предлагается 8 файлов tempdb.
Относительно 1С:Предприятие 8.3 можно встретить рекомендацию о том, что общий размер Initial size для всех файлов БД tempdb должен быть от 25% до 40% от размера рабочей БД 1С:Предприятие.
Саму процедуру переноса файлов tempdb на другой диск мы рассматривали ранее в заметке SQL Server 2008 - Перенос файлов БД tempdb на отдельный диск. Эта процедура может использоваться и на новых версиях СУБД, вплоть до SQL Server 2016.
Рассмотрим частный пример распределения файлов tempdb по разным дисковым томам, имеющим разные показатели производительности. В нашем примере имеется два тома NTFS:
R: менее производительный, но больший по объёму дискЧасть файлов данных в файловой группе tempdb, а также файл лога размещены на быстром диске. Файлы данных, расположенные на быстром диске установлены фиксированного размера без возможности авторасширения (исключением здесь является только файл лога). Другая часть файлов данных размещена на менее производительном дисковом томе, но при этом для файлов включено авторасширение.
В результате такой конфигурации, файлы tempdb в нашем случае будут распределены по дисковым томам следующим образом: 4 файла данных и лог tempdb окажутся на быстром томе T:
Другие 4 файла данных tempdb окажутся на менее производительном дисковом томе R:
В случае если в ходе работы экземпляра SQL Server потребуется дополнительное расширение ёмкости tempdb, то файлы начнут прирастать на меньшем по производительности, но большем по объёму дисковом томе R.
К операциям, которые могут вызвать бурный рост tempdb при работе БД 1С:Предприятие 8.3 можно отнести, например, регламентные процедуры с конфигурацией 1С, выполняемые из конфигуратора (обновление конфигурации, перерасчёт итогов и т.п.). Кроме того, активный рост tempdb может вызвать построение в 1С каких-то тяжёлых отчётов с большим количеством данных и за длительные периоды при условии, что код отчётов неоптимален или вообще содержит ошибки. В практической среде при размере БД около 170GB во время построения подобного отчёта мы наблюдали рост tempdb до 350GB. Учитывая эти моменты стоит подумать о полной изоляции файлов tempdb на выделенных дисковых томах, чтобы их возможный бурный рост не смог нарушить функционирования других БД SQL Server.
Используемый в нашем примере дисковый том T: представляет собой RAM-диск, подключенный к серверу SQL Server по методике, описанной в отдельной статье нашего Блога : Организуем RAM-диск для кластера Windows Server с помощью Linux-IO FC Target
Работа с новым форматом файловой базы данных, начиная с "1С:Предприятие" 8.3.8
Начиная с версии платформы "1С:Предприятие" 8.3.8 появилась поддержка нового формата файловых баз данных (включая работу в режиме совместимости с предыдущими версиями). Новый формат файловых баз данных предназначен для ускорения процесса открытия и работы с информационной базой, поэтому, начиная с версии платформы 8.3.9, новый формат используется по умолчанию при создании новых файловых баз данных.
В новом формате (версии " 8.3.8" ) появились следующие возможности:
- Уменьшен размер и оптимизирована структура заголовка с метаинформацией в файле 1Cv8.1CD . Это позволяет существенно снизить число операций чтения файла при открытии базы данных и, тем самым, заметно ускорить время старта и начала работы программы.
- Теперь можно настраивать размер внутренней страницы файла данных. Это размер порции данных, в которых хранится информация и которыми обменивается программа с файловой системой. Предыдущий формат файловой базы данных (версии " 8.2.14" ) поддерживал единственный размер внутренней страницы файла – 4Кб . Новый формат по умолчанию использует размер страницы 8Кб , но позволяет его менять в диапазоне от 4Кб до 64Кб .
Наибольший эффект от использования нового формата файловых баз данных ожидается в следующих сценариях:
- "холодный" запуск программы,
- работа с файлами базы данных по локальной сети,
- работа с сильно фрагментированной базой данных,
- использование дисковых подсистем с невысокой производительностью.
При создании новых файловых баз данных рекомендуется использовать настройки формата базы по умолчанию (версия формата " 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 и выше.
Подробно про использование утилиты CNVDBFL.EXE можно почитать в документации по администрированию "1С:Предприятие", или в документации: "Утилита преобразования cnvdbfl". Также информация о возможностях и командах утилиты CNVDBFL.EXE выводится при её запуске без параметров, или с ключом " -h ".
Если Вы хотите проверить параметры Вашей файловой базы данных, используйте следующий вызов утилиты (указав в команде правильный путь к Вашей базе данных):
При этом утилита выведет версию формата файла и размер страницы.
Версия формата " 8.3.8 " указывает на то, что используется новый формат файла. Версия формата " 8.2.14 " означает, что формат – старый, и имеет смысл выполнить конвертацию базы данных в новый формат.
Размер страницы может принимать одно из значений: 4096 , 8192 , 16384 , 32768 , или 65536 байт. Для старой версии формата файла используется размер страницы 4096 байтов ( 4Кб ), для новой версии по умолчанию установлен размер в 8192 байта ( 8Кб ).
Для конвертации файловой базы данных Вы можете использовать следующую команду:
где 16k замените на нужный размер страницы файла ( 4k , 8k , 16k , 32k , или 64k ) и укажите правильный путь к Вашей базе данных.
ВНИМАНИЕ!
Напоминаем, что чтобы избежать риска потери Ваших данных, всегда имейте свежую резервную копию Вашей файловой базы данных перед выполнением операции конвертации файлов.
Иногда приходится столкнуться с ситуацией, когда плоды многолетней работы, находящиеся в SQL-базе данных оказываются под угрозой. Эта статья о том, как не допустить потерю данных, а в случае, если это всё-таки произошло, как восстановить данные из того, что осталось от некогда нормальной базы.
Итак, приступим. Ситуация следующая: имеется сервер с запущенной на нем 1С+SQL. Во время работы SQL базы рубанули питание. Результат плачевный: база находится в состоянии suspect, и когда 1с пытается к ней зацепиться, выдается ошибка, что мол соединиться невозможно т.к. база помечена suspect for recovery. Этот режим в принципе означает, что MSSQL Server попытается восстановить базу своими средствами. Я не стал ни чего трогать и оставил все на ночь, в надежде, что к утру база восстановится, но и утром было то же самое, и к базе, стало быть, ни как не подобраться. Backup по закону подлости имеется, но он трехдневной давности, плюс имеется куча документов которые проводятся лишь по базе, а по бумажным документам их нет, т.е. возможности вручную восстановить документы нет. Потратив кучу сил, и нервов, (которые, как известно не восстанавливаются :)), я пришел к следующей последовательности действий, необходимых для восстановления базы.
1) Основной принцип поначалу – не навреди. Глушим SQL server и копируем *.mdf и *.ldf файлы от базы в сторону.
2) В принципе, бывает, что состояние suspect возникает из-за того, что поменялись пути к файлам с базой (например, добавился новый диск в системе, который потом убрали, переименовали папку с базой и т.д.). Затем, конечно же, пути восстановили, но база все равно остается помеченной как suspect. Вот что мы делаем:
3) Запускаем SQL Server.
4) Пробуем подключить базу через Enterprise Manager:
Правой кнопкой по Databases, в появившемся меню выбираем All tasks->Attach database, затем в появившемся диалогов окне выбираем файл с базой (*.mdf) и устанавливаем необходимые параметры.
5) или через Query Analyser примерно такой командой:
a. sp_attach_db @dbname = 'DemoXMB',
b. @filename1 = 'E:\Data\DemoXMB_Data.MDF',
c. @filename2 = 'E:\Data\DemoXMB_Log.LDF'
6) Пути к базе, естественно нужно заменить на свои. Если база подключилась, то, можно сказать, отделались легким испугом, если же нет, то продолжим.
7) Если log-файл не поврежден (*.ldf), а поврежден *.mdf (например, при подключении базы sql ругается на ошибки в mdf-файле), и режим сохранения backup'а стоит full, то восстанавливаем базу без восстановления лога транзакций, почти 100%, что все мучения на этом могут закончиться.
8) Если же наоборот, поврежден ldf-файл, но остался *.mdf файл, при подключении база ругается на отсутствие/повреждение лога транзакций. В этом случае можно воспользоваться ХП "sp_attach_single_file_db"
Например:
use master
EXEC sp_attach_single_file_db @dbname = 'DemoXMB',
@physname = 'c:\mssql7\data\DemoXMB_Dat.mdf'
При выполнении этих команд, создастся файл DemoXMB_Log.ldf в том же каталоге где и база, размером 1MB и авторасширением.
Если есть *.MDF и *.LDF-файлы, или данные хранятся более чем в одном физическом файле (общее количество подключаемых физических файлов не должно превышать 16-ти), то следует использовать ХП "sp_attach_db"
Например:
use master
EXEC sp_attach_db @dbname = 'DemoXMB',
@filename1 = 'c:\mssql7\data\DemoXMB_Dat.mdf',
@filename1 = 'c:\mssql7\data\DemoXMB_Log.ldf'
Для подключения более 16-ти физических файлов к БД следует использовать команду:
CREATE DATABASE FOR ATTACH
Однако если ничего не помогло, оказались поврежденными оба файла и база всё еще в состоянии suspect, то можно попробовать сбросить состояние базы следующей последовательностью: (перед использованием этой ХП необходимо разрешить прямое изменение системных таблиц)
use master
go
Разрешаем прямое изменение системных таблиц:
sp_configure 'allow updates',1
go
reconfigure with override
go
Для сброса признака suspect выполняем в БД master ХП sp_resetstatus:
sp_resetstatus 'DataBaseName'
go
А теперь запретим прямое изменение системных таблиц:
sp_configure 'allow updates',0
go
reconfigure with override
go
В принципе, когда я выполнил все эти шаги, статус suspect сбросился, НО! при попытке выполнить какие-либо действия SQL начинала ругаться, что база все еще в состоянии suspect. И тогда я сделал так:
Из QA выполняем скрипт:
Use master
go
sp_configure 'allow updates', 1
reconfigure with override
go
Там же выполняем :
update sysdatabases set status= 32768 where name = '<db_name>'
Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).
Из QA выполняем:
USE '<db_name>'
GO
sp_dboption '<db_name>', 'single_user', 'true'
go
DBCC CHECKDB('<db_name>', REPAIR_ALLOW_DATA_LOSS)
go
Если все в порядке, то:
sp_dboption '<db_name>', 'single_user', 'false'
go
Use master
go
sp_configure 'allow updates', 0
go
После этого стало возможно просмотреть таблицы базы из SQL, а вот работать с ней было невозможно. Теперь необходимо при помощи Data Transformation Services экспортировать данные в новую базу. После этого проводим восстановление/тестирование базы средствами 1С. Внимание! Многие не обращают внимания на этот очень важный пункт. В результате, вы можете в один прекрасный момент обнаружить, что база восстановлена, мягко говоря, не совсем корректно. Т.е. в документе вместо номенклатуры будет стоять нечто вроде 10122/<Объект не найден>, это та проблема, которая возникла у меня, вариантов же может быть уйма. Поэтому лучше потерять время, но проверить базу средствами 1С.
Но! Здесь следует сделать паузу. Статья не была бы полной, если бы я не описал методы для предотвращения подобных проблем. Итак, самый простой и надежный способ: архивация, архивация и еще раз архивация. В Enterprise Manager заходим в меню Tools->Wizards->Management->Backup Wizard и настраиваем все необходимые параметры. В результате, у меня полный сброс SQL базы на диск происходит ночью, а затем каждые 15 минут backup изменений, внесенных в базу. В принципе, если бы у меня был такой backup, я бы за пару минут сделал откат назад, и продолжил бы попивать Coca-Cola :).
*.cf - файл содержит только конфигурацию(код и структура) без пользовательских данных. Создаётся из конфигуратора 1С 8.х: «Конфигурация -> Сохранить конфигурацию в файл» или «Конфигурация -> Поставка конфигурации -> Создать файл поставки и обновление конфигурации -> признак «Создать файл поставки»».
*.cfu - файл содержит только обновление конфигурации. Например файл 1cv8.cfu. Создать конфигурацию из этого файла невозможно, так как он содержит в себе только отличия новой конфигурации от предыдущей. Создаётся из конфигуратора 1С 8.х: «Конфигурация -> Поставка конфигурации -> Создать файл поставки и обновление конфигурации -> признак «Создать файл обновления конфигурации»».
*.cfe - файл-расширение, предназначенный для доработки конфигурации без её изменения. При использовании расширений 1С (*.cfe) - доработанная конфигурация может полноценно обновляться и с поддержки не снимается.
*.dt - файл содержит конфигурацию вместе с пользовательской базой данных. Это специализированный формат архива 1С 8. Создаётся из конфигуратора 1С 8.х: «Администрирование -> Выгрузить информационную базу».
*.epf (*.erf) – файл внешней обработки (отчёта). Любую обработку (отчёт) из конфигурации можно сохранить внешней. Создаётся из конфигуратора 1С 8.х: «Конфигурация -> Открыть конфигурацию -> становимся на нужную обработку (отчёт) -> выделяем правой кнопкой мыши -> Сохранить как внешнюю обработку, отчёт…».
*.1cd – файл полноценной базы данных. Представление имени по умолчанию: 1Cv8.1CD. Включает в себя конфигурацию, базу данных, пользовательские настройки. Открывается платформой 1С 8.x. Создаётся для разработки новой конфигурации автоматически по кнопке «Добавить» при выборе пункта «Создание новой информационной базы».
*.log, *.lgf, *.lgp, *.elf - лог файлы, которые собирают информацию (регистрируют данные) в 1С 8.0 8.1, 8.2, 8.3. Например, файл 1Cv8.lgf (в каталоге 1Cv8Log ) содержит информацию журнала регистрации.
*. cdn - файл с таким расширением ( 1Cv8.cdn) служит для ручной или автоматической блокировки базы данных 1С Предприятия восьмой версии .
*.mxl - файлы печатных форм используются, в том числе и в 1С. Являются как печатными формами документов, справочников, отчётов, так и различными накопителями данных для различных классификаторов. Открывается через Конфигуратор или в режиме 1С:Предприятии через «файл -> открыть». Создаётся точно так же: в режиме Конфигуратор или в 1С:Предприятии через «файл -> новый». Так же файлы с такими расширениями могут служить правилами переноса, например, из 1С 7.7 в 8.2 ( acc77_82.xml и вспомогательная обработка exp77_82.ert) - находятся они обычно в папке ExtForms.
*.efd - это архивный файл 1С, используется для установки конфигурации. Содержит или конфигурацию 1с или обновление к ней. Запускается с помощью вспомогательного исполняющего файла setup.exe (должен находиться в одной папке).
*.mft – вспомогательный файл для создания конфигурации из шаблона. Содержит информацию о конфигурации, описание, пути, название. Используется непосредственно самой платформой при создании информационной базы 1С из шаблона.
*.grs - файлы графических схем в специализированном формате 1С. Открывается через Конфигуратор или в режиме 1С:Предприятии через «файл -> открыть». Создаётся точно так же: в режиме Конфигуратор или в 1С:Предприятии через «файл -> новый».
*.geo - файлы географических схем в специализированном формате 1С. Открывается через Конфигуратор или в режиме 1С:Предприятии через «файл -> открыть». Создаётся точно так же: в режиме Конфигуратор или в 1С:Предприятии через «файл -> новый».
*.st - файлы шаблонов текстов. Используются в основном 1С разработчиками.
*.pff - файл с сохраненными замерами производительности. Используются системными администраторами и специалистами 1С.
*.pfl - файл содержащий различные параметры для старта и работы с 1С:
. 1Cv8.pfl - параметры для компьютера/информационной базы/пользователя (в т.ч. пароли пользователей, настройки текстового редактора, настройки глобального поиска по текстам конфигурации, список переменных для быстрого просмотра в отладчике ). Настройки модулей в конфигураторе хранятся в файле 1Cv8.pfl . Этот файл обычно находится в каталоге настроек пользователя C:\Users\<ИмяПользователя>\AppData\Roaming\1C\1cv8.
За несколько лет сначала вынужденного, а потом и вполне занимательного администрирования 1С у меня накопился набор решений под большинство особенностей продукта. Предлагаю отложить в сторону высокие материи про кластеры и тюнинг SQL, и перетряхнуть запасы скриптов и механизмов, которые облегчают жизнь с 1С.
Будут как простые инструменты создания новых пользователей и мониторинга "все ли вышли из базы", так и более изощренные интерфейсы проверки целостности базы и ее перемещения.
Как у большинства сложных приложений, у 1С через некоторое время работы вылезают странные ошибки, и возникает порой необъяснимое поведение. Специальные люди по 1С советуют в таких случаях почистить кэш.
Если запустить 1С с параметром /ClearCache, то будут очищены только клиент-серверные запросы. Локальные метаданные останутся и их нужно удалять отдельно на уровне файлов и папок. Эти данные хранятся в профиле пользователя, в папках с длинными названиями из GUID баз данных. Если баз на сервере немного, то такой кэш нетрудно удалить руками. Но если БД исчисляется десятками, то чистке вручную вы не обрадуетесь.
В подобных ситуациях выручит скрипт на Powershell, который запускается каждый раз при выходе пользователя из системы:
И никаких связанных со старым кэшем проблем.
Для исправления испорченной файловой базы в поставку 1С входит утилита chdbfl.exe, которая просто считывает содержимое базы во временный файл. Если какие-то данные считать не может — пропускает. При этом у нее нет ключей запуска для автоматизации, и проверку приходится запускать вручную.
Вообще, правильнее запускать проверку БД конфигуратором, но этот процесс проходит значительно дольше. Если же использовать только проверку физической целостности средствами chdbfl.exe, то не забывайте делать резервную копию из-за возможной потери данных.
Для баз 8.1 Андрей Скляров создал хороший инструмент Check1CD, с двумя параметрами запуска: "исправлять найденные ошибки" и “путь к базе”.
Но в Check1CD не хватает двух вещей:
Раз есть "хотелка" и немного свободного времени, то почему бы не попробовать решить вопрос самостоятельно?
Доработать код для передачи параметров через ключи командной строки — дело техники.
С выходом 1С 8.2 возникла проблема — путь к chdbfl менялся с установкой нового релиза. Что ж, дополним скрипт:
Надо сказать, недавно был опубликован исходный код Check1CD. Да, тоже на AutoIT.
Аналогичный механизм можно применять и для автоматического запуска различных регламентных механизмов, где нужно запускать 1С и ждать завершения операции.
При различных регламентных операциях с 1С (ночное обновление конфигурации или бэкап в .dt) важно обеспечить отсутствие подключенных к ней пользователей. Можно конечно запускать 1С: Предприятие с ключом /C ЗавершитьРаботуПользователей, но это не всегда удобно, да и хочется же потом написать личное письмо с рекомендациями по устранению склероза.
Можно использовать штатную возможность подключения к 1С через COMConnector и скрипт на AutoIT. Код написан под 1С 8.1 и позволяет выкинуть пользователей из базы с записью в журнал.
Но операцию иногда нужно проворачивать по просьбе самого пользователя, который запустил "тяжелый" отчет и повесил 1С. Если не хотите решать эти вопросы самостоятельно, то просто выведите любителям “тяжелых” отчётов ярлык на скомпилированный скрипт:
Еще COMConnector помогает проверить наличие обновлений конфигурации, получить какую-то информацию из базы, и автоматизировать заведение пользователей в 1С.
На мой взгляд, создавать новых пользователей 1С должен системный администратор, а не программист 1С. Но последнему нужно сделать процесс максимально простым. Чтобы администратору не приходилось "заглядывать" в каждую базу отдельно, можно использовать еще один скрипт.
Для примера приведу функцию создания пользователей в типовой Бухгалтерии 2.0.
Юрлиц развелось слишком много — нужно разбивать на столбцы.
Занятно, но после смены нескольких поколений администраторов в одной компании из далекого прошлого новенькие уже не знали как создать пользователя вручную.
Если нужно перенести базу 1С: Предприятия вместе с ее данными в SQL на другой сервер, то делать это вручную целесообразно только для 1-2 БД.
При большем их числе рутина станет утомительной - лучше воспользоваться скриптом.
Список баз для миграции можно брать и из файла, а лог выводить в текстовый файл. Аналогичным образом можно конвертировать несколько десятков баз из файловых в SQL простой выгрузкой-загрузкой в .dt
Конечно, это далеко не все, что можно автоматизировать в связке с 1С. Но разного рода обмены, получение real-time информации из 1С в других приложениях и прочие сценарии не попали в этот обзор из-за узкой направленности и специфики.
Наверняка у вас тоже есть свой набор "ноу хау" для администрирования 1С — будет здорово если поделитесь с коллегами в комментариях.
Скрипты и ноу-хау предоставлены avelor, за что ему огромное спасибо!
Читайте также: