Hướng dẫn học Microsoft SQL Server 2008 part 110 pptx

Import and Export Wizard On many occasions SQL DBAs need to do the following: ■ Copy only a few tables from one SQL Server database to another SQL Server database ■ Import data from a fl

Detaching and Attaching

Though it is often overlooked, one of the easiest ways to move a database from one computer to another

is to detach the database, copy the files, and attach the database to SQL Server on the destination

computer

For developers who frequently move databases between notebooks and servers, this is the recommended

method Detaching a database effectively deletes the database from SQL Server’s awareness but leaves the

files intact The database must have no current connections and not be replicated if it is to be detached

Only members of theSysAdminsfixed server role may detach and attach databases

For more details on the security roles, refer to Chapter 50, ‘‘Authorizing Securables.’’

Detaching and attaching the database will carry with it any database users, security roles, and

permis-sions, but it will not replicate server logins These will need to be resolved manually on the destination

server It’s best to coordinate security with the network administration folks and leverage their security

groups If the source and destination servers have access to the same network security groups, this will

alleviate the security login issues for most installations

Using Management Studio, right-click the database to be copied and select Tasks➪ Detach The Detach

Database dialog, shown in Figure 44-17, will appear

FIGURE 44-17

The Detach Database feature removes the database from SQL Server’s list of databases and frees the

files for copying

Once the database file is detached, it will disappear from the list of databases in Management Studio.

The files may be copied or moved like regular files

To reattach the database file, select Databases in the Management Studio console tree and Tasks➪

Attach from the action menu or context menu The Attach Databases dialog, shown in Figure 44-18,

simply offers a place to select the file and verify the file locations and names

FIGURE 44-18

The database may be reattached by means of Management Studio’s Attach Databases tool

In code, the database is detached by running thesp_detach_dbsystem stored procedure The first

parameter is the database to be detached A second optional parameter simply turns off automatic

updating of the index statistics The following command detaches theAdventureWorks2008sample

database:

sp_detach_db ‘AdventureWorks2008’

If you wish to reattach a database with code, the counterpart tosp_detach_dbis thesp_attach_db

system stored procedure Attaching a database requires specifying the file locations as well as the

database name, as follows:

EXEC sp_attach_db @dbname = ‘AdventureWorks2008’,

Best Practice

It is recommended to use CREATE DATABASE database_name FOR ATTACH instead of the

sp_attach_dbstored procedure, as it will be removed in a future version of SQL Server Here is an

example:

CREATE DATABASE AdventureWorks2008 ON

(FILENAME = ‘ G:\MSSQL10.INST1\MSSQL\Data\AdventureWorks2008_Data.mdf’),

(FILENAME = ‘H:\MSSQL10.INST1\MSSQL\LOG\AdventureWorks2008_Log.ldf’)

FOR ATTACH;

Special Instructions for Detaching and Attaching the msdb

and model Databases

Detaching and attaching the msdb and model databases results in an error by default In order to detach

and attach the msdb and model databases, you need to start SQL Server with the -c option, the -m

option, and trace flag 3608 Trace flag 3608 recovers only the master database Once you start SQL Server

with these startup parameters, you can detach/attach msdb and model databases without any error message

Import and Export Wizard

On many occasions SQL DBAs need to do the following:

■ Copy only a few tables from one SQL Server database to another SQL Server database

■ Import data from a flat file or Microsoft Office Excel file

■ Copy data from one table to another with different collations

To achieve these DBA tasks easily and quickly, Microsoft has provided another powerful wizard called

SQL Server Import and Export Wizard This wizard enables copying data to and from any data source

for which a managed NET Framework data provider or a native OLE DB provider is available

You can access the Import and Export Wizard from various locations:

■ Choose Import and Export Data from Start ➪ Programs ➪ Microsoft SQL Server 2008

■ Open Management Studio, right-click a database and choose Task ➪ Import Data or Export Data from the context menu

■ Open SQL Server Business Intelligence Development Studio (BIDS) from Start ➪

Programs➪ Microsoft SQL Server 2008 Open an SSIS solution, select SSIS Import and

Export Wizard from the Project menu or by right-clicking the SSIS Packages folder

■ RunDTSWizard.exe(C:\Program Files\Microsoft SQL Server\100\DTS\Binn)

from the command prompt

To move data with the Import and Export Wizard, follow these steps:

1 Launch the Import and Export Wizard using one of the preceding methods.

2 Skip past the Welcome to SQL Server Import and Export Wizard by clicking Next.

3 On the Choose a Data Source page, select the source data If you launched the wizard from

Management Studio by right-clicking the database and choosing Task➪Export Data, the

source information is already preconfigured with the server and database name Depending on

the source data, the other options on this page will vary For example, selecting SQL Server

Native Client 10.0 allows you to specify the SQL Server, authentication, and database, as

shown in Figure 44-19 Click Next to proceed

FIGURE 44-19

Selecting SQL Server Native Client 10.0 as the data source and theAdventureWorksdatabase

4 On the Choose a Destination page, select the destination target If you launched the wizard

from Management Studio by right-clicking the database and choosing Task➪Import Data,

the destination information is already preconfigured with the server and database name This page also allows you to create a new destination database by clicking the New option, which invokes the dialog shown in Figure 44-20

FIGURE 44-20

Clicking New enables you to create a destination database

5 The Specify Table or Query page enables you to either copy all the data from existing source

tables or views or write a T-SQL query to limit the data to copy

6 On the Select Source Tables and Views page, select all the tables and views you want to

copy If you opted to write a query on the previous page, then you can just select the query

on this page Click Preview to preview up to 200 rows of source data Click Edit Map-pings to change the destination column names, data types, nullability, and size, as shown in Figure 44-21 If the destination table exists, you can either delete or append rows to it If there

is no destination table, you can create one

7 Depending on how you launched the Import and Export Wizard, the last step varies For

example, if you launched the wizard from BIDS, then in the last step you cannot run the resulting package; instead the package is saved as part of the SSIS solution If you launched the wizard from any other method (for example, Management Studio), then the wizard allows running the package in the last step, as shown in Figure 44-22

Best Practice

To copy the full database or multiple databases, use the Copy Database Wizard instead of the Import and

Export Wizard

FIGURE 44-21

Configuring the destination table and column mappings

FIGURE 44-22

Running the package immediately and saving the package with encryption

When you need to move a database, don’t back it up; there are better ways to move it Choose the right

transfer method based on network proximity of the servers and the objects and/or data to be moved

Some key points to remember are as follows:

■ Use the Detach/Attach method to quickly and easily move or copy a database from one server

to another

■ If you cannot afford to detach a database, use the good old Backup/Restore method to copy a database from one server to another

■ The Copy Database Wizard is very useful for copying or moving one or more databases from one server to another on the same network

■ To copy only a few tables from one server to another or to copy data to and from any data source for which a managed NET Framework data provider or a native OLE DB provider is available, use the Import and Export Wizard

■ Use Management Studio to quickly generate scripts to distribute database schemas, security, jobs, and limited data

Chapter 41, ‘‘Recovery Planning,’’ covers not only techniques for performing a backup, but also working

with transaction logs and recovering various data objects, up to an entire server

Database Snapshots

IN THIS CHAPTER

How database snapshots work Creating a database snapshot Using your database snapshots Performance considerations and best practices

The Database Snapshot feature, originally introduced in SQL Server

2005, allows for a point-in-time, read-only, consistent view of your

user databases to use for reporting, auditing, or recovering purposes

Before database snapshots, this functionality was achieved by running a backup

and restoring it to another database The big advantages provided by database

snapshots are the speed at which they can be created, as well as the ability to

create multiple database snapshots of the same source database, providing you

with snapshots of the database at different times

The Database Snapshot feature is only available in Enter-prise and Developer Editions of SQL Server 2008.

The Database Snapshot feature was primarily designed to do the following:

■ Generate reports without blocking the production/source database

■ Perform reporting on a database mirror

■ Recover from user or administrator errors

■ Revert the source database to an earlier time

■ Manage a test database

Database snapshots are similar to databases in many ways but they do have some

limitations of which you should be aware:

■ Database snapshots are read-only static copies of the source database

■ Database snapshots cannot be created for system databases (master,

model, andtempdb)

■ Database snapshots can be created only on an NTFS file system

■ Database snapshots can be created only on the same SQL Server instance where the source database exists

■ Database snapshots depend on the source database, so if the source database is unavailable for any reason, then all its database snapshots will become unavailable too

■ The source database cannot be dropped, detached, or restored as long as it has any database snapshots; but source database backups are not affected by database snapshots

■ You cannot backup or restore a database snapshot Nor can you attach or detach a database snapshot

■ You cannot revert to the database snapshot if you have multiple database snapshots You will need to drop all the database snapshots except the one to which you want to revert

■ Database snapshots do not support Filestream

■ Full-text indexing is not supported on database snapshots, and full-text catalogs are not propagated from the source database

■ In a log shipping configuration, database snapshots are allowed only on the primary database, not on the secondary or warm-standby database

■ Database snapshots are I/O intensive and may impact the performance of the system

If these limitations are acceptable, then Database Snapshots can be an excellent feature that you can use

to create point-in-time, read-only copies of your production databases

How Database Snapshots Work

As discussed earlier, a database snapshot is a point-in-time, read-only, static view of the source database

as it existed at the time the database snapshot was created When a database snapshot is created, SQL

Server runs recovery on the database snapshot and rolls back uncommitted transactions to make the

database snapshot transactionally consistent The transactions in the source database are not affected

A database snapshot is not the same as the source database It is a different database that has the same

number of data files as the source database but it does not have any transaction log file When it is

initially created, the data files in the snapshot database do not contain any user data and are almost

empty That is why creating a database snapshot does not take a long time Database snapshots use

a copy-on-first-write method for each source database page that is updated for the first time after the

database snapshot is created

For every database snapshot, SQL Server creates an in-memory bitmap It has a bit for each data page

indicating if the page is copied to the snapshot Every time an update is made to the source database,

SQL Server checks the bitmap to see if it has been copied to the snapshot If it is not copied, then SQL

Server copies the data page from the source database to the database snapshot and then makes the

update Next time, if the same page is updated, it is not copied, as the database snapshot just contains

the data as it existed on the source database when the snapshot was created This is referred to as

copy-on-first-write technology and is shown in Figure 45-1 If a data page on the source database is

never updated, it is never copied to the database snapshot

FIGURE 45-1

Database snapshot using copy-on-first-write technology

Data Page Data Page Source Database Database Snapshot

Data Page at the time snapshot was created Updated Data Page Unallocated Page Update

Creating a Database Snapshot

Database snapshots can be only created using the Transact-SQLCREATE DATABASE AS SNAPSHOT

command

SQL Server Management Studio does not have any graphical interface to create database

snapshots.

Here are the step-by-step instructions to create a database snapshot of theAdventureWorkssample

database:

1 The first step is to find out the information about the files in the source database The

follow-ing command can be used to retrieve information about the files in theAdventureWorks

database:

USE AdventureWorks;

GO

EXECUTE sp_helpfile;

GO

Result (abridged):

AdventureWorks_Data G:\ \AdventureWorks_Data.mdf 200640KB

AdventureWorks_Log H:\ \AdventureWorks_Log.ldf 504KB