Перевод базы данных SQL Server в Offline(перевести в автономный режим)
Решение:
правой кнопкой по бд — Создать запрос(Query):
| Цитата |
|---|
| USE master GO ALTER DATABASE [Имя базы данных] SET OFFLINE WITH ROLLBACK IMMEDIATE GO |
. инструкции WITH ROLLBACK IMMEDIATE, которая должна закрыть все активные соединения …но по факту может быть: ALTER DATABASE failed because a lock could not be placed on databas
И чтобы понять кто занимает бд (информацию об активных сессиях )
| Цитата |
|---|
| USE master GO SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID(‘Имя базы данных’) GO |
Из полученного вывода станет понятно, – какой именно пользователь и из какого приложения “держит” нашу базу данных. Одним из интересующих нас показателей будет идентификатор соединения — spid
image
Помимо представленного примера информацию о всех активных соединениях к серверу БД можно получить с помощью хранимых процедур sp_who или sp_who2:
| Цитата |
|---|
| EXEC sp_who2 |
| Цитата |
|---|
| KILL <spid> |
После сброса активных сессий интересующая нас база данных должна успешно завершить переход состояние Offline.
Принудительный автономный режим базы данных MS SQL
СервераСредний уровень
Перевод базы данных Microsoft SQL в Offline режим через SQL Server Management Studio (традиционный способ это выбрать в SSMS конкретную базу данных, далее Задачи — Перевести в автомоторный режим) может затянуться на несколько часов, как правило причиной такого поведения являются активные сеансы.
Перевод базы данных в режим «вне сети».
Что бы заставить желаемую базу данных принудительно и незамедлительно перейти в статус «Вне сети» и перестать смотреть на диалоговое окно с отключением, требуется закрыть все активные соединения с помощью инструкции WITH ROLLBACK IMMEDIATE.
Выполним всего один запрос. Предварительно замените [ИМЯ БД] на имя вашей базы данных.
Для того, чтобы получить её состояние обратно в Online, так же можно выполнить запрос:
Как правильно завершить соединение с базой данных
Нередко при выполнении определенных задач по обслуживанию или обновлению администратору приходится прерывать все соединения пользователей с базой данных. Иногда причиной тому правила эксклюзивности при обновлении или стремление защитить целостность данных и не влиять на работу клиентов при миграции, когда нужно обеспечить корректность изменений. Завершить соединения с базой данных можно несколькими способами.
Вариант 1. Простой, но неисчерпывающий подход: перевести базу данных в автономный режим
При использовании этого метода мы просто переводим базу данных в автономный режим, а затем возвращаем ее в оперативный режим. Этот процесс прост, но он не завершится до тех пор, пока не будут закончены все текущие транзакции и закрыты все сеансы. Это не лучший подход к переводу базы данных в монопольный режим, и я не рекомендую его использовать.
Вы можете выполнить отмену всех открытых транзакций и закрыть сеансы с помощью дополнительного предложения ROLLBACK IMMEDIATE, но помните, что администратору базы данных следует избегать команд, негативно влияющих на работу конечных пользователей:
- Транзакции завершаются перед разрывом соединения, если не выдана команда ROLLBACK IMMEDIATE; простота выполнения.
- В зависимости от открытых транзакций вам, возможно, придется ждать завершения автономной команды, если не включить ROLLBACK IMMEDIATE.
Открытые сеансы без активных транзакций не завершаются и не закрываются, если не задействовано ROLLBACK IMMEDIATE, поэтому технически этот вариант нс позволяет достичь цели.
Рекомендуется избегать этого метода, если только у вас нет полного понимания того, как приложения и пользователи работают с базой данных, и уверенности, что перечисленные выше недостатки не помешают вам получить монопольный доступ.
Вариант 2. Динамическая инструкция SQL для завершения всех пользовательских сеансов базы данных
Можно воспользоваться динамическим административным представлением sys.dm exec sessions для идентификации всех пользовательских сеансов для определенной базы данных — или всех баз данных, если применяемые изменения охватывают область сервера, — и создать динамическую инструкцию KILL для каждого сеанса, возвращаемого из запроса, код которого приведен в листинге.
- Возможности этого программного кода несколько шире, чем у первого варианта, и теперь в вашем распоряжении есть код (благодаря этой статье).
- Существует проблема промежутка времени между выполнением запроса для получения динамической инструкции SQL и запуском этой динамической инструкции. В этот период создаются новые сеансы, которые будут вне действия динамической инструкции SQL или, хуже того, могут быть выполнены, а значения session id завершаемых сеансов могут быть назначены сеансам, не имеющим никакого отношения к базе данных, с которой вы работаете.
- Во время применения KILL выполняется откат сеансов, и пользователи могут думать, что их транзакции зафиксированы, хотя на самом деле произошла их отмена.
Вариант 3. Изменение базы данных на SINGLE_USER или RESTRICTEDJJSER
Существует три различных режима подключения пользователей к базам данных: MULTI USER, SINGLE USER и RESTRICTED USER. Обычно база данных находится в режиме MULTI_ USER, то есть несколько пользователей могут подключаться одновременно. В режиме SINGLE_USER база данных может обслуживать один сеанс, и, когда этот сеанс открыт, для базы данных не может быть организовано никаких других сеансов. В режиме RESTRICTED_USER любой пользователь, который является участником роли базы данных dbowner или участником роли сервера sysadmin или dbereator, может подключиться к базе данных, но все остальные пользователи лишаются этой возможности. При переключении, например, первого режима все открытые сеансы, нс относящиеся к привилегированным ролям, должны завершить работу, прежде чем будет выполнена инструкция ALTER DATABASE.
Программный код для каждого режима:
Если приемлемо выполнить отмену всех открытых транзакций базы данных, можно усовершенствовать приведенную выше команду, но помните о проблемах, уже упомянутых в отношении WITH ROLLBACK IMMEDIATE:
По окончании вернитесь к режиму MULTI_USER с помощью команды:
- Транзакции могут завершиться, прежде чем разрываются подключения (если не включено предложение WITH ROLLBACK IMMEDIATE).
- У привилегированных пользователей по-прежнему остается возможность подключения через RESTRICTED_USER. Если вы корректно назначили права, то у вас нс будет конечных пользователей с уровнем разрешений, который обеспечил бы им непрерывный доступ. Единственные пользователи, которым нужен такой уровень доступа, — это администраторы баз данных и ИТ-персонал, непосредственно ответственный за администрирование среды обработки данных и часто выполняющий процесс обновления или миграции, ради ознакомления с которым вы и читаете эту статью.
- В зависимости от открытых транзакций вам, возможно, придется ждать завершения автономной команды, если вы нс используете предложение WITH ROLLBACK IMMEDIATE.
- Если применяется параметр SINGLE_ USER, рекомендуется вставить его в сценарий обновления в начале сценария. В противном случае после закрытия сеанса, выполнившего инструкцию ALTER DATABASE… SET SINGLE USER, конечный пользователь может получить контроль над базой данных, и вам не удастся подключиться или изменить ее, пока этот сеанс не будет закрыт и при условии, что никто другой не предпримет попытки подключения.
Дополнительные соображения
В зависимости от особенностей использования баз данных настоятельно рекомендуется в первую очередь везде, где возможно, ограничить подключения приложений. Есть вероятность, что пользовательские соединения будут восстановлены, если не пресечь попытки пользователей вернуться к базе данных после принятия описанных выше мер. Данная задача — еше одно напоминание о том, что, имея дело с технологиями, вы никогда не работаете индивидуально. Это непременно коллективные усилия, когда успех всего проекта зависит от слаженных действий нескольких групп.
SQL Server 2011 — Автономная база данных
Denali несет в себе множество новых инструментов, а так же расширений функционала для существующих. В этой статье в деталях рассмотрим один из новых инструментов, который, я уверен, придется по душе разработчикам баз данных. Этот инструмент, фича — автономные базы данных (Contained Database). Рассмотрим что они собой представляют, как с ними работать, к чему можно применить и другие вещи.
Что не так с текущими базами?
Перед тем как перейти к описанию сущности независимых баз данных, рассмотрим почему они были придуманы и чем не устраивает разработчиков текущая реализация.
Вот некоторые из ключевых проблем:
Потеря информации во время разворачивания базы или передвижения ее между серверами.
Во время передвижения базы данных между серверами, то такая информация как логины, пароли, задания агента SQL Server и прочее не может быть передвинуто вместе с базой. Потому что эта информация принадлежит серверу баз данных. Пересоздание упомянутых объектов руками не самое приятное занятие, которое к тому же занимает много времени и не гарантирует защиты от ошибок.
Различия между Разработкой и Разворачиванием приложений.
При разворачивании приложения разработчиков могут поджидать самые разные неприятности, начиная от несовпадения тонких настроек окружения, таких как разрешения на создание новых логинов, отключенная командная строка (xp_cmdshell), языковые настройки сервера.
Вопросы безопасности в администрировании приложения.
Весьма сложно администрировать и поддерживать отдельно стоящую базу данных из-за того, что, например, задания агента SQL Server доступны в пределах всего сервера, что влечет за собой повышение привилегий отдельно взятых пользователей. Однако эти повышенные права дают доступ к другим частям сервера, которые не желательно открывать. Все это может вести к серьезным проблемам безопасности.
После того, как обозначили ключевые недостатки существующих баз, перейдем к описанию нового типа.
Автономные базы данных
Уже исходя из названия и описанных недостатков старых баз, я думаю, вы догадываетесь, в чем прелесть нового типа баз. Автономные базы данных хранят всю необходимую для работы и настройки информацию в себе. Такие базы полностью независимы от настроек SQL сервера, не имеют внешних зависимостей и содержат в себе все механизмы аутентификации. Так же не имеет значения, какая настройка языка выставлена у сервера.
Таблицы, функции, процедуры, ограничения, схемы, типы, библиотеки, представления, логины, задания агента SQL Server, системные настройки, связанные сервера (linked servers) — все хранится в базе.
Естественно, что главным преимуществом такой базы будет легкость разворачивания и переноса. Достаточно только развернуть базу и она сразу готова к работе. Больше не будет забытых скриптов для пользователей, их ролей, агентов и тд.
Термины, которые надо запомнить
Application boundary (граница приложения) — граница между экземпляром сервера и кодом приложения. Под кодом приложения понимается вся база со всеми объектами, которые могут понадобиться в процессе работы.
Application Model (модель приложения) — внутри границ приложения есть место, где идет разработка и управление приложением.
Contained (содержащийся) — пользовательская сущность которая полностью содержится в пределах границы приложения.
Uncontained (не содержащийся) — пользовательская сущность которая пересекает границы приложения.
Non-contained database (зависимая база данных) -база, для которой свойство containment = NONE. База зависит от некоторых объектов принадлежащих экземпляру сервера.
Fully contained database (автономная база данных) — база, которая не позволяет каким-либо объектам или функциям пересекать границы приложения.
Partially contained database (частично зависимая база данных) — база, которая позволяет некоторым объектам действовать с пересечением границ приложения. Доступно в CTP 1.
Contained user (автономный пользователь)
Есть два типа таких пользователей:
- Пользователь, который авторизуется средствами базы данных.
- Пользователь, который использует средства Windows и его данные не содержаться в базе данных.
4 шага для создания автономной базы данных
Я думаю, что на данный момент уже достаточно теоретических знаний и концепций о том, как работает такая база данных, и настало время немного размяться «в поле». Следующие 4 шага описывают как создать автономную базу данных.
Шаг 1. Разрешить использование автономных баз данных на уровне сервера.
Шаг 2. Создать базу данных и выставить режим автономности как частичный. Свойство CONTAINMENT должно быть равно Partial.
Шаг 3. Создать автономного пользователя в новой базе данных.
Шаг 4. Зайти в новую базу данных под учетной записью автономного пользователя.
Теперь рассмотрим каждый шаг подробно и в картинках.
Шаг 1. Разрешить использование автономных баз данных на уровне сервера.
Присоединитесь к экземпляру нового SQL Server 2011 и из Обозревателя объектов (Object Explorer) вызовите контекстное меню для сервера. В контекстном меню необходимо выбрать пункт Properties (Свойства).
То же самое может быть достигнуто с помощью скрипта.
—Enabled Advanced options
— разрешить работать с настройками с закладки Advanced
sp_configure ‘show advanced’, 1;
RECONFIGURE WITH OVERRIDE;
Go
—Enabled Database Containment
—Разрешить использование автономных баз данных
sp_configure ‘contained database authentication’, 1;
RECONFIGURE WITH OVERRIDE;
go
Шаг 2. Создать базу данных и выставить режим автономности как частичный
Создадим новую базу и назовем ее TestContainedDB.
После создания открываем ее свойства через контекстное меню
То же самое может быть достигнуто с помощью скрипта.
USE [master]
GO
CREATE DATABASE [TestContainedDB]
CONTAINMENT = PARTIAL
ON PRIMARY
LOG ON
GO
ALTER DATABASE [TestContainedDB] SET COMPATIBILITY_LEVEL = 110
GO
Шаг 3. Создать автономного пользователя в новой базе данных.
В новой базе данных перейдите в узел Security, затем Users и с помощью контекстного меню создаем нового пользователя.
Указываем, что пользователь будет владельцем базы. Для этого на странице Membership отмечаем галочкой пункт db_owner.
Эти же действия можно совершить при помощи TSql
USE [TestContainedDB]
GO
CREATE USER [TestUser]
WITH PASSWORD=’testuser’,
DEFAULT_SCHEMA=[dbo]
GO
Как только описанные действия будут завершены, можно убедиться, что пользователь появился в системе.
Шаг 4. Зайти в новую базу данных под учетной записью автономного пользователя.
Для демонстрации шага надо завершить работу в SSMS, и войти снова следуя описанным шагам.
На этой закладке надо указать к какой базе данных мы собираемся присоедениться. В данном случае это TestContainedDB.
Теперь можно жать на кнопку Connect, и мы окажемся в автономном окружении базы.
Конвертация базы в автономную
Я думаю после описания плюсов автономной базы данных и того, как ее можно создать, вы задумались о том, можно ли перевести существующую базу в автономный режим. Можно. Сейчас будет продемонстрирован такой процесс. Поскольку демонстрация будет вестись на тестовой базе, то для начала ее и создам, воспользовавшись скриптом ниже:
USE [master]
GO
CREATE DATABASE [NonContainedDB]
CONTAINMENT = NONE
ON PRIMARY
GO
ALTER DATABASE [NonContainedDB] SET COMPATIBILITY_LEVEL = 110
GO
IF (1 = FULLTEXTSERVICEPROPERTY(‘IsFullTextInstalled’))
begin
EXEC [NonContainedDB].[dbo].[sp_fulltext_database] @action = ‘enable’
end
GO
Затем создаем таблицу с данными.
— Drop the table if it exists
— удалить таблицу, если она существует
IF EXISTS (SELECT * FROM sys.objects WHERE name = N’tbl_Players’ AND type = ‘U’)
DROP TABLE tbl_Players
GO
SET ANSI_NULLS ON
GO
—Create the table
— создать таблицу
CREATE TABLE tbl_Players (
PlayerID INT IDENTITY,
PlayerName VARCHAR(15),
BelongsTo VARCHAR(15),
MatchPlayed INT,
RunsMade INT,
WicketsTaken INT,
FeePerMatch NUMERIC(16,2)
)
—Insert the records
— внести записи в таблицу
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘A. Won’,’India’,10,440,10, 1000000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘A. Cricket’,’India’,10,50,17, 400000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘B. Dhanman’,’India’,10,650,0,3600000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘C. Barsat’,’India’,10,950,0,5000000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘A. Mirza’,’India’,2,3,38, 3600000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘M. Karol’,’US’,15,44,4, 2000000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘Z. Hamsa’,’US’,3,580,0, 400)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘K. Loly’,’US’,6,500,12,800000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘S. Summer’,’US’,87,50,8,1230000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘J.June’,’US’,12,510,9, 4988000)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘A.Namaki’,’Australia’,1,4,180, 999999)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘Z. Samaki’,’Australia’,2,6,147, 888888)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘MS. Kaki’,’Australia’,40,66,0,1234)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘S. Boon’,’Australia’,170,888,10,890)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘DC. Shane’,’Australia’,28,39,338, 4444499)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘S. Noami’,’Singapore’,165,484,45, 5678)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘Z. Biswas’,’Singapore’,73,51,50, 22222)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘K. Dolly’,’Singapore’,65,59,1,99999)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘S. Winter’,’Singapore’,7,50,8,12)
INSERT INTO tbl_Players(PlayerName, BelongsTo, MatchPlayed,RunsMade,WicketsTaken,FeePerMatch) VALUES(‘J.August’,’Singapore’,9,99,98, 890)
Для полноты картины добавим хранимую процедуру.
If Exists (Select * from sys.objects where name = ‘usp_SelectRecordsByPlayerName’ and type = ‘P’)
Drop Procedure usp_SelectRecordsByPlayerName
Go
— Create the stored procedure
Create Procedure [dbo].[usp_SelectRecordsByPlayerName]
( @PlayerID int )
As
Begin
Select
PlayerID
,PlayerName
, BelongsTo
, MatchPlayed
,RunsMade
,WicketsTaken
,FeePerMatch
From
tbl_Players
Where PlayerId = @PlayerID
End
В итоге у нас должна быть база данных, таблица и хранимая процедура. Сейчас база работает в нормальном, зависимом режиме и нашей целью будет превратить ее в автономную базу данных.
На первом шаге нужно будет создать нового пользователя на уровне сервера и пользователя для базы. Это можно сделать с помощью такого скрипта:
—Create a login on the server
— Создаем пользователя на уровне сервера
CREATE LOGIN NonContainedUser
WITH PASSWORD = ‘somepassword@123’
—Create a «non-contained» users for the login on the server
— создаем автономного пользователя
USE NonContainedDB
GO
CREATE USER NonContainedUser FOR LOGIN NonContainedUser
GO
Теперь надо определить какие объекты принадлежат связанной базе данных. Для этого можно выполнить следующий код
USE NonContainedDB
GO
SELECT
class_desc
,feature_name
,feature_type_name
FROM sys.dm_db_uncontained_entities
Результат должен быть как на скриншоте ниже.
Можно проигнорировать ROUTE. Итак, по данным скрипта, у нас имеется 2 объекта в связанной базе данных.
Для определения пользователей принадлежащих серверу можно запустить такой скрипт:
USE NonContainedDB
GO
SELECT dp.name
FROM sys.database_principals dp
JOIN sys.server_principals sp ON dp.sid = sp.sid
WHERE dp.authentication_type = 1
AND sp.is_disabled = 0
Что даст нам в результате выполнения
На базе NonContainedDB надо вызвать контекстное меню и выбрать Properties. Затем перейти на закладку Options и выбрать для свойства Containment type значение Partial.
Другой способ для описанных действий заключается в написании скрипта
USE master
GO
ALTER DATABASE NonContainedDB SET CONTAINMENT=PARTIAL;
GO
После того как настройка выставлена, необходимо мигрировать пользователей на автономную базу.
USE NonContainedDB
GO
EXEC sp_migrate_user_to_contained @username = N’NonContainedUser’,
@rename = N’keep_name’,
@disable_login = N’disable_login’
Процедура sp_migrate_user_to_contained нужна для миграции пользователей в автономную базу. Она конвертирует пользователей уровня сервера в пользователей автономной базы. После процедуры можно снова запустить скрипт определяющий зависимых пользователей.
USE NonContainedDB
GO
SELECT dp.name
FROM sys.database_principals dp
JOIN sys.server_principals sp ON dp.sid = sp.sid
WHERE dp.authentication_type = 1
AND sp.is_disabled = 0
Можно убедиться что NonContainedUser больше не появляется. Это означает что пользователь был изменен и его учетная запись была заблокирована на уровне сервера.
Отсоединитесь от текущего сервера и вызовите форму соединения. В полях для имени и пароля введите данные пользователя, которого мы мигрировали на автономную базу. Далее в опциях соединения задайте все как упоминалось выше, в разделе соединения с автономной базой.
После соединения в строке о базе данных должно быть что-то похожее.
Бэкап автономной базы данных.
Осуществляется точно так же как и архивирование обычной базы данных. Так что это процесс можно сделать с интерфейса пользователя или с помощью скрипта.
Интерфейс
Присоединитесь к базе данных с помощью SSMS, в навигаторе объектов (Object Explore) находите желаемую базу. В контекстном меню идете по пунктам Tasks > Backup
Сделать бэкап базы можно с помощью нехитрого скрипта.
BACKUP DATABASE TestContainedDB
TO DISK='<File Path>\TestContainedDB.bak’
Восстановление архивной базы
Опять же есть два пути: через интерфейс пользователя и с помощью скрипта.
Интерфейс
Через интерфейс все делается схожим образом с архивированием
Присоединитесь к базе данных с помощью SSMS, в навигаторе объектов (Object Explore) находите желаемую базу. В контекстном меню идете по пунктам Tasks > Restore
RESTORE DATABASE TestContainedDB
FROM DISK='<File Path>\TestContainedDB.bak’
Во время восстановления базы можно получить сообщение:
Msg 12824, Level 16, State 1, Line 1
The sp_configure value ‘contained database authentication’ must be set to 1 in order to restore a contained database. You may need to use RECONFIGURE to set the value_in_use.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
Из которого становится ясно, что необходимо активировать опцию Contained Database Authentication в настройках SQL Server на уровне экземпляра сервера. Эта настройка по умолчанию выключена. Выполните скрипт ниже для устранения проблемы.
—Enabled Advanced options
— включаем возможность редактирования опций
sp_configure ‘show advanced’, 1;
RECONFIGURE WITH OVERRIDE;
go
—Enabled Database Containment
— включаем возможность аутентификации для автономных баз данных
sp_configure ‘contained database authentication’, 1;
RECONFIGURE WITH OVERRIDE;
go
Еще немного информации об автономных базах данных
Методы аутентификации поддерживаемые автономными базами остались те же:
SQL Server Authentication
Windows Based Authentication
Изменение базы данных изменилось. CREATE / ALTER DATABASE работают теперь по-другому. Выражение Alter Database <database name> больше не работает. Вместо имени базы надо указывать служебное слово CURRENT.
ALTER DATABASE CURRENT