Hướng dẫn học Microsoft SQL Server 2008 part 12 docx

Installing SQL Server2008 IN THIS CHAPTER Server-hardware recommendations Planning an installation Installing multiple instances of SQL Server Upgrading from previous versions of SQL Ser

Installing SQL Server

2008

IN THIS CHAPTER Server-hardware

recommendations Planning an installation Installing multiple instances of SQL Server

Upgrading from previous versions of SQL Server Migrating to SQL Server

The actual process of installing SQL Server is relatively easy; the trick is

planning and configuring the server to meet the current and future needs

of a production environment — planning the hardware, selecting the

operating system, choosing the collation, and several other decisions should be

settled prior to the SQL Server installation

Not every SQL Server 2008 server will be a fresh installation SQL Server 2000

and SQL Server 2005 servers can be upgraded to SQL Server 2008 Additionally,

the data might reside in a foreign database, such as Microsoft Access, MySQL, or

Oracle, and the project might involve porting the database to SQL Server

Not every SQL Server 2008 server will run production databases — there

are developer sandbox servers, quality test servers, integration test servers,

performance test servers, and the list goes on This chapter discusses all these

situations to help you avoid surprises

Selecting Server Hardware

The value per dollar for hardware has improved significantly and continues to do

so Nevertheless, large datacenters can still cost hundreds of thousands of dollars

This section provides some design guidelines for planning a server

CPU planning

SQL Server needs plenty of raw CPU horsepower Fortunately, the newer crop

of CPUs perform very well and today’s servers use multi-core CPUs Microsoft

licenses SQL Server by the CPU socket, not the number of cores Comparing the

dropping price of multi-core CPUs with the license cost of SQL Server, it makes

sense to buy the most cores possible per socket When planning your server, note

the following:

will see high transactions (>10K per second), then choose Itanium 64-bit CPUs because they

have better throughput than x64 CPUs

What’s New with SQL Server Setup?

brand-new It’s been completely rewritten from the ground up

If running the Surface Area Configuration tool was part of your SQL Server 2005 installation process, you’ll

notice that it’s gone, replaced with Policy-Based Management policies

Copious memory

Memory is a magic elixir for SQL Server Any time the data is already in cache it’s a big win for

per-formance Balance the performance of the CPUs, memory, and disk subsystems, but focus on memory

More memory will reduce the I/O requirement and thus also reduce the CPU requirement

When planning server memory, I recommend the following:

■ The easy answer is to buy as much memory as you can afford SQL Server consumes memory

for cached query execution plans and cached data pages, so the amount of memory needed isn’t based on the size of the database but on the number of queries I recommend using this formula as a baseline for required memory: 2 Gb for the OS and SQL Server, plus 1 Gb per 1,000 queries per second Of course, this greatly depends on the complexity of the query and the type of index access An efficiently designed database (great schema, queries, and indexing) can support more queries per gigabyte than a poorly designed database

■ If the amount of memory will eventually exceed 4 Gb, I also strongly recommend using 64-bit

versions of the operating system and SQL Server because the memory addressing is so much smoother than the 32-bit AWE solution

To enable AWE, SQL Server 2008 must run under an account that has the Lock Pages in Memory option turned on and the AWE Enabled option set to 1 using sp_configure

Disk-drive subsystems

The disk subsystem is critical for both performance and availability Here are some guidelines for

planning the disk subsystem:

■ The scalability bottleneck is typically the disk subsystem throughput If you can use a storage

area network (SAN) for your disk subsystem, do so A properly configured SAN will scale

further than local disk subsystems SANs offer four significant benefits: They spread the files

across several disk spindles; they use a high-speed fiber optic connection; they typically

include a very large RAM buffer to absorb bursts of traffic; and SANs can usually perform a

hardware level snapshot backup and restore

The cons are that SANs cost 40–50 times as much as local disk space and they are very

difficult to configure and tune, so encourage the SAN administrator to focus on the database

requirements and carefully configure the database LUNs (Logical Unit Number — similar to

a virtual drive) so the database isn’t lost in the organization’s common file traffic This can

be very difficult to do, especially when file server and database traffic are combined on the

same SAN

■ Never, never, ever try to use iSCSI devices that connect the server and the disk subsystem

using Ethernet The Ethernet simply won’t keep up and the TCP/IP stack possessing will

consume CPU cycles It’s a sure way to waste a lot of time (trust me)

■ Watch the prices for the new solid-state drives (SSD) and move to them as soon as it’s

afford-able SSD drives will dramatically improve both database performance and availability Even

if you have a SAN, I’d use a local SSD drive for the database transaction log,tempdband its

transaction log

If you aren’t using a SAN, here are my recommendations for configuring local direct attached storage

(DAS) Each DAS disk subsystem has its own disk controller:

■ Using one large RAID 5 disk array and placing all the files on the array may be easy to

con-figure, but it will cost performance The goal of the disk subsystem is more than redundancy

You want to separate different files onto dedicated disks for specific purposes

■ SATA drives don’t wait for a write to complete before telling Windows they’re finished with

the task While this might be great for a PC, it shortcuts the SQL Server write-ahead

transac-tion log verificatransac-tion and compromises data durability Don’t use SATA drives for productransac-tion,

use SCSI drives

■ The goal for database disk subsystems is not to use the largest disk available, but to use more

spindles Using four 36GB drives is far better than a single 146GB drive More spindles is

always better than fewer spindles If a byte is striped across 8 drives, then the controller can

read the entire byte in one-eighth of the time it would take if the byte were on a single drive

Use RAID striping, multiple filegroups, or a SAN to spread the load across multiple spindles

■ When choosing drives, choose the highest spindle speed and throughput you can afford

■ SQL Server is optimized to read and write sequentially from the disk subsystem for both data

files and transaction logs, so use RAID 1 (mirrored) or RAID 10 (mirrored and striped), which

is also optimized for sequential operations, rather than RAID 5, which is better for random

access

■ While software options are available to provide behavior similar to RAID, they are not as

efficient as RAID-specific hardware solutions The software solutions tie up CPU cycles to

perform the RAID activities that could be used for server processing Don’t use software RAID

for a production SQL Server

■ The transaction log for any database that sees a significant value of writes should be on a

dedicated DAS so that the heads can stay near the end of the transaction log without moving

to other files In addition, be sure to put enough memory into the disk controller to buffer a

burst of transactions, but ensure that the disk controller buffer has an on-board battery

good idea.

■ Windows wants to have a quick swap file Regardless of how much physical memory is in the

server, configure a large swap file and place it on a dedicated disk subsystem

■ To recap scaling out a non-SAN disk subsystem, Table 4-1 lists one possible configuration of

disk subsystems Each drive letter might actually be configured for multiple striped drives

They’re listed by priority — for example, if you only have four drive subsystems, then break out the transaction log, first data file, andtempdbtransaction log

TABLE 4-1

Scaling Non-SAN Disk Subsystems

RAID Illustrated

that utilizes two or more drives in combination for increased performance and fault tolerance RAID

applications are typically found in high-performance disk systems utilized by servers to improve the

persistence and availability of data Table 4-2 describes the various levels of RAID

Network performance

Typical motherboards today include built-in network interface cards (NICs) capable of auto-switching

between 10/100/1,000Mbps As with most built-in devices, these tend to utilize the CPU for required

processing, which affects performance A variety of manufacturers today offer NIC cards that include

onboard TCP/IP stack possessing, freeing up those tasks from the CPU This improves overall network

TABLE 4-2

RAID Levels

(percent of disks dedicated

to redundancy)

Description

disk extends the storage as if the disk were replaced with a larger one

across multiple drives, speeding up data writes and reads No parity, redundancy, or fault tolerance is available

two drives and read from either drive, providing better fault tolerance

5

Parity

1/(n-1) For example, if the RAID array has five drives,

array is used for redundancy

Data striping with a parity bit written

to one of the drives Because of the parity bit, any single drive can fail and the disk subsystem can still function When the failed disk drive is replaced, the disk subsystem can recreate the data on the failed drive it contained

6

Parity Parity

Depends on the number

of drives (e.g., if ten drives and the last two are used for parity, then 25%)

Or use a formula: 2/(n-2)

RAID 6 is similar to RAID 5, except the parity bit is mirrored to two drives, so any data drive and one of the parity drives could fail

simultaneously and the drive subsystem could continue to function

the speed of data striping and the protection of data Mirroring

I strongly recommend running any production SQL Server on a dedicated server — don’t use the server

for file or printer services, and no exchange, and no IIS — for two reasons:

■ Availability: Multiple services running on the same server increases how often the server

requires service pack installations, adjustments, and possibly rebooting A dedicated SQL Server installation increases database availability

■ Economics: SQL Server is both resource intensive and expensive SQL Server eats memory

for lunch It doesn’t make economic sense to share the server resources between the expensive SQL Server license and other less expensive software

When to Consolidate and Virtualize?

one large box can be cost effective and attractive in a spreadsheet The question is, when is it a good

idea for SQL Server?

■ CTP testing: Personally, I’m a big fan of Microsoft Virtual PC and I often build up a

SQL Server instance using VPC Until the SQL Server 2008 RTM version is available,

I only run Katmai CTP builds in a VPC (I wrote this entire book with Katmai CTPs

running on a VPC full-screen on one monitor and Word running on the host operating

system on a second monitor.) Virtual PC is so easy to set up, and so safe, it doesn’t

make any sense to run a pre-RTM version of any software on the host operating

system

■ Developer sandboxes: Developer Edition is so inexpensive that I recommend all

developers have a license for Developer Edition on their own machine, rather than use

a virtualized server

■ QA, test, integration testing, and pre-prod servers: Every organization has its own

way of pushing code from the developer to production, or from the vendor to

pro-duction Because these applications demand strict application compatibility, but not

performance compatibility, VPCs are perfect for this type of testing

■ Service pack testing: A virtual server is a great way to build up test servers for these

configurations, or for testing Microsoft service packs

■ Performance testing: Depending on the scope of performance testing, a virtual server

may be able to show performance gains for a new rev of the database code; but if the

continued

environment needs to be identical to production and that counts out virtualization

■ Production: With Windows Server 2008 and HyperV, running multiple SQL Server

servers in a virtualized environment for production is a very reasonable alternative

The other obvious option of SQL Server consolidation is running multiple SQL Server instances on the same

physical server This still enables each instance to have its own server settings and service pack level My

primary concern with multiple instances is that I want to avoid any resource contention

Operating system

SQL Server 2008 installs and runs on various operating systems — from Windows XP to Windows

Server 2003 Enterprise Edition, with the more feature-rich versions running on the higher-end operating

systems Appendix A, ‘‘SQL Server 2008 Specs,’’ includes a table listing the supported operating systems

by edition

Service accounts

The SQL Server services require Windows login accounts to run and access the file system It’s possible

to allow SQL Server to run using the local service account, but creating a specific Windows user account

for SQL Server services provides better security and reliability You can configure these accounts with

the required minimum set of permissions (user, not administrator) and access to the data files

The accounts can be specified independently during installation by selecting the ‘‘Customize for each

service account’’ option By default, SQL Server, SQL Server Agent, Analysis Server, and SQL Browser

share the same login account Ensure that the assigned Windows login account for each service has

the appropriate file and resource permissions Each login account and service relationship is listed in

Table 4-3

If the installation will include servers that will communicate and perform distributed queries or

replica-tion, then the login account must be a domain-level account

Server instances

SQL Server 2008 Enterprise Edition supports up to 50 instances of SQL Server running on the same

physical server, including instances of different editions (Enterprise, Standard, or Developer) The

advan-tage of multiple instances is that each instance can have its own server-level configuration and service

pack level

Using multiple instances of SQL Server to provide multiple databases on the same server negatively affects performance Each instance requires its own resources as well as CPU cycles to handle requests While using a multi-core processor could mitigate the performance issues to

an extent, using a large virtualized server or a single SQL Server to handle multiple databases is the best

solution.

SQL Server SQL Express on Windows 2000– local

system SQL Express on all other operating systems–network service

All other editions on all operating systems–domain user

SQL Express–domain user, local system, network service All other editions– domain user, local system, network service

network service

network service, local service

network service, local service Integration

Services

Windows 2000–local system All other operating systems–network service

Domain user, local system, network service, local service

network service, local service SQL Server

Browser

SQL Express on Windows 2000–local system

SQL Express on all other operating systems–local service

All other editions on all operating systems–domain user

Domain user, local system, network service, local service

SQL Server Active

Directory Helper

The default location for SQL Server and associated files will be similar to the following:

C:\Program Files\Microsoft SQL Server\MSSQL.#

An instance can be installed as the default instance (with the same name as the server) or a named

instance (with the name as servername\instancename) I recommend installing only named instances on a

production server as a security measure Depending on the hack, the hacker needs to know the instance

name as well as the server name

Not all installed services are shared among the multiple instances Table 4-4 shows a list of shared

ver-sus instance services Instance-specific services will have their own installed components

TABLE 4-4

Shared SQL Server Services

Performing the Installation

Once the installation plan has been created and the server is set up to meet the SQL Server

requirements, it is time to install the software

one UI a broad collection of installation utilities and resources — from the planning stage to advanced

options

In the Planning page there’s an option to install the Upgrade Advisor If you’re upgrading an existing

database to SQL Server, I recommend running this utility on the existing database to check for any

potential issues

By default, the Installation Center will choose the highest CPU level available on the server (x86, x64,

IA-64) If you want to install a different CPU version of SQL Server, the Installation Center’s Options

page is the only location for this option

Attended installations

A new installation is initiated from the Installation page➪ ‘‘New SQL Server stand-alone installation or

add features to an existing installation.’’ The installation process moves through several pages according

to the type of installation and components selected

Errors, or missing items, appear at the bottom of the page with red Xs You cannot progress past any

page with an error