Administering the SQL Server 2005 Database Engine

This chapter is from the book

SQL Server 2005 Management and Administration

Learn More Buy

This chapter is from the book

This chapter is from the book 

SQL Server 2005 Management and Administration

Learn More Buy

Administering the SQL Server Database Engine Folders

After you configure the SQL Server properties, you must manage the SQL Server Database Engine folders and understand what and how the settings should be configured. The SQL Server folders contain an abundant number of configuration settings that need to be managed on an ongoing basis. The main SQL Server Database Engine top-level folders, as shown in Figure 1.9, consist of

• Databases
• Security
• Server Objects
• Replication
• Management
• Notification Services

Figure 1.9 Viewing the Database Engine folders.

Each folder can be expanded upon, which leads to more subfolders and thus more management of settings. The following sections discuss the folders within the SQL Server tree, starting with the Databases folder.

Administering the Databases Folder

The Databases folder is the main location for administering system and user databases. Management tasks that can be conducted by right-clicking the Database folder consist of creating new databases, attaching databases, restoring databases, and creating custom reports.

The Databases folder contains subfolders as a repository for items such as system databases, database snapshots, and user databases. When a Database folder is expanded, each database has a predefined subfolder structure that includes configuration settings for that specific database. The database structure is as follows: Tables, Views, Synonyms, Programmability, Service Broker, Storage, and Security.

Let's start by examining the top-level folders and then the subfolders in subsequent sections.

Administering the System Databases Subfolder

The System Databases subfolder is the first folder within the Database tree. It consists of all the system databases that make up SQL Server 2005. The system databases consist of

• Master Database—The master database is an important system database in SQL Server 2005. It houses all system-level data, including system configuration settings, login information, disk space, stored procedures, linked servers, the existence of other databases, along with other crucial information.
• Model Database—The model database serves as a template for creating new databases in SQL Server 2005. The data residing in the model database is commonly applied to a new database with the Create Database command. In addition, the tempdb database is re-created with the help of the model database every time SQL Server 2005 is started.
• Msdb Database—Used mostly by the SQL Server Agent, the msdb database stores alerts, scheduled jobs, and operators. In addition, it stores historical information on backups and restores, SQL Mail, and Service Broker.
• Tempdb—The tempdb database holds temporary information, including tables, stored procedures, objects, and intermediate result sets. Each time SQL Server is started, the tempdb database starts with a clean copy.

Administering the Database Snapshots Subfolder

The second top-level folder under Databases is Database Snapshots. Database snapshots are a new technology introduced in SQL Server 2005. A snapshot allows you to create a point-in-time read-only static view of a database. Typical scenarios for which organizations use snapshots consist of running reporting queries, reverting databases to state when the snapshot was created in the event of an error, and safeguarding data by creating a snapshot before large bulk inserts occur. All database snapshots are created via TSQL syntax and not the Management Studio.

For more information on creating and restoring a database snapshot, view the database snapshot sections in Chapter 17, "Backing Up and Restoring the SQL Server 2005 Environment" (online).

Administering a User Databases Subfolder

The rest of the subfolders under the top-level Database folder are all the user databases. The user database is a repository for all aspects of an online transaction processing (OLTP) database, including administration, management, and programming. Each user database running within the Database Engine shows up as a separate subfolder. From within the User Database folder, you can conduct the following tasks: backup, restore, take offline, manage database storage, manage properties, manage database authorization, shrink, and configure log shipping or database mirroring. In addition, from within this folder, programmers can create the OLTP database schema, including tables, views, constraints, and stored procedures.

Administering the Security Folder

The second top-level folder in the SQL Server instance tree, Security, is a repository for all the Database Engine securable items meant for managing authorization. The sublevel Security Folders consist of

• Logins—This subfolder is used for creating and managing access to the SQL Server Database Engine. A login can be created based on a Windows or SQL Server account. In addition, it is possible to configure password policies, server role and user mapping access, and permission settings.
• Server Roles—SQL Server 2005 leverages the role-based model for granting authorization to the SQL Server 2005 Database Engine. Predefined SQL Server Roles already exist when SQL Server is deployed. These predefined roles should be leveraged when granting access to SQL Server and databases.
• Credentials—Credentials are used when there is a need to provide SQL Server authentication users an identity outside SQL Server. The principal rationale is for creating credentials to execute code in assemblies and for providing SQL Server access to a domain resource.

For more information on the Security folder, authorization, permission management, and step-by-step instructions on how to create logins, server roles, and credentials, refer to Chapter 13.

Administering the Server Objects Folder

The third top-level folder located in Object Explorer is called Server Objects. Here, you create backup devices, endpoints, linked servers, and triggers.

Backup Devices

Backup devices are a component of the backup and restore process when working with OLTP databases. Unlike the earlier versions of SQL Server, backup devices are not needed; however, they provide a great way for managing all the backup data and transaction log files for a database under one file and location.

To create a backup device, follow these steps:

1. Choose Start, All Programs, Microsoft SQL Server 2005, SQL Server Management Studio.
2. In Object Explorer, first connect to the Database Engine, expand the desired server, and then expand the Server Objects folder.
3. Right-click the Backup Devices folder and select New Backup Device.
4. In the Backup Device dialog box, specify a Device Name and enter the destination file path, as shown in Figure 1.10. Click OK to complete this task.
   

   Figure 1.10 Creating a backup device with SQL Server Management Studio.

This TSQL syntax can be used to create the backup device:

USE [master]
GO
EXEC master.dbo.sp_addumpdevice  @devtype = N'disk',
@logicalname = N'Rustom''s Backup Device',
@physicalname = N'C:\Rustom''s Backup Device.bak'
GO

For more information on using backup devices and step-by-step instructions on backing up and restoring a SQL Server environment, refer to Chapter 17.

Endpoints

Applications must use a specific port that SQL Server has been configured to listen on to connect to a SQL Server instance. In the past, the authentication process and handshake agreement were challenged by the security industry as not being robust or secure. Therefore, SQL Server 2005 introduces a new concept called endpoints to strengthen the communication security process.

The Endpoint folder residing under the Server Objects folder is a repository for all the endpoints created within a SQL Server instance. The endpoints are broken out by system endpoints, database mirroring, service broker, Simple Object Access Protocol (SOAP), and TSQL.

The endpoint creation and specified security options are covered in Chapter 13.

Linked Servers

As the enterprise scales, more and more SQL Server 2005 servers are introduced into an organization's infrastructure. As this occurs, you are challenged by providing a means to allow distributed transactions and queries between different SQL Server instances. Linked servers provide a way for organizations to overcome these hurdles by providing the means of distributed transactions, remote queries, and remote stored procedure calls between separate SQL Server instances or non–SQL Server sources such as Microsoft Access.

Follow these steps to create a linked server with SQL Server Management Studio (SSMS):

1. Choose Start, All Programs, Microsoft SQL Server 2005, SQL Server Management Studio.
2. In Object Explorer, first connect to the Database Engine, expand the desired server, and then expand the Server Objects Folder.
3. Right-click the Linked Servers folder and select New Linked Server.
4. The New Linked Server dialog box contains three pages of configuration settings: General, Security, and Server Options. On the General Page, specify a linked server name, and select the type of server to connect to. For example, the remote server could be a SQL Server or another data source. For this example, select SQL Server.
5. The next page focuses on security and includes configuration settings for the security context mapping between the local and remote SQL Server instances. On the Security page, first click Add and enter the local login user account to be used. Second, either impersonate the local account, which will pass the username and password to the remote server, or enter a remote user and password.
6. Still within the Security page, enter an option for a security context pertaining to the external login that is not defined in the previous list. The following options are available:
   • Not Be Made—Indicates that a login will not be created for user accounts that are not already listed.
   • Be Made Without a User's Security Context—Indicates that a connection will be made without using a user's security context for connections.
   • Be Made Using the Login's Current Security Context—Indicates that a connection will be made by using the current security context of the user which is logged on.
   • Be Made Using This Security Context—Indicates that a connection will be made by providing the login and password security context.
7. On the Server Options page, you can configure additional connection settings. Make any desired server option changes and click OK.

Triggers

The final folder in the Server Objects tree is Triggers. It is a repository for all the triggers configured within the SQL Server instance. Again, creating triggers is a development task and, therefore, is not covered in this book.

Administering the Replication Folder

Replication is a means of distributing data among SQL Server instances. In addition, replication can also be used as a form of high availability and for offloading reporting queries from a production server to a second instance of SQL Server. When administering and managing replication, you conduct all the replication tasks from within this Replication folder. Tasks include configuring the distributor, creating publications, creating local subscriptions, and launching the Replication Monitor for troubleshooting and monitoring.

Administering, managing, and monitoring replication can be reviewed in Chapter 6, "Administering SQL Server Replication."

Administering the Notification Services Folder

Notification Services is used for developing applications that create and send notifications to subscribers. Because Notification Services is a SQL Server component, Chapter 4, "Administering SQL Server 2005 Notification Services," is dedicated to administering Notification Services.