По материалам статьи Энди Уоррен на SWYNK.COM «SQL Permissions: More about the Fixed Roles»

В предыдущих своих статьях Энди уже рассмотрел применимость ролей Public и DataReader/DataWriter, а также те сложности, которые могут у Вас возникнуть при их применении. В этой статье автор обсуждает фиксированные роли.

DB_AccessAdmin
Эта роль предоставляет права добавлять или удалить пользователей для определенной базы данных. Энди пишет, что члены этой роли не могут выполнять sp_adduser, но зато им доступна sp_dropuser. Хорошей практикой является использование sp_grantdbaccess и sp_revokedbaccess, которые прекрасно работают. Эта роль может воздействовать только на уже существующие логины, и не может создавать новые. Запуск sp_dbfixedrolepermission покажет список разрешений, которые установлены для этой роли:
Db_accessadmin      Sp_addalias
Db_accessadmin      Sp_dropalias
Db_accessadmin      Sp_dropuser <
Db_accessadmin      Sp_grantdbaccess
Db_accessadmin      Sp_revokedbaccess

DB_SecurityAdmin
Эта роль предоставляет право управлять разрешениями, владельцами, и ролями - но только для тех логинов, которым уже был предоставлен доступ к базе данных. Хотя Энди считает возможности этой роли полезными, но сам он предпочитает назначать группы NT в роли SQL сервера, а затем управлять разрешениями путём добавления/удаления пользователей в группы NT. Вот список разрешений от sp_dbfixedrolepermission:
Db_securityadmin      DENY
Db_securityadmin      GRANT
Db_securityadmin      REVOKE
Db_securityadmin      Sp_addapprole
Db_securityadmin      Sp_addgroup
Db_securityadmin      Sp_addrole
Db_securityadmin      Sp_addrolemember
Db_securityadmin      Sp_approlepassword
Db_securityadmin      Sp_changegroup
Db_securityadmin      Sp_changeobjectowner
Db_securityadmin      Sp_dropapprole
Db_securityadmin      Sp_dropgroup
Db_securityadmin      Sp_droprole
Db_securityadmin      Sp_droprolemember

DB_BackupOperator
В BOL говорится, что пользователи, которые являются членом этой роли, могут делать резервные копии, плюс DBCC и Checkpoint. Checkpoint работает, а DBCC автору статьи заставить работать под этой ролью не удалось. Если Вы посмотрите на результат работы sp_dbfixedpermission, представленный ниже, то увидите, что в этом списке на DBCC разрешения нет. Энди не уверен в том, что эта роль будет иметь широкое применение, так как большинство DBA выполняет резервирование через задания по расписанию. Для восстановления резервной копии Вам потребуются разрешения роли DB_RestoreOperator, хотя Энди считает, что восстанавливать удобнее под ролью DBCreator или SYSADMINS.
Db_backupoperator      BACKUP DATABASE
Db_backupoperator      BACKUP LOG
Db_backupoperator      CHECKPOINT

DB_DDLAdmin
Эта роль предоставляет разрешение своим членам только на запуск DDL. Это полезно для разработчиков, которые изменяют схемы или если Вы хотите разрешить пользователям иметь собственные объекты. Имейте только в виду, что эти объекты будут принадлежать им, а не DBO (если Вы не используете sp_changeobjectowner до запуска этих объектов в промышленную эксплуатацию). В BOL сказано, что члены этой роли не могут выполнять Grant, Deny, или Revoke, но Энди убедился, что члены этой роли МОГУТ управлять разрешениями для объектов, владельцами которые они являются.
Db_ddladmin      All DDL but GRANT, REVOKE, DENY
Db_ddladmin      Dbcc cleantable
Db_ddladmin      Dbcc show_statistics
Db_ddladmin      Dbcc showcontig
Db_ddladmin      REFERENCES permission on any table
Db_ddladmin      Sp_changeobjectowner
Db_ddladmin      Sp_fulltext_column
Db_ddladmin      Sp_fulltext_table
Db_ddladmin      Sp_recompile
Db_ddladmin      Sp_rename
Db_ddladmin      Sp_tableoption
Db_ddladmin      TRUNCATETABLE

DB_Owner
Члены этой роли имеют все разрешения в базе данных. Но необходимо помнить, что объекты, созданные членами этой роли, будут принадлежать создавшему их пользователю, а не DBO (например, andy.testtable, а не dbo.testtable) - если пользователь также не входит в роль sysadmins. Что бы поменять собственника, нужно выполнить:

sp_changeobjectowner 'объект', 'dbo'