1c mdf что это
Где должны находиться файлы базы данных sql *mdf и *.ldf?
У меня они находятся в каталоге базы, *mdf -3Гб, *ldf - 2 Гб. Хорошо ли так делать? Может ли из-за этого быть замедление работы? Это сделали до меня.
И еще вопрос. Есть заказ на переход снова на dbf версию. В связи с тем, что многие операции под dbf версию работают быстрее в разы. Про индексацию базы после сбоев предупредила. Чего еще ожидать? Что делать с sql файлами в каталоге базы?
"Земную жизнь пройдя до половины. " как сказал поэт.
Тут уже немного за половину: после 1 гигабайта начнутся проблемы по чтению, придется лепить приблуду kernel33.dll
Что касается SQL-баз - "умные люди" советуют держать лог-файл журнала (*.ldf) на отдельном диске, сам файл базы на другом - это также и 7-чных баз данных касается. Что касается расположения файлов - лучше располагать поближе к "корню диска" и не использовать кириллических символов в названии папок.
Где должны находиться файлы базы данных sql *mdf и *.ldf? - согласна с ответом 4.
Есть заказ на переход снова на dbf версию. В связи с тем, что многие операции под dbf версию работают быстрее в разы
Это что за функции такие, может их не так много и имеет смысл адаптировать под SQL
(5) Я даже не хочу об этом думать. Там почти самописная конфигурация, очень сложная и запутанная в смысле количества документов и процессов.
Базу будем резать однозначно, но вот хотят попробовать перейти на скл, что может под ним будет комфортнее работать.
Может ли дать заметный эффект в скорости если просто скл файлы перенести в другое место, как написано в (4)?
М-да. Вы для начала хоть с направлением определитесь однозначно, а то собираетесь переходить одновременно в противоположных направлениях.
(7)Сорри, это описка. На дбф хотят перейти.
На тестовом сервере в дбф версии многие отчеты работают быстрее. И загрузка самой базы в разы быстрее. Да и вообще тестовый сервер работает быстрее. Может потому что на нем никто не работает, а может, потому что у меня файлы скл сервера лежат не в каталоге базы. ?
Нет. Без модернизации конфигурации заметного прироста не будет.
Действительно, при использовании 1cv77 и MS SQL есть ряд проблем с выполнением регламентных операций
однако при больших объемах данных SQL дает значительный прирост производительности в обычной работе пользователей (операции чтения/записи).
Тут надо рассматривать ситуацию исходя их количества одновременных операций ввода данных. Объема отчетных данных.
Анализа используемых алгоритмов и оптимизации.
Проблемы с выполнением регламентных операция можно обойти следующим образом:
1. Выгрузка в ДБФ
2. Выполнение регламентных операций в монопольном режиме (перепроведение и т.д.)
3. Загрузка в SQL
Особенной разницы в расположении конфигурационных файлов нет. Объем данных конфигурации (md) небольшой.
По поводу файлов.
По "феншую" mdf и ldf на разных физических дисках. НО если файлы лежат на том же компьютере где установлен SQL никакой разницы вы не заметите.
По хорошему - методами ускорения будет:
- Перевод на прямые запросы
- Использование УРИБ для разделения ввода данных
Иногда приходится столкнуться с ситуацией, когда плоды многолетней работы, находящиеся в 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 = ' '
Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).
Из QA выполняем:
USE ' '
GO
sp_dboption ' ', 'single_user', 'true'
go
DBCC CHECKDB(' ', REPAIR_ALLOW_DATA_LOSS)
go
Если все в порядке, то:
sp_dboption ' ', '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 :).
Файл MDF — это основной файл хранилища SQL Server, в котором хранятся все физические данные. SQL Server также использует некоторые другие файлы LDF (файл журнала транзакций), NDF (файл вторичного хранилища). Теперь поговорим о том, как восстановить базу данных из файла MDF без файла LDF. Есть некоторые ситуации, когда нам нужно восстановить данные из файла MDF, например, если мы переносим SQL Server, если мы отказываемся использовать старые серверы SQL, и т. Д. В таких ситуациях мы должны прикрепить файл MDF в SQL Server.
Теперь вопрос в том, как прикрепить файл MDF к SQL серверу? — Есть два способа выполнить эту задачу, в этом разделе мы рассмотрим оба метода восстановления базы данных из файла MDF.
Восстановление файла MDF в SQL Server без LDF с помощью SQL Server Managment Studio
Выполните все указанные шаги, чтобы успешно прикрепить файл .mdf в SQL Server.
SQL Server создаст файл LDF при прикреплении файла MDF.
Теперь вам нужно проверить базу данных в папке базы данных.
Вывод
ИНСТРУКЦИЯ 1С 8 → перейти в меню [СТАТЬИ И ИНСТРУКЦИИ]
*.cf - файл содержит только конфигурацию(код и структура) без пользовательских данных. Создаётся из конфигуратора 1С 8.х: «Конфигурация -> Сохранить конфигурацию в файл» или «Конфигурация -> Поставка конфигурации -> Создать файл поставки и обновление конфигурации -> признак «Создать файл поставки»».
*.cfu - файл содержит только обновление конфигурации. Например файл 1cv8.cfu. Создать конфигурацию из этого файла невозможно, так как он содержит в себе только отличия новой конфигурации от предыдущей. Создаётся из конфигуратора 1С 8.х: «Конфигурация -> Поставка конфигурации -> Создать файл поставки и обновление конфигурации -> признак «Создать файл обновления конфигурации»».
*.cfe - файл-расширение, предназначенный для доработки конфигурации без её изменения. При использовании расширений 1С (*.cfe) - доработанная конфигурация может полноценно обновляться и с поддержки не снимается.
*.dt - файл содержит конфигурацию вместе с пользовательской базой данных. Это специализированный формат архива 1С 8. Создаётся из конфигуратора 1С 8.х: «Администрирование -> Выгрузить информационную базу».
*.epf (*.erf) – файл внешней обработки (отчёта). Любую обработку (отчёт) из конфигурации можно сохранить внешней. Создаётся из конфигуратора 1С 8.х: «Конфигурация -> Открыть конфигурацию -> становимся на нужную обработку (отчёт) -> выделяем правой кнопкой мыши -> Сохранить как внешнюю обработку, отчёт…». Открыть эти файлы в режиме 1С Предприятия 8.3 можно по инструкции .
*.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С.
. 1Cv8.pfl - параметры для компьютера/информационной базы/пользователя (в т.ч. пароли пользователей, настройки текстового редактора, настройки глобального поиска по текстам конфигурации, список переменных для быстрого просмотра в отладчике ). Настройки модулей в конфигураторе хранятся в файле 1Cv8.pfl . Этот файл обычно находится в каталоге настроек пользователя C:\Users\<ИмяПользователя>\AppData\Roaming\1C\1cv8.
ИмяПользователя>
. 1Cv8cmn.pfl - общие параметры для компьютера, используемые в 1С:Предприятии/Конфигураторе (в т.ч. цвета редактора модулей в конфигураторе )
*.ini - стандартное расширение файла настроек в разных программах. В 1С 8 используется файл nethasp.ini для хранения настроек аппаратного ключа.
Есть 1С-сервер, есть MySQl-сервере
Работают в связке. 10 баз.
1 база перестала загружаться ни в 1С предприятие, ни в конфигуратор. Проходит аутентификация, затем зависает и отключается по таймауту. Проверка SQl-базы на ошибки ничего не дало, ошибок нет.
Зависание с 1 базой происходит под любым пользователем и даже если сделав бекап поставить её на другую базу, происходит тоже.
Подскажите, как решить данную проблему.
Зараннее, спасибо.
службы сервера 1с предприятия, может не достаточно будет для перегрузки, желательно перегрузить сервер, если это возможно.
1.) ребут сервера 1С и SQL
2.) скопировать базы с SQL или снять бекап, и поднять заново в новой SQl базе, если есть другой сервак на нем, после этого подрубить как новую базу к серверу 1С Предприятия
3.) взять самый свежий архив и плакать, у нормального админа должен делаться каждую ночь
4.) искать умельцев, в прошлой конторе нашли какого умельца, который восстановил поврежденные 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 = ''
Перезапускаем SQL Server. В принципе база должна быть видна (в emergency mode).
Из QA выполняем:
USE ''
GO
sp_dboption '', 'single_user', 'true'
go
DBCC CHECKDB('', REPAIR_ALLOW_DATA_LOSS)
go
Если все в порядке, то:
sp_dboption '', '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 :).
Как восстановить файл MDF в SQL Server?
Здесь мы опишем два метода для подключения или восстановления базы данных MDF в SQL Server:
- Используя SQL Server Management Studio
- Используя T-SQL
Прикрепите или восстановите файл MDF в SQL Server с помощью сценария T-SQL
Чтобы прикрепить файл MDF в SQL Server с помощью T-SQL, вы выполнили следующий сценарий T-SQL —
CREATE DATABASE testdatabase ON
(FILENAME = 'C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLDATAtestdatabase.mdf')
FOR ATTACH_REBUILD_LOG
GO
Используя вышеуказанные решения, вы можете легко прикрепить файл MDF в SQL Server, но иногда из-за некоторых ошибок пользователь не может восстановить MDF в SQL Server. Некоторые ошибки обсуждаются ниже —
Учитывайте запросы пользователя —
2 — «Я использовал сценарий T-SQL для восстановления базы данных из файла MDF на сервере SQL, но когда я выполняю команду, сервер SQL отображает ошибку 5172 (заголовок файла mdf не является допустимым заголовком файла базы данных. Неправильное свойство размера файла) «Так как мне прикрепить .mdf в SQL Server».
Решение — Эта ошибка возникает, когда информация заголовка файла MDF повреждена, и база данных становится недоступной, поэтому для решения этих проблем вам необходимо восстановить файл MDF. Чтобы удалить ошибку 5172, вам необходимо использовать Recovery Tool.
После восстановления файла MDF с помощью программного обеспечения вы можете подключить MDF в SQL Server. Это программное обеспечение позволяет пользователю восстанавливать удаленные объекты базы данных SQL, а также удаленные записи таблицы SQL. Пользователь может легко восстановить как первичные, так и вторичные файлы с помощью этого программного обеспечения. Кроме того, это программное обеспечение поддерживает Microsoft SQL Server 2019/2017/2016/2014/2012 и более раннюю версию.
Выполните указанные ниже шаги, чтобы восстановить базу данных только из файла MDF.
2. Щелкните на Открыть и просмотреть файл MDF из вашей системы. Далее Выберите Версия SQL Server и Расширенный режим сканирования. (Пользователь также может проверить pпросмотреть удаленный объектs вариант.)
3. Предварительный просмотр объектов базы данных SQL SQL Стол, хранимая процедура, функции, взгляды, индексы и т.д. (Это программное обеспечение показывает удаленные записи таблицы SQL красным цветом.)
4. Щелкните на Кнопка экспорта и заполнить требуемые детали для восстановления базы данных из файла MDF.
Читайте также: