Monday, September 8, 2008

What is the Global.asax file?

What is the Global.asax file?


The Global.asax file (also known as the ASP.NET application file) is an optional file that is located in the application's root directory and is the ASP.NET counterpart of the Global.asa of ASP. This file exposes the application and session level events in ASP.NET and provides a gateway to all the application and the session level events in ASP.NET. This file can be used to implement the important application and session level events such as Application_Start, Application_End, Session_Start, Session_End, etc. This article provides an overview of the Global.asax file, the events stored in this file and how we can perform application wide tasks with the help of this file.


According to MSDN, "The Global.asax file, also known as the ASP.NET application file, is an optional file that contains code for responding to application-level events raised by ASP.NET." The Global.asax file is parsed and dynamically compiled by ASP.NET into a .NET Framework class the first time any resource or URL within its application namespace is activated or requested. Whenever the application is requested for the first time, the Global.asax file is parsed and compiled to a class that extends the HttpApplication class. When the Global.asax file changes, the framework reboots the application and the Application_OnStart event is fired once again when the next request comes in. Note that the Global.asax file does not need recompilation if no changes have been made to it. There can be only one Global.asax file per application and it should be located in the application's root directory only.


The following are some of the important events in the Global.asax file.


· Application_Init


· Application_Start


· Session_Start


· Application_BeginRequest


· Application_EndRequest


· Application_AuthenticateRequest


· Application_Error


· Session_End


· Application_End


The purpose of these event handlers is discussed in this section below.


Application_Init


The Application_Init event is fired when an application initializes the first time.


Application_Start


The Application_Start event is fired the first time when an application starts.


Session_Start


The Session_Start event is fired the first time when a user’s session is started. This typically contains for session initialization logic code.


Application_BeginRequest


The Application_BeginRequest event is fired each time a new request comes in.


Application_EndRequest


The Application_EndRequest event is fired when the application terminates.


Application_AuthenticateRequest


The Application_AuthenticateRequest event indicates that a request is ready to be authenticated. If you are using Forms Authentication, this event can be used to check for the user's roles and rights.


Application_Error


The Application_Error event is fired when an unhandled error occurs within the application.


Session_End


The Session_End Event is fired whenever a single user Session ends or times out.


Application_End


The Application_End event is last event of its kind that is fired when the application ends or times out. It typically contains application cleanup logic.



Friday, September 5, 2008

“Cannot Generate SSPI Context” error message, more comments for SQL Server

The “Cannot generate SSPI context” issue is described by http://support.microsoft.com/?id=811889 in general. In this post I will discuss one daunting case of “Cannot generate SSPI context” error message when failing to connect to SQL server. In most related cases, customers report this issue as "I can connect to my local SQL Server, but once I connect to my network, I can't connection to my local SQL Server". Such issue is reported against MSDE and SQLExpress. But actually, it can happen with any SKU of SQL Server, including SQL Server 2000 and SQL Server 2005, that support NT integrated authentication. The error message for the failed connection that we discussed here is




[SNAC] “[SQL Native Client]SQL Network Interfaces: The Local Security Authority cannot be contacted.[SQL Native Client]Cannot generate SSPI context”
[MDAC] “Cannot generate SSPI context”;
[.Net1.0/2.0]” Failed System.Data.SqlClient.SqlException: Cannot generate SSPI context”



It can happen when all of followings are true:
(1) The hosting machine of SQL Server is connected to a network, including home network or dialup connection, but it is disconnected from its domain.
(2) The OS of the hosting machine is Windows XP or 2000. Not windows 2003.
(3) The connection is to a local SQL Server.
(4) Connection configuration causes network library to choose TCP/IP provider.


A scenario that meets all of (1) (2) and (3) looks like an extreme corner case. But the reality is that it is quit often if the hosting machine is a laptop computer. One solution, of course, is to avoid condition (1) by connecting to your corporate domain through VPN or disconnecting from network completely. The reason why they work is subtle and I’ll discuss it later. From user’s perspective, however, in many cases, either connecting over VPN or disconnecting from network might prevent you from accessing some valuable resources, so I want to discuss solutions that do not depend on (1) first.



In most cases, users do not explicitly require TCP/IP as the connection provider. For example connection strings in form of “.\<instance>”, “(local)\<instance>”, “<servername>\<instancename>” are among them. Users might wonder why network library chooses TCP/IP provider instead of Shared Memory provider, if the connection string is not prefixed with “tcp” and the server is local. A simple answer is that it can happen if the TCP/IP provider is in front of other providers in the client protocol order list, or/and the local server is not listening on Share Memory and Name Pipe. As described above, only TCP/IP provider has the issue; hence, configuring network library not to choose TCP/IP is a solution. To do that, first, on the server side, make sure your server is listening on Shared Memory or/and Named Pipe connection requests; then, on the client side, change the protocol order list such that Shared Memory and/or Named Pipe are in front of TCP/IP, or prefixing your connection strings with “lpc” or “np” to force Shared Memory or Named Pipe, or using alias that prefix Named Pipe in connection strings, whichever you feel most comfortable with. Note that certain SKUs of SQL Server have named pipe connection turned off by default.



In very rare case, however, if you really in need of TCP/IP connection, the option is to use TCP/IP loop-back address, i.e. “127.0.0.1”, as your <servername>. For example, if your connection string has form of “<servername>\<instancename>” and is not prefixed with “tcp”, without modifying the connection string, you can configure an alias with alias name as <servername>\<instancenane>, protocol as TCP/IP, server as “127.0.0.1\<instancename>” or “127.0.0.1,<port>”. Remember that the “Cannot Generate SSPI context” problem described in this post only happens when connecting to a local server; thus, the “127.0.0.1” is applicable. If the connection string is prefixed with “tcp”, then you do need to modify your connection string to specify “127.0.0.1” as <servername>.



If these workarounds described above do not fit your needs, we would like to hear more from you.



The reason that we didn’t fix this subtle issue is because the limitation is rooted in a behavior of an integrated authentication module (SPNEGO) in XP and windows 2000, i.e. whether to fallback to NTLM if KDC is not available when the target SPN points to local machine. KDC, normally, is part of your domain controller. For this specific case, SPNEGO chooses not to fallback, hence connection fail. This issue is not a security issue though. Reader might ponder why avoiding using TCP/IP provider can solve the problem while explaining it is because certain behavior of SPNEGO in Windows. Not going too deep, the simple answer is that only TCP/IP provider, with an exception of loop-back connection, uses SPNEGO while other providers use NTLM. Be aware that only TCP/IP provider can provides the benefits of Kerberos authentication as discussed in http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx



Back to the questions we left before, the reason that disconnected from network (no network media) works is because, in such case, local <servername> is resolved to “127.0.0.1” by windows network layer and NTLM is used directly. When connected over VPN, the SPNEGO issue goes away because the KDC is accessible in this case.



From the error message reported by SNAC ODBC/OLEDB, you can differentiated the issue described by this post from another case of “Cannot generate SSPI context”, in which the root cause is because, in Active Directory, the Service Principle Name (SPN) of SQL Server is registered for a domain account different from the SQL Server is actually running under. The error message for the other case is “[SQL Native Client]SQL Network Interfaces: The target principal name is incorrect.[SQL Native Client]Cannot generate SSPI context. The “Cannot generate SSPI context” issue is described by http://support.microsoft.com/?id=811889 in general

Important Backup Options

Important Backup options


INIT


Specifies that all backup sets should be overwritten, but preserves the media header. If INIT is specified, any existing backup set data on that device is overwritten.


The backup media is not overwritten if any one of the following conditions is met:




  • All backup sets on the media have not yet expired. For more information, see the EXPIREDATE and RETAINDAYS options.

  • The backup set name given in the BACKUP statement, if provided, does not match the name on the backup media. For more information, see the NAME clause.


Use the SKIP option to override these checks. For more information about interactions when using SKIP, NOSKIP, INIT, and NOINIT, see the Remarks section.



Note If the backup media is password protected, SQL Server does not write to the media unless the media password is supplied. This check is not overridden by the SKIP option. Password-protected media may be overwritten only by reformatting it. For more information, see the FORMAT option.



NOINIT


Indicates that the backup set is appended to the specified disk or tape device, preserving existing backup sets. NOINIT is the default.


The FILE option of the RESTORE command is used to select the appropriate backup set at restore time



STANDBY = undo_file_name


Used only with BACKUP LOG. Backs up the tail of the log and leaves the database in read-only and standby mode. The undo file name specifies storage to hold rollback changes which must be undone if RESTORE LOG operations are to be subsequently applied.


If the specified undo file name does not exist, SQL Server creates it. If the file does exist, SQL Server overwrites it


NOUNLOAD


Specifies the tape is not unloaded automatically from the tape drive after a backup. NOUNLOAD remains set until UNLOAD is specified. This option is used only for tape devices.


UNLOAD


Specifies that the tape is automatically rewound and unloaded when the backup is finished. UNLOAD is set by default when a new user session is started. It remains set until that user specifies NOUNLOAD. This option is used only for tape devices.


RESTART


Specifies that SQL Server restarts an interrupted backup operation. The RESTART option saves time because it restarts the backup operation at the point it was interrupted. To RESTART a specific backup operation, repeat the entire BACKUP statement and add the RESTART option. Using the RESTART option is not required but can save time.


NO_LOG | TRUNCATE_ONLY


Removes the inactive part of the log without making a backup copy of it and truncates the log. This option frees space. Specifying a backup device is unnecessary because the log backup is not saved. NO_LOG and TRUNCATE_ONLY are synonyms.


After backing up the log using either NO_LOG or TRUNCATE_ONLY, the changes recorded in the log are not recoverable



NO_TRUNCATE


Allows backing up the log in situations where the database is damaged.

How to take backup in Multiple files?

Problem
How to take backup in Multiple files (Or you can say how to split backup file in multiple backup files)?

Solution


Advantage:



1. We can store backup on multiple drive if disk space is the issue



2. Easy to transfer on network servers


T-SQL for Backup


BACKUP DATABASE [Northwind] TO


DISK = 'C:\Northwind_file1.bak',


DISK = 'D:\Northwind_file2.bak',


DISK = 'E:\Northwind_file3.bak'


WITH INIT , NOUNLOAD , NAME = 'Northwind backup', NOSKIP , STATS = 10, NOFORMAT



T-SQL for Restore


RESTORE DATABASE [northwind] FROM


DISK = N'C:\Northwind_file1.bak',


DISK = N'D:\Northwind_file2.bak',


DISK = N'E:\Northwind_file3.bak' WITH FILE = 1, NOUNLOAD , STATS = 10, RECOVERY , REPLACE

SQL Server Windows Authentication (MIX Mode Authenticatio)

SSPI (Security Support Provider Interface)


SSPI allows an application to use various security models available on a computer or network without changing the interface to the security system.




What is Kerberos?


Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of this protocol is available from the Massachusetts Institute of Technology. Kerberos is available in many commercial products as well.



The Internet is an insecure place. Many of the protocols used in the Internet do not provide any security. Tools to "sniff" passwords off of the network are in common use by malicious hackers. Thus, applications which send an unencrypted password over the network are extremely vulnerable. Worse yet, other client/server applications rely on the client program to be "honest" about the identity of the user who is using it. Other applications rely on the client to restrict its activities to those which it is allowed to do, with no other enforcement by the server.



Some sites attempt to use firewalls to solve their network security problems. Unfortunately, firewalls assume that "the bad guys" are on the outside, which is often a very bad assumption. Most of the really damaging incidents of computer crime are carried out by insiders. Firewalls also have a significant disadvantage in that they restrict how your users can use the Internet. (After all, firewalls are simply a less extreme example of the dictum that there is nothing more secure then a computer which is not connected to the network --- and powered off!) In many places, these restrictions are simply unrealistic and unacceptable.



Kerberos was created by MIT as a solution to these network security problems. The Kerberos protocol uses strong cryptography so that a client can prove its identity to a server (and vice versa) across an insecure network connection. After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business.



Kerberos is freely available from MIT, under copyright permissions very similar those used for the BSD operating system and the X Window System. MIT provides Kerberos in source form so that anyone who wishes to use it may look over the code for themselves and assure themselves that the code is trustworthy. In addition, for those who prefer to rely on a professionally supported product, Kerberos is available as a product from many different vendors.


In summary, Kerberos is a solution to your network security problems. It provides the tools of authentication and strong cryptography over the network to help you secure your information systems across your entire enterprise. We hope you find Kerberos as useful as it has been to us. At MIT, Kerberos has been invaluable to our Information/Technology architecture.



NTLM (NT LAN Manager)


NTLM is a suite of authentication and session security protocols used in various Microsoft network protocol implementations and supported by the NTLM Security Support Provider ("NTLMSSP"). Originally used for authentication and negotiation of secure DCE/RPC, NTLM is also used throughout Microsoft's systems as an integrated single sign-on mechanism. It is probably best recognized as part of the "Integrated Windows Authentication" stack for HTTP authentication; however, it is also used in Microsoft implementations of SMTP, POP3, IMAP (all part of Exchange), CIFS/SMB, Telnet, SIP, and possibly others.


The NTLM Security Support Provider provides authentication, integrity, and confidentiality services within the Window Security Support Provider Interface (SSPI) framework. SSPI specifies a core set of security functionality that is implemented by supporting providers; the NTLMSSP is such a provider. The SSPI specifies, and the NTLMSSP implements, the following core operations:


1. Authentication -- NTLM provides a challenge-response authentication mechanism, in which clients are able to prove their identities without sending a password to the server.


2. Signing -- The NTLMSSP provides a means of applying a digital "signature" to a message. This ensures that the signed message has not been modified (either accidentally or intentionally) and that that signing party has knowledge of a shared secret. NTLM implements a symmetric signature scheme (Message Authentication Code, or MAC); that is, a valid signature can only be generated and verified by parties that possess the common shared key.


3. Sealing -- The NTLMSSP implements a symmetric-key encryption mechanism, which provides message confidentiality. In the case of NTLM, sealing also implies signing (a signed message is not necessarily sealed, but all sealed messages are signed).


NTLM has been largely supplanted by Kerberos as the authentication protocol of choice for domain-based scenarios. However, Kerberos is a trusted-third-party scheme, and cannot be used in situations where no trusted third party exists; for example, member servers (servers that are not part of a domain), local accounts, and authentication to resources in an untrusted domain. In such scenarios, NTLM continues to be the primary authentication mechanism (and likely will be for a long time).




How to make sure that you are using Kerberos authentication


SQL Server 2005 supports Kerberos authentication indirectly through the Windows Security Support Provider Interface (SSPI) when you are using Windows integrated authentication instead of SQL authentication. However, SQL Server will only use Kerberos authentication under certain circumstances when SQL Server can use SSPI to negotiate the authentication protocol to use. If SQL Server cannot use Kerberos authentication, Windows will use NTLM authentication. For security reasons, we recommend that you use Kerberos authentication instead of NTLM authentication. Administrators and users should know how to make sure that they are using Kerberos authentication for remote connections.

To use Kerberos authentication, you must make sure that all the following conditions are true:

• Both the server and the client computers must be members of the same Windows domain or members of trusted domains.


• The server's service principal name (SPN) must be registered in the Active Directory service.


• The instance of SQL Server 2005 must enable the TCP/IP protocol.


• The client must connect to the instance of SQL Server 2005 by using the TCP/IP protocol. For example, you can put the TCP/IP protocol at the top of the client's protocol order. Or you can add the prefix "tcp:" in the connection string to specify that the connection will use the TCP/IP protocol.



After you connected to an instance of SQL Server 2005, run the following Transact-SQL statement in SQL Server Management Studio:




select auth_scheme from sys.dm_exec_connections where session_id=@@spid 

If SQL Server is using Kerberos authentication, a character string that is listed as "KERBEROS" appears in the auth_scheme column in the result window.

Thursday, September 4, 2008

The Basics of Hyper-Threading: What is it?

The Basics of Hyper-Threading: What is it?


Modern processors can only handle one instruction from one program at any given point in time. Each instruction that is sent to the processor is called a thread. What I mean is that even though it looks like you're multitasking with your computer (running more then one program at a time) you're really not.


The CPU will divide it's time and power evenly between all the programs by switching back and forth. This little charade of switching back and forth tricks the end user (you and me) and gives us the sense of multitasking.


Dual CPU based systems can work on two independent threads of information from the software but each processor is still limited at working on one thread at any given moment though. The software must be able to dish out two separate pieces of information like Win2000 or Adobe Photoshop for a dual processor system to be really used, by the way.


So what's new with the Pentium4 3.06GHz processor?


The Pentium 4 3.06 GHz processor is the first Intel desktop processor in history that can process two independent threads at the same time. With a SMT (Simultaneous Multi-Thread) enabled OS like Win2000/XP, Linux, etc. the operation system will identify the P4 3.06 GHz CPU as two logical processors that share the single physical CPU's resources. A physical processor can be thought of as the chip itself, whereas a logical processor is what the computer sees - with Hyper-Threading enabled the computer can have one physical processor installed in the motherboard, but the computer will see two logical processors, and treat the system as if there were actually two processors.


Even when we put a regular processor under 100% load, we're never fully utilizing 100% of the execution units. With a HyperThreading enabled processor those spare execution units can used towards computing other things now.


In the last HyperThreading enabled processor, both threads are simultaneously being computed, and the CPU's efficiency has increased from around 50% to over 90%!


The last example is of dual HyperThreading enabled processors which can work on four independent threads at the same time. Again CPU efficiency is around 90% (and in this case there would be four logical processors, and two physical processors).


While this all sounds very good in the above example, it's also about the most ideal situation ever - so let's get back to the real world.


If you were to run two pieces of software that are completely different, and use different execution units, your system performance should get a noticeable boost however!


The operating system will also play a key role in how well HyperThreading works. The OS assigns operations to the independent logical processors, and so if it's determined that one of the logical CPU's is to remain idle, the OS will issue a HALT command to the free logical processor thus devoting all of the other system resources to the working logical processor.


As you can see, HyperThreading has the potential to significantly boost system performance under certain circumstances. From Xeon/HyperThreading test results over at Anandtech you get a feel that HyperThreading Technology is still in it's infancy in terms of real added value across the board. As it stands now, the performance that HT brings to the table is still very application specific. Some programs will notice a performance boost, and in some cases, other programs will see a performance hit with HT enabled.


As more and more software is written specifically for HyperThreading, the performance differences will grow larger. It didn't take long for software developers to adopt SSE2, hopefully they'll jump on the HyperThreading bandwagon quickly and the consumer will see the benefit of this this ingenuous technology quickly


Networking Terms

Networking Terms


VIP


A virtual IP address (VIP or VIPA) is an IP address that is not connected to a specific computer or network interface card (NIC) on a computer. Incoming packets are sent to the VIP address, but all packets travel through real network interfaces.



VIPs are mostly used for connection redundancy; a VIP address may still be available if a computer or NIC fails because an alternative computer or NIC replies to connections



We can also use VIP for load balancing and Automatic Failover



Port Number


Definition: A port number represents an endpoint or "channel" for network communications. Port numbers allow different applications on the same computer to utilize network resources without interfering with each other.


Port numbers most commonly appear in network programming, particularly socket programming. Sometimes, though, port numbers are made visible to the casual user. For example, some Web sites a person visits on the Internet use a URL like the following:


In this example, the number 8080 refers to the port number used by the Web browser to connect to the Web server. Normally, a Web site uses port number 80 and this number need not be included with the URL (although it can be).


In IP networking, port numbers can theoretically range from 0 to 65535. Most popular network applications, though, use port numbers at the low end of the range (such as 80 for HTTP). The port number is included as a field within the header of each IP packet.


Note: The term port also refers to several other aspects of network technology. A port can refer to a physical connection point for peripheral devices such as serial, parallel, and USB ports. The term port also refers to certain Ethernet connection points, such as those on a hub, switch, or router.


You can find the list of port number at below URL


http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers



UDP (User Datagram Protocol)


Definition: UDP is a lightweight transport built on top of IP. UDP squeezes extra performance from IP by not implementing some of the features a more heavyweight protocol like TCP offers. Specifically, UDP allows individual packets to be dropped (with no retries) and UDP packets to be received in a different order than they were sent.


UDP is often used in videoconferencing applications or games where optimal performance is preferred over guaranteed message delivery. UDP is one of the oldest network protocols, introduced in 1980 in RFC document 768.



DNS Server (Domain Name System)


Definition: The DNS translates Internet domain and host names to IP Addresses. DNS automatically converts the names we type in our Web browser address bar to the IP addresses of Web servers hosting those sites.


DNS implements a distributed database to store this name and address information for all public hosts on the Internet. DNS assumes IP addresses do not change (are statically assigned rather than dynamically assigned).



The DNS database resides on a hierarchy of special database servers. When clients like Web browsers issue requests involving Internet host names, a piece of software called the DNS resolver (usually built into the network operating system) first contacts a DNS server to determine the server's IP address. If the DNS server does not contain the needed mapping, it will in turn forward the request to a different DNS server at the next higher level in the hierarchy. After potentially several forwarding and delegation messages are sent within the DNS hierarchy, the IP address for the given host eventually arrives at the resolver, that in turn completes the request over Internet Protocol.


DNS additionally includes support for caching requests and for redundancy. Most network operating systems support configuration of primary, secondary, and tertiary DNS servers, each of which can service initial requests from clients. ISPs maintain their own DNS servers and use DHCP to automatically configure clients, relieving most home users of the burden of DNS configuration.


Also Known As: Domain Name System, Domain Name Service, Domain Name Server


Dynamic Host Configuration Protocol Definition: DHCP allows a computer to join an IP-based network without having a pre-configured IP address. DHCP is a protocol that assigns unique IP addresses to devices, then releases and renews these addresses as devices leave and re-join the network.


Internet Service Providers (ISPs) usually use DHCP to allow customers to join the Internet with minimum effort. Likewise, home network equipment like broadband routers offers DHCP support for added convenience in joining home computers to the LAN.


DHCP environments require a DHCP server set up with the appropriate configuration parameters for the given network. Key DHCP parameters include the range or "pool" of available IP addresses, the correct subnet masks, plus gateway and name server addresses.


Devices running DHCP client software can then automatically retrieve these settings from DHCP servers as needed. Using DHCP on a network means system administrators do not need to configure these parameters individually for each client device.




NetBIOS Definition: NetBIOS is a software protocol for providing computer communication services on local networks. Microsoft Windows uses NetBIOS on Ethernet or Token Ring networks.



Software applications on a NetBIOS network locate each other via their NetBIOS names. A NetBIOS name is up to 16 characters long and in Windows, separate from the computer name. Applications on other computers access NetBIOS names over UDP port 137. It provides name resolution services for NetBIOS.


Two applications start a NetBIOS session when one (the client) sends a command to "Call" another (the server) over TCP port 139 on a remote computer. Both sides issue "Send" and "Receive" commands to deliver messages in both directions. The "Hang-Up" command terminates a NetBIOS session.


NetBIOS also supports connectionless communications via UDP datagrams. Applications listen on UDP port 138 to receive NetBIOS datagrams.


NetBIOS and NetBEUI are separate but related technologies. NetBEUI extends NetBIOS with additional networking capabilities.


Also Known As: Network Basic Input/Output System


WINS Definition: The Windows Internet Naming Service (WINS) supports name resolution, the automated conversion of computer names to network addresses, for Windows networks. Specifically, WINS converts NETBIOS names to IP addresses on a LAN or WAN.


Like DNS, the Windows Internet Naming Service employs a distributed client/server system to maintain the mapping of computer names to addresses. Windows clients can be configured to use primary and secondary WINS servers that dynamically update name/address pairings as computers join and leave the network. The dynamic behavior of WINS means that it also supports networks using



Can not open user default database; login failed

Troubleshooting Authentication Issues


Problem:


Can not open user default database; login failed



Scenario:


I have windows DBA group which has default database DB1 and has SYSADMIN rights on SQL Server, by some reasons the DB1 database is corrupted and user is unable to login.



Solution:


Step 1:


Connect SQL Server using SQLCMD/OSQL as below and give the default database name as MASTER



sqlcmd -E -d master



Step 2: Now issue ALTER LOGIN statement and change the default database


Use SP_DefaultDB procedure to change the default database




sp_defaultdb (SQL Server 2000)


Changes the default database for a login


Syntax


EXEC sp_defaultdb 'Victoria', 'pubs'



(SQL Server 2005)


ALTER LOGIN LOGINNAME WITH DEFAULT_DATABASE = MASTER

Index Covering

What is Index Covering?

Index covering means to add a non-clustered index on every column  which are used in Query. Easy solution to improve query performance

 

Scenario: Speed Up a Query for a Table with a Clustered Index

Consider a very typical scenario: you have a table EmployeeSalary table with a clustered index on Employee_ID column. You need to speed up a select query quickly:

SELECT Salary_DATE, SUM(AMOUNT) FROM EmployeeSalary GROUP BY Salary_DATE

 

The query's execution plan is quite simple: the database engine scans the whole clustered index, and then it sorts the intermediate result set to satisfy the GROUP BY clause.

 

Can a non-clustered index speed up the query? Definitely. Just create a non-clustered index that contains all the columns used in the query:

CREATE  INDEX sal_amt ON dbo.EmployeeDetail(Salary_DATE, AMOUNT)

 

Re-execute the query it will run faster than the previous query.  If you, look at the execution plan: the query accesses only the index salary_amt; it doesn't touch the table at all. In fact, there is no need to access the table because all the columns necessary to satisfy the query are already stored in the index. This is called index covering.