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

Once installed, a package is known to the Integration Services service, which in turn can be connected to SQL Server Management Studio for tracking and monitoring.. Log on to the target

tab, add a provider for each output type that will be logged (multiple are allowed) On the Details tab,

specify the events for which log entries will be written; the advanced view, shown in Figure 37-6, also

allows selecting which columns will be included in each event’s log entry

FIGURE 37-6

Advanced view of the Logging Details tab

The tree view in the left pane represents the container hierarchy of the package The check boxes

correspond to each object’sLoggingModeproperty: clear for Disabled, a black check for Enabled,

and a gray check forUseParentSetting(logging settings inherited from the parent) By default,

all objects inherit from the package settings Highlighting an item in the tree displays the details

for that object in the current tab Note that providers can only be configured for the package, and

any object withUseParentSettingwill have its options grayed out in deference to its parents’

settings

The standard log providers are as follows:

■ Text File: Writes a comma-separated-value text file Configure with an appropriate File

connection manager

■ SQL Profiler: Writes a TRCfile that can be viewed in the Profiler application This can be

a useful option when viewed with other trace or performance information within Profiler

Configure with an appropriate File connection manager

■ SQL Server: Writes log entries to thedbo.sysssislogtable in the database indicated by

the associated OLE DB connection manager Any database can be chosen to host this table If

the table does not exist, then it will be created on first use

■ Event Log: Writes log entries to the Windows application event log on the computer that

executes the package No configuration is required

■ XML File: Writes an XMLfile Configure with an appropriate File connection manager

Once a useful set of event/column combinations has been constructed, it can be saved as a template and

reloaded on other packages

Package configurations

Package configurations make it easier to move packages between servers and environments, providing

a way to set properties within the package based on environment-specific configurations For example,

the server names and input directories might change between the development and production

environments

Right-click on the package design surface and choose Package Configurations to setup/modify

con-figurations The configurations shown are applied to the package in the order listed To add a new

configuration, ensure that configurations are enabled and click Add to start the Package Configuration

Wizard Choose the desired Configuration Type (storage location) There are essentially three categories

to consider:

■ Registry and Environment Variable: These types can hold a single property only

■ XML File and SQL Server Table: Each of these configuration types can hold any number of

property settings

■ Parent Package Variable: Allows access to the contents of a single variable from the calling

package

Most configuration types allow the storage location to be identified either directly or via an environment

variable The environment variable approach can be useful when the storage location (such as file

direc-tory) must change between environments Once the configuration type and location are specified, the

Select Properties to Export option enables the properties that will change between environments to be

chosen Complete the wizard by reviewing the selections and giving the configuration a name

Configurations can be reused between packages if the names of the objects containing the properties to

be set are the same between packages For example, packages that use the same names for their

con-nection managers could share a configuration that sets server or filenames To share a configuration in

a subsequent package, choose the same configuration type, and then specify the same storage location

(e.g., XML filename) as the initial package When prompted by a dialog warning that the configuration

already exists, select Reuse Existing

Checkpoint restart

Enabling checkpoint restart allows a package to restart without rerunning tasks that already completed

successfully Note the following basic rules about restart points:

■ Only Control Flow tasks define restart points — a Data Flow task is viewed as a single unit of work regardless of the number of components it contains

■ Any transaction in progress is rolled back on failure, but the restart point may not coincide with a transaction boundary, so unexpected results can occur

■ Any loop containers are started over from the first iteration

■ The configuration used on restart is saved in the checkpoint file, rather than the current configuration file

Enable checkpoints by setting the package properties:

■ CheckpointFilename: Name of the file in which checkpoint information should be saved

■ CheckpointUsage: Set to eitherIfExists(starts at the beginning of the package if no file exists or at the restart point if the checkpoint file exists) orAlways(fails if the checkpoint file does not exist)

■ SaveCheckPoints: Set toTrue

In addition, theFailPackageOnFailureproperty must be set toTruefor the package and every

task or container that can act as a restart point

Deploying Packages

The Business Intelligence Development Studio is an excellent environment for designing and debugging

Integration Services packages, but it is not an efficient method for routinely executing packages

Without installing a package on a server, it can execute without the development overhead by using

dtexec/dtexecui You can rundtexecuifrom the command line, or you can choose the Execute

Package Utility from the Start menu, and specify the desired execution options Then either choose the

Execute button or switch to the Command Line page to copy the appropriatedtexeccommand-line

switches

Conversely, installing packages on the target SQL Server(s) makes sense when a package will be reused

Once installed, a package is known to the Integration Services service, which in turn can be connected

to SQL Server Management Studio for tracking and monitoring Integration Services also caches the

components executed by packages to reduce startup time

Installing packages

Creating a deployment utility enables the installation of all the packages in a project on a target server

Configure the utility by right-clicking on the project (not the package) in the Solution Explorer and

choosing Properties Navigate to the Deployment Utility page of the resulting dialog and set the value

ofCreateDeploymentUtilitytoTrue Review the settings forDeploymentOutputPath

indicating where the install package will be written relative to the project directory, and the setting of

AllowConfigurationChanges, which enables configuration values to be adjusted as part of the

install process Save the property changes, and then right-click on the project and choose Build to create

the install package

Once the deployment utility has been created, double-click the package manifest(<project

name>.SSISDeploymentManifest) to start the package installation Given a network

connection to the target server and adequate permissions, the installation can be run from any

machine

In addition, individual packages can be installed on a server using SQL Server Management Studio Log

on to the target server and connect the local instance of Integration Services in the Object Explorer On

either the File System or msdb nodes, right-click and choose Import Package Note that the source

pack-age can be stored either as a file or as a SQL Server (msdb) packpack-age Similar functionality is available

from thedtutilcommand-line utility

Executing packages

Once installed on the target server, a package can be executed in several ways:

■ Locate the installed package in SQL Server Management Studio, right-click, and choose Run

Package, which in turn invokesdtexecuifor the selected package

■ Run thedtexecuiutility, which enables the full array of execution options to be selected It

also displays the command-line switches to use with thedtexeccommand-line utility

■ From a SQL Agent Job step, choose the step type as SQL Server Integration Services Package,

and the package source as SSIS Package Store

The execution method and location that you choose can have a profound effect on performance and

reporting Execution usingdtexec/dtexecuican offload package processing from the SQL Server

when run on another server or workstation These options also default to providing verbose feedback

during execution, which can be useful in tracking progress or understanding errors However, consider

network traffic that may be introduced by this scenario For example, loading a series of data files

from a file server to the SQL Server via a workstation can double the network load (every file must

move from the file server to the workstation, and then again from the workstation to the SQL Server)

compared to running the package on the SQL Server

Running a package via the SQL Agent causes the package to execute on the SQL Server, which tends to

minimize network load, but this can be a problem if the SQL Server does not have adequate resources

to accommodate the often memory-hungry package

Integration Services is a capable environment for building applications that move large quantities of data

efficiently and for sequencing multi-step processing with error handling Management features such as

easy installation, auditing and logging facilities, and environment-specific configurations make Integration

Services applications easy to live with once developed

Many organizations have written reams of Transact-SQL and programmed custom applications to address

tasks that Integration Services handles with ease For those willing to make a small investment in

learn-ing the Integration Services environment, the cost savlearn-ings and performance gains can be truly stunnlearn-ing

The best way to get started is to choose a small project and dive in Like any programming

envi-ronment, the first application won’t be perfect, but soon you’ll wonder how you ever lived without

Integration Services

Access as a Front End

to SQL Server

IN THIS CHAPTER

Access–SQL Server use case scenarios

Migrating from Access to SQL Server

Designing your Access front end

Connecting to SQL Server Monitoring and

troubleshooting

Ad hoc querying and reporting

Access was originally conceived as a standalone desktop database product,

combining in one file a relational database engine (Jet) as well as user

interface objects, such as forms, reports, macros, designers, and a VBA

coding environment Its very name, Access, denoted one of its most powerful

features: the ability to easily incorporate data originating from heterogeneous

data sources When Access was introduced, installable ISAM drivers were used

primarily for linking to the prevailing desktop databases, such as Paradox, dBase,

and FoxPro, or to Lotus and Excel spreadsheets An ODBC installable ISAM

enables connecting to many server-based database systems, such as SQL Server

and Oracle, and additional drivers have been added to connect to Microsoft

Exchange Server data and to HTML tables In Access 2003, Windows SharePoint

Services support was added, which enabled linking to SharePoint lists, allowing

them to be queried and updated as if they were standard relational tables

Access 2007 introduced a new version of the Jet database engine, ACE, which is

designed to support Access-specific features but is 100% backward compatible

with Jet When it comes to the mechanics of working with SQL Server, the

underlying architecture is fundamentally the same as it was in Jet, so regardless

of which version of Access you are using, the techniques for working with SQL

Server data described in this chapter apply, except where otherwise noted

The Access 2007 user interface is designed to make working in the Access

environment more intuitive for information workers, providing a more Excel-like

experience in datasheet view, introducing powerful new filtering, sorting, and

totaling features, along with improved designers for forms and reports

For more in-depth information and ideas for getting the most out of using Access 2007 as a front end for

Access–SQL Server Use Case Scenarios

Using Access as a front end to SQL Server can be an optimal solution for a wide variety of business

problems, often delivering the best return on investment while meeting the business requirements The

following are several scenarios in which Access has proven to be effective:

■ The business problem does not warrant the expense of a full-fledged, end-to-end NET solution

■ You want to empower users to solve their own problems For example, executives and power users want to access server data to run their own analytics and create ad hoc reports

■ You need to deliver a solution in a time frame that does not allow for a lengthy development process

■ You work in an agile, iterative programming environment, and Access enables you to deliver prototypes quickly

■ Your application exists behind the corporate firewall where users are authenticated by Windows

■ You use Access as part of a hybrid application, such as a customer-facing web application created in ASP.NET with a data maintenance component that uses Access

■ You work with heterogeneous data from different vendors or data stores For example, cus-tomer data is stored in relational SQL Server tables, while internal data may be stored in SharePoint lists Access makes it simple to create data entry forms and reports based on queries that join this heterogeneous data

Access projects or ODBC linked tables?

Access project files, also called ADPs or adp files, provide an alternative to using the Access database

engine by allowing an Access application to connect to the tables in a SQL Server database using OLE

DB as an alternative to the Jet engine, which connects to SQL Server using ODBC Because ADPs do not

use a local database engine, they also do not support the use of local Access tables

ADPs also provide visual designers for creating database objects in SQL Server However, these features

can become outdated as new versions of SQL Server are released Microsoft recommends the use of

Access databases with ODBC linked tables to connect to SQL Server data, which gives you the best

performance in most situations and the widest set of features For creating server-side objects, Microsoft

recommends that you use a version of SQL Server that contains SQL Server Management Studio

If you are an Access developer who does not have access to one of the full versions of SQL Server, the SQL Server Developer Edition, which is priced at $49 U.S., contains all of the features and functionality of the Enterprise Edition It has all the designers and tools you need to create

and secure your server-side data objects, although there are some licensing restrictions.

Migrating from Access to SQL Server

become indispensable to the business, and you need server-side features such as security, support for

larger numbers of concurrent users, and reliability

Migrating to SQL Server is not a panacea for problems that may have existed in the original Access

application In fact, the exact opposite is often true It is not uncommon for a straight port of an

Access application to run much more slowly when the data is in SQL Server The Access Jet/ACE

database engine and the SQL Server database engine are quite different, and what worked well in your

Access application can cause problems when the data is moved to the server Performance problems are

magnified, not reduced, when server and network overhead are added to the mix

You need to diagnose and thoroughly understand any problems with your Access application before you

dive into migrating Often issues like database corruption and poor performance can be fixed by taking

simple measures to solve the problem in Access, removing the need to do a migration at all In other

cases, a complete rewrite from the ground up is required Thoroughly understanding the problem will

help you make the right decision, saving you time and money

Once the decision is made, migrating data is actually the easiest and least complicated part of the

process

Resources for Migrating from Access to SQL Server

Rather than rewrite it all, some great resources are already available that will help you plan and implement

a migration:

■ Microsoft Access or SQL Server: What’s Right in Your Organization? http://

download.microsoft.com/download/a/4/7/a47b7b0e-976d-4f49-b15d-f02ade638ebe/SQLAccessWhatsRight.doc

■ The SQL Server Migration Assistant for Access (SSMA Access) starter videos and FAQ

www.microsoft.com/sqlserver/2005/en/us/migration-access-learning.aspx

■ Move Access data to a SQL Server database by using the Upsizing Wizard http://

office.microsoft.com/en-us/access/HA102755371033.aspx?pid=

CH101759711033

■ Use the Upsizing Wizard (Access 2003) http://office.microsoft.com/en-us/

access/HP052730091033.aspx

■ SQL Server Integration Services (SQL Server 2008 Books Online) http://msdn

.microsoft.com/en-us/library/ms141026.aspx

■ Microsoft Access to SQL Server Upsizing Center (resources from FMS, Inc.) www

.fmsinc.com/Consulting/sqlserverupsizing.aspx

Designing Your Access Front End

When creating an Access application that connects to SQL Server, use the same general design principles

that you would if you were creating a web application Here are a few general suggestions:

■ Fetch only needed data Do not link to large tables or views

■ Perform data processing on the server, not the client

■ Normalize your database and create appropriate indexes

■ Do not useSELECT *without aWHEREclause, or allow users to do so Create query-by-form user interfaces that force users to select criteria that reduce the size of result sets

■ Populate form elements such as list boxes and combo boxes when a user clicks on the control, not when the form loads Otherwise, if you have a bound form with six combo boxes, then Access must run seven concurrent queries when the form opens

■ Take advantage of local Jet/ACE storage to cache static data that rarely changes

■ For editing data, create browse forms populated with read-only data When the user selects a row to edit, load it read/write in a separate form

■ When creating reports, use pass-through queries to execute stored procedures, views, or user-defined functions that process aggregate data on the server

■ Do not use Access expressions or functions in queries The function must run once for every row retrieved, slowing down processing If you want to format the data, do so using expressions bound to form or report controls

■ If you want users to be able to create their own ad hoc queries without negatively impacting OLTP operations, create a separate set of ‘‘reporting tables’’ that they can query instead of the tables used in production Reporting tables can be refreshed in the background or on demand

If you want to maximize the performance and scalability of your Access– SQL Server applications, or just want a deeper understanding of the interactions between Access and SQL Server, the white paper ‘‘Optimizing Microsoft Office Access Applications Linked to SQL Server’’

( http://msdn.microsoft.com/en-us/library/bb188204.aspx ) is indispensable Many pitfalls can be

avoided by understanding how Access interacts with SQL Server, freeing you to create rich Access client

applications quickly and easily while treading lightly on your SQL Server.

Connecting to SQL Server

There are several ways you can interact with SQL Server data from an Access client application:

■ Through linked tables and views in the user interface

■ Programmatically using VBA/ADO

■ Using pass-through queries to bypass the Jet/ACE database engine Pass-through queries are

Linking to tables and views

When you connect to a SQL Server database using the Access user interface, a wizard loads, prompting

you for information about the ODBC database to which you want to connect You have the option to

import the data into a new table in the current Access database, or to link to the data source by creating

a linked table The wizard then asks you to select an ODBC driver (see Figure 38-1) If you are using

SQL Server 2008, choose the SQL Server Native Client 10.0 driver

FIGURE 38-1

Use the External Data tab on the ribbon to access the ODBC Administrator and specify a DSN to

connect to SQL Server

You are then prompted for additional information, such as the database name Once the DSN is created,

Access displays a list of tables to which you can link You can then select one or more tables, which are

displayed in the Access user interface using the underscore character to separate the schema name from

the object name For example, Sales.SalesOrderHeader will be displayed as Sales_SalesOrderHeader If

you are linking to a view, you will be prompted to designate a primary key, which Access requires in

order for the view to be updatable

Using DSNs to link to SQL Server tables is fine for quick-and-dirty linking, but DSNs are difficult to

manage, so for applications you deploy to your users you may prefer to link using VBA code There are

several advantages to this:

■ You can prompt the user for specific connection information, such as the name of a server or

database