What’s New in SQL Server System and Database Administration
System Administrator Responsibilities
System Databases
System Tables
System Views
System Stored Procedures
Summary
8 Installing SQL Server 2008
What’s New in Installing SQL Server 2008
Installation Requirements
Installation Walkthrough
Installing SQL Server Using a Configuration File
Installing Service Packs and Cumulative Updates
Slipstream Installations
Summary
9 Upgrading to SQL Server 2008
What’s New in Upgrading SQL Server
Using the SQL Server Upgrade Advisor (UA)
Destination: SQL Server 2008 or SQL Server 2008 R2
Upgrading Using a Configuration File
Slipstreaming Upgrades
Upgrading Other SQL Server Components
Summary
10 Client Installation and Configuration
What’s New in Client Installation and Configuration
Client/Server Networking Considerations
Client Installation
Client Configuration
Client Data Access Technologies
Summary
11 Security and User Administration
What’s New in Security and User Administration
An Overview of SQL Server Security
Authentication Methods
Managing Principals
Managing Securables
Managing Permissions
Managing SQL Server Logins
Managing SQL Server Users
Managing Database Roles
Managing SQL Server Permissions
The Execution Context
Summary
12 Data Encryption
What’s New in Data Encryption
An Overview of Data Security
An Overview of Data Encryption
SQL Server Key Management
Column-Level Encryption
Transparent Data Encryption
Column-Level Encryption Versus Transparent Data Encryption
Summary
13 Security and Compliance
Exposure and Risk
Across the Life Cycle
The Security Big Picture
Identity Access Management Components
Compliance and SQL Server
SQL Server Auditing
Setting Up Auditing via T-SQL
SQL Injection Is Easy to Do
Summary
14 Database Backup and Restore
What’s New in Database Backup and Restore
Developing a Backup and Restore Plan
Types of Backups
Recovery Models
Backup Devices
Backing Up a Database
Backing Up the Transaction Log
Backup Scenarios
Restoring Databases and Transaction Logs
Restore Scenarios
Additional Backup Considerations
Summary
15 Database Mail
What’s New in Database Mail
Setting Up Database Mail
Sending and Receiving with Database Mail
Using SQL Server Agent Mail
Related Views and Procedures
Summary
16 SQL Server Scheduling and Notification
What’s New in Scheduling and Notification
Configuring the SQL Server Agent
Viewing the SQL Server Agent Error Log
SQL Server Agent Security
Managing Operators
Managing Jobs
Managing Alerts
Scripting Jobs and Alerts
Multiserver Job Management
Event Forwarding
Summary
17 Administering SQL Server 2008 with PowerShell
What’s New with PowerShell
Overview of PowerShell
PowerShell Scripting Basics
PowerShell in SQL Server 2008
Step-By-Step Examples
Summary
18 SQL Server High Availability
What’s New in High Availability
What Is High Availability?
The Fundamentals of HA
Building Solutions with One or More HA Options
Other HA Techniques That Yield Great Results
High Availability from the Windows Server Family Side
Summary
19 Replication
What’s New in Data Replication
What Is Replication?
The Publisher, Distributor, and Subscriber Magazine Metaphor
Replication Scenarios
Subscriptions
Replication Agents
Planning for SQL Server Data Replication
SQL Server Replication Types
Basing the Replication Design on User Requirements
Setting Up Replication
Scripting Replication
Monitoring Replication
Summary
20 Database Mirroring
What’s New in Database Mirroring
What Is Database Mirroring?
Roles of the Database Mirroring Configuration
Setting Up and Configuring Database Mirroring
Testing Failover from the Principal to the Mirror
Client Setup and Configuration for Database Mirroring
Migrate to Database Mirroring 2008 as Fast as You Can
Using Replication and Database Mirroring Together
Using Database Snapshots from a Mirror for Reporting
Summary
21 SQL Server Clustering
What’s New in SQL Server Clustering
How Microsoft SQL Server Clustering Works
Installing SQL Server Clustering
Summary
22 Administering Policy-Based Management
Introduction to Policy-Based Management
Policy-Based Management Concepts
Implementing Policy-Based Management
Sample Templates and Real-World Examples
Policy-Based Management Best Practices
Summary
Part IV: Database Administration
23 Creating and Managing Databases
What’s New in Creating and Managing Databases
Data Storage in SQL Server
Database Files
Creating Databases
Setting Database Options
Managing Databases
Summary
24 Creating and Managing Tables
What’s New in SQL Server 2008
Creating Tables
Defining Columns
Defining Table Location
Defining Table Constraints
Modifying Tables
Dropping Tables
Using Partitioned Tables
Creating Temporary Tables
Summary
25 Creating and Managing Indexes
What’s New in Creating and Managing Indexes
Types of Indexes
Creating Indexes
Managing Indexes
Dropping Indexes
Online Indexing Operations
Indexes on Views
Summary
26 Implementing Data Integrity
What’s New in Data Integrity
Types of Data Integrity
Enforcing Data Integrity
Using Constraints
Rules
Defaults
Summary
27 Creating and Managing Views in SQL Server
What’s New in Creating and Managing Views
Definition of Views
Using Views
Creating Views
Managing Views
Data Modifications and Views
Partitioned Views
Indexed Views
Summary
28 Creating and Managing Stored Procedures
What’s New in Creating and Managing Stored Procedures
Advantages of Stored Procedures
Creating Stored Procedures
Executing Stored Procedures
Deferred Name Resolution
Viewing Stored Procedures
Modifying Stored Procedures
Using Input Parameters
Using Output Parameters
Returning Procedure Status
Debugging Stored Procedures Using SQL Server Management Studio
Using System Stored Procedures
Startup Procedures
Summary
29 Creating and Managing User-Defined Functions
What’s New in SQL Server 2008
Why Use User-Defined Functions?
Types of User-Defined Functions
Creating and Managing User-Defined Functions
Rewriting Stored Procedures as Functions
Creating and Using CLR Functions
Summary
30 Creating and Managing Triggers
What’s New in Creating and Managing Triggers
Using DML Triggers
Using DDL Triggers
Using CLR Triggers
Using Nested Triggers
Using Recursive Triggers
Summary
31 Transaction Management and the Transaction Log
What’s New in Transaction Management
What Is a Transaction?
How SQL Server Manages Transactions
Defining Transactions
Transactions and Batches
Transactions and Stored Procedures
Transactions and Triggers
Transactions and Locking
Coding Effective Transactions
Transaction Logging and the Recovery Process
Long-Running Transactions
Bound Connections
Distributed Transactions
Summary
32 Database Snapshots
What’s New with Database Snapshots
What Are Database Snapshots?
Limitations and Restrictions of Database Snapshots
Copy-on-Write Technology
When to Use Database Snapshots
Setup and Breakdown of a Database Snapshot
Reverting to a Database Snapshot for Recovery
Setting Up Snapshots Against a Database Mirror
Database Snapshots Maintenance and Security Considerations
Summary
33 Database Maintenance
What’s New in Database Maintenance
The Maintenance Plan Wizard
Managing Maintenance Plans Without the Wizard
Executing a Maintenance Plan
Maintenance Without a Maintenance Plan
Database Maintenance Policies
Summary
Part V: SQL Server Performance and Optimization
34 Data Structures, Indexes, and Performance
What’s New for Data Structures, Indexes, and Performance
Understanding Data Structures
Database Files and Filegroups
Database Pages
Space Allocation Structures
Data Compression
Understanding Table Structures
Understanding Index Structures
Data Modification and Performance
Index Utilization
Index Selection
Evaluating Index Usefulness
Index Statistics
SQL Server Index Maintenance
Index Design Guidelines
Indexed Views
Indexes on Computed Columns
Filtered Indexes and Statistics
Choosing Indexes: Query Versus Update Performance
Identifying Missing Indexes
Identifying Unused Indexes
Summary
35 Understanding Query Optimization
What’s New in Query Optimization
What Is the Query Optimizer?
Query Compilation and Optimization
Query Analysis
Row Estimation and Index Selection
Join Selection
Execution Plan Selection
Query Plan Caching
Other Query Processing Strategies
Parallel Query Processing
Common Query Optimization Problems
Managing the Optimizer
Summary
36 Query Analysis
What’s New in Query Analysis
Query Analysis in SSMS
SSMS Client Statistics
Using the SET SHOWPLAN Options
Using sys.dm_exec_query_plan
Query Statistics
Query Analysis with SQL Server Profiler
Summary
37 Locking and Performance
What’s New in Locking and Performance
The Need for Locking
Transaction Isolation Levels in SQL Server
The Lock Manager
Monitoring Lock Activity in SQL Server
SQL Server Lock Types
SQL Server Lock Granularity
Lock Compatibility
Locking Contention and Deadlocks
Table Hints for Locking
Optimistic Locking
Summary
38 Database Design and Performance
What’s New in Database Design and Performance
Basic Tenets of Designing for Performance
Logical Database Design Issues
Denormalizing a Database
Database Filegroups and Performance
RAID Technology
SQL Server and SAN Technology
Summary
39 Monitoring SQL Server Performance
What’s New in Monitoring SQL Server Performance
Performance Monitoring Tools
A Performance Monitoring Approach
Summary
40 Managing Workloads with the Resource Governor
Overview of Resource Governor
Resource Governor Components
Configuring Resource Governor
Monitoring Resource Usage
Modifying Your Resource Governor Configuration
Summary
41 A Performance and Tuning Methodology
The Full Architectural Landscape
Primary Performance and Tuning Handles
A Performance and Tuning Methodology
Performance and Tuning Design Guidelines
Tools of the Performance and Tuning Trade
Summary
Part VI: SQL Server Application Development
42 What’s New for Transact-SQL in SQL Server 2008
MERGE Statement
Insert over DML
GROUP BY Clause Enhancements
Variable Assignment in DECLARE Statement
Compound Assignment Operators
Row Constructors
New date and time Data Types and Functions
Table-Valued Parameters
Hierarchyid Data Type
Using FILESTREAM Storage
Sparse Columns
Spatial Data Types
Change Data Capture
Change Tracking
Summary
43 Transact-SQL Programming Guidelines, Tips, and Tricks
General T-SQL Coding Recommendations
General T-SQL Performance Recommendations
T-SQL Tips and Tricks
In Case You Missed It: New Transact-SQL Features in SQL Server 2005
The xml Data Type
The max Specifier
TOP Enhancements
The OUTPUT Clause
Common Table Expressions
Ranking Functions
PIVOT and UNPIVOT
The APPLY Operator
TRY...CATCH Logic for Error Handling
The TABLESAMPLE Clause
Summary
44 Advanced Stored Procedure Programming and Optimization
T-SQL Stored Procedure Coding Guidelines
Using Cursors in Stored Procedures
Nested Stored Procedures
Using Temporary Tables in Stored Procedures
Using Remote Stored Procedures
Stored Procedure Performance
Using Dynamic SQL in Stored Procedures
Installing and Using .NET CLR Stored Procedures
Using Extended Stored Procedures
Summary
45 SQL Server and the .NET Framework
What’s New in SQL Server 2008 and the .NET Framework
Getting Comfortable with ADO.NET 3.5 and SQL Server 2008
Developing with LINQ to SQL
Using ADO.NET Data Services
Leveraging the Microsoft Sync Framework
Summary
46 SQLCLR: Developing SQL Server Objects in .NET
What’s New for SQLCLR in SQL Server 2008
Developing Custom Managed Database Objects
Summary
47 Using XML in SQL Server 2008
What’s New in Using XML in SQL Server 2008
Understanding XML
Relational Data As XML: The FOR XML Modes
XML As Relational Data: Using OPENXML
Using the xml Data Type
Indexing and Full-Text Indexing of xml Columns
Summary
48 SQL Server Web Services
What’s New in SQL Server Web Services
Web Services Migration Path
Web Services History and Overview
Building Web Services
Examples: A C# Client Application
Using Catalog Views and System Stored Procedures
Controlling Access Permissions
Summary
49 SQL Server Service Broker
What’s New in Service Broker
Understanding Distributed Messaging
Designing a Sample System
Understanding Service Broker Constructs
Service Broker Routing and Security
Troubleshooting SSB Applications with ssbdiagnose.exe
Related System Catalogs
Summary
50 SQL Server Full-Text Search
What’s New in SQL Server 2008 Full-Text Search
Upgrade Options in SQL Server 2008
How SQL Server FTS Works
Implementing SQL Server 2008 Full-Text Catalogs
Setting Up a Full-Text Index
Full-Text Searches
Full-Text Search Maintenance
Full-Text Search Performance
Full-Text Search Troubleshooting
Summary
Part VII: SQL Server Business Intelligence Features
51 SQL Server 2008 Analysis Services
What’s New in SSAS
Understanding SSAS and OLAP
Understanding the SSAS Environment Wizards
An Analytics Design Methodology
An OLAP Requirements Example: CompSales International
Summary
52 SQL Server Integration Services
What’s New with SSIS
SSIS Basics
SSIS Architecture and Concepts
SSIS Tools and Utilities
A Data Transformation Requirement
Running the SSIS Wizard
The SSIS Designer
The Package Execution Utility
Connection Projects in Visual Studio
Change Data Capture Addition with R2
Using bcp
Logged and Nonlogged Operations
Summary
53 SQL Server 2008 Reporting Services
What’s New in SSRS 2008
Reporting Services Architecture
Installing and Configuring SSRS
Developing Reports
Management and Security
Performance and Monitoring
Summary
Part VIII: Bonus Chapters
54 Managing Linked and Remote Servers
What’s New in Managing Linked and Remote Servers
Managing Remote Servers
Linked Servers
Adding, Dropping, and Configuring Linked Servers
Mapping Local Logins to Logins on Linked Servers
Obtaining General Information About Linked Servers
Executing a Stored Procedure via a Linked Server
Setting Up Linked Servers Using SQL Server Management Studio
Summary
55 Configuring, Tuning, and Optimizing SQL Server Options
What’s New in Configuring, Tuning, and Optimizing SQL Server Options
SQL Server Instance Architecture
Configuration Options
Fixing an Incorrect Option Setting
Setting Configuration Options with SSMS
Obsolete Configuration Options
Configuration Options and Performance
Database Engine Tuning Advisor
Data Collection Sets
Summary
56 SQL Server Disaster Recovery Planning
What’s New in SQL Server Disaster Recovery Planning
How to Approach Disaster Recovery
Microsoft SQL Server Options for Disaster Recovery
The Overall Disaster Recovery Process
Have You Detached a Database Recently?
Third-Party Disaster Recovery Alternatives
Summary
Index
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y-Z
Nội dung
ptg 294 CHAPTER 11 Security and User Administration Some complexity has been introduced, based on the hierarchical nature of some of the security components. Security can be established on these hierarchical components, which in turn cascades the security to the underlying components. In addition, not all the permission components apply to every securable. Many of the securables have a select number of permissions that apply to them; conversely, many permissions apply only to a select number of securables. For example, SELECT permission is applicable to securables such as tables and views but would not be appropriate for stored procedures. The following sections discuss the tiers of the security model and their underlying components. Authentication Methods The first level of security encountered when accessing SQL Server is known as authentication. The authentication process performs the validation needed to allow a user or client machine to connect to SQL Server. This connection can be granted via a Windows login or SQL Server login. Windows Authentication Mode Windows Authentication mode validates the account name and password, using informa- tion stored in the Windows operating system. A Windows account or group must be estab- lished first, and then security can be established for that account in SQL Server. This mode has the advantage of providing a single login account and the capability to leverage domain security features, such as password length and expiration, account locking, encryption, and auditing. Microsoft recommends this approach. Mixed Authentication Mode Mixed authentication allows for both Windows authentication and SQL Server authentica- tion. SQL Server authentication is based on a login that is created in SQL Server and lives in SQL Server only. No Windows account is involved with SQL Server authentication. The account and password are established and maintained in SQL Server. SQL Server logins can be created with stronger password enforcement that help better protect the login. This topic is discussed in more detail in the section “Managing SQL Server Logins,” later in this chapter. SQL Server authentication is useful in environments in which a Windows domain controller does not control network access. It can also be useful for Web applications or legacy applications, where it may be cumbersome to establish a Windows user account for every connection to the database server. Download from www.wowebook.com ptg 295 Managing Principals 11 Setting the Authentication Mode You can select the authentication mode when you install SQL Server, and you can change it after the installation. To change the authentication mode after installation, you right- click the server node in the Object Explorer and choose the Properties option. When the Server Properties dialog appears, you select the Security page (see Figure 11.1). The Security page allows you to specify Windows Authentication mode or SQL Server and Windows Authentication mode (that is, mixed authentication). Any changes to the authentication mode require a restart of SQL Server to make the change effective. FIGURE 11.1 Changing the authentication mode. Managing Principals Principals are the entities that can request permission to SQL Server resources. They are made up of groups, individuals, or processes. Each principal has its own unique identifier on the server and is scoped at the Windows, server, or database level. The principals at the Windows level are Windows users or groups. The principals at the SQL Server level include SQL Server logins and server roles. The principals scoped at the database level include database users, data roles, and application roles. Download from www.wowebook.com ptg 296 Logins Every principal granted security to SQL Server must have an associated login. The login provides access to SQL Server and can be associated with principals scoped at the Windows and server levels. These logins can be associated with Windows accounts, Windows groups, or SQL Server logins. Logins are stored in the master database and can be granted permission to resources scoped at the server level. Logins provide the initial permission needed to access a SQL Server instance and allow you to grant access to the related databases. Permissions to specific database resources must be granted via a database user. The important point to remember is that logins and users are directly related to each other but are different enti- ties. It is possible to create a new login without creating an associated database user, but a new database user must have an associated login. To better understand logins, you can look at the sys.server_principals catalog view. This view contains a row for every server-level principal, including each server login. The following example selects from this view and displays the results: select left(name,25) name, type, type_desc from sys.server_principals AS log WHERE (log.type in (‘U’, ‘G’, ‘S’, ‘R’)) order by 3,1 /*Results from previous query name type type_desc bulkadmin R SERVER_ROLE dbcreator R SERVER_ROLE diskadmin R SERVER_ROLE processadmin R SERVER_ROLE public R SERVER_ROLE securityadmin R SERVER_ROLE serveradmin R SERVER_ROLE setupadmin R SERVER_ROLE sysadmin R SERVER_ROLE sa S SQL_LOGIN DBSVRXP\LocalUser1 U WINDOWS_LOGIN HOME\Administrator U WINDOWS_LOGIN NT AUTHORITY\SYSTEM U WINDOWS_LOGIN */ The results from the sys.server_principals selection include the name of the server principal as well as the type of principal. The rows that have a type_desc value of SQL_LOGIN, WINDOWS_GROUP, or WINDOWS_LOGIN are all logins established on the SQL Server instance. A login with a type_desc of SQL_LOGIN represents a login created with SQL Server authentication. Logins with a type_desc of WINDOWS_GROUP or WINDOWS_LOGIN are CHAPTER 11 Security and User Administration Download from www.wowebook.com ptg 297 Managing Principals 11 Windows groups or individual Windows users granted logins to SQL Server. The other entries with type_desc of SERVER_ROLE are fixed server roles discussed later in this chapter. The logins established for Windows logins or groups can be part of the local domain of the SQL Server machine, or they can be part of another domain. In the previous example, DBSVRXP\LocalUser1 is a login established for a local user on a database server named DBSVRXP. The HOME\Administrator login is also a Windows login, but it is part of a network domain named HOME. Both logins are preceded by the domain that they are part of and are displayed this way in SQL Server. NOTE In SQL Server 2000, logins were stored in the syslogins system table in the master database. The syslogins table is still available for selection as a view, but it is available only for backward compatibility. The catalog views (including sys.server_principals) are recommended for use instead. You might have noticed in the earlier sys.server_principals output that two other logins are listed that we have not discussed yet. These logins (SA and NT AUTHORITY\SYSTEM) are system accounts installed by default at installation time. Each of these accounts serves a special purpose in SQL Server. The SA account is a SQL_LOGIN assigned to the sysadmin fixed server role. The SA account and members of the sysadmin fixed server role have permission to perform any activity within SQL Server. The SA account cannot be removed, and it can always be used to gain access to SQL Server. The SA account should always have a strong password to prevent malicious attacks, and it should be used only by database administrators. Users or logins requiring full administrative privileges can be assigned a separate SQL Server login that is assigned to the sysadmin fixed server role. This improves the audit trail and limits the amount of use on the SA account. The NT AUTHORITY\SYSTEM login is an account related to the local system account under which SQL Server services can run. It is also added as a member of the sysadmin fixed server role and has full administrative privileges in SQL Server. This account can also be removed if the SQL Server services are not running with the local system account. This should be done with caution, however, because it can affect applications such as Reporting Services. One other special account was not listed, but it would have been in SQL Server 2005. The BUILTIN\Administrators login is a Windows group that corresponds to the local adminis- trators group for the machine that SQL Server is running on. The BUILTIN\Administrators group is no longer added by default as a SQL Server login during installation. In SQL Server 2005, it was also added as a member of the sysadmin fixed server role, but this is no longer the case. This change improves the security of SQL Server out of the box by limit- ing the number of people that have access (by default) to the SQL Server instance. Download from www.wowebook.com ptg 298 NOTE The BUILTIN\Administrators group can be manually added in SQL Server 2008 if desired. This allows domain administrators and anyone else who has been added to the local administrators group to have sysadmin privileges. Adding this group is not recommended but can be done if you want to set network privileges that are similar to past versions of SQL Server. SQL Server Security: Users Database users are principals scoped at the database level. Database users establish a link between logins (which are stored at the server level) and users (which are stored at the database level). Database users are required to use the database and are also required to access any object stored in the database. Generally, the login name and database username are the same, but this is not a require- ment. If desired, you could add a login named Chris and assign it to a user named Kayla. This type of naming convention would obviously cause some confusion and is not recom- mended, but SQL Server has the flexibility to allow you to do it. In addition, a user can be associated with a single person or a group of people. This capability is tied to the fact that a login can be related to a single account or group. For example, a login named training could be created and tied to a Windows group (that is, domain\training) that contains all the training personnel. This login could then be tied to a single database user. That single database user would control database access for all the users in the Windows group. TIP The relationship between logins and users can be broken when databases are moved or copied between servers. The reason is that a database user contains a reference to the associated login. Logins are referenced based on a unique identifier called a secu- rity identifier (SID). When a database is copied from one server to another, the users in that database contain references to logins that may not exist on the destination server or that may have different SIDs. You c an use the sp_change_users_login system stored procedure to identify and fix these situations. You can run the following command against a newly restored or attached database to check for orphaned users: EXEC sp_change_users_login ‘Report’ If orphaned users are shown in the results, you can rerun the procedure and fix the problems. For example, if the results indicate that a user named Chris is orphaned, you can run the following command to add a new login named Chris and tie the orphaned database user to this newly created login: EXEC sp_change_users_login ‘Auto_Fix’, ‘Chris’, NULL, ‘pw’ Refer to SQL Server Books Online for full documentation on the sp_change_users_login system stored procedure. CHAPTER 11 Security and User Administration Download from www.wowebook.com ptg 299 Managing Principals 11 You can use the sys.database_principals catalog view to list all the users in a given data- base. The following example shows a SELECT statement using this view and the results from the SELECT: SELECT left(u.name,25) AS [Name], type, left(type_desc,15) as type_desc FROM sys.database_principals AS u WHERE (u.type in (‘U’, ‘S’, ‘G’)) ORDER BY 1 /*Results from previous query Name type type_desc dbo S SQL_USER DBSVRXP\LocalUser1 U WINDOWS_USER guest S SQL_USER INFORMATION_SCHEMA S SQL_USER sys S SQL_USER */ The SELECT statement in this example returns five rows (that is, five users). This SELECT was run against the AdventureWorks2008 database, and the only user explicitly added to the database was the Windows user DBSVRXP\LocalUser1. The other users are special users who are added by default to each database. These users do not have corresponding server logins named the same. These users are discussed in the following sections. The dbo User The dbo user is the database owner and cannot be deleted from the database. Members of the sysadmin server role are mapped to the dbo user in each database, which allows them to administer all databases. Objects owned by dbo that are part of the dbo schema can be referenced by the object name alone. When an object is referenced without a schema name, SQL Server first looks for the object in the default schema for the user that is connected. If the object is not in the user’s default schema, the object is retrieved from the dbo schema. Users can have a default schema that is set to dbo. Schemas and their relationship to users are discussed in more detail in the section “User/Schema Separation,” later in this chapter. The guest User The guest user is created by default in each database when the database is created. This account allows users that do not have a user account in the database to access the data- base. By default, the guest user does not have permission to connect to the database. To allow logins without a specific user account to connect to the database, you need to grant Download from www.wowebook.com ptg 300 CONNECT permission to the guest account. You can run the following command in the target database to grant the CONNECT permission: GRANT CONNECT TO GUEST When the guest account is granted CONNECT permission, any login can use the database. This opens a possible security hole. The default permissions for the guest account are limited by design. You can change the permissions for the guest account, and all logins that use it will be granted those permissions. Generally, you should create new database users and grant permissions to these users instead of using the guest account. If you want to lock down the guest account, you can. You cannot drop the guest user, but you can disable it by revoking its CONNECT permission. The following example demon- strates how to revoke the CONNECT permission for the guest user: REVOKE CONNECT FROM guest If you decide to grant additional access to the guest account, you should do so with caution. The guest account can be used as a means for attacking your database. The INFORMATION_SCHEMA User The INFORMATION_SCHEMA user owns all the information schema views installed in each database. These views provide an internal view of the SQL Server metadata that is inde- pendent of the underlying system tables. Some examples of these views include INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.CHECK_CONSTRAINTS. The INFORMATION_SCHEMA user cannot be dropped from the database. The sys User The sys account gives users access to system objects such as system tables, system views, extended stored procedures, and other objects that are part of the system catalog. The sys user owns these objects. Like the INFORMATION_SCHEMA user, it cannot be dropped from the database. TIP If you are interested in viewing the specific objects owned by any of the special users discussed in these sections, you can use a SELECT statement like the following: Find all objects owned by a given user SELECT name, object_id, schema_id, type_desc FROM sys.all_objects WHERE OBJECTPROPERTYEX(object_id, N’OwnerId’) = USER_ID(N’sys’) ORDER BY 1 The SELECT in this example shows all the objects owned by the sys user. To change the user, you simply change the parameter of the USER_ID function in the SELECT statement from ’sys’ to whatever user you want. CHAPTER 11 Security and User Administration Download from www.wowebook.com ptg 301 Managing Principals 11 User/Schema Separation The changes to schema security introduced in SQL Server 2005 have been carried forward to SQL Server 2008. Versions of SQL Server before SQL Server 2005 had schemas, but they did not conform to the American National Standards Institute (ANSI) definition of schemas. ANSI defines a schema as a collection of database objects that one user owns and that forms a single namespace. A single namespace is one in which each object name is unique and there are no duplicates. So, for example, if you have two tables named customer, they cannot exist in the same namespace. To fully understand the user/schema changes in SQL Server 2008, you need to understand how schemas were used in prior versions of SQL Server. In SQL Server 7.0 and 2000, a default schema was created for each user, and it had the same name as the user. For example, if you created a new user named Rachael, a corresponding schema named Rachael would be created as well. There was no option in those releases to change the default schema for a user, and each user was forever bound to a schema with the same name. When the user created new objects, the objects were created by default in that user’s schema, which is always the name of the user. So, if Rachael created an object named customer, it was placed in the Rachael schema, and the object was owned by Rachael. When Rachael wanted to reference the object, she could use a three-part name with the format database.owner.object. If a linked server was used, according to the SQL Server 2000 documentation, the object in the linked server could be referenced with the four-part name linked_server.catalog.schema.object. (for example myserver.AdventureWorks2008.Rachael.Customer). You can see that the schema name is used prior to the object name when the object is outside the local server. The bottom line is that the schema and owner were basically the same thing in SQL Server 7.0 and 2000. With SQL Server 2005 and SQL Server 2008, the owner and schema have been separated. This is made possible in part by allowing a database user to have a default schema differ- ent from the name of the user. For example, our sample user Rachael could be assigned the default schema Sales. When Rachael creates objects in the database, her objects are created, by default, in the Sales schema. If Rachael wants to reference an object that she created, she can reference the table in a number of different ways. She can use the full four-part name (server.database.schema.object) that includes the Sales schema name to reference the object via a linked server. She can simply refer to the object with the object name alone, and the Sales schema will be searched first for the object. She can also use a three-part name or a two part name. If the object name is not found in the Sales schema, Download from www.wowebook.com ptg 302 the dbo schema will be searched. This concept is illustrated in the following sample SELECT statements that all retrieve the same rows from the Region table that was created by Rachael in the Adventureworks2008 database. select * from region select * from sales.region select * from AdventureWorks2008.Sales.Region The important point to remember is that owners and schemas are different from one another in SQL Server 2008. For example, you can have a customer table created in the Sales schema, and that table can be owned by a user named Chris. The object should be referenced with the schema name qualifier, such as Sales.Customer, not Chris.Customer. This has the distinct advantage of allowing object ownership to change without affecting the code that references the object. The reason is that database code that references an object uses the schema name instead of the object owner. The schema enhancements in SQL Server 2008 go well beyond the user/schema separa- tion. Schemas are an integral part of all the database objects that exist in SQL Server. As we delve into more details about SQL Server security and the assignment of permissions, you will see that schemas play a very important part. Roles Roles provide a consistent yet flexible model for security administration. Roles are similar to the groups used in administering networks. Permissions are applied to a role, and then members are added to the role. Any member of the role has all the permissions that the role has. The use of roles simplifies the administrative work related to security. Roles can be created based on job function, application, or any other logical group of users. With roles, you do not have to apply security to each individual user. Any required changes to permissions for the role can be made to the role security, and the members of the role receive those changes. SQL Server has the following three types of roles: . Fixed server and fixed database roles—These roles are installed by default and have a predefined set of permissions. . User-defined roles—These roles are created in each database, with a custom set of permissions for each set of users assigned to it. . Application roles—These special roles can be used to manage database access for an application. These roles are discussed in the following sections. CHAPTER 11 Security and User Administration Download from www.wowebook.com ptg 303 Managing Principals 11 Fixed Server Roles Fixed server roles are scoped at the server level, which means that the permissions for these roles are oriented toward server-level securables. These roles contain a variety of fixed permissions geared toward common administrative tasks. Logins (not users) are assigned to these roles. The same fixed server roles available in SQL Server 2000 and SQL Server 2005 are also available in SQL Server 2008. There is, however, one new role named public that has been added. Server principals, by default, are granted the permissions that have been granted to the public role. There are a limited number of permissions that are initially granted to the public role, but you can change the permissions if you like. A complete list of all the fixed server roles and their related permissions is shown in Table 11.2. A single login can be assigned to one or more of these fixed server roles. When multiple roles are assigned, the combination of all the permissions is allocated to the login. TABLE 11.2 Fixed Server Roles Role Permission bulkadmin Allowed to run the BULK INSERT statement. dbcreator Allowed to use CREATE, ALTER, DROP, and RESTORE on any database. diskadmin Allowed to manage disk files that are used by SQL Server. processadmin Allowed to terminate SQL Server processes. public Assigned to all logins. Permissions granted to this role are assigned to every login by default. securityadmin Allowed to use GRANT, DENY, and REVOKE permissions for logins at the server and database levels. Members of this role can reset passwords for SQL Server logins. serveradmin Allowed to change server-wide configuration properties and shut down the server, if needed. setupadmin Allowed to add and remove linked servers and execute some system stored procedures. sysadmin Allowed to perform any activity in the server. Download from www.wowebook.com . created in SQL Server and lives in SQL Server only. No Windows account is involved with SQL Server authentication. The account and password are established and maintained in SQL Server. SQL Server. diskadmin R SERVER_ ROLE processadmin R SERVER_ ROLE public R SERVER_ ROLE securityadmin R SERVER_ ROLE serveradmin R SERVER_ ROLE setupadmin R SERVER_ ROLE sysadmin R SERVER_ ROLE sa S SQL_ LOGIN. Separation The changes to schema security introduced in SQL Server 2005 have been carried forward to SQL Server 2008. Versions of SQL Server before SQL Server 2005 had schemas, but they did not conform