Перенос базы данных mysql на другой диск windows

Перенос пользовательской базы данных¶

1. Договариваемся с творческой частью коллектива, что в определенное время все перестают работать с базой. А именно, прекращают что-то туда добавлять и/или изменять.

2. Останавливаем сервисы, которые работают с МБД в автоматическом режиме, например:

DB Import — импорт новостных лент
DDB — распределенная база данных
Sch_to_DB — репликация расписаний
иначе, есть вероятность потерять часть информации.

3. Запускаем Microsoft SQL Server Management Studio.

4. Самым первым делом всегда делаем бэкап базы!

5. Далее, смотрим, где лежат файлы нужной нам базы данных (в нашем примере это будет МБД под названием «RADIO-DB»). Для этого, нажимаем на ней ПКМ и открываем Properties (Свойства). Заходим в раздел Files (Файлы) и смотрим раздел Path (Путь):

6. Далее, нажимаем ПКМ на целевой базе и выбираем пункт Tasks\Detach (Задачи\Отсоединить):

7. В открывшемся окне ставим обе галочки и нажимаем ОК. После чего, МБД пропадет из списка:

8. Через обычный проводник заходим в каталог, где лежат нужные нам файлы. В нашем примере, это C:\Program Files\Microsoft SQL Server\MSSQL11.SQLEXPRESS2012\MSSQL\DATA.

9. Копируем эти файлы в новый каталог на новый диск и снова открываем Microsoft SQL Server Management Studio.

10. Нажимаем ПКМ на разделе Databases (Базы данных), выбираем пункт Attach (Присоединить) и в открывшемся окне нажимаем кнопку Add (Добавить) и выбираем нужный нам файл RADIO-DB.mdf уже из нового каталога:

Убеждаемся, что пути у нас теперь новые и нажимаем ОК.

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

1.3.5. Изменение свойств базы данных

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

Для изменения свойства используется оператор SET. Команда будет выглядеть следующим образом:

ALTER DATABASE Имя_базы
SET имя_свойства

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

Давайте посмотрим имена свойств которые нужно подставить вместо параметра имя_свойства:

SINGLE_USER – перевести базу данных в однопользовательский режим. Только один пользователь сможет работать с базой;
RESTRICTED_USER – к базе данных разрешено подключаться только пользователям, которые принадлежат роли db_owner, dbcreator или sysadmin;
MULTI_USER – нормальный многопользовательский режим, при котором действуют все права (используется по умолчанию);
OFFLINE – отключить базу данных, подключения будут невозможны. Команды должна выполняться, когда к базе данных нет активных подключений. Вы при этом должны быть подключены к базе данных master.
ONLINE – вернуть базу данных в активное состояние;
READ_ONLY — перевести базу данных в режим только для чтения, изменение данных будет невозможно;
READ_WRITE — вернуть базе данных полный доступ на запись и чтение;
CURSOR_CLOSE_ON_COMMIT ON – по завершении транзакции (принятии или откате) все открытые курсоры будут закрываться. Если ON заменить на OFF, то при нормальном завершении транзакции (принятии изменений) курсоры остаются открытыми. При откате все курсоры кроме INSENSITIVE и STATIC закрываются;
RECOVERY FULL – использовать полную модель восстановления;
BULK_LOGGED — установить модель восстановления BULK_LOGGED;
SIMPLE – установить простую модель восстановления.

Это основные параметры, которые можно изменить. Более подробно о моделях восстановления можно узнать из файла Doc/BackupRestore.pdf на компакт диске.

Теперь давайте посмотрим на примеры использования этих свойств:

Следующий пример разрешает доступ только одному пользователю:

ALTER DATABASE TestDatabase
SET SINGLE_USER

Доступ только только пользователям ролей db_owner, dbcreator или sysadmin:

ALTER DATABASE TestDatabase
SET RESTRICTED_USER

Возвращаем нормальный многопользовательский режим:

ALTER DATABASE TestDatabase
SET MULTI_USER

Вывести базу данных в off-line, т.е. доступ будет запрещен всем пользователям:

ALTER DATABASE TestDatabase
SET OFFLINE

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

ALTER DATABASE TestDatabase
SET ONLINE

Перевести базу данных в режим только для чтения, любые изменения будут отклонены:

ALTER DATABASE TestDatabase
SET READ_ONLY

Вернуть базе данных полный доступ на запись и чтение:

ALTER DATABASE TestDatabase
SET READ_WRITE

По завершении транзакции (принятии или откате) все открытые курсоры будут закрываться:

ALTER DATABASE TestDatabase
SET CURSOR_CLOSE_ON_COMMIT ON

Установить полную модель восстановления:

ALTER DATABASE TestDatabase
SET RECOVERY FULL

Установить модель восстановления BULK_LOGGED:

ALTER DATABASE TestDatabase
SET BULK_LOGGED

Установить простую модель восстановления:

ALTER DATABASE TestDatabase
SET SIMPLE

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

ALTER DATABASE Имя_базы
COLLATE имя_кодировки

Перемещение определения данных с SQL Server на MariaDB

Чтобы скопировать структуры данных SQL Server в MariaDB,необходимо:

Создайте CSV-файл из данных SQL Server.
Измените синтаксис так,чтобы он работал в MariaDB.
Запустите файл в MariaDB.

Переменные,влияющие на DDL-заявления

На операторы DDL влияют некоторые системные переменные сервера.

sql_mode определяет поведение некоторых операторов и выражений SQL, включая строгую проверку ошибок и некоторые детали синтаксиса. Такие объекты, как хранимые процедуры , триггеры и представления хранимых функций , всегда выполняются с sql_mode, который действовал во время их создания. sql_mode = ‘MSSQL’ можно использовать, чтобы MariaDB работала как можно ближе к SQL Server.

включает так называемый строгий режим InnoDB. Обычно некоторые ошибки в параметрах CREATE TABLE игнорируются. Когда включен строгий режим InnoDB, создание таблиц InnoDB завершится ошибкой с ошибкой, если будут сделаны определенные ошибки.

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

Дампы и sys.sql_modules

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

В качестве альтернативы процедура sp_helptext () возвращает информацию о том, как воссоздать определенный объект. Аналогичная информация также присутствует в таблице sql_modules ( столбец ) в схеме . Однако такая информация не является готовым набором операторов SQL.

Однако помните, что . Схема SQL Server примерно соответствует базе данных MariaDB.

Чтобы выполнить дамп, мы можем передать файл в mysql , клиент командной строки MariaDB.

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

mysql --show-warnings < dump.sql

указывает MariaDB выводить любые предупреждения, созданные операторами, содержащимися в дампе. Без этой опции предупреждения не будут появляться на экране. Предупреждения не останавливают выполнение дампа.

Ошибки появятся на экране. Ошибки остановят выполнение дампа, если не опция —force (или просто ).

Для других параметров см. .

Другой способ достичь той же цели — сначала запустить клиент в интерактивном режиме, а затем запустить команду. Например:

root@d5a54a082d1b:/
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 22
Server version: 10.4.7-MariaDB-1:10.4.7+maria~bionic mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB > \W
Show warnings enabled.
MariaDB > source dump.sql

В этом случае для отображения предупреждений мы использовали команду , где «w» — это верхний регистр. Чтобы скрыть предупреждения (что по умолчанию), мы можем использовать (нижний регистр).

Другие команды см.в разделе .

CSV Data

Если структуры таблиц уже находятся в MariaDB,нам нужно только импортировать данные таблиц.Хотя это можно сделать,как описано выше,более практичным может оказаться экспорт CSV-файлов из SQL Server и импорт их в MariaDB.

SQL Server Management Studio и некоторые другие инструменты Microsoft позволяют экспортировать файлы CSV.

MariaDB позволяет импортировать файлы CSV с помощью оператора LOAD DATA INFILE , который по сути является эквивалентом для MariaDB .

Может случиться так, что мы хотим импортировать не все данные, а их отфильтрованную или преобразованную версию. В этом случае мы можем предпочесть использовать механизм хранения CONNECT для доступа к файлам CSV и запроса к ним. Результаты запроса можно вставить в таблицу с помощью INSERT SELECT .

Перенос tempdb на другой диск

Главная » IT

Небольшая заметка как действовать в случае когда вам необходимо перенести базу tempdb на другой диск. Такая ситуация может случится в результате сбоя диска, на котором она была размещена в рабочем состоянии и вам потребуется перенос tempdb на другой диск для того, чтобы запустить SQL Server.

Запланированный перенос базы данных

В случае если вам просто необходимо перенести рабочую базу данных, то в manegement studio необходимо выполнить запрос:

Где:

database_name — имя базы данных, которую необходимо перенести;
logical_name — логическое имя файла;
disk:\new_path\new_file_name — новый путь к файлу данных.

Такую команду необходимо выполнить для каждого файла данных перемещаемой БД. После чего следует остановить службу MSSQL и переместить файлы данных в новое расположение. При перемещении не забудьте скопировать и права доступа на папку и файлы данных. Затем вновь запустите службы SQL Server.

Перемещение базы данных в случае сбоя

Такая ситуация может возникнуть, если восстановить базу данных в прежнее место невозможно, а без этой базы данных SQL сервер не запускается. Например, как я уже писал в начале, вышедший из строя диск с базой tempdb приведет к остановке MSSQL и невозможности его запуска.

Процедура действий в данном случае почти такая же как и при запланированном переносе. Все операции производим через командную строку cmd с правами администратора. Для начала необходимо запустить SQL сервер в режиме восстановления:

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

После того как введены все SQL запросы в интерактивном режиме sqlcmd необходимо ввести команду GO, чтобы выполнить этим самые запросы, а затем EXIT, чтобы выйти из интерактивного режима sqlcmd. Папка c:\tempdb (или та куда вы переносите базу данных tempdb) должна быть заранее создана. Если вы восстанавливаете не tempdb, а любую другую БД, то необходимо в эту папку так же положить файлы БД из резервной копии с именами совпадающими с теми, что указаны в SQL запросах.

Теперь можно перезапускать MSSQL сервер в стандартном режиме:

Если используется не экземпляр по умолчанию, а именованый, то необходимо заменить MSSQLSERVER на MSSQL$instancename, где instancename — наименование экземпляра MSSQL.

Если все сделано верно, то службы MSSQL запустятся и продолжат работу в штатном режиме.

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

С помощью проводника Windows перейдите в папку файловой системы, в которой находятся файлы базы данных. Правой кнопкой мыши щелкните эту папку и выберите пункт Свойства.

На вкладке Безопасность щелкните Изменитьи затем ― Добавить.

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

В поле Введите имена объектов для выбора введите имя идентификатора безопасности службы. В качестве идентификатора безопасности службы компонента Компонент Database Engine используйте NT SERVICEMSSQLSERVER для экземпляра по умолчанию или NT SERVICEMSSQL$InstanceName — для именованного экземпляра.

Щелкните Проверить имена , чтобы проверить введенные данные. Проверка зачастую выявляет ошибки, по ее окончании может появиться сообщение о том, что имя не найдено. При нажатии кнопки ОК открывается диалоговое окно Обнаружено несколько имен .Теперь выберите идентификатор безопасности службы MSSQLSERVER или NT SERVICEMSSQL$InstanceName и нажмите кнопку ОК. Снова нажмите кнопку ОК , чтобы вернуться в диалоговое окно Разрешения.

В поле имен Группа или пользователь выберите имя идентификатора безопасности службы, а затем в поле Разрешения для установите флажок Разрешить для параметра Полный доступ.

Нажмите кнопку Применить, а затем дважды кнопку ОК , чтобы выполнить выход.

Вот теперь, точно всё

Спасибо за внимание!. P.S

В зависимости от конкретной ОС, конкретной версии SQL сервера, вашей кармы и наличия солнечных вспышек, что-то может пойти не так. Прежде чем приступать к вышеописанным действиям, убедитесь, что: а) оно вам действительно надо б) вы морально готовы ц) вы понимаете, что вы делаете д) у вас вся ночь впереди, чтобы переустановить SQL заново и развернуть бэкап

P.S. В зависимости от конкретной ОС, конкретной версии SQL сервера, вашей кармы и наличия солнечных вспышек, что-то может пойти не так. Прежде чем приступать к вышеописанным действиям, убедитесь, что: а) оно вам действительно надо б) вы морально готовы ц) вы понимаете, что вы делаете д) у вас вся ночь впереди, чтобы переустановить SQL заново и развернуть бэкап.

detach_db2.PNG Просмотреть (31,7 КБ) Станислав Середницкий (Москва), 22/03/2018 17:27

detach_db.PNG Просмотреть (62,9 КБ) Станислав Середницкий (Москва), 22/03/2018 17:28

detach_db3.PNG Просмотреть (87,3 КБ) Станислав Середницкий (Москва), 22/03/2018 17:56

ОБЛАСТЬ ПРИМЕНЕНИЯ: SQL Server База данных SQL Azure Azure Synapse Analytics (хранилище данных SQL) Parallel Data Warehouse APPLIES TO: SQL Server Azure SQL Database Azure Synapse Analytics (SQL DW) Parallel Data Warehouse

SQL Server SQL Server позволяет переносить в новое место файлы данных, журнала и полнотекстового каталога пользовательской базы данных; новое место указывается при помощи предложения FILENAME инструкции ALTER DATABASE . In SQL Server SQL Server , you can move the data, log, and full-text catalog files of a user database to a new location by specifying the new file location in the FILENAME clause of the ALTER DATABASE statement. Этот метод подходит для перемещения файлов базы данных в пределах одного экземпляра SQL Server SQL Server . This method applies to moving database files within the same instance SQL Server SQL Server . Для переноса базы данных на другой экземпляр SQL Server SQL Server или другой сервер применяются операции резервного копирования и восстановления или отключения и подключения. To move a database to another instance of SQL Server SQL Server or to another server, use backup and restore or detach and attach operations.

Процедура восстановления после сбоя

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

Важно!

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

Убедитесь, что учетная запись службы для ядра СУБД SQL Server имеет полные разрешения на новое расположение файлов. Дополнительные сведения см. в статье Настройка учетных записей службы Windows и разрешений. Если учетная запись службы ядра СУБД не может управлять файлами в новом расположении, экземпляр SQL Server не запустится.
Остановите работу экземпляра SQL Server , если он запущен.
Запустите экземпляр SQL Server в режиме восстановления «только master», запустив из командной строки одну из следующих команд. При использовании параметра запуска 3608 SQL Server прекращается автоматический запуск и восстановление любой базы данных, кроме . Дополнительные сведения см. в разделах и .

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

В случае с экземпляром по умолчанию (MSSQLSERVER) запустите следующую команду:

В случае с именованным экземпляром запустите следующую команду:

Дополнительные сведения см. в статье Iniciar, parar, pausar, retomar e reiniciar os serviços SQL Server.
Сразу после запуска службы с флагом трассировки 3608 и запустите подключение к серверу sqlcmd, чтобы утвердить доступное отдельное подключение. Например, при локальном выполнении программы sqlcmd на том же сервере, что и экземпляр по умолчанию (MSSQLSERVER), а также для подключения с помощью встроенной проверки подлинности Active Directory выполните следующую команду:

Чтобы подключиться к именованному экземпляру на локальном сервере с помощью встроенной проверки подлинности Active Directory выполните следующее:

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

Для каждого перемещаемого файла используйте команды sqlcmd или SQL Server Management Studio для выполнения следующей инструкции. Дополнительные сведения об использовании программы sqlcmd см. в статье Использование программы sqlcmd. После открытия сеанса sqlcmd выполните следующую инструкцию по одному разу для перемещения каждого файла:
Завершите работу программы sqlcmd или SQL Server Management Studio.
Остановите экземпляр SQL Server. Например, в командной строке выполните команду .
Скопируйте файл (файлы) в новое расположение.
Повторно запустите экземпляр SQL Server. Например, в командной строке выполните команду .
Проверьте изменения в файле с помощью следующего запроса.
Поскольку на шаге 7 вместо того чтобы переместить файлы базы данных, вы скопировали их, теперь можно безопасно удалить неиспользуемые файлы базы данных из их предыдущего расположения.

Перемещение базы данных master Moving the master Database

Чтобы переместить базу данных master, выполните следующие действия. To move the master database, follow these steps.

В меню Пуск выберите Все программы, укажите Microsoft SQL Server, затем Средства настройкии выберите пункт Диспетчер конфигурации SQL Server. From the Start menu, point to All Programs, point to Microsoft SQL Server, point to Configuration Tools, and then click SQL Server Configuration Manager.

Находясь в узле Службы SQL Server , щелкните правой кнопкой мыши экземпляр SQL Server SQL Server , например SQL Server (MSSQLSERVER) , и выберите пункт Свойства. In the SQL Server Services node, right-click the instance of SQL Server SQL Server (for example, SQL Server (MSSQLSERVER)) and choose Properties.

В диалоговом окне Свойства SQL Server ( имя_экземпляра ) перейдите на вкладку Параметры запуска . In the SQL Server (instance_name) Properties dialog box, click the Startup Parameters tab.

В поле Существующие параметры выберите параметр -d, чтобы переместить файл данных master. In the Existing parameters box, select the -d parameter to move the master data file. Нажмите Обновить для сохранения изменений. Click Update to save the change.

В поле Укажите параметр запуска задайте новый путь к базе данных master. In the Specify a startup parameter box, change the parameter to the new path of the master database.

В поле Существующие параметры выберите параметр -l, чтобы переместить файл журнала master. In the Existing parameters box, select the -l parameter to move the master log file. Нажмите Обновить для сохранения изменений. Click Update to save the change.

Значение параметра для файла данных должно соответствовать параметру -d , а значение для файла журнала — параметру -l . The parameter value for the data file must follow the -d parameter and the value for the log file must follow the -l parameter. В следующем примере показаны значения параметров для указания местоположения файла базы данных master по умолчанию. The following example shows the parameter values for the default location of the master data file.

-dC:\Program Files\Microsoft SQL Server\MSSQL .MSSQLSERVER\MSSQL\DATA\master.mdf

-lC:\Program Files\Microsoft SQL Server\MSSQL .MSSQLSERVER\MSSQL\DATA\mastlog.ldf

Если планируется переместить файл данных базы данных master в расположение E:\SQLData , значения параметра будут изменены следующим образом. If the planned relocation for the master data file is E:\SQLData , the parameter values would be changed as follows:

Остановите работу экземпляра SQL Server SQL Server , щелкнув правой кнопкой мыши имя экземпляра и выбрав команду Остановить. Stop the instance of SQL Server SQL Server by right-clicking the instance name and choosing Stop.

Переместите файлы master.mdf и mastlog.ldf на новое место. Move the master.mdf and mastlog.ldf files to the new location.

Повторно запустите экземпляр SQL Server SQL Server . Restart the instance of SQL Server SQL Server .

Проверьте правильность изменений для базы данных master, выполнив следующий запрос. Verify the file change for the master database by running the following query.

На этом этапе среда SQL Server должна выполняться как обычно. At this point SQL Server should run normally. Однако корпорация Майкрософт рекомендует также изменить запись реестра, указанную в HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\instance_ID\Setup , где instance_ID имеет вид MSSQL13.MSSQLSERVER . However Microsoft recommends also adjusting the registry entry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\instance_ID\Setup , where instance_ID is like MSSQL13.MSSQLSERVER . В этом кусте измените значение SQLDataRoot на новый путь. In that hive, change the SQLDataRoot value to the new path. Невозможность обновления реестра может привести сбою исправления и обновления. Failure to update the registry can cause patching and upgrading to fail.

Сводка

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

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

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

Кроме того, при попытке создания полно текстового каталога индекса на диске, на котором ресурс SQL Server не зависит, отображается следующая ошибка:

Резервное копирование непосредственно на сетевой ресурс

Как правило, когда вы пытаетесь создать резервную копию непосредственно в сетевой папке с помощью такой команды:

Скорее всего, вы получите сообщение об ошибке:

Эта ошибка возникает, несмотря на то, что вы запустили команду резервного копирования SQL с использованием аутентификации Windows (ключ -E) и учетной записи Windows в качестве возможности доступа и копирования файлов на общий ресурс через проводник Windows.

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

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

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

Отредактируйте свойства службы SQL Server и на вкладке «Вход в систему» настройте службу для запуска в качестве альтернативной учетной записи с правами доступа к сети.

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

Перезапустите сервис.

Список служб теперь должен показывать, что служба SQL Server работает как настроенная вами учетная запись.

Теперь, когда вы запускаете команду для резервного копирования непосредственно в сетевой ресурс:

Вы должны увидеть сообщение об успехе:

Теперь файл резервной копии находится в общей сетевой папке:

Соображения об общих ресурсах сети

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

Эта ошибка означает, что имя пользователя и пароль учетной записи не были приняты сетевым ресурсом и команда завершилась неудачно.

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

Последствия для безопасности

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

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

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

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

1.3.4. Переименование базы данных

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

ALTER DATABASE TestDatabase 
MODIFY NAME = MyDatabase

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

Если вы попробовали выполнить этот сценарий, то верните ей старое имя TestDatabase, потому что в дальнейшем при тестировании сценариев мы будем ссылаться на него.

Решение

Если эта проблема проявляется регулярно, то рекомендуется переместить TEMPDB на другой диск большего размера.

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

определить логические имена файлов базы данных TEMPDB (колонка «NAME» результата выполнения процедуры). Для этого нужно в Query Analyzer выполнить следующую команду:

изменить месторасположение файлов базы данных TEMPDB с помощью команды ALTER DATABASE . Для этого нужно в Query Analyzer выполнить следующую последовательность команд:

Перезапустить Microsoft SQL Server.

Более подробное описание и рекомендации по использованию этих команд можно найти в документации по Microsoft SQL Server.

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

Следует учитывать, что для достижения максимальной производительности в работе tempdb может потребоваться разнесение файла данных и лога транзакций БД tempdb . Также следует отметить то, что для поднятия производительности хорошо нагруженных систем в документе MSDN Library — Optimizing tempdb Performance присутствует рекомендация создавать отдельные группы файлов tempdb на разных дисках для каждого ядра серверного процессора.

По умолчанию БД tempdb настроена на авто-расширение (Autogrow) и при каждой перезагрузке SQL Server пересоздаёт файлы этой БД с минимальным размером инициализации ( Initial Size ). Опираясь на рекомендации вышеуказанного документа, мы увеличим размер инициализации файлов tempdb таким образом, чтобы свести к минимуму затраты системных ресурсов на операции авто-расширения.

Для того чтобы определить где в текущий момент физически располагаются файлы БД tempdb , откроем SQL Server Management Studio и выполним SQL запрос:

FROM sys . master_files

WHERE database_id = DB_ID ( N’tempdb’ );

Получим примерно такой результат:

Затем, определившись с тем, на каких логических дисках будут расположены файлы БД, и какой они будут иметь размер, выполним SQL запрос:

ALTER DATABASE tempdb

MODIFY FILE ( NAME = tempdev , FILENAME = ‘H:TempDB_Datatempdb.mdf’ , SIZE = 10240 );

ALTER DATABASE tempdb

MODIFY FILE ( NAME = templog , FILENAME = ‘I:TempDB_Logtemplog.ldf’ , SIZE = 3072 );

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

После успешного выполнения запроса — перезапустим службу SQL Server и убедимся что наши файлы расположены там где мы хотим, выполнив SQL запрос:

FROM sys . master_files

WHERE database_id = DB_ID ( N’tempdb’ );

Если всё нормально, результат должен быть примерно таким:

После этого необходимо удалить файлы tempdb . mdf и templog . ldf с их старого месторасположения.

Как бороться со 100% нагрузкой процессора после переноса баз 1С со старого SQL сервера на новый

Проблема в том, что после переноса выполняются регламентные задания. Если Вы перенесете одну не очень большую базу, нагрузка будет кратковременной и позволит работать на сервере, но мы переносим 18 баз и все они довольно большие. Поэтому после переноса 10й базы у нас нагрузка на процессор выросла до 100%.

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

Тем самым нам удалось снизить нагрузку на сервер и перенести все базы.

Статья подготовлена компанией Сервисы для Бизнеса сервера для удаленной работы в России и Европе, безопасная почта, обмен файлами через Интернет с шифрованием (аналог DroBox).