A trigger is a SQL procedure that initiates an action when an event (INSERT, DEL ETE or UPDATE) occurs.

Triggers are stored in and managed by the DBMS.Triggers a re used to maintain the referential integrity of data by changing the data in a systematic fashion. A trigger cannot be called or executed; the DBMS automatical ly fires the trigger as a result of a data modification to the associated table. Triggers can be viewed as similar to stored procedures in that both consist of procedural logic that is stored at the database level. Stored procedures, howeve r, are not event-drive and are not attached to a specific table as triggers are. Stored procedures are explicitly executed by invoking a CALL to the procedure w hile triggers are implicitly executed. In addition, triggers can also execute st ored procedures. Nested Trigger: A trigger can also contain INSERT, UPDATE and DELETE logic withi n itself, so when the trigger is fired because of data modification it can also cause another data modification, thereby firing another trigger. A trigger that contains data modification logic within itself is called a nested trigger. INDEXES: ----------------------------------------------------------------------------------------------After large amount of data has been inserted in a table the sql server takes mor e time to fetch data from the table. So we create Indexes which assist the server in fetching the data quickly. What are Indexes?Why do we need them? When is it a good time to create indexes on tables OR on which type of tables do we create indexes? which type of index should be created and when? From Job: It is always good to create indexes after we have inserted all the data in the t able as non clustered indexes are recreated on inserting data in the table While building a reports we must make use of temporary tables and create indexes on these tables after inserting data in them. Types of Indexes: 1)Clustered 2)Non-Clustered 2a)Unique NonClustered 2b)NonUnique NonClustered Composite Indexes Filtered Indexes Some more Important Terms: Covering an Query: When every column in the query has an index on it.Even the columns in the where clause are indexed. Note:If a query is not covered then sql optimizer will perform a scan.(which sca n table scan or index scan. Are both the same ) Covering an Index: Creating a non-clustered index on a Index Seek Index Scan What is the Difference between Index Seek vs. Index Scan?

An index scan means that SQL Server reads all the rows in a table, and then retu rns only those rows that satisfy the search criteria. When an index scan is performed, all the rows in the leaf level of the index are scanned. This essentially means that all the rows of the index are examined instead of th e table directly. This is sometimes compared to a table scan, in which all the table data is read directly. However, there is usually little difference between an index scan and a table sc an. Index Scan is nothing but scanning on the data pages from the first page to the last page. If there is an index on a table, and if the query is touching a larger amount of data, which means the query is retrieving more than 50 percent or 90 percent of the da ta, and then optimizer would just scan all the data pages to retrieve the data rows. If there is no index, then you might see a Table Scan (Index Scan) in the execut ion plan. An index seek, on the other hand, means that the Query Optimizer relies entirely on the index leaf data to locate rows satisfying the query condition. An index seek will be most beneficial in cases where a small percentage of rows will be returned. An index seek will only affect the rows that satisfy a query condition and the p ages that contain these qualifying rows; in terms of performance, this is highly beneficial when a table has a very large number of rows. Index seeks are generally preferred for the highly selective queries. What that means is that the query is just requesting a fewer number of rows or j ust retrieving the other 10 (some documents says 15 percent) of the rows of the table. In general query optimizer tries to use an Index Seek which means that optimizer has found a useful index to retrieve recordset. But if it is not able to do so either because there is no index or no useful ind exes on the table then SQL Server has to scan all the records that satisfy query condition.

Index Properties: P-Pad Index F-Fill Factor S-Sort on temp DB I-Ignore Duplicate Key S-Statistics Recompute D-Drop Existing O-Online On A-Allow Page locks A-Allow Row locks M-Max degree of parallelism

Following things will help to improve the performance after creating indexes: Keep upto date stats. Add more index if possible (extra condition in where or join which is indexed) Partition Table Replication and have read only database.