Как перенести tempdb на другой диск: Как переместить tempdb на другой диск?

Содержание

Перенос системной базы tempdb на отдельный диск — Реальные заметки Ubuntu & Mikrotik

Прочитано:
2 824

По большинству рекомендаций имеет место быть после того, как развернули сервер базы данных (SQL Server 2008 R2) произвести некоторую его настройку нацеленную на производительную работу.

Вот к примеру: на сервере базы данных присутствует системная база tempdb, в моем случае она, как показывает практика активно задействуется приложением 1С для хранения промежуточных результатов и временных таблиц. Данная системная база tempdb если на сервере имеется несколько баз данных не простаивает, а используется сразу всеми 1С базами. Раз я поставил сервер базы данных в дефолтной конфигурации, то данная база располагается в дефолтной папке (C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA), а это как я уже понял плохая идея. Более практичным будет вынести ее (tempdb) на отдельный диск (LUN или HDD/SSD) .

Хочу также обратить внимание что кодировка данной системной базы tempdb должна также быть такой же как и у разворачиваемых баз. т. е. Cyrillic_General_CI_AS, посмотреть это можно так:

Start — All Programs — Microsoft SQL Server 2008 R2 — SQL Server Management Studio, авторизуюсь: (local)(SQL Server 10.50.1600 — NEMDOMB\aollo) — Databases — System Databases — через правый клик мышью на системной базе tempdb открываем свойства (Properties) — General — Maintenance — Collation — Cyrillic_General_CI_AS, после это уже для новых баз выбираем точно такую же кодировку.

Теперь собственно сама процедура по изменению месторасположения файла системной базы tempdb:

Start — All Programs — Microsoft SQL Server 2008 R2 — SQL Server Management Studio, авторизуюсь: (local)(SQL Server 10. 50.1600 — NEMDOMB\aollo), после создаю запрос New Query (Новый Запрос) и в поле с мигающим курсором ввожу следующий код:

use master

alter database tempdb

modify file (

name = tempdev,

filename = N'D:\tempdb.mdf')

go

alter database tempdb

modify file (

name = templog,

filename = N'D:\templog.ldf')

go

После запускаю написанный выше запрос: Query — Execute (F5) , после чего будут в окне Messages сформированы сообщения отчета:

The file «tempdev» has been modified in the system catalog. The new path will be used the next time the database is started.

The file «templog» has been modified in the system catalog. The new path will be used the next time the database is started.

Теперь чтобы изменения пришли в действо, нужно перезапустить SQL—сервер:

Start — Administrative Tools — Services — находим службу службу SQL Server и перезапускаем ее) или же через консоль командной строки:

Start — All Programs — Accessories — запускаем командную строку с правами Администратора и:

C:\Windows\system32>net stop MSSQLSERVER

The following services are dependent on the SQL Server (MSSQLSERVER) service.

Stopping the SQL Server (MSSQLSERVER) service will also stop these services.

SQL Server Agent (MSSQLSERVER)

Do you want to continue this operation? (Y/N) [N]: y

The SQL Server Agent (MSSQLSERVER) service is stopping.

The SQL Server Agent (MSSQLSERVER) service was stopped successfully.

The SQL Server (MSSQLSERVER) service is stopping.

The SQL Server (MSSQLSERVER) service was stopped successfully.

C:\Windows\system32>net start MSSQLSERVER

C:\Windows\system32>net start SQLSERVERAGENT

Теперь файл базы tempdb и его лог файл располагаются на новом месте, согласно моему скрипту выше — это диск D:

C:\Windows\system32>dir d:\

Volume in drive D is New Volume

Volume Serial Number is EC61-BE42

Directory of d:\

20.11.2015 15:03 8 388 608 tempdb.mdf

20.11.2015 15:03 524 288 templog.ldf

2 File(s) 8 912 896 bytes

0 Dir(s) 53 446 139 904 bytes free

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

C:\Windows\system32>del /f /q "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\tempdb.mdf"

C:\Windows\system32>del /f /q "C:\Program Files\Microsoft SQL Server\MSSQL10_50. MSSQLSERVER\MSSQL\DATA\templog.ldf"

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

Перенос экземпляра SQL Server 2012 на другой диск в кластере Windows Server 2012 R2

Имеется двух-узловой кластер Windows Failover Cluster из двух виртуальных машин Hyper-V c гостевой ОС Windows Server 2012 R2. В кластере развёрнуто несколько высоко-доступных экземпляров SQL Server 2012 SP3. Каждый кластерный экземпляр SQL Server расположен на выделенном кластерном диске. Возникла необходимость переноса экземпляров SQL с одного кластерного диска на другой с последующим отключением ранее используемого кластерного диска. В этой заметке будет пошагово рассмотрена процедура данного переноса на примере отдельно взятого кластерного экземпляра SQL Server.

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

1. Подключаем новый LUN к узлам кластера
2. Инициализируем LUN и форматируем новый раздел NTFS
3. Добавляем новый диск в кластер Failover Cluster
4. Снимаем рабочую нагрузку с экземпляра SQL Server
5. Добавляем дисковый ресурс к кластерной роли SQL Server
6. Выполняем частичную остановку кластерной роли SQL Server (останавливаем Имя и Службы)
7. Копируем файлы экземпляра SQL Server на целевой кластерный диск (robocopy)
8. Изменяем буквы кластерных дисков
9. Изменяем дисковую зависимость кластерного ресурса SQL Server
10. Запускаем кластерную роль SQL Server
11. Проверяем доступность экземпляра SQL Server
12. Выполняем проверочную миграцию кластерной роли SQL Server между узлами кластера
13. Возобновляем рабочую нагрузку на экземпляр SQL Server
14. Удаляем из кластера старый диск
15. Отключаем LUN старого диска от виртуальных машин

Рассмотрим все шаги по порядку.

Шаг 1. Подключаем новый LUN к виртуальным машинам

В нашем случае LUN-ы с СХД пробрасываются в виртуальные машины через FC SAN посредствам технологии NPIV. Поэтому первым делом нам нужно презентовать дополнительный новый LUN на оба узла кластера Windows Failover Cluster, то есть на обе виртуальные машины на базе гипервизора Hyper-V в Windows Server 2012 R2. Описывать то, как это делается не будем, так как это зависит от используемой инфраструктуры FC SAN, моделей коммутаторов и СХД. В конечном итоге на каждом из наших виртуальных серверов в оснастке Device Manager мы должны увидеть новые дисковые устройства

Если LUN подключен к серверу по нескольким путям, то проверяем доступность всех путей на вкладке MPIO в свойствах подключенного дискового устройства. Запомним Location нового диска, так как он нам может пригодится на следующем шаге (справедливо, когда подключается множество однообразных дисков).

Шаг 2. Форматируем новый раздел NTFS

Так как LUN подключен к обоим серверам, выполнить инициализацию и форматирование нового диска можно на любом из этих серверов. Я предпочитаю предварительно мигрировать все кластерные роли на один из серверов и выполнять процедуру настройки нового диска на свободном узле кластера. Откроем оснастку Disk Management и по Location найдём интересующий нас новый диск. Сначала переведём диск в Online, затем выполним его инициализацию – Initialize Disk

В процессе инициализации диска будет создана таблица разделов.

После того, как диск будет проинициализирован, создаём на нём новый раздел.

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

Теперь созданный логический диск нужно подключить к кластеру Windows Failover Cluster.

Шаг 3. Добавляем новый диск в кластер Failover Cluster

В оснастке Failover Cluster Manager подкачаемся к кластеру, содержащему кластерную роль высоко-доступного экземпляра SQL Server и в разделе Storage > Disks вызываем пункт добавления нового диска Add Disk. В открывшемся поверх окне выбираем ранее отформатированный нами диск:

Диск появится в консоли с типом Available Storage, то есть в данный момент он не привязан ни к какой кластерной роли.

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

Шаг 4. Снимаем рабочую нагрузку с экземпляра SQL Server

На данном этапе мы должны снять всю продуктивную нагрузку на наш кластерный экземпляр SQL Server, то есть выключить все приложения и службы, которые могут обращаться к базам данных экземпляра. В нашем примере выполняется перенос экземпляра SQL Server, в котором размещаются базы данных, используемые в работе сервера Microsoft System Center Configuration Manager (SCCM). Таким образом на данном шаге на сервере SCCM мы останавливаем все службы, которые используют обращение к базам данных SQL Server.

Шаг 5. Добавляем дисковый ресурс к кластерной роли SQL Server

В оснастке Failover Cluster Manager переходим а раздел управления кластерными ролями (Roles), в списке доступных ролей выбираем целевой кластерный экземпляр SQL Server и в меню действий вызываем пункт добавления дискового ресурса — Add Storage.

В открывшемся окне из списка кластерных дисков с типом Available Storage выбираем ранее соответствующий свободный кластерный диск.

После этого в перечне ресурсов кластерной роли SQL Server появится новый дисковый ресурс.

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

Шаг 6. Выполняем частичную остановку кластерной роли SQL Server

В перечне ресурсов кластерной роли выбираем ресурс с именем кластера Name:<Имя кластера> и в меню действий вызываем пункт выключения ресурса – Take Offline.

После этого будут остановлены ресурсы службы экземпляра SQL Server (<Имя экземпляра>) и агента SQL Server Agent (<Имя экземпляра>). А сама кластерная роль изменит статус на Partially Running.

Соответствующие указанным кластерным ресурсам системные службы SQL Server (<Имя экземпляра>) и SQL Server Agent (<Имя экземпляра>), относящиеся к нашему экземпляру SQL Server будут остановлены. Убедиться в этом можно проверив состояние служб в оснастке управления службами Services и/или оснастке SQL Server Configuration Manager.

Шаг 7. Копируем файлы экземпляра SQL Server на целевой кластерный диск

Частичная остановка кластерной роли с нетронутыми дисковыми ресурсами роли позволит нам выполнить любые файловые операции с файлами экземпляра SQL Server, так как теперь эти файлы не блокируются системными службами экземпляра. В нашем примере файлы остановленного кластерного экземпляра SQL Server размещены в каталоге MSSQL11.SCCM на диске S: и нам нужно скопировать этот каталог на новый кластерный диск X:.

Для правильного полноценного копирования всех атрибутов файлов и разрешений безопасности, установленных на всех вложенных каталогах и файлах, воспользуемся утилитой robocopy (команду выполнять, запустив консоль от имени Администратора):

ROBOCOPY "S:\MSSQL11.SCCM" "X:\MSSQL11.SCCM" /E /B /COPYALL /DCOPY:DAT /V /R:2 /W:10 /UNILOG+:X:\MSSQL11. SCCM.log /BYTES /TEE /NP /UNICODE

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

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

Шаг 8. Изменяем буквы кластерных дисков

Так как конфигурация остановленного экземпляра SQL Server хочет видеть свои файлы в каталоге S:\MSSQL11.SCCM, нам потребуется выполнить замену букв дисков, таким образом, чтобы буква S: была присвоена вновь подключенному диску, на который мы только что скопировали файлы экземпляра. А старому диску мы присвоим текущую букву нового диска (X:). То есть фактически мы должны поменять местами буквы старого и нового диска.

Чтобы букву диска S: можно было присвоить новому диску, эту букву нужно освободить, то есть снять её со старого диска. Для этого в оснастке Failover Cluster Manager и в области управления ресурсами кластерной роли выбираем старый диск и в меню действий вызываем пункт смены буквы диска – Change Drive Letter. В окне выбора буквы диска выбираем вариант <none> и сохраняем изменения.

Теперь буква диска S: свободна и мы назначаем её на новый диск.

После этого старому диску присваиваем освободившуюся букву X:

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

Шаг 9. Изменяем дисковую зависимость кластерного ресурса SQL Server

Среди ресурсов кластерной роли SQL Server в конфигурации по умолчанию только один ресурс имеет зависимость от кластерного диска – это ресурс службы экземпляра с именем SQL Server (<Имя экземпляра>). Откроем свойства этого ресурса и на закладке зависимостей Dependencies из выпадающего списка вместо старого кластерного диска выберем новый диск. Сохраним изменения.

Теперь всё готово к запуску кластерной роли.

Шаг 10. Запускаем кластерную роль SQL Server

Пробуем запустить ресурс службы экземпляра с именем SQL Server (<Имя экземпляра>), выбрав в меню действий Bring Online. При запуске этого ресурса автоматически должен быть запущен зависимый ресурс с именем кластера Name:<Имя кластера>.

После этого аналогичным образом запускаем кластерный ресурс агента SQL Server Agent (<Имя экземпляра>).

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

Шаг 11. Проверяем доступность экземпляра SQL Server

Проверяем статус системных служб SQL Server в оснастках управления службами Services или SQL Server Configuration Manager. Пробуем подключиться к экземпляру, например с помощью консоли SQL Server Management Studio. Если всё хорошо, переходим к проверке успешности миграции кластерной роли между узлами кластера.

Шаг 12. Выполняем проверочную миграцию кластерной роли SQL Server

Выполняем проверочную передачу кластерной роли SQL Server на второй узел кластера и обратно. Сделать это можно как с помощью оснастки Failover Cluster Manager , так и с помощью PowerShell:

Get-ClusterGroup "<Имя кластерной роли>" | Move-ClusterGroup

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

Шаг 13. Возобновляем рабочую нагрузку на экземпляр SQL Server

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

Шаг 14. Удаляем из кластера старый диск

В оснастке Failover Cluster Manager в области управления ресурсами кластерной роли выбираем старый кластерный диск (он теперь с буквой X:) и в меню действий вызываем команду его извлечения из кластерной роли — Remove from SQL Server (<Имя экземпляра>).

После этого переходим в раздел управления дисками кластера (Storage > Disks) и удаляем старый диск, имеющий теперь статус Available Storage.

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

Шаг 15. Отключаем LUN старого диска от виртуальных машин

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

Дополнительные источники информации:

Justin’s IT Blog — How-To: Migrate MS SQL Cluster to a New SAN

Перемещение файлов данных и журналов TempDB на новый диск в SQL Server

Хотя это не то, что вам нужно делать часто, иногда может возникнуть необходимость переместить базу данных tempdb на новый диск. Этот сценарий произошел недавно, когда в процессе сборки виртуального сервера мне было создано всего 2 дополнительных диска. Поскольку рекомендуется размещать данные, журнал и базу данных tempdb на отдельных дисках, мне пришлось временно поместить базу данных tempdb на диск E:\ при первоначальной настройке новой установки SQL Server.

В конце концов новый диск, назовем его R:\, был добавлен к серверу, и теперь мне нужно было переместить базу данных tempdb на этот диск.

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

ИСПОЛЬЗОВАТЬ [мастер]
ВЫБЕРИТЕ имя КАК «Имя»,
Physical_name AS 'Физическое местоположение',
state_desc AS 'Статус'
ИЗ sys.master_files
ГДЕ database_id = DB_ID('tempdb')

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

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

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

ИСПОЛЬЗОВАТЬ [мастер]
ИДТИ
ИЗМЕНИТЬ БАЗУ ДАННЫХ tempdb
ИЗМЕНИТЬ ФАЙЛ (ИМЯ = tempdev,
FILENAME = 'R:\SQL\tempdb.mdf')
ИДТИ
ИЗМЕНИТЬ БАЗУ ДАННЫХ tempdb
ИЗМЕНИТЬ ФАЙЛ (ИМЯ = templog,
FILENAME = 'R:\SQL\templog.ldf')
ИДТИ

Последним шагом является перезапуск экземпляра SQL Server. Вы можете сделать это, щелкнув правой кнопкой мыши имя SQL Server в обозревателе объектов и выбрав Остановить , затем Запустить службу или открыть Диспетчер конфигурации SQL Server и сделать это оттуда. Я предпочитаю использовать для этого Диспетчер конфигурации SQL Server, так как у меня были проблемы с работой служб при удаленном подключении к SQL-серверу через Management Studio. Хотя это случается редко, этого достаточно, чтобы побудить меня всегда входить непосредственно на сервер для запуска/остановки служб.

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

Описанные выше действия также можно использовать для перемещения системных баз данных msdb и model. Вам просто нужно изменить значения ALTER DATABASE , NAME и FILENAME , чтобы они указывали на применимую базу данных. Если вы хотите переместить базу данных master , вам потребуется несколько иной подход. Чтобы узнать больше об этом, вы можете обратиться к моему сообщению о перемещении основной системной базы данных в новое место в SQL Server.

Поместить tempdb в хранилище экземпляров

Поместите базу данных tempdb в хранилище экземпляров — директивное руководство AWS

Перемещение базы данных tempdb в хранилище экземпляровИнициализация хранилища экземпляровИспользование расширения буферного пула

При использовании хранилища экземпляров Amazon EC2 используйте том хранилища экземпляров для базы данных tempdb. Ан
хранилище экземпляров предоставляет временное (эфемерное) хранилище на уровне блоков для вашего экземпляра. Мы
рекомендуется размещать базу данных tempdb на томе хранилища экземпляров по двум причинам: скорость и стоимость.
Tempdb обычно является наиболее интенсивно используемой базой данных, поэтому она выигрывает от самого быстрого доступного
водить машину. Еще одним преимуществом размещения базы данных tempdb в хранилище экземпляров является экономия средств, поскольку вы
не оплачивается отдельно за ввод-вывод по отношению к хранилищу экземпляров.

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

При использовании тома хранилища экземпляров:

Инициализировать том перед запуском службы SQL Server. В противном случае SQL-сервер
процедура запуска завершится ошибкой.
Предоставить разрешения (полный доступ) на том хранилища экземпляров явно SQL
Учетная запись запуска сервера.

Перемещение tempdb в хранилище экземпляров

Чтобы переместить tempdb в том хранилища экземпляров:

В Windows запустите diskmgmt.msc от имени администратора, чтобы открыть
Системная утилита управления дисками.
Инициализировать новый диск.
Щелкните диск правой кнопкой мыши и выберите New Simple Volume .
Выполните подсказки, используя следующие параметры для форматирования тома:
Дополнительные сведения см. в документации по управлению дисками на веб-сайте Microsoft.
Подключитесь к экземпляру SQL Server и выполните следующую команду, чтобы
логическое и физическое имя файла базы данных tempdb:
```
 $ sp_helpdb 'tempdb' 
```
На следующем снимке экрана показана команда и ее выходные данные.

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

 Мастер ЕГЭ
ИДТИ
ИЗМЕНИТЬ ФАЙЛ ИЗМЕНЕНИЯ БАЗЫ ДАННЫХ TempDB (ИМЯ = tempdev, ИМЯ ФАЙЛА = 'T:\tempdb.mdf', SIZE = 524288 КБ)
ИДТИ
ИЗМЕНИТЬ ФАЙЛ ИЗМЕНЕНИЯ БАЗЫ ДАННЫХ TempDB (ИМЯ = temp2, FILENAME = 'T:\tempdb_mssql_2.ndf', SIZE = 524288 КБ)
ИДТИ
ИЗМЕНИТЬ ФАЙЛ ИЗМЕНЕНИЯ БАЗЫ ДАННЫХ TempDB (ИМЯ = temp3, ИМЯ ФАЙЛА = 'T:\tempdb_mssql_3.ndf', SIZE = 524288 КБ)
ИДТИ
ИЗМЕНИТЬ ФАЙЛ ИЗМЕНЕНИЯ TempDB БАЗЫ ДАННЫХ (ИМЯ = temp4, FILENAME = 'T:\tempdb_mssql_4.ndf', SIZE = 524288 КБ)
ИДТИ
ИЗМЕНИТЬ ФАЙЛ ИЗМЕНЕНИЯ БАЗЫ ДАННЫХ TempDB (ИМЯ = templog, ИМЯ ФАЙЛА = 'T:\templog.ldf')
ВПЕРЕД

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

Чтобы убедиться, что том хранилища экземпляров инициализирован до запуска SQL Server в
В случае перезагрузки экземпляра или запуска/остановки выполните действия, описанные в следующем разделе. В противном случае SQL
Запуск сервера завершится ошибкой, так как tempdb не была инициализирована.

Инициализация хранилища экземпляров

Для инициализации хранилища данных:

Откройте диспетчер служб Windows ( services. msc ) и установите
SQL Server и зависимые от него службы (например, агент SQL Server) для запуска вручную.
(Вы будете использовать сценарий, чтобы запустить его, когда том хранилища экземпляров будет готов.)
Создайте сценарий PowerShell для передачи в экземпляр Amazon EC2 в качестве пользовательских данных. Этот скрипт делает
следующее:
- Обнаруживает временное хранилище и создает для него диск tempdb (диск T в
  пример).
- Обновляет временный диск, если экземпляр EC2 останавливается и перезапускается.
- Предоставляет стартовой учетной записи SQL Server полный контроль над только что инициализированным
  том временной базы данных. В примере предполагается экземпляр по умолчанию, поэтому используется NT. СЕРВИС\МССКЛСЕРВЕР . Для именованного экземпляра это обычно будет NT. SERVICE\MSSQL$ по
  по умолчанию.
- Сохраняет скрипт на локальном томе ( c:\scripts в
  пример) и присваивает ему имя файла
  ( InstanceStoreMapping.ps1 ).
- Создает запланированное задание с помощью планировщика заданий Windows. Эта задача запускает
  Скрипт PowerShell при запуске.
- Запускает SQL Server и агент SQL Server после предыдущих действий.
Следующий скрипт из второй лабораторной работы MS-SQL
Доступность Group Workshop с некоторыми изменениями. Скопируйте скрипт в
Поле данных пользователя при запуске экземпляра EC2 и настройке
это по необходимости.

 
# Создаем пул и виртуальный диск для TempDB, используя локальный NVMe, ReFS 64K, T:Drive
    $NVMe = Get-PhysicalDisk | ? { $_. CanPool -eq $True -and $_.FriendlyName -eq "NVMe Amazon EC2 NVMe"}
    New-StoragePool -FriendlyName TempDBPool -StorageSubsystemFriendlyName "Хранилище Windows*" -PhysicalDisks $NVMe
    New-VirtualDisk -StoragePoolFriendlyName TempDBPool -FriendlyName TempDBDisk -ResiliencySettingName simple -ProvisioningType Fixed -UseMaximumSize
    Get-VirtualDisk -FriendlyName TempDBDisk | Получить-Диск | Инициализировать-Диск-Passthru | New-Partition -DriveLetter T -UseMaximumSize | Format-Volume -FileSystem ReFS -AllocationUnitSize 65536 -NewFileSystemLabel TempDBfiles -Confirm:$false
    # Скрипт для обработки обновления NVMe при запуске/остановке экземпляра
    $InstanceStoreMapping = {
    если (!(Get-Volume -DriveLetter T)) {
        #Создать пул и виртуальный диск для TempDB, используя зеркалирование с NVMe
        $NVMe = Get-PhysicalDisk | ? { $_.CanPool -eq $True -and $_.FriendlyName -eq "NVMe Amazon EC2 NVMe"}
        New-StoragePool -FriendlyName TempDBPool -StorageSubsystemFriendlyName "Хранилище Windows*" -PhysicalDisks $NVMe
        New-VirtualDisk -StoragePoolFriendlyName TempDBPool -FriendlyName TempDBDisk -ResiliencySettingName simple -ProvisioningType Fixed -UseMaximumSize
        Get-VirtualDisk -FriendlyName TempDBDisk | Получить-Диск | Инициализировать-Диск-Passthru | New-Partition -DriveLetter T -UseMaximumSize | Format-Volume -FileSystem ReFS -AllocationUnitSize 65536 -NewFileSystemLabel TempDBfiles -Confirm:$false
         #предоставить стартовой учетной записи SQL Server полный доступ к новому диску
        $item = gi -literalpath "T:\"
        $acl = $item. GetAccessControl()
        $permission="NT SERVICE\MSSQLSERVER","Полный контроль","Разрешить"
        $rule = New-Object System.Security.AccessControl.FileSystemAccessRule $permission
        $acl.SetAccessRule($правило)
        $item.SetAccessControl($acl)
        # Перезапустите SQL, чтобы он мог создать базу данных tempdb на новом диске
        Остановка службы SQLSERVERAGENT
        Остановить службу MSSQLSERVER
        Запуск службы MSSQLSERVER
        Служба запуска SQLSERVERAGENT
        }
    }
    Каталог New-Item -ItemType -Path c:\Scripts
    $InstanceStoreMapping | set-content c:\Scripts\InstanceStoreMapping.ps1
# Создать запланированную задачу при запуске для запуска сценария, если это необходимо (если T: потерян)
    $action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument 'c:\scripts\InstanceStoreMapping.ps1'
    $trigger = New-ScheduledTaskTrigger-AtStartup
    Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "Перестроить TempDBPool" -Description "Перестроить TempDBPool, если требуется" -RunLevel Highest -User System

Использование расширения буферного пула

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