Locking Hints

Locking Hints

Locking behavior can be further modified by providing locking hints in the WITH parameter of the FROM clause in SELECT statements. Figure 10-44 lists several of the locking hints available with SQL Server. The first four hints override the transaction isolation level; the next two influence the type of lock issued. For a full list of locking hints, see the documentation at http://msdn.microsoft.com/en-us/library/ms187373.aspx .

Chapter 10 Managing Databases with SQL Server 2008 R2

Consider the following statements:

/* *** EXAMPE CODE – DO NOT RUN *** */ SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; DECLARE MyCursor CURSOR DYNAMIC SCROLL_LOCKS FOR

SELECT

FROM

dbo.TRANS WITH READUNCOMMITTED NOLOCK;

Without the locking hints, the cursor MyCursor would have REPEATABLE READ isola- tion and would issue update locks on all rows read. The locks would be held until the transac- tion committed. With the locking hints, the isolation level for this cursor becomes READ UNCOMMITTED. Furthermore, the specification of NOLOCK changes this cursor from DYNAMIC to READ_ONLY.

Consider another example:

/* *** EXAMPE CODE – DO NOT RUN *** */ SET TRANSACTION ISOLATION LEVEL REPEATABLE READ; DECLARE MyCursor CURSOR DYNAMIC SCROLL_LOCKS FOR

SELECT

FROM

dbo.TRANS WITH HOLDLOCK;

Here, the locking hint will cause SQL Server to hold update locks on all rows read until the transaction commits. The effect is to change the transaction isolation level for this cursor from REPEATABLE READ to SERIALIZABLE.

In general, the beginner is advised not to provide locking hints. Rather, until you have become an expert, set the isolation level and cursor concurrency to appropriate values for your transactions and cursors and leave it at that. In fact, the SQL Server 2008 R2 documentation specifically suggests relying on the SQL Server query optimizer and only using locking hints when absolutely necessary.

SQL Server 2008 R2 Security

We discussed security in general terms in Chapter 9. Here, we will summarize how those general ideas pertain to SQL Server security. Starting with SQL Server 2005 and continuing with SQL Server 2008 R2, Microsoft introduced a more complex version of the model of DBMS security shown in Figure 9-14. The SQL Server 2008 R2 model is shown in Figure 10-45.

As usual, security consists of authentication and authorization. As shown in Figure 10-1, we have to log into SQL Server itself first, and we log in using one of the server logins illustrated in Figure 10-45. This login will be a member of one or more server roles, and each of these roles has specific permission at the server level.

We are currently logged into SQL Server 2008 R2 (on a computer running the Windows Server 2008 R2 operating system and named WS82-003) as the login WS83-003\Auer (see the User name in Figure 10-1 [which is grayed out but is still the user name being used]), which means that we logged in based on the local computer user account Auer, and, as shown in Figure 10-46, that login is assigned to the sysadmin role. This means that the user Auer has all the privileges of an SQL Server 2008 R2 systems administrator (which is everything!). SQL Server 2008 R2 logins can either be based on Windows operating system security (recommended by Microsoft), SQL–Server-specific logins (see the sa login in Figure 10-46— sa is the SQL Server system administrator account and if you use it be sure to set a secure password for it), or both (which is how our SQL Server 2008 R2 instance is set up).

Part 4 Multiuser Database Processing

Server

Database

Server Logins

Schema (Default = dbo)

Database Users

Server Roles

Database Roles

Server Schema Objects: Permissions

Schema Permissions

Tables

Database

Table Columns

Permissions

Procedures

Figure 10-45

To see the server permissions that the login Auer has, we look at the Permissions page of

SQL Server 2008 R2 Security Model

the Server Properties dialog box (right-click the SQL Server object at the top of the Object Explorer, and then click the Properties command). Figure 10-47 shows the effective properties for the login Auer.

This gives us an overview of the SQL Server authorization model. SQL Server principals (either server principals, such as logins and server roles, or database principals, such users and database roles) are granted permissions to SQL Server securable objects (databases, schemas, tables, procedures, etc.). The new concept here is the schema. An SQL Server schema is a named container for SQL Server. In other words, SQL objects such as tables and stored procedures are now held in a container called a schema. A schema can be owned by any SQL server principal. The main advantage is that schema ownership can be transferred, and thus a database principal can be deleted without the loss of the objects owned by that princi-

Figure 10-46

pal. For more information, see “User–Schema Separation” at http://msdn.microsoft.com/en-us/ library/ms190387.aspx . The default schema, the one an object will automatically be assigned

Server Logins and Server Roles

The Server Security folder object

The Logins folder object

The Server Roles folder object

The sysadmin Server Role object

The Server Role Properties dialog box for the sysadmin role

Chapter 10 Managing Databases with SQL Server 2008 R2

The Security folder object

The Server Properties dialog box

The Permissions page

The login WORKSTATION/Auer

The effective permissions for the login

Figure 10-47

Effective Server Permissions for the Login WS82-003\Auer

to, is the dbo schema. In earlier versions of SQL Server, dbo (database owner) was only a user, now dbo is also a schema name.

As an example, let’s create a login for use by the View Ridge Gallery. Creating a New Login

1. Expand the Security folder object in the Object Explorer so that the Logins folder

object is displayed.

2. Right-click the Logins folder object to display the shortcut menu.

3. In the shortcut menu, click the New Login command. The Login – New dialog box is

displayed.

4. The completed new login data is shown in Figure 10-48. Use that figure for reference

Figure 10-48

in the following steps.

Creating the VRG-User Login The Security folder

object The Logins folder

object The Login - New

dialog box The OK button

436

Part 4 Multiuser Database Processing

5. In the Login name text box, type in the login name VRG-User.

6. Click the SQL Server authentication radio button to enable the use of SQL Server

authentication mode.

7. In the Password text box, type the password VRG-User+password.

8. In the Confirm password text box, type the password VRG-User+password.

9. Uncheck the Enforce password policy check box to disable enforcing password policy, disable enforcing password expiration, and disable forcing a password change.