SQL Server 2011 — Автономная база данных

[@SkyRZN]

Спасибо! Интересная вещица получается.

[@CLaiN]

Давайте еще!

[@VioletTape]

С радостью исполню!
С моей стороны все готово уже, переводы на руках. Осталось только подзаработать кармы на добрых делах.

[@Anakros]

Картинки некоторые не отображаются.

[@VioletTape]

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

[@Anakros]

Обновил несколько раз страницу, все загрузились :)

[@unfilled]

Вообще интересно, если у нас есть linked server, «привязанный» к какой-то БД, сможем ли мы к нему обратиться в контексте другой БД?
и немножко позанудствую по переводу:
Мне кажется, что linked servers стоит переводить не как «соединенные сервера», а как связанные сервера" — такая же формулировка используется MS в переводах BOL.
«Агенты задач» \ «агенты заданий», имхо, лучше перевести как «задания агента SQL Server» — более длинный вариант, но сразу понятный.

[@serkuzm]

Вопрос немного не в тему топика.
Может кто-то знает как обстоят дела с разработкой «inproc» версии MSSQL? В помоему в декабре 2010 даже был опрос о том как назвать такую версию. Но что-то больше новостей об этой разработке я лично не видел.

[@indlborm]

«Потеря информации во время разворачивания базы или передвижения ее между серверами»

а можно чуть подробнее раскрыть сценарий этих передвижений?
насколько я понимаю, должно иметься в виду что-то отличное от штатных механизмов move db, copy db — т.к. они предлагают «движение» и связанных объектов (логины, задания и тд). по крайней мере, если делать это через гуй.
с логинами/паролями вопрос примерно тот же: имеются в виду способы авторизации по SQL/внутреннему механизму бд? или имеется в виду, что доменный аккаунт на новом сервере может «не попасть» в нужные группы безопасности SQL?

«Процедура sp_migrate_user_to_contained нужна для миграции пользователей в автономную базу»

а как у этом случае будет протекать авторизация одноименных пользователей на сервере/в бд1/в бдН?
т.е. имеем 2+ «унаследованных» баз, базы раньше жили на отдельных серверах, везде был сделан вход через «sa», пароли sa разные.
сможет ли приложение прозрачно аутентифицироваться/авторизоваться под sa своей базы?
вытекающий вопрос: если мы мигрируем БД с сервера на сервер, и на новом сервере в списке учеток сервера/автономных бд уже есть аккаунт с таким же именем — что будет?

[@unfilled]

насколько я понимаю, должно иметься в виду что-то отличное от штатных механизмов move db, copy db — т.к. они предлагают «движение» и связанных объектов (логины, задания и тд). по крайней мере, если делать это через гуй.

Да, SQL Server позволяет переносить логины на другой сервер, с помощью SSIS-пакета (задачи Transfer Logins и Transfer jobs). Но для этого у вас должен быть доступ к обоим SQL Server'ам с нехилыми правами. Contained Databases — позволит разработчикам, например, создать БД, набить ее какими-то служебными данными, сразу добавить туда какие-то job'ы и предопределенных пользователей и распространять. Это, возможно, будет удобно. От покупателя требуется только наличие SQL Server'a и не требуется наличие администратора баз данных — все «регламенты» уже включены в БД.
Вот, кстати, сейчас подумалось, что 1С, с их подходом к БД, будут очень рады запихать туда как можно больше и постараться запретить администраторам «на местах» менять в их базе хоть что-то.

т.е. имеем 2+ «унаследованных» баз, базы раньше жили на отдельных серверах, везде был сделан вход через «sa», пароли sa разные.
сможет ли приложение прозрачно аутентифицироваться/авторизоваться под sa своей базы?

Вы, по-моему, немного запутались с логинами и пользователями. Логин — это сущность сервера, связанная с сущностью БД — пользователем. Т.е. одному логину могут соответствовать несколько пользователей в разных БД.
Когда вы создаете автономного пользователя в contained database, для него НЕ создается логин. И после конвертации обычного пользователя в автономного — ему больше не нужен логин (в примере его логин вообще становится запрещенным — disabled).
Ваше приложение сможет авторизоваться, если в строке соединения будет прописана ВАША же contained database.

если мы мигрируем БД с сервера на сервер, и на новом сервере в списке учеток сервера/автономных бд уже есть аккаунт с таким же именем — что будет?

Ничего не будет. Список логинов сервера проверяться не будет — пользователь в contained database «самодостаточен», ему логин не нужен, а общего списка пользователей автономных БД тоже не существует — они хранятся каждый в своей базе.

[@VioletTape]

Все достаточно подробно написал unfilled. От себя могу добавить сценарий который использовался у нас на работе. Мы писали скрипты обновлений и доступа до продуктовой базы данных у нас не было. Иногда нам надо было получить продуктовую базу в предрелизном окружении, где у нас прав тоже не было. Так вот при таком разворачивании бэкапа у нас часто терялся доступ к базе, так как группа не распространялась автоматом на эту базу. Приходилось тормошить службу поддержки и админов.

а как у этом случае будет протекать авторизация одноименных пользователей на сервере/в бд1/в бдН?

На одном из рисунков, где показан процесс соединения к автономной базе можно заметить, что при соединении указывается конкретная база. И при соединении уже SSMS определяет что за тип у базы и проверка пользователей идет либо у сервера, либо у базы. Конфликтов нет. Дальше видно, что строка соединения в Object Explorer сильно отлична от стандартной при подключении к обычной базе.