Перенос mdf ldf на сервер sql на другой компьютер

Обновлено: 21.11.2024

Я знаю, что поначалу этот вопрос может показаться безумным, но вот в чем дело: у нас есть более 1 ТБ файлов .MDF базы данных SharePoint SQL. Мы можем использовать EMC MirrorView для зеркалирования SAN LUN из одного центра обработки данных в другой. Мы можем зеркалировать ТОЛЬКО файлы .MDF, потому что файлы .LDF изменяются слишком часто и заполняют наше соединение между центрами обработки данных.

Итак, вот что я могу сделать: в центре обработки данных A я могу отключить SharePoint, чтобы приложение, использующее SQL, было отключено. Затем я могу установить для всех баз данных SQL Server режим SINGLE_USER, а затем перевести их в автономный режим. Я думаю, что теперь в моем файле данных есть все данные — теперь каждая транзакция будет завершена, а файл T-Log не содержит ничего, чего еще нет в файле данных.

Затем в центре обработки данных B я жду завершения последней зеркальной синхронизации, а затем могу просто прикрепить к зеркальной копии файлы .MDF. Я думаю, что базы данных могут быть помечены как подозрительные, но на самом деле они должны быть в порядке. Или, может быть, если я сделаю что-то подобное, SQL без проблем переведет базу данных в оперативный режим.

СОЗДАТЬ БАЗА ДАННЫХ [AdventureWorks] ON (FILENAME = N'M:\SQLData\AdventureWorks.mdf') ДЛЯ ПРИСОЕДИНЕНИЯ

<р>. хотя, возможно, мне также нужно указать имя и местоположение .ldf.

Я собираюсь протестировать это, но даже тестирование между этими центрами обработки данных нетривиально, поэтому я надеялся получить отзывы.

Большое спасибо!

13 июля 2011 г., 10:50

Если присоединение не работает, используйте sp_attach_single_file_db.

Вы настраиваете другое приложение SharePoint в DCB?

13 июля 2011 г., 11:47

AlexSQLForums (13.07.2011)
Вы настраиваете другое приложение SharePoint в DCB?

На самом деле мы переезжаем на DCB, но у нас есть только ограниченное окно технического обслуживания для перехода. Таким образом, мы должны получить данные заранее, копирование ТБ через нашу глобальную сеть заняло бы слишком много времени.

Теоретически мы могли бы делать резервные копии, копировать их перед перемещением, а затем просто делать последнюю резервную копию TLog и восстанавливать ее в течение окна, но на этом сервере более 130 (!) баз данных. Написание всего этого было бы нетривиальной задачей.

13 июля 2011 г., 14:01

Гейл Шоу
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: обсуждение производительности БД с периодическими отклонениями в вопросах восстановления

13 июля 2011 г., 14:04

jpSQLDude (13.07.2011)
Итак, вот что я могу сделать: в центре обработки данных A я могу отключить SharePoint, чтобы приложение, использующее SQL, было отключено. Затем я могу установить для всех баз данных SQL Server режим SINGLE_USER, а затем перевести их в автономный режим. Я думаю, что теперь в моем файле данных есть все данные — теперь каждая транзакция будет завершена, а файл T-Log не содержит ничего, чего еще нет в файле данных.
Тогда в центре обработки данных B я жду завершения последней зеркальной синхронизации, а затем могу просто прикрепить к зеркальной копии файлы .MDF. Я думаю, что базы данных могут быть помечены как подозрительные, но на самом деле они должны быть в порядке. Или, может быть, если я сделаю что-то подобное, SQL без проблем переведет базу данных в оперативный режим.

Это сработает, и базы данных будут подключены чисто и без ошибок, однако в случае серьезного сбоя, когда центр обработки данных A внезапно и неожиданно отключается (т. базы данных онлайн вообще.

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

13 июля 2011 г., 14:20

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

объявить @DB sysname, @LstRes varchar(50)

установить @lstRes = 'LastTranLogThatWasRestored.TLS'

установить @DB = 'Моя база данных'

выберите «ВОССТАНОВИТЬ ЖУРНАЛ» + rtrim(@db) + char(13)

+ 'FROM DIKS = ' + char(39)

+ 'БЕЗ ВОССТАНОВЛЕНИЯ' + char(13)

+ 'select' + char(39) + substring(physical_device_name,charindex('TLog',physical_device_name),50) + char(39) + char(13)

из msdb..backupset a присоединиться к msdb..backupmediaset b на a.media_set_id = b.media_set_id

присоединиться к msdb..backupmediafamily c на a.media_set_id = c.media_set_id

и имя_базы_данных = @DB

и подстрока(физическое_имя_устройства,charindex('TLog',физическое_имя_устройства),50) > @LstRes

упорядочить по backup_start_date ASC

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

Все, что вам нужно добавить, это ЖУРНАЛ ВОССТАНОВЛЕНИЯ С ВОССТАНОВЛЕНИЕМ, когда вы будете готовы.

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

Лео
В жизни нет ничего настолько сложного, что нельзя было бы усложнить, приложив немного усилий.

13 июля 2011 г., 16:07

GilaMonster (13.07.2011)

jpSQLDude (13.07.2011)
Итак, вот что я могу сделать: в центре обработки данных A я могу отключить SharePoint, чтобы приложение, использующее SQL, было отключено. Затем я могу установить для всех баз данных SQL Server режим SINGLE_USER, а затем перевести их в автономный режим. Я думаю, что теперь в моем файле данных есть все данные — теперь каждая транзакция будет завершена, а файл T-Log не содержит ничего, чего еще нет в файле данных.
Тогда в центре обработки данных B я жду завершения последней зеркальной синхронизации, а затем могу просто прикрепить к зеркальной копии файлы .MDF. Я думаю, что базы данных могут быть помечены как подозрительные, но на самом деле они должны быть в порядке. Или, может быть, если я сделаю что-то подобное, SQL без проблем переведет базу данных в оперативный режим.

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

Меня беспокоит целостность баз данных после их подключения к новой системе. Не знаю, что произойдет, поскольку SQL Server записывает транзакции в файл журнала, прикрепленный к системе в старом центре обработки данных, но эти транзакции никогда не записываются в новом центре обработки данных.

По сути, я вижу, что файл mdf будет обновляться через репликацию SAN, но файл журнала не будет. Даже если файл данных не появится в новой системе сразу же, я не понимаю, как SQL Server может вызвать его с изменениями, которые были реплицированы в файл.

Джеффри Уильямс
Проблемы — это возможности, блестяще замаскированные под непреодолимые препятствия.

У меня есть база данных, и я хочу переместить файлы .mdf и .ldf в другое место. Но я не хочу останавливать службу MSSQLSERVER и не хочу экспортировать на другой сервер.

Как я могу это сделать?

12 ответов 12

Вам не нужно останавливать службу SQL Server для перемещения файлов базы данных, но вам нужно перевести конкретную базу данных в автономный режим. Это связано с тем, что вы не можете перемещать файлы во время доступа к ним, а перевод базы данных в автономный режим останавливает использование файлов приложением SQL Server.

Процесс их перемещения довольно прост. Отключение/присоединение уже было описано, но это не так сложно.

Измените расположение файлов с помощью команды ALTER DATABASE:

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

Отключить базу данных

(Я использую WITH ROLLBACK IMMEDIATE, чтобы исключить всех и откатить все текущие открытые транзакции)

Переместить/скопировать файлы в новое место

Просто скопируйте файлы, используя ваш любимый метод (Click 'n Drag, XCopy, Copy-Item, Robocopy)

Подключить базу данных к сети

Подробнее это описано здесь.

Это сработало для меня. В моем случае мне также пришлось переместить файл LDF с помощью первой команды: например. мастер ЕГЭ; --сделайте все это с мастера ALTER DATABASE foo MODIFY FILE (name='DB_Data1_log',filename='X:\NewDBFile\DB_Data1_log.ldf'); --Filename — новое местоположение

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

После перемещения файлов базы данных убедитесь, что у пользователя "NT SERVICE\MSSQLSERVER" есть разрешения на доступ к ним, иначе вы получите ошибки при попытке вернуть базу данных в оперативный режим.

@mlhDev На самом деле в моем случае порядок ИЗМЕНЕНИЯ ФАЙЛА можно изменить. Если вы сначала запустите MODIFY FILE, он сообщит вам, что команда выполнена успешно, и местоположение будет изменено после операции оффлайн-онлайн (формулировки разные, но вы поняли идею). Однако порядок Offline->Move files->Online имеет значение по очевидной причине. Также отметьте примечание Demonslay335. Разрешение доступа к файлу важно.

Файлы MDF и LDF защищены и не могут быть перемещены, пока база данных находится в сети.

Если вы не возражаете против того, чтобы база данных перестала работать, вы можете ОТСОЕДИНИТЬ ее, переместить файлы, а затем ПРИСОЕДИНИТЬ ее.

Щелкните правой кнопкой мыши имя базы данных
Выбрать свойства
Перейдите на вкладку "Файлы".
Запишите путь и имя файла файлов MDF и LDF. Этот шаг важен, если вы не хотите заниматься поиском отсутствующих файлов.
Щелкните правой кнопкой мыши имя базы данных
Выберите «Задачи» -> «Отключить».
Переместите файлы куда хотите
Щелкните правой кнопкой мыши узел "Базы данных" вашего сервера.
Выберите "Прикрепить".
Нажмите кнопку "Добавить".
Укажите новое местоположение
Нажмите "ОК".

Сейчас все должно быть в порядке. Информацию о процессе DETACH - ATTACH можно найти здесь.

В ссылке о DETACH - ATTACH есть рекомендация использовать оператор ALTER DATABASE, если база данных хранится на том же экземпляре SQL Server. Дополнительные сведения см. в разделе Перемещение баз данных пользователей.

Если вы хотите, чтобы он работал во время движения, выполните РЕЗЕРВНОЕ КОПИРОВАНИЕ - ВОССТАНОВЛЕНИЕ. В процессе восстановления вы можете определить новое расположение файлов базы данных.

Я рекомендую открывать SQL Management Studio от имени администратора, чтобы избежать проблем с доступом к файлам при повторном подключении

Чтобы переместить файлы системной базы данных, выполните следующие действия:

Войдите как пользователь sa в SSMS

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

Завершить все сеансы, подключенные к серверу из SSMS.

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

Мастер ЕГЭ;
ВЫБЕРИТЕ * ИЗ sys.master_files;

Определите путь и запишите текущий путь к файлам.

Используйте TSQL, чтобы изменить путь к файлу для всех баз данных, кроме master:

ИЗМЕНИТЬ БАЗУ ДАННЫХ имя_базы_данных ИЗМЕНИТЬ ФАЙЛ (ИМЯ = логическое_имя, ИМЯ ФАЙЛА = 'новый_путь\имя_файла_ОС')

Теперь расположение файла было изменено.

Обязательно переместите файлы ldf и mdf

В SSMS щелкните правой кнопкой мыши сервер и выберите свойства . Внутри свойств перейдите в «Настройки базы данных». Измените расположение базы данных по умолчанию для данных и журнала на путь назначения. Выйдите из сервера.

Например: измените C:\Program Files\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\DATA\ на E:\projects\DataBaseFiles\MSSQL\DATA\

Остановить экземпляр SQL Server.

Скопируйте файл или файлы в новое место. Используйте Robocopy для перемещения файлов, чтобы скопировать права доступа в папку назначения. Откройте cmd, запустите от имени администратора и используйте следующую команду:

robocopy /sec исходная папка целевая папка

Для запуска команды лучше перейти в исходное местоположение. Удалите другие файлы, кроме файлов системной базы данных, которые копируются. Например:

(Здесь мы перемещаем все файлы системной базы данных в новое место.)

В меню "Пуск" выберите "Все программы", выберите "Microsoft SQL Server", выберите "Инструменты настройки" и щелкните "Диспетчер конфигурации SQL Server".

Выполните следующие шаги в диспетчере конфигурации SQL Server:

В узле «Службы SQL Server» щелкните правой кнопкой мыши экземпляр SQL Server (например, SQL Server (MSSQLSERVER)) и выберите «Свойства». В диалоговом окне «Свойства SQL Server (instance_name)» щелкните вкладку «Параметры запуска». В поле «Существующие параметры» выберите параметр –d, чтобы переместить файл основных данных. Щелкните Обновить, чтобы сохранить изменение. В поле Укажите параметр запуска измените параметр на новый путь к базе данных master. В поле «Существующие параметры» выберите параметр –l, чтобы переместить главный файл журнала. Щелкните Обновить, чтобы сохранить изменение. В поле Укажите параметр запуска измените параметр на новый путь к базе данных master.

Значение параметра файла данных должно следовать за параметром -d, а значение файла журнала должно следовать за параметром -l. В следующем примере показаны значения параметров для расположения файла основных данных по умолчанию.

Если планируется перемещение файла основных данных в E:\SQLData, значения параметров будут изменены следующим образом:

Остановите экземпляр SQL Server, щелкнув имя экземпляра правой кнопкой мыши и выбрав Остановить. Перезапустите экземпляр SQL Server.

Войдите в систему SSMS как пользователь sa и проверьте расположение файлов базы данных, выполнив следующий запрос:

Читайте также: