Speed Up SQL Server Apps -提高SQL Server应用程序的运行效率 (Part 2)

6) Utilize SQL Server Aliases（使用SQL Server别名）
SQL Server Client Network Utility allows you to create alias names for SQL Server instances. The utility also lets you associate each alias with a specific network protocol. Once you create an alias, any connections that use the aliased name will be directed to the corresponding server name or IP address.

Aliases are beneficial in many scenarios. For example, you can alias an IP address of a remote SQL Server to a friendly name, or you can create an alias if your application requires the Named Pipes protocol instead of TCP/IP. The biggest benefit of using SQL Server aliases comes from being able to redirect all connections from a client computer to another SQL Server quickly and easily. One common scenario is using redirection to a standby SQL Server for high availability. Consider what happens if your primary server goes down. You need to point all applications to the secondary server in a flash. This might require modifying many connection strings if you have a Web server with many Web sites—or you can simply alias the name of the primary server to the name of your secondary server.

Figure 1. Create SQL Server Aliases.                                                    
You can set up a SQL Server alias in the SQL Server Client Network Utility. Any connections to MyServer end up connecting to MyBackupServer instead, without you modifying any connection strings. You set aliases on computers where your ADO or ADO.NET executes.

 

SQL Server Client Network Utility is a part of SQL Server client tools, but you don't have to install the client tools on every computer you want to use. The MDAC pack install also includes this utility, which you can run by executing "cliconfg" from the command prompt if SQL Server client tools aren't installed.

7) Disable Triggers Instead of Dropping Them（使Triggers失效，而不是删除）
Business rules in table triggers often expect your application to update the table one row at a time. Also, some triggers generate an error when the code in the trigger assigns to a local variable the value returned by selecting a column from the inserted virtual table. The assignment fails if you're updating multiple rows because the inserted table contains more than one row, so the subquery returns more than a single value.

Multirow updates need special handling in such a scenario. Developers often wind up dropping a trigger before multirow updates, then creating them later to resume single-row updates. However, I recommend disabling such a trigger instead:

ALTER TABLE MyTable 
     

   DISABLE TRIGGER MyTrigger 
     

You can re-enable the trigger once you finish your multirow data updates:

ALTER TABLE MyTable 
     

   ENABLE TRIGGER MyTrigger 
     

 

8) Don't Rename Script-Based Objects（不要改名基于SQL脚本创建的对象）
You'll often create a script-based object, such as a view, a stored procedure, or a user-defined function. SQL Server then stores the script that created the object in the text column of the syscomments system table. SQL Server also creates a row in the sysobjects table, as it does for most database objects.

The problem arises when you rename the object in Enterprise Manager or with the sp_rename stored procedure. Unfortunately, SQL Server then only modifies the object name in the sysobjects table. It doesn't modify the script in the syscomments table, so the script remains stored with the old name.

The new object will work, but you'll get an error the next time you try to modify the object in Enterprise Manager, because the object name in the script doesn't match the new name. You might also end up deploying the object to another server with the old name inadvertently, because Enterprise Manager generates scripts by reading the syscomments table. The "CREATE …" part of the script winds up using the old name. Save the original script, delete the object, then re-create it with the new name.

9) Don't Trust Generated Table Modification Scripts（不要相信自动生成的数据表修改脚本）
Enterprise Manager, Visual Studio, and third-party tools let you add, drop, and modify table columns in a visual, easy-to-use environment. You click on Save; then they generate and execute Transact-SQL scripts under the hood. It's tempting to modify tables this way—after all, they shield you from the complexities of data definition language.

However, the scripts these visual tools produce often generate more SQL than required, or they generate scripts that might not be suitable in a production environment. These scripts often drop and re-create the table you're modifying instead of using the ALTER TABLE command. Consequently, large tables (with millions of rows) can chew up cycles before the data is copied back to the table.

You don't need to stop using these tools, though. Fortunately, they let you save modification scripts before they execute. Use this option, and inspect the generated script before executing it. I suspect you'll find that a few simple ALTER TABLE commands will speed up the same modifications and obviate having to drop and re-create the table.

10) Examine Your Apps With SQL Server Profiler（通过SQL Server Profiler工具测试应用程序性能）
Allocate a few hours at the end of the development cycle to run a trace in SQL Server Profiler and capture your application's workload. This lets you identify any potential long-running queries and create additional indexes for optimizing data retrieval.

As a rule, I create a primary key and a clustered index on each table. Next, I index each foreign key, then I create additional indexes to speed up certain queries. Doing a SQL Server trace allows me to quickly identify any opportunities for useful indexes I might have missed.

My trace includes the Stored Procedures-RPC:Completed event and the TSQL-SQL:BatchCompleted event. Both of these events populate the Duration column. I usually investigate trace events that take longer than 100 ms. I paste the code into Query Analyzer and examine the execution plan. You'll need some practice with reading and interpreting execution plans, but after a while you should be able to spot any potential issues in the execution plan quickly. You should always run a trace on your production database to make sure it's performing well with tables containing production data, rather than the sample amounts in your development database.