Логический файл не является частью базы данных
Собственно довольно нехитрый инструмент, позволяющий быстро восстановить, свежий или на определенную дату, бэкап, на любую из тестовых баз. Также программка может перед восстановлением выгрузить конфигурацию БД в *.cf.
И еще немного информации по настройкам. Некоторые настройки я не стал выводить в интерфейс так как у нас на предприятии они никогда не меняются. Так как те базы что чаще всего приходится восстанавливать имеют одни и те же параметры. Но если это необходимо - вывести в интерфейс большого труда не составит. Как будет возможность постараюсь доработать эти нюансы.
Собственно настройки хранятся в файле settings.xml
Разберем по порядку.
Параметры: User, Password, MainInstance, DefaultDB, ConfigPath, NeedSaveConfig, BackUpPath, DataSourcePath выведены в интерфейс и не требуют правки через XML.
А вот остальные сейчас расскажу для чего нужны.
EveryDayNewLogFile - Может иметь значение false или true. Обозначает необходимость каждый день писать логи в новый лог-файл. Если стоит истина, тогда каждый новый день создается новый лог файл. Имя файла содержит дату. Если нет, то всегда пишется в один файл.
LogMainFileName - Имя файла-лога, в который всегда будут писаться логи. Используется в том случае если предыдущий параметр равен false.
ComUser - Имя пользователя в ИС 1С. Тот пользователь под которым можно подключиться через COM соединение.
ComPass - Пользователь для пользователя который был указан в предыдущем параметре.
LogicalDBName - Логическое имя файла базы данных
LogicalDBLogName - Логическое имя файла лога базы данных
Два последних параметра можно посмотреть через MS SQL Managments Studio, нажав правой кнопкой на базе данных, и выбрав пункт "Свойства". Во вкладке "Файлы", видны эти параметры.
Специальные предложения
Да, и ещё довод в пользу более тесной интеграции с 1С - это ещё и считывание данных о подключении к СУБД из самой инфраструктуры 1С т.е. из кластера - чтобы надо было лишь выбрать ИБ откуда и ИБ куда (причём из списка, в котором сначала указаны кластеры, там же могут быть уже указаны и имеющиеся бэкапы (ну это отдельно настраивается для каждой ИБ и/или общим каталогом))! Вот тогда да - это было бы действительно "быстро" - но лишь по части GUI-взаимодействия, а не по части техники работы с самим бэкапом!
Да и зачем программе путь к файлам БД? Тем более, что это не обязан быть один каталог!
(1)Безусловно Ваши доводы имеют основание, описанная Вами обработка была бы интересна как в написании так и в рассмотрении, возьму на заметку идею.
Про путь к файлам БД, исключительно потому что я в своем скрипте (шаблонном) использовал эти пути. Тот самый скрипт был взят за основу программы.
Подскажи, в чем именно ошибки при восстановлении ?
2019-02-14 01:11 > ViewDBList() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:13 > ViewDBList() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:16 > ViewDBList() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:17 > TestConnection() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:18 > TestConnection() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:19 > Запускаем восстановление базы данных: buh3_ecodor_00
2019-02-14 01:19 > Восстанавливаем из файла: D:\Backup_SQL\buh_ecodor_00\buh_ecodor_00_backup_2019_02_12_05 0001_5847766.bak
2019-02-14 01:19 > RestoreDB() error: RESTORE DATABASE прервано с ошибкой.
Логический файл "upp_db" не является частью базы данных "buh3_ecodor_00". Используйте RESTORE FILELISTONLY для вывода списка имен логических файлов.
2019-02-14 01:24 > Запускаем восстановление базы данных: buh3_ecodor_00
2019-02-14 01:24 > Восстанавливаем из файла: D:\Backup_SQL\buh_ecodor_00\buh_ecodor_00_backup_2019_02_12_05 0001_5847766.bak
2019-02-14 01:24 > RestoreDB() error: RESTORE DATABASE прервано с ошибкой.
Логический файл "upp_db" не является частью базы данных "buh3_ecodor_00". Используйте RESTORE FILELISTONLY для вывода списка имен логических файлов.
(3) Прошу прощения, сразу не описал, сейчас поправлю в статье.
1. Первые ошибки связаны вероятно с тем что не введен правильный пользователь и пароль для СУБД. Чаще всего пользователь SA и пароль какой был введен по умолчанию.
После того как введете нажмите "сохранить настройки" что бы при следующем запуске не было таких проблем.
2. Я забыл упомянуть что не все настройки выведены в интерфейс, так как не часто меняются в пределах одной компании. В xml файле, есть такой параметр как логическое имя БД. В MS SQL Managment Studio можно посмотреть вот тут, в свойствах базы:
Да, и ещё довод в пользу более тесной интеграции с 1С - это ещё и считывание данных о подключении к СУБД из самой инфраструктуры 1С т.е. из кластера - чтобы надо было лишь выбрать ИБ откуда и ИБ куда (причём из списка, в котором сначала указаны кластеры, там же могут быть уже указаны и имеющиеся бэкапы (ну это отдельно настраивается для каждой ИБ и/или общим каталогом))! Вот тогда да - это было бы действительно "быстро" - но лишь по части GUI-взаимодействия, а не по части техники работы с самим бэкапом!
Да и зачем программе путь к файлам БД? Тем более, что это не обязан быть один каталог!
(1)Безусловно Ваши доводы имеют основание, описанная Вами обработка была бы интересна как в написании так и в рассмотрении, возьму на заметку идею.
Про путь к файлам БД, исключительно потому что я в своем скрипте (шаблонном) использовал эти пути. Тот самый скрипт был взят за основу программы.
Подскажи, в чем именно ошибки при восстановлении ?
2019-02-14 01:11 > ViewDBList() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:13 > ViewDBList() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:16 > ViewDBList() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:17 > TestConnection() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:18 > TestConnection() error: [DBNETLIB][ConnectionOpen (Connect()).]SQL Server не существует, или доступ запрещен.
2019-02-14 01:19 > Запускаем восстановление базы данных: buh3_ecodor_00
2019-02-14 01:19 > Восстанавливаем из файла: D:\Backup_SQL\buh_ecodor_00\buh_ecodor_00_backup_2019_02_12_05 0001_5847766.bak
2019-02-14 01:19 > RestoreDB() error: RESTORE DATABASE прервано с ошибкой.
Логический файл "upp_db" не является частью базы данных "buh3_ecodor_00". Используйте RESTORE FILELISTONLY для вывода списка имен логических файлов.
2019-02-14 01:24 > Запускаем восстановление базы данных: buh3_ecodor_00
2019-02-14 01:24 > Восстанавливаем из файла: D:\Backup_SQL\buh_ecodor_00\buh_ecodor_00_backup_2019_02_12_05 0001_5847766.bak
2019-02-14 01:24 > RestoreDB() error: RESTORE DATABASE прервано с ошибкой.
Логический файл "upp_db" не является частью базы данных "buh3_ecodor_00". Используйте RESTORE FILELISTONLY для вывода списка имен логических файлов.
(3) Прошу прощения, сразу не описал, сейчас поправлю в статье.
1. Первые ошибки связаны вероятно с тем что не введен правильный пользователь и пароль для СУБД. Чаще всего пользователь SA и пароль какой был введен по умолчанию.
После того как введете нажмите "сохранить настройки" что бы при следующем запуске не было таких проблем.
2. Я забыл упомянуть что не все настройки выведены в интерфейс, так как не часто меняются в пределах одной компании. В xml файле, есть такой параметр как логическое имя БД. В MS SQL Managment Studio можно посмотреть вот тут, в свойствах базы:
Пожалуйста, запустите ниже sql и проверьте логические имена
Затем замените логическое имя, показанное на в скрипте ниже
Проверьте свойства базы данных и убедитесь, что логическое имя совпадает с именем файла. Используйте команду Alter Database, чтобы изменить их:
Я использовал Powershell для этого, и у меня была такая же ошибка. Что меня поразило, так это то, что я использовал "$ db_log.mdf", а подчеркивание - допустимый символ для определений переменных, поэтому он действительно искал $ db_log, а не объединял.
Итак, мой код выглядел так:
Я пытался восстановить базу данных из резервной копии по UNC-пути. Было 2 проблемы:
База данных начиналась с чисел: 123DbName, поэтому это нужно было заключить в [], например [123DbName]
Я писал полный UNC-путь к серверу, на который хотел переехать: \ server \ e $ \ data | \ server \ f $ \ log, как только я удалил серверную часть и оставил только e и f, все заработало.
У меня возникла эта проблема при попытке восстановить базу данных на MS SQL Server 2012.
Вот мой сценарий восстановления базы данных:
И я столкнулся с ошибкой:
Вот как я это исправил:
Проблема заключалась в том, что я неправильно ссылался на логические файлы.
Мне пришлось запустить команду ниже для файла резервной копии:
Это отображало LogicalName и соответствующие PhysicalName файлов данных и журнала для базы данных соответственно:
Все, что мне нужно было сделать, это просто заменить LogicalName и соответствующие PhysicalName файлов данных и журнала для базы данных соответственно в скрипте:
И задача восстановления базы данных успешно выполнилась:
надеюсь, это поможет
То, о чем вы просите, нетривиально и имеет несколько потенциальных ловушек (хотите ли вы перезаписать базу данных, если она существует? Что, если база данных используется, когда вы пытаетесь перезаписать? Вы хотите поместить физические файлы в в одном каталоге все время? и т. д.) ..
К счастью, об этом спрашивали раньше, смотрите, я не тестировал, но выглядит нормально.
Прежде всего, я очень новичок в базах данных, поэтому, пожалуйста, держите инструкции простыми для меня. благодаря!
Обычно, когда мне нужно внести изменения вручную, я просто создаю резервную копию моей базы данных SQL Server Management Studio 2012 под названием Фильмы , затем загружаю ее на свой компьютер, а затем использую функцию восстановления реализовать его.
Я все еще на стадии тестирования, поэтому данные не нужно хранить, которые можно получить в Интернете, однако я хотел попробовать сохранить данные сегодня, поэтому я использовал параметр резервного копирования хоста, который создал файл DB_76779_test_backup.bak для меня.
Затем я загружу это и «попытаюсь» обновить его информацию в базе данных SQL на моей машине ( Кино ), и я считаю, что я все испортил.
From what I remember I right-clicked my database "Movies" and selected "Tasks -> Restore -> Database", I kept everything as is, but for Source I selected Device then chose the DB_76779_test_backup.bak file and and below that selected "Movies" as the Database and hit OK.
Казалось, это работает нормально, поэтому я открыл и отредактировал значения таблиц, которые нужно было изменить. Затем, как обычно, я только что поддержал его, ftp'ed его на хост и восстановил мою базу данных.
Однако при попытке восстановления я получил ошибку, и моя поддержка показала мне следующее.
«Логический файл« Фильмы »не является частью базы данных« DB_76779_test ». RESTORE FILELISTONLY, чтобы отобразить имена логических файлов. "
Я боюсь, что мы поддерживаем только восстановление баз данных, содержащих только 1 .mdf и 1 .ldf-файл без дополнительных разделов.
Я предполагаю, что, поскольку единственное, что я сделал на этот раз, - это восстановить мою базу данных на моем компьютере, так это то, что я как-то сломал ее или создал более одного файла mdf и ldf (не знаю, что это такое). Все, что я пытался сделать, это сохранить фактические данные в Интернете, поэтому я даже не уверен, что это правильный способ сделать это, но независимо от того, что я не могу восстановить базу данных на моем хосте сейчас.
Я надеюсь, что кто-то здесь мгновенно осознал, какую идиотскую ошибку я сделал, потому что я знаю только базовый уровень базы данных и не слишком много механики «под капотом».
Читайте также: