Перенос sql базы с одного сервера на другой: Копирование баз данных на другие серверы — SQL Server

Перенос базы данных с одного сервера MySQL на другой

Переношу БД (MySQL).
Перенос делаю самым обычным методом — «copy-past» каталога в каталог «data».
Далее стартую и смотрю, таблицы в БД выдают «Rows -1». Смотрю через Navicat.
Не первый раз переношу БД, но тут что-то не то. ПО не моё и БД создавал не я.
Может что-то с доступом?
Просто не знаю, как выглядят запароленные БД из Navicat.
Пароль при установке MySQL на root ставил естественно свой.
Export-Import в этом существенно поможет?
P.S. Если БД под доступом, то это всё? Туши свет?
БД обширная, набивалась несколько лет. Организация теперь решила писать свое ПО, так как содержание текущего стало проблематично.
Неужели БД насмерть привязана к разработчикам, а не к предприятию (это же уже авторские права)?
Или проще надавить (по закону) на разработчиков, то-бы они выдали пароль на доступ к БД?
P.P.S (!)
Немного становится понятнее. В файлах базы нет файлов MYI и MID! Это как-то хитро БД делали, что они могут лежать в других каталогах?
(Сегодня доступа к тому ПК не имею, посмотреть смогу лишь завтра)
Почему так?

UPD:
Проблема решена!
Угон пароля на root. (жадный установщик (продавший ПО организации), установил какую-то, мне неизвестную, тулзу по управлению БД, а пароль в ней был просто сохранен в закрытом виде. Ведь такие разработчики всё время думают, что покупатель ЛОХ, но покупатель через несколько лет нанимает другого разработчика, и та контора остаётся без денег за, якобы «поддержку и сопровождение», а это обновление списка фамилий участников комиссии в собственной БД(!!!) или обновление 5-10 вопросов из тестовых задач. Плюс, ко всему, такие разработчики получают ещё большой толстый минус и очернение в репутацию по всему городу!)
P.S. Ребята, ПО надо продавать честно!
БД созданная покупателем ПО, является 100% собственностью организации купившей данное ПО. И имеет полное право на предоставление пароля к БД.






2

Перенос данных копированием каталога данных в случае MySQL возможно только если в базах данных используется исключительно тип таблиц MyISAM (разумеется операция осуществляется после остановки сервера — иначе данные будут повреждены). В случае MyISAM и мета-информация, и индексы и данные полностью располагаются в каталогах баз данных. Если имеются таблицы InnoDB — данные могут находится в едином табличном пространстве.

Перенос данных через копирование применяют очень редко. Только если у вас MyISAM-таблицы, и, как правило, через утилиту mysqlhotcopy, входящую в состав MySQL.

Штатным переносом данных из одной базы данных в другую является процедура создания и разворачивания SQL-дампа: текстового файла с SQL-инструкциями, воспроизводящими базу данных. Создать дамп dbname.sql базы данных dbname можно при помощи утилиты mysqldump

mysqldump -u user -p dbname > dbname.sql

развернуть его на новом сервере в заранее созданной базе данных dbname_new можно при помощи утилиты mysql

mysql -u user -p dbname_new < dbname.sql

Вместо user — указывается имя MySQL-пользователя, из под которого осуществляются операции, параметр -p сообщает, позволяет ввести пароль сразу после запуска команд. Утилиты входят в состав любой инсталляции MySQL и доступны из командной строки.






8







Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации



Почта

Необходима, но никому не показывается




By clicking “Отправить ответ”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.


Как перенести пользователей Microsoft SQL на новый сервер

Предыстория: понадобилось мне перенести очень большое количество БД с одного сервера на другой в связи… (да не важно в связи с чем, просто была нужда). Но так как Баз Данных было очень много, а разрешений для этих БД было еще больше, да и логины/пароли забивать для этих учетных записей хотелось и того меньше, пришлось искать обходные пути, как упростить данное мероприятие. И оно нашлось! Да, проверено данное действо на Microsoft SQL Server 2012 и 2014. Предположительно будет работать и в более высоких версиях включая 2019, но это не точно.

Итак, что у нас есть:
1. Приаттаченные БД на новом сервере;
2. В наличии пока еще живой старый сервер SQL c с которого эти БД переносились.

Предварительно мы имеем подобные симптомы:
При переносе баз с одного экземпляра SQL Server на другой имена входа (логины) и пароли к ним не переносятся автоматически. Соответственно после переноса пользователи не смогут подключиться к своей базе данных и получат сообщение об ошибке.

Инструкция к действию:
1. На исходном сервере, с которого перенесены базы, выполняем следующий запрос на БД Master:

USE master
GO
IF OBJECT_ID (‘sp_hexadecimal’) IS NOT NULL
  DROP PROCEDURE sp_hexadecimal
GO
CREATE PROCEDURE sp_hexadecimal
    @binvalue varbinary(256),
    @hexvalue VARCHAR (514) OUTPUT
AS
DECLARE @charvalue VARCHAR (514)
DECLARE @i INT
DECLARE @LENGTH INT
DECLARE @hexstring CHAR(16)
SELECT @charvalue = ‘0x’
SELECT @i = 1
SELECT @LENGTH = DATALENGTH (@binvalue)
SELECT @hexstring = ‘0123456789ABCDEF’
WHILE (@i < = @LENGTH)
BEGIN
  DECLARE @tempint INT
  DECLARE @firstint INT
  DECLARE @secondint INT
  SELECT @tempint = CONVERT(INT, SUBSTRING(@binvalue,@i,1))
  SELECT @firstint = FLOOR(@tempint/16)
  SELECT @secondint = @tempint — (@firstint*16)
  SELECT @charvalue = @charvalue +
    SUBSTRING(@hexstring, @firstint+1, 1) +
    SUBSTRING(@hexstring, @secondint+1, 1)
  SELECT @i = @i + 1
END
 
SELECT @hexvalue = @charvalue
GO
 
IF OBJECT_ID (‘sp_help_revlogin’) IS NOT NULL
  DROP PROCEDURE sp_help_revlogin
GO
CREATE PROCEDURE sp_help_revlogin @login_name sysname = NULL AS
DECLARE @name sysname
DECLARE @TYPE VARCHAR (1)
DECLARE @hasaccess INT
DECLARE @denylogin INT
DECLARE @is_disabled INT
DECLARE @PWD_varbinary  varbinary (256)
DECLARE @PWD_string  VARCHAR (514)
DECLARE @SID_varbinary varbinary (85)
DECLARE @SID_string VARCHAR (514)
DECLARE @tmpstr  VARCHAR (1024)
DECLARE @is_policy_checked VARCHAR (3)
DECLARE @is_expiration_checked VARCHAR (3)
 
DECLARE @defaultdb sysname
 
IF (@login_name IS NULL)
  DECLARE login_curs CURSOR FOR
 
      SELECT p. sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
sys.server_principals p LEFT JOIN sys.syslogins l
      ON ( l.name = p.name ) WHERE p.type IN ( ‘S’, ‘G’, ‘U’ ) AND p.name <> ‘sa’
ELSE
  DECLARE login_curs CURSOR FOR
 
 
      SELECT p.sid, p.name, p.type, p.is_disabled, p.default_database_name, l.hasaccess, l.denylogin FROM
sys.server_principals p LEFT JOIN sys.syslogins l
      ON ( l.name = p.name ) WHERE p.type IN ( ‘S’, ‘G’, ‘U’ ) AND p.name = @login_name
OPEN login_curs
 
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @TYPE, @is_disabled, @defaultdb, @hasaccess, @denylogin
IF (@@fetch_status = -1)
BEGIN
  PRINT ‘Имена не найдены.’
  CLOSE login_curs
  DEALLOCATE login_curs
  RETURN -1
END
SET @tmpstr = ‘/* sp_help_revlogin script ‘
PRINT @tmpstr
SET @tmpstr = ‘** Generated ‘ + CONVERT (VARCHAR, GETDATE()) + ‘ on ‘ + @@SERVERNAME + ‘ */’
PRINT @tmpstr
PRINT »
WHILE (@@fetch_status <> -1)
BEGIN
  IF (@@fetch_status <> -2)
  BEGIN
    PRINT »
    SET @tmpstr = ‘— Login: ‘ + @name
    PRINT @tmpstr
    IF (@TYPE IN ( ‘G’, ‘U’))
    BEGIN — NT authenticated account/group
 
      SET @tmpstr = ‘CREATE LOGIN ‘ + QUOTENAME( @name ) + ‘ FROM WINDOWS WITH DEFAULT_DATABASE = [‘ + @defaultdb + ‘]’
    END
    ELSE BEGIN — SQL Server authentication
        — obtain password and sid
            SET @PWD_varbinary = CAST( LOGINPROPERTY( @name, ‘PasswordHash’ ) AS varbinary (256) )
        EXEC sp_hexadecimal @PWD_varbinary, @PWD_string OUT
        EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
 
        — obtain password policy state
        SELECT @is_policy_checked = CASE is_policy_checked WHEN 1 THEN ‘ON’ WHEN 0 THEN ‘OFF’ ELSE NULL END FROM sys. sql_logins WHERE name = @name
        SELECT @is_expiration_checked = CASE is_expiration_checked WHEN 1 THEN ‘ON’ WHEN 0 THEN ‘OFF’ ELSE NULL END FROM sys.sql_logins WHERE name = @name
 
            SET @tmpstr = ‘CREATE LOGIN ‘ + QUOTENAME( @name ) + ‘ WITH PASSWORD = ‘ + @PWD_string + ‘ HASHED, SID = ‘ + @SID_string + ‘, DEFAULT_DATABASE = [‘ + @defaultdb + ‘]’
 
        IF ( @is_policy_checked IS NOT NULL )
        BEGIN
          SET @tmpstr = @tmpstr + ‘, CHECK_POLICY = ‘ + @is_policy_checked
        END
        IF ( @is_expiration_checked IS NOT NULL )
        BEGIN
          SET @tmpstr = @tmpstr + ‘, CHECK_EXPIRATION = ‘ + @is_expiration_checked
        END
    END
    IF (@denylogin = 1)
    BEGIN — login is denied access
      SET @tmpstr = @tmpstr + ‘; DENY CONNECT SQL TO ‘ + QUOTENAME( @name )
    END
    ELSE IF (@hasaccess = 0)
    BEGIN — login exists but does not have access
      SET @tmpstr = @tmpstr + ‘; REVOKE CONNECT SQL TO ‘ + QUOTENAME( @name )
    END
    IF (@is_disabled = 1)
    BEGIN — login is disabled
      SET @tmpstr = @tmpstr + ‘; ALTER LOGIN ‘ + QUOTENAME( @name ) + ‘ DISABLE’
    END
    PRINT @tmpstr
  END
 
  FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @TYPE, @is_disabled, @defaultdb, @hasaccess, @denylogin
   END
CLOSE login_curs
DEALLOCATE login_curs
RETURN 0
GO

2. Этот запрос создаст в базе master две хранимых процедуры — sp_hexadecimal и sp_help_revlogin.
Запускаем процедуру sp_help_revlogin:

USE master
GO
EXEC sp_help_revlogin

3. В результате мы должны получить список созданных ранее пользователей, с хэшами паролей и настройками доступа к приаттаченным ранее БД.
4. Копируем данный скрипт на новый сервер, выбирая тех пользователей которые нам необходимы и выполняем этот скрипт на базе master.

Исходник взят и переосмыслен с сайта Microsoft: How to transfer logins and passwords between instances of SQL Server

Да, еще есть не тру-метод, это найти вот такую программу, которая из master.mdf сама выдерет пароли/логины, но само собой, о правах на БД речи не идет.
И да, это не реклама. В своем уме платить за нее 50$ никакого желания нет.
SQL Server Password Changer

копий баз данных с резервным копированием и восстановлением — SQL Server

  • Статья

Применяется к: SQL Server

В SQL Server можно создать новую базу данных, восстановив резервную копию базы данных пользователя, созданную с помощью SQL Server 2005 (9.x) или более поздней версии. Тем не менее, резервные копии master , model и msdb , созданные с помощью более ранней версии SQL Server, не могут быть восстановлены SQL Server. Кроме того, резервные копии SQL Server не могут быть восстановлены любой более ранней версией SQL Server.

Важно

В SQL Server 2016 используется другой путь по умолчанию, чем в более ранних версиях. Поэтому для восстановления резервных копий базы данных, созданной в местоположении по умолчанию более ранних версий, необходимо использовать параметр MOVE. Сведения о новом пути по умолчанию см. в разделе Расположение файлов для экземпляров по умолчанию и именованных экземпляров SQL Server. Дополнительные сведения о перемещении файлов базы данных см. в разделе «Перемещение файлов базы данных» далее в этом разделе.

Общие действия по использованию резервного копирования и восстановления для копирования базы данных

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

Общие шаги:

  1. Создайте резервную копию исходной базы данных, которая может находиться на экземпляре SQL Server 2005 (9.x) или более поздней версии. Компьютер, на котором работает этот экземпляр SQL Server, является исходным компьютером 9.0014 .

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

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

Некоторые дополнительные соображения, которые могут повлиять на этот процесс:

Перед восстановлением файлов базы данных

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

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

Это может быть необходимо в следующих ситуациях:

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

  • Возможно, в целевом расположении недостаточно места.

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

    • Если существующий файл базы данных можно перезаписать, он будет перезаписан (это не повлияет на файл, принадлежащий базе данных с другим именем).

    • Если существующий файл невозможно перезаписать, возникнет ошибка восстановления.

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

Перемещение файлов базы данных

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

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

  • Возможно, потребуется восстановить некоторые файлы базы данных из резервной копии на другой диск из-за ограничений по емкости. Это обычное явление, потому что большинство компьютеров в организации не имеют одинакового количества и размера дисководов или идентичных конфигураций программного обеспечения.

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

Дополнительные сведения см. в разделе «Восстановление файлов и файловых групп в новое расположение» далее в этом разделе.

Изменение имени базы данных

Имя базы данных можно изменить по мере ее восстановления на конечном компьютере без необходимости сначала восстанавливать базу данных, а затем изменять имя вручную. Например, может потребоваться изменить имя базы данных с 9 на0013 Sales — SalesCopy , чтобы указать, что это копия базы данных.

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

При обновлении базы данных с помощью Restore

При восстановлении резервных копий из более ранней версии полезно заранее знать, существует ли путь (диск и каталог) каждого из полнотекстовых каталогов в резервной копии на целевом компьютере. . Чтобы перечислить логические имена и физические имена, путь и имя файла) каждого файла в резервной копии, включая файлы каталога, используйте ВОССТАНОВЛЕНИЕ FILELISTONLY FROM <резервное_устройство> заявление. Дополнительные сведения см. в разделе ВОССТАНОВЛЕНИЕ FILELISTONLY (Transact-SQL).

Если такой же путь не существует на целевом компьютере, у вас есть две альтернативы:

  • Создайте эквивалентное сопоставление диска/каталога на целевом компьютере.

  • Переместите файлы каталога в новое место во время операции восстановления, используя предложение WITH MOVE в инструкции RESTORE DATABASE. Дополнительные сведения см. в разделе ВОССТАНОВЛЕНИЕ (Transact-SQL).

Сведения об альтернативных вариантах обновления полнотекстовых индексов см. в разделе Обновление полнотекстового поиска.

Владение базой данных

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

Управление метаданными при восстановлении на другом экземпляре сервера

При восстановлении базы данных на другом экземпляре сервера, чтобы обеспечить единообразие работы пользователей и приложений, может потребоваться заново создать некоторые или все метаданные для базы данных, например в качестве логинов и заданий на другом экземпляре сервера. Дополнительные сведения см. в разделе Управление метаданными при предоставлении доступа к базе данных на другом экземпляре сервера (SQL Server).

Просмотр файлов данных и журналов в наборе резервных копий

  • ВОССТАНОВИТЬ ТОЛЬКО ФАЙЛИСТ (Transact-SQL)

Восстановить файлы и файловые группы в новое место

  • Восстановить файлы в новое место (SQL Server)

  • Восстановление резервной копии базы данных с помощью SSMS

Восстановление файлов и файловых групп поверх существующих файлов

  • Восстановление файлов и файловых групп поверх существующих файлов (SQL Server)

Восстановить базу данных с новым именем

  • Восстановление резервной копии базы данных с помощью SSMS

Перезапуск прерванной операции восстановления

  • Перезапуск прерванной операции восстановления (Transact-SQL)

Изменить владельца базы данных

  • sp_changedbowner (Transact-SQL)

Скопируйте базу данных с помощью объектов управления SQL Server (SMO)

  • ReadFileList

  • Переместить файлы

  • Замена базы данных

  • Восстановление

См.

также

Копирование баз данных на другие серверы
Расположение файлов для экземпляров SQL Server по умолчанию и именованных Перенос базы данных SQL с SQL Server на другой

Документация по блокировке пользователя

UserLock Часто задаваемые вопросы

  1. На вашем текущем SQL Server откройте Microsoft SQL Server Management Studio с учетной записью, имеющей права администратора на SQL Server.​

  2. Выберите базу данных UserLock, щелкните правой кнопкой мыши, чтобы отобразить контекстное меню, выберите «Задачи», затем нажмите «Отсоединить».

  3. Установите флажок «удалить», чтобы отключить базу данных и сбросить соединения, и нажмите «ОК».

  4. Скопируйте файлы базы данных UserLock с вашего текущего SQL Server на новый

  5. На новом сервере SQL откройте студию управления Microsoft SQL Server и подключите базу данных UserLock 9.0015

  6. Нажмите Добавить:

  7. Выберите новую базу данных и нажмите OK:

  8. Нажмите «ОК» для подтверждения:

  9. На сервере UserLock откройте консоль UserLock.