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

Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 862 Part V Data Connectivity 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’s LoggingMode property: clear for Disabled, a black check for Enabled, and a gray check for UseParentSetting (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 o bject in the current tab. Note that providers can only be configured for the package, and any object with UseParentSetting will have its options grayed out in deference to its parents’ settings. 862 www.getcoolebook.com Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 863 Performing ETL with Integration Services 37 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 . TRC file 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 the dbo.sysssislog table 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 i t 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 . XML file. 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 i n 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 E nvironment Variable: These types can hold a single property only. ■ XMLFileandSQLServerTable:Each of these configuration types can hold any number of property settings. ■ Parent Package V ariable: Allows access to the contents of a single variable from the calling package. Most configuration types allow the storage l ocation 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 863 www.getcoolebook.com Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 864 Part V Data Connectivity 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. ■ Theconfigurationusedonrestartissavedin 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 either IfExists (starts at the beginning of the package if no file exists or at the restart point if the checkpoint file exists) or Always (fails if the checkpoint file does not exist). ■ SaveCheckPoints: Set to True. In addition, the FailPackageOnFailure property must be set to True for 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 run dtexecui from 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 appropriate dtexec command-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 b y packages to reduce startup time. 864 www.getcoolebook.com Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 865 Performing ETL with Integration Services 37 Installing packages Creating a deployment utility enables the i nstallation 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 a nd choosing Properties. Navigate to the Deployment Utility page of the resulting dialog and set the value of CreateDeploymentUtility to True. Review the settings for DeploymentOutputPath 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 o f 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) package. Similar functionality is available from the dtutil command-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 invokes dtexecui for the selected package. ■ Run the dtexecui utility, which enables the full array of execution options to be selected. It also displays the command-line switches to use with the dtexec command-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 using dtexec/dtexecui can 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. 865 www.getcoolebook.com Nielsen c37.tex V4 - 07/21/2009 2:13pm Page 866 Part V Data Connectivity Summary 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, a uditing 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 c ost savings and performance gains can be truly stunning. 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. 866 www.getcoolebook.com Nielsen c38.tex V4 - 07/23/2009 4:01pm Page 867 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 A ccess was originally conceived a s 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 i s 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 a s 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 your SQL Server data, see the Microsoft Office Access Vision white paper, http://office.microsoft.com/en-us/access/HA102133061033.aspx. 867 www.getcoolebook.com Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 868 Part V Data Connectivity 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 a lso 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 Successful Access database applications outlive their usefulness for a variety of reasons, and at some point you may decide that it’s time to upgrade to a server database. Or perhaps your application has 868 www.getcoolebook.com Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 869 Access as a Front End to SQL Server 38 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 an y problems with your Access a pplication 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 R ather 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 869 www.getcoolebook.com Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 870 Part V Data Connectivity 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 use SELECT * without a WHERE clause, or allow users to do so. Create q uery-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 e dit, 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 written in Transact-SQL and are passed directly to SQL Server without being syntax checked or parsed by Jet/ACE or ODBC. They always return read-only data. 870 www.getcoolebook.com Nielsen c38.tex V4 - 07/21/2009 2:15pm Page 871 Access as a Front End to SQL Server 38 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 o r 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. ■ If you are using SQL logins, you can prompt for user credentials to avoid storing them on the local machine. ■ You do not need to worry about copying o r maintaining DSNs on different machines. 871 www.getcoolebook.com . http://office .microsoft. com/en-us/ access/HP052730 0910 33.aspx ■ SQL Server Integration Services (SQL Server 2008 Books Online) http://msdn .microsoft. com/en-us/library/ms141026.aspx ■ Microsoft Access to SQL. 867 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. 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