Sei sulla pagina 1di 75

Databases

Understanding Databases
Database Basics A table contains a collection of rows, also referred to as records or tuples, and columns, also
referred to as attributes.
Declarative referential integrity (DRI) constraints can be added to the tables to make sure that
interrelated data in different tables remains consistent.
You should not create any user objects, such as tables, views, stored procedures, or triggers,
in the master database. The master database contains system-level information used by the
instance of SQL Server, such as logon information and configuration option settings.
OLTP Database
Online Transaction Processing (OLTP) relational databases are optimal for managing changing data.
They typically have several users who are performing transactions at the same time that change realtime data.

OLTP databases generally do the following:

Support large numbers of concurrent users who are regularly adding and modifying
data.
Represent the constantly changing state of an organization, but do not save its history.
Contain lots of data, including extensive data used to verify transactions.
Have complex structures.
Are tuned to be responsive to transaction activity.
Provide the technology infrastructure to support the day-to-day operations of an
organization.
Individual transactions are completed quickly and access relatively small amounts of
data. OLTP systems are designed and tuned to process hundreds or thousands of
transactions being entered at the same time.

Data Warehouse

Following is a list of what data warehouses can do:

Combine data from heterogeneous data sources into a single homogenous structure.
Organize data in simplified structures for efficiency of analytical queries instead of
for transaction processing.
Contain transformed data that is valid, consistent, consolidated, and formatted for
analysis.
Provide stable data that represents business history.
Be updated periodically with additional data instead of making frequent transactions.
Simplify security requirements.

Database Snapshot
A database snapshot is a read-only, static view of a database, the source database. Each database
snapshot is transaction-consistent with the source database as it existed at the time of the
snapshot's creation.
System Databases
Master Database
The master database records all the system-level information for a SQL Server system. This includes
instance-wide metadata such as logon accounts, endpoints, linked servers, and system configuration
settings. Also, master is the database that records the existence of all other databases and the
location of those database files and records the initialization information for SQL Server. Therefore,
SQL Server cannot start if the master database is unavailable. In SQL Server 2005, system objects are
no longer stored in the master database; instead, they are stored in the Resource database.
Restrictions -

The following operations cannot be performed on the master database:

Adding files or filegroups.


Changing collation. The default collation is the server collation.
Changing the database owner. master is owned by dbo.
Creating a full-text catalog or full-text index.
Creating triggers on system tables in the database.
Dropping the database.
Dropping the guest user from the database.
Participating in database mirroring.
Removing the primary filegroup, primary data file, or log file.
Renaming the database or primary filegroup.
Setting the database to OFFLINE.
Setting the database or primary filegroup to READ_ONLY.

Recommendations

When you work with the master database, consider the following recommendations:

Always have a current backup of the master database available.


Back up the master database as soon as possible after the following operations:
Creating, modifying, or dropping any database
Changing server or database configuration values
Modifying or adding logon accounts
Do not create user objects in master. Otherwise, master must be backed up more
frequently.
Do not set the TRUSTWORTHY option to ON for the master database.

Model Database
The model database is used as the template for all databases created on an instance of SQL Server.
Because tempdb is created every time SQL Server is started, the model database must always exist
on a SQL Server system.

Model database usage When a CREATE DATABASE statement is issued, the first part of the database is created by
copying in the contents of the model database. The rest of the new database is then filled with
empty pages.
If you modify the model database, all databases created afterward will inherit those changes.
For example, you could set permissions or database options, or add objects such as tables,
functions, or stored procedures.
The following operations cannot be performed on the model database:

Adding files or file groups.


Changing collation. The default collation is the server collation.
Changing the database owner. model is owned by dbo.
Dropping the database.
Dropping the guest user from the database.
Participating in database mirroring.
Removing the primary filegroup, primary data file, or log file.
Renaming the database or primary filegroup.
Setting the database to OFFLINE.
Setting the database or primary filegroup to READ_ONLY.
Creating procedures, views, or triggers using the WITH ENCRYPTION option. The
encryption key is tied to the database in which the object is created. Encrypted objects
created in the model database can only be used in model.

Msdb Database
The msdb database is used by SQL Server Agent for scheduling alerts and jobs and by other features
such as Service Broker and Database Mail

The following operations cannot be performed on the msdb database:

Changing collation. The default collation is the server collation.


Dropping the database.
Dropping the guest user from the database.
Participating in database mirroring.
Removing the primary filegroup, primary data file, or log file.
Renaming the database or primary filegroup.
Setting the database to OFFLINE.
Setting the primary filegroup to READ_ONLY.

Resource Database -

The Resource database is a read-only database that contains all the system objects that are
included with SQL Server 2005. SQL Server system objects, such as sys.objects, are
physically persisted in the Resource database, but they logically appear in the sys schema of
every database. The Resource database does not contain user data or user metadata.
The Resource database makes upgrading to a new version of SQL Server an easier and faster
procedure. In earlier versions of SQL Server, upgrading required dropping and creating
system objects. Because the Resource database file contains all system objects, an upgrade is
now accomplished simply by copying the single Resource database file to the local server.
Similarly, rolling back system object changes in a service pack only requires overwriting the
current version of the Resource database with the older version.
The Resource database depends on the location of the master database. If you move the master
database, you must also move the Resource database to the same location.
SQL Server cannot back up the Resource database. You can perform your own file-based or a diskbased backup by treating the mssqlsystemresource.mdf file as if it were a binary (.EXE) file, rather
than a database file, but you cannot use SQL Server to restore your backups. Restoring a backup
copy of mssqlsystemresource.mdf can only be done manually, and you must be careful not to
overwrite the current Resource database with an out-of-date or potentially insecure version.

Tempdb Database
The tempdb system database is a global resource that is available to all users
connected to the instance of SQL Server and is used to hold the following:

Temporary user objects that are explicitly created, such as: global or local
temporary tables, temporary stored procedures, table variables, or
cursors.
Internal objects that are created by the SQL Server 2005 Database
Engine, for example, work tables to store intermediate results for spools
or sorting.
Row versions that are generated by data modification transactions in a
database that uses read-committed using row versioning isolation or
snapshot isolation transactions.
Row versions that are generated by data modification transactions for
features, such as: online index operations, Multiple Active Result Sets
(MARS), and AFTER triggers.

Operations within tempdb are minimally logged. This enables transactions to be


rolled back. tempdb is re-created every time SQL Server is started so that the
system always starts with a clean copy of the database. Temporary tables and
stored procedures are dropped automatically on disconnect, and no connections
are active when the system is shut down. Therefore, there is never anything in
tempdb to be saved from one session of SQL Server to another. Backup and
restore operations are not allowed on tempdb.

The following operations cannot be performed on the tempdb database:

Adding filegroups.
Backing up or restoring the database.
Changing collation. The default collation is the server collation.
Changing the database owner. tempdb is owned by dbo.
Creating a database snapshot.
Dropping the database.
Dropping the guest user from the database.
Participating in database mirroring.
Removing the primary filegroup, primary data file, or log file.
Renaming the database or primary filegroup.
Running DBCC CHECKALLOC.
Running DBCC CHECKCATALOG.
Setting the database to OFFLINE.
Setting the database or primary filegroup to READ_ONLY.

Understanding Files and File groups

At a minimum, every SQL Server 2005 database has two operating system files: a data file
and a log file. Data files contain data and objects such as tables, indexes, stored procedures,
and views. Log files contain the information that is required to recover all transactions in the
database. Data files can be grouped together in filegroups for allocation and administration
purposes.
SQL Server 2005 databases have three types of files, as shown in the following table.
File
Primary

Secondary

Description
The primary data file contains the startup information for the database and
points to the other files in the database. User data and objects can be stored in
this file or in secondary data files. Every database has one primary data file. The
recommended file name extension for primary data files is .mdf.
Secondary data files are optional, are user-defined, and store user data.
Secondary files can be used to spread data across multiple disks by putting each
file on a different disk drive. Additionally, if a database exceeds the maximum
size for a single Windows file, you can use secondary data files so the database
can continue to grow.

The recommended file name extension for secondary data files is .ndf.
The transaction log files hold the log information that is used to recover the
Transaction
database. There must be at least one log file for each database. The
Log
recommended file name extension for transaction logs is .ldf.
By default, the data and transaction logs are put on the same drive and path. This is done to
handle single-disk systems. However, this may not be optimal for production environments.
We recommend that you put data and log files on separate disks.

File Groups Every database has a primary filegroup. This filegroup contains the primary data file and any
secondary files that are not put into other filegroups. User-defined filegroups can be created
to group data files together for administrative, data allocation, and placement purposes.
For example, three files, Data1.ndf, Data2.ndf, and Data3.ndf, can be created on three disk
drives, respectively, and assigned to the filegroup fgroup1. A table can then be created
specifically on the filegroup fgroup1. Queries for data from the table will be spread across
the three disks; this will improve performance. The same performance improvement can be
accomplished by using a single file created on a RAID (redundant array of independent disks)
stripe set. However, files and filegroups let you easily add new files to new disks.
All data files are stored in the filegroups listed in the following table.
Filegroup
Primary
Userdefined

Description
The filegroup that contains the primary file. All system tables are allocated to
the primary filegroup.
Any filegroup that is specifically created by the user when the user first creates
or later modifies the database.

Default Filegroup
When objects are created in the database without specifying which filegroup they belong to,
they are assigned to the default filegroup. At any time, exactly one filegroup is designated as
the default filegroup. The files in the default filegroup must be large enough to hold any new
objects not allocated to other filegroups.
The PRIMARY filegroup is the default filegroup unless it is changed by using the ALTER
DATABASE statement. Allocation for the system objects and tables remains within the
PRIMARY filegroup, not the new default filegroup.
Introduction to Transaction Logs

Every SQL Server 2005 database has a transaction log that records all transactions and the
database modifications made by each transaction. The transaction log is a critical component
of the database and, if there is a system failure, the transaction log might be required to bring
your database back to a consistent state. The transaction log should never be deleted or
moved unless you fully understand the ramifications of doing this.
Operations Supported by the Transaction Log
The transaction log supports the following operations:

Recovery of individual transactions.


Recovery of all incomplete transactions when SQL Server is started.
Rolling a restored database, file, filegroup, or page forward to the point of failure.
Supporting transactional replication.

Supporting standby-server solutions.

Recovery of Individual Transactions


If an application issues a ROLLBACK statement, or if the Database Engine detects an error
such as the loss of communication with a client, the log records are used to roll back the
modifications made by an incomplete transaction.

Recovery of all Incomplete Transactions When SQL Server Is Started


If a server that is running SQL Server fails, the databases may be left in a state where some
modifications were never written from the buffer cache to the data files, and there may be
some modifications from incomplete transactions in the data files. When an instance of SQL
Server is started, it runs a recovery of each database. Every modification recorded in the log
which may not have been written to the data files is rolled forward. Every incomplete
transaction found in the transaction log is then rolled back to make sure the integrity of the
database is preserved.

Rolling a Restored Database, File, Filegroup, or Page Forward to the Point of


Failure
After a hardware loss or disk failure affecting the database files, you can restore the database
to the point of failure. You first restore the last full database backup and the last differential
database backup, and then restore the subsequent sequence of the transaction log backups to
the point of failure. As you restore each log backup, the Database Engine reapplies all the
modifications recorded in the log to roll forward all the transactions. When the last log
backup is restored, the Database Engine then uses the log information to roll back all
transactions that were not complete at that point.

Supporting Transactional Replication


The Log Reader Agent monitors the transaction log of each database configured for
transactional replication and copies the transactions marked for replication from the
transaction log into the distribution database. For more information, see How Transactional
Replication Works.

Supporting Standby-Server Solutions


The standby-server solutions, database mirroring, and log shipping, rely heavily on the
transaction log. In a log shipping scenario, the primary server sends the active transaction log
of the primary database to one or more destinations. Each secondary server restores the log to
its local secondary database. For more information, see Understanding Log Shipping.
In a database mirroring scenario, every update to a database, the principal database, is
immediately reproduced in a separate, full copy of the database, the mirror database. The
principal server instance sends each log record immediately to the mirror server instance
which applies the incoming log records to the mirror database, continually rolling it forward.
For more information, see Overview of Database Mirroring.

Database States

A database is always in one specific state. For example, these states include ONLINE,
OFFLINE, or SUSPECT. To verify the current state of a database, select the state_desc
column in the sys.databases catalog view or the Status property in the
DATABASEPROPERTYEX function.
Database State Definitions

The following table defines the database states.


State
ONLINE

OFFLINE

RESTORING

RECOVERING

RECOVERY
PENDING

SUSPECT

EMERGENCY

Definition
Database is available for access. The primary filegroup is online, although
the undo phase of recovery may not have been completed.
Database is unavailable. A database becomes offline by explicit user action
and remains offline until additional user action is taken. For example, the
database may be taken offline in order to move a file to a new disk. The
database is then brought back online after the move has been completed.
One or more files of the primary filegroup are being restored, or one or
more secondary files are being restored offline. The database is
unavailable.
Database is being recovered. The recovering process is a transient state;
the database will automatically become online if the recovery succeeds. If
the recovery fails, the database will become suspect. The database is
unavailable.
SQL Server has encountered a resource-related error during recovery. The
database is not damaged, but files may be missing or system resource
limitations may be preventing it from starting. The database is unavailable.
Additional action by the user is required to resolve the error and let the
recovery process be completed.
At least the primary filegroup is suspect and may be damaged. The
database cannot be recovered during startup of SQL Server. The database
is unavailable. Additional action by the user is required to resolve the
problem.
User has changed the database and set the status to EMERGENCY. The
database is in single-user mode and may be repaired or restored. The
database is marked READ_ONLY, logging is disabled, and access is
limited to members of the sysadmin fixed server role. EMERGENCY is
primarily used for troubleshooting purposes. For example, a database
marked as suspect can be set to the EMERGENCY state. This could permit
the system administrator read-only access to the database. Only members
of the sysadmin fixed server role can set a database to the EMERGENCY
state.

File States

In SQL Server 2005, the state of a database file is maintained independently from the state of
the database. A file is always in one specific state, such as ONLINE or OFFLINE. To view
the current state of a file, use the sys.master_files or sys.database_files catalog view. If the
database is offline, the state of the files can be viewed from the sys.master_files catalog view.
The state of the files in a filegroup determines the availability of the whole filegroup. For a
filegroup to be available, all files within the filegroup must be online. To view the current
state of a filegroup, use the sys.filegroups catalog view.
The following table defines the file states.
State
ONLINE

OFFLINE

Definition
The file is available for all operations. Files in the primary filegroup are
always online if the database itself is online. If a file in the primary filegroup
is not online, the database is not online and the states of the secondary files
are undefined.
The file is not available for access and may not be present on the disk. Files
become offline by explicit user action and remain offline until additional user
action is taken.
Caution: A file should only be set offline when the file is corrupted, but it
can be restored. A file set to offline can only be set online by restoring the
file from backup. For more information about restoring a single file, see
RESTORE (Transact-SQL).

The file is being restored. Files enter the restoring state because of a restore
RESTORING command affecting the whole file, not just a page restore, and remain in this
state until the restore is completed and the file is recovered.
The recovery of the file has been postponed. A file enters this state
automatically because of a piecemeal restore process in which the file is not
RECOVERY
restored and recovered. Additional action by the user is required to resolve
PENDING
the error and allow for the recovery process to be completed. For more
information, see Performing Piecemeal Restores.
Recovery of the file failed during an online restore process. If the file is in
the primary filegroup, the database is also marked as suspect. Otherwise,
only the file is suspect and the database is still online.
SUSPECT

The file will remain in the suspect state until it is made available by one of
the following methods:

DEFUNCT

Restore and recovery


DBCC CHECKDB with REPAIR_ALLOW_DATA_LOSS

The file was dropped when it was not online. All files in a filegroup become
defunct when an offline filegroup is removed.

Designing Databases
Developing a Database Plan
The first step in creating a database is creating a plan that serves both as a guide to be used when
implementing the database and as a functional specification for the database after it has been
implemented. The complexity and detail of a database design is dictated by the complexity and size
of the database application and also the user population.

In planning the database, regardless of its size and complexity, use the following basic steps:

Gather information.
Identify the objects.
Model the objects.
Identify the types of information for each object.
Identify the relationships between objects.

Online Transaction Processing Design Considerations


Transaction processing system databases should be designed to promote the following:

Good data placement


I/O bottlenecks are a big concern for OLTP systems, because of the number of users
modifying data all over the database. When you design a database, determine the
likely access patterns of the data and combine frequently accessed data together. Use
filegroups and RAID (redundant array of independent disks) systems to help in this.
Short transactions to minimize long-term locks and improve concurrency
Avoid user interaction during transactions. Whenever possible, run a single stored
procedure to process the whole transaction. The order in which you reference tables
within your transactions can affect concurrency. Put references to frequently accessed
tables at the end of the transaction to minimize the duration that locks are held.
Online backup
OLTP systems are frequently characterized by continuous operations in which down
time is kept to an absolute minimum. That is, they operate 24 hours a day, 7 days a
week. Although the SQL Server 2005 Database Engine can back up a database while
it is being used, schedule the backup process to occur during times of low activity to
minimize the effects on users.
High normalization of the database
Reduce redundant information to increase the speed of updates and improve
concurrency. Reducing data also improves the speed of backups, because less data has
to be backed up.
Minimal or no historical or aggregated data
Data that is rarely referenced can be archived into separate databases, or moved out of
the heavily updated tables into tables that contain only historical data. This keeps
tables as small as possible, and improves backup times and query performance.
Careful use of indexes
Indexes must be updated every time a row is added or modified. To avoid over-

indexing heavily updated tables, keep indexes narrow. Use the Database Engine
Tuning Advisor to design your indexes.
Optimum hardware configuration to handle the large numbers of concurrent users and
quick response times required by an OLTP system

Decision Support Design Considerations


Decision-support system databases should be designed to promote the following:

Heavy indexing
Decision-support systems have low update requirements, but large volumes of data.
Use many indexes to improve query performance.
Demoralization of the database
Introduce pre-aggregated or summarized data to satisfy common query requirements
and improve query response times.
Use of a star or snowflake schema to organize the data within the database.
Normalization

Normalization is the process of organizing data in a database. This includes creating tables
and establishing relationships between those tables according to rules designed both to
protect the data and to make the database more flexible by eliminating redundancy and
inconsistent dependency.
Redundant data wastes disk space and creates maintenance problems. If data that exists in
more than one place must be changed, the data must be changed in exactly the same way in
all locations. A customer address change is much easier to implement if that data is stored
only in the Customers table and nowhere else in the database.
What is an "inconsistent dependency"? While it is intuitive for a user to look in the
Customers table for the address of a particular customer, it may not make sense to look there
for the salary of the employee who calls on that customer. The employee's salary is related to,
or dependent on, the employee and thus should be moved to the Employees table.
Inconsistent dependencies can make data difficult to access because the path to find the data
may be missing or broken.
There are a few rules for database normalization. Each rule is called a "normal form." If the
first rule is observed, the database is said to be in "first normal form." If the first three rules
are observed, the database is considered to be in "third normal form." Although other levels
of normalization are possible, third normal form is considered the highest level necessary for
most applications.

First Normal Form

Eliminate repeating groups in individual tables.


Create a separate table for each set of related data.
Identify each set of related data with a primary key.

Do not use multiple fields in a single table to store similar data. For example, to track an
inventory item that may come from two possible sources, an inventory record may contain
fields for Vendor Code 1 and Vendor Code 2.
What happens when you add a third vendor? Adding a field is not the answer; it requires
program and table modifications and does not smoothly accommodate a dynamic number of
vendors. Instead, place all vendor information in a separate table called Vendors, then link
inventory to vendors with an item number key, or vendors to inventory with a vendor code
key.

Second Normal Form

Create separate tables for sets of values that apply to multiple records.
Relate these tables with a foreign key.

Records should not depend on anything other than a table's primary key (a compound key, if
necessary). For example, consider a customer's address in an accounting system. The address
is needed by the Customers table, but also by the Orders, Shipping, Invoices, Accounts
Receivable, and Collections tables. Instead of storing the customer's address as a separate
entry in each of these tables, store it in one place, either in the Customers table or in a
separate Addresses table.

Third Normal Form

Eliminate fields that do not depend on the key.

Values in a record that are not part of that record's key do not belong in the table. In general,
any time the contents of a group of fields may apply to more than a single record in the table,
consider placing those fields in a separate table.
For example, in an Employee Recruitment table, a candidate's university name and address
may be included. But you need a complete list of universities for group mailings. If university
information is stored in the Candidates table, there is no way to list universities with no
current candidates. Create a separate Universities table and link it to the Candidates table
with a university code key.

Recursive Queries Using Common Table Expressions

A common table expression (CTE) provides the significant advantage of being able to
reference itself, thereby creating a recursive CTE. A recursive CTE is one in which an initial
CTE is repeatedly executed to return subsets of data until the complete result set is obtained.
A query is referred to as a recursive query when it references a recursive CTE. Returning
hierarchical data is a common use of recursive queries, for example: Displaying employees in
an organizational chart, or data in a bill of materials scenario in which a parent product has
one or more components and those components may, in turn, have subcomponents or may be
components of other parents.

recursive CTE consists of three elements:


1. Invocation of the routine.
The first invocation of the recursive CTE consists of one or more
CTE_query_definitions joined by UNION ALL, UNION, EXCEPT, or INTERSECT
operators. Because these query definitions form the base result set of the CTE
structure, they are referred to as anchor members.
CTE_query_definitions are considered anchor members unless they reference the
CTE itself. All anchor-member query definitions must be positioned before the first
recursive member definition, and a UNION ALL operator must be used to join the
last anchor member with the first recursive member.
2. Recursive invocation of the routine.
The recursive invocation includes one or more CTE_query_definitions joined by
UNION ALL operators that reference the CTE itself. These query definitions are
referred to as recursive members.
3. Termination check.
The termination check is implicit; recursion stops when no rows are returned from the
previous invocation.

WITH cte_name ( column_name [,...n] )


AS
(
CTE_query_definition - Anchor member is defined.
UNION ALL
CTE_query_definition - Recursive member is defined referencing cte_name.
)
-- Statement using the CTE
SELECT *
FROM cte_name

WITH DirectReports (ManagerID, EmployeeID, Title, DeptID, Level)

AS
(
-- Anchor member definition
SELECT e.ManagerID, e.EmployeeID, e.Title, edh.DepartmentID,
0 AS Level
FROM dbo.MyEmployees AS e
INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
ON e.EmployeeID = edh.BusinessEntityID AND edh.EndDate IS NULL
WHERE ManagerID IS NULL
UNION ALL
-- Recursive member definition
SELECT e.ManagerID, e.EmployeeID, e.Title, edh.DepartmentID,
Level + 1
FROM dbo.MyEmployees AS e
INNER JOIN HumanResources.EmployeeDepartmentHistory AS edh
ON e.EmployeeID = edh.BusinessEntityID AND edh.EndDate IS NULL
INNER JOIN DirectReports AS d
ON e.ManagerID = d.EmployeeID
)
-- Statement that executes the CTE
SELECT ManagerID, EmployeeID, Title, DeptID, Level
FROM DirectReports
INNER JOIN HumanResources.Department AS dp
ON DirectReports.DeptID = dp.DepartmentID
WHERE dp.GroupName = N'Sales and Marketing' OR Level = 0;
GO

Using APPLY
The APPLY operator allows you to invoke a table-valued function for each row returned by an outer
table expression of a query. The table-valued function acts as the right input and the outer table
expression acts as the left input. The right input is evaluated for each row from the left input and the
rows produced are combined for the final output. The list of columns produced by the APPLY
operator is the set of columns in the left input followed by the list of columns returned by the right
input.
There are two forms of APPLY: CROSS APPLY and OUTER APPLY. CROSS APPLY returns only rows from
the outer table that produce a result set from the table-valued function. OUTER APPLY returns both
rows that produce a result set, and rows that do not, with NULL values in the columns produced by
the table-valued function.

--Create Employees table and insert values.


CREATE TABLE Employees
(
empid
int
NOT NULL
,mgrid
int
NULL
,empname varchar(25) NOT NULL
,salary money
NOT NULL
CONSTRAINT PK_Employees PRIMARY KEY(empid)
);
GO
INSERT INTO Employees VALUES(1 , NULL, 'Nancy'
,
INSERT INTO Employees VALUES(2 , 1
, 'Andrew' ,
INSERT INTO Employees VALUES(3 , 1
, 'Janet'
,
INSERT INTO Employees VALUES(4 , 1
, 'Margaret',

$10000.00);
$5000.00);
$5000.00);
$5000.00);

INSERT INTO Employees VALUES(5 , 2


, 'Steven' , $2500.00);
INSERT INTO Employees VALUES(6 , 2
, 'Michael' , $2500.00);
INSERT INTO Employees VALUES(7 , 3
, 'Robert' , $2500.00);
INSERT INTO Employees VALUES(8 , 3
, 'Laura'
, $2500.00);
INSERT INTO Employees VALUES(9 , 3
, 'Ann'
, $2500.00);
INSERT INTO Employees VALUES(10, 4
, 'Ina'
, $2500.00);
INSERT INTO Employees VALUES(11, 7
, 'David'
, $2000.00);
INSERT INTO Employees VALUES(12, 7
, 'Ron'
, $2000.00);
INSERT INTO Employees VALUES(13, 7
, 'Dan'
, $2000.00);
INSERT INTO Employees VALUES(14, 11 , 'James'
, $1500.00);
GO
--Create Departments table and insert values.
CREATE TABLE Departments
(
deptid
INT NOT NULL PRIMARY KEY
,deptname VARCHAR(25) NOT NULL
,deptmgrid INT NULL REFERENCES Employees
);
GO
INSERT INTO Departments VALUES(1, 'HR',
2);
INSERT INTO Departments VALUES(2, 'Marketing',
7);
INSERT INTO Departments VALUES(3, 'Finance',
8);
INSERT INTO Departments VALUES(4, 'R&D',
9);
INSERT INTO Departments VALUES(5, 'Training',
4);
INSERT INTO Departments VALUES(6, 'Gardening', NULL);

CREATE FUNCTION dbo.fn_getsubtree(@empid AS INT)


RETURNS @TREE TABLE
(
empid
INT NOT NULL
,empname VARCHAR(25) NOT NULL
,mgrid
INT NULL
,lvl
INT NOT NULL
)
AS
BEGIN
WITH Employees_Subtree(empid, empname, mgrid, lvl)
AS
(
-- Anchor Member (AM)
SELECT empid, empname, mgrid, 0
FROM Employees
WHERE empid = @empid
UNION all
-- Recursive Member (RM)
SELECT e.empid, e.empname, e.mgrid, es.lvl+1
FROM Employees AS e
JOIN Employees_Subtree AS es
ON e.mgrid = es.empid
)
INSERT INTO @TREE
SELECT * FROM Employees_Subtree;
RETURN
END
GO

SELECT D.deptid, D.deptname, D.deptmgrid


,ST.empid, ST.empname, ST.mgrid
FROM Departments AS D
CROSS APPLY fn_getsubtree(D.deptmgrid) AS ST;
deptid
----------1
1
1
2
2
2
2
2
3
4
5
5

deptname
---------HR
HR
HR
Marketing
Marketing
Marketing
Marketing
Marketing
Finance
R&D
Training
Training

deptmgrid
----------2
2
2
7
7
7
7
7
8
9
4
4

empid
----------2
5
6
7
11
12
13
14
8
9
4
10

empname
---------Andrew
Steven
Michael
Robert
David
Ron
Dan
James
Laura
Ann
Margaret
Ina

mgrid
----------1
2
2
3
7
7
7
11
3
3
1
4

lvl
--0
1
1
0
1
1
1
2
0
0
0
1

Notice that each row from the Departments table is duplicated as many times as there are
rows returned from fn_getsubtree for the department's manager.
Also, the Gardening department does not appear in the results. Because this department has
no manager, fn_getsubtree returned an empty set for it. By using OUTER APPLY, the
Gardening department will also appear in the result set, with null values in the deptmgrid
field, as well as in the fields returned by fn_getsubtree.

Using PIVOT and UNPIVOT


You can use the PIVOT and UNPIVOT relational operators to change a table-valued expression into
another table. PIVOT rotates a table-valued expression by turning the unique values from one
column in the expression into multiple columns in the output, and performs aggregations where
they are required on any remaining column values that are wanted in the final output. UNPIVOT
performs the opposite operation to PIVOT by rotating columns of a table-valued expression into
column values.

SELECT <non-pivoted column>,


[first pivoted column] AS <column name>,
[second pivoted column] AS <column name>,
...
[last pivoted column] AS <column name>
FROM
(<SELECT query that produces the data>)

AS <alias for the source query>


PIVOT
(
<aggregation function>(<column being aggregated>)
FOR
[<column that contains the values that will become column headers>]
IN ( [first pivoted column], [second pivoted column],
... [last pivoted column])
) AS <alias for the pivot table>
<optional ORDER BY clause>;
SELECT 'AverageCost' AS Cost_Sorted_By_Production_Days,
[0], [1], [2], [3], [4]
FROM
(SELECT DaysToManufacture, StandardCost
FROM Production.Product) AS SourceTable
PIVOT
(
AVG(StandardCost)
FOR DaysToManufacture IN ([0], [1], [2], [3], [4])
) AS PivotTable;

UNPIVOT performs almost the reverse operation of PIVOT, by rotating columns into rows. Suppose
the table produced in the previous example is stored in the database as pvt, and you want to rotate
the column identifiers Emp1, Emp2, Emp3, Emp4, and Emp5 into row values that correspond to a
particular vendor. This means that you must identify two additional columns. The column that will
contain the column values that you are rotating (Emp1, Emp2,...) will be called Employee, and the
column that will hold the values that currently reside under the columns being rotated will be called
Orders. These columns correspond to the pivot_column and value_column, respectively, in the
Transact-SQL definition. Here is the query.
--Create the table and insert values as portrayed in the previous example.
CREATE TABLE pvt (VendorID int, Emp1 int, Emp2 int,
Emp3 int, Emp4 int, Emp5 int);
GO
INSERT INTO pvt VALUES (1,4,3,5,4,4);
INSERT INTO pvt VALUES (2,4,1,5,5,5);
INSERT INTO pvt VALUES (3,4,3,5,4,4);
INSERT INTO pvt VALUES (4,4,2,5,5,4);
INSERT INTO pvt VALUES (5,5,1,5,5,5);
GO
--Unpivot the table.
SELECT VendorID, Employee, Orders
FROM
(SELECT VendorID, Emp1, Emp2, Emp3, Emp4, Emp5
FROM pvt) p

UNPIVOT
(Orders FOR Employee IN
(Emp1, Emp2, Emp3, Emp4, Emp5)
)AS unpvt;
GO

Limiting Result Sets by Using TABLESAMPLE

The TABLESAMPLE clause limits the number of rows returned from a table in the FROM
clause to a sample number or PERCENT of rows. For example:
TABLESAMPLE cannot be applied to derived tables, tables from linked servers, and tables
derived from table-valued functions, rowset functions, or OPENXML. TABLESAMPLE
cannot be specified in the definition of a view or an inline table-valued function.

SELECT FirstName, LastName


FROM Person.Person
TABLESAMPLE (10 PERCENT) ;
SELECT FirstName, LastName
FROM Person.Person
TABLESAMPLE (100 ROWS) ;

Correlated Sub queries


A correlated sub query is an inner sub query which is referenced by the main outer query
such that the inner query is considered as being executed repeatedly.
Example:
----Example of Correlated Subqueries
USE AdventureWorks;
GO
SELECT e.EmployeeID
FROM HumanResources.Employee e
WHERE e.ContactID IN
(
SELECT c.ContactID
FROM Person.Contact c
WHERE MONTH(c.ModifiedDate) = MONTH(e.ModifiedDate)
)
GO
A noncorrelated subquery is subquery that is independent of the outer query and it can
executed on its own without relying on main outer query.
Example:
----Example of Noncorrelated Subqueries

USE AdventureWorks;
GO
SELECT e.EmployeeID
FROM HumanResources.Employee e
WHERE e.ContactID IN
(
SELECT c.ContactID
FROM Person.Contact c
WHERE c.Title = 'Mr.'
)
GO
Nested Subquery:-If a Subquery contains another subquery, then the subquery inside another
subquery is called nested subquery.

SET ROWCOUNT
Causes SQL Server to stop processing the query after the specified number of rows are returned.
SET ROWCOUNT { number | @number_var }

The setting of the SET ROWCOUNT option is ignored for INSERT, UPDATE, and
DELETE statements against remote tables and local and remote partitioned views.
To set this option off so that all rows are returned, specify SET ROWCOUNT 0.
SET ROWCOUNT overrides the SELECT statement TOP keyword if the rowcount is the
smaller value.
SET ROWCOUNT is ignored in INSERT, UPDATE, and DELETE statements when an
explicit TOP expression is used in the same statement. This includes statements in which
INSERT is followed by a SELECT clause.
The setting of SET ROWCOUNT is set at execute or run time and not at parse time.

SET CONCAT_NULL_YIELDS_NULL
Controls whether concatenation results are treated as null or empty string values.
When SET CONCAT_NULL_YIELDS_NULL is ON, concatenating a null value with a
string yields a NULL result. For example, SELECT 'abc' + NULL yields NULL. When SET
CONCAT_NULL_YIELDS_NULL is OFF, concatenating a null value with a string yields
the string itself (the null value is treated as an empty string). For example, SELECT 'abc' +
NULL yields abc.

COLLATE
Is a clause that can be applied to a database definition or a column definition to define the
collation, or to a character string expression to apply a collation cast.

Built-in Functions
Rowset Functions

OPENQUERY
OPENQUERY can be referenced in the FROM clause of a query as if it were a table name.
OPENQUERY can also be referenced as the target table of an INSERT, UPDATE, or
DELETE statement. This is subject to the capabilities of the OLE DB provider. Although the
query may return multiple result sets, OPENQUERY returns only the first one.

OPENQUERY ( linked_server ,'query' )

linked_server
Is an identifier representing the name of the linked server.
'query'
Is the query string executed in the linked server. The maximum length of the string is 8 KB.
OPENROWSET

This method is an alternative to accessing tables in a linked server and is a one-time, ad hoc
method of connecting and accessing remote data by using OLE DB. For more frequent
references to OLE DB data sources, use linked servers instead.
The OPENROWSET function can be referenced in the FROM clause of a query as if it were
a table name. The OPENROWSET function can also be referenced as the target table of an
INSERT, UPDATE, or DELETE statement, subject to the capabilities of the OLE DB
provider. Although the query might return multiple result sets, OPENROWSET returns only
the first one.
SELECT a.*
FROM OPENROWSET('SQLNCLI', 'Server=Seattle1;Trusted_Connection=yes;',
'SELECT GroupName, Name, DepartmentID
FROM AdventureWorks2008R2.HumanResources.Department
ORDER BY GroupName, Name') AS a;

SELECT a.*
FROM OPENROWSET('SQLNCLI',
'Server=10.240.21.216;UID=linkedserver2;PWD=linkedser
ver2;',
'SELECT top 10 siteid
FROM siteshare3appindus.dbo.site
') AS a;

OPENDATASOURCE

Provides ad hoc connection information as part of a four-part object name without using a
linked server name.
The OPENDATASOURCE function can be used in the same Transact-SQL syntax locations
as a linked-server name. Therefore, OPENDATASOURCE can be used as the first part of a
four-part name that refers to a table or view name in a SELECT, INSERT, UPDATE, or
DELETE statement, or to a remote stored procedure in an EXECUTE statement. When
executing remote stored procedures, OPENDATASOURCE should refer to another instance
of SQL Server. OPENDATASOURCE does not accept variables for its arguments.
Like the OPENROWSET function, OPENDATASOURCE should only reference OLE DB
data sources that are accessed infrequently. Define a linked server for any data sources
accessed more than several times. Neither OPENDATASOURCE nor OPENROWSET
provide all the functionality of linked-server definitions, such as security management and
the ability to query catalog information. All connection information, including passwords,
must be provided every time that OPENDATASOURCE is called.

SELECT *
FROM OPENDATASOURCE('SQLNCLI',
'DataSource=10.240.21.216;UID=linkedserver2;PWD=linke
dserver2').siteshare3appindus.dbo.site
Aggregate Functions
Aggregate functions perform a calculation on a set of values and return a single value. Except
for COUNT, aggregate functions ignore null values. Aggregate functions are frequently used
with the GROUP BY clause of the SELECT statement.
All aggregate functions are deterministic. This means aggregate functions return the same
value any time that they are called by using a specific set of input values.
Aggregate functions can be used as expressions only in the following:

The select list of a SELECT statement (either a subquery or an outer query).


A COMPUTE or COMPUTE BY clause.
A HAVING clause.

Transact-SQL provides the following aggregate functions:

MIN
MAX
AVG
COUNT
COUNT_BIG
SUM

GROUPING(Indicates whether a specified column expression in a GROUP BY list is


aggregated or not. GROUPING returns 1 for aggregated or 0 for not aggregated in the
result set)
Ranking Functions

Ranking functions return a ranking value for each row in a partition. Depending on the
function that is used, some rows might receive the same value as other rows. Ranking
functions are nondeterministic.
ROW_NUMBER
Returns the sequential number of a row within a partition of a result set, starting at 1 for the first
row in each partition
ROW_NUMBER ( )

OVER ( [ <partition_by_clause> ] <order_by_clause> )

RANK
Returns the rank of each row within the partition of a result set. The rank of a row is one plus the
number of ranks that come before the row in question.
RANK ( )

OVER ( [ < partition_by_clause > ] < order_by_clause > )

DENSE_RANKReturns the rank of rows within the partition of a result set, without any gaps in the ranking. The
rank of a row is one plus the number of distinct ranks that come before the row in question.
DENSE_RANK ( )

OVER ( [ <partition_by_clause> ] < order_by_clause > )

NTILE -

Distributes the rows in an ordered partition into a specified number of groups. The groups are
numbered, starting at one. For each row, NTILE returns the number of the group to which the
row belongs.
NTILE (integer_expression)
order_by_clause > )

OVER ( [ <partition_by_clause> ] <

Mathematical functions
Round -Returns a numeric value, rounded to the specified length or precision.
ROUND ( numeric_expression , length [ ,function ] )
CELING -

Returns the smallest integer greater than, or equal to, the specified numeric expression.
CEILING ( numeric_expression )

FLOOR

Returns the largest integer less than or equal to the specified numeric expression.
FLOOR ( numeric_expression )

Control-of-Flow Language
BEGIN...END
Encloses a series of Transact-SQL statements so that a group of Transact-SQL statements can
be executed. BEGIN and END are control-of-flow language keywords.
BREAK
Exits the innermost loop in a WHILE statement or an IFELSE statement inside a WHILE
loop. Any statements appearing after the END keyword, marking the end of the loop, are
executed.
CONTINUE
Restarts a WHILE loop. Any statements after the CONTINUE keyword are ignored.
ELSE (IF...ELSE)
Imposes conditions on the execution of a Transact-SQL statement. The Transact-SQL
statement (sql_statement) following the Boolean_expression is executed if the
Boolean_expression evaluates to TRUE. The optional ELSE keyword is an alternate
Transact-SQL statement that is executed when Boolean_expression evaluates to FALSE or
NULL.
END (BEGIN...END)
Encloses a series of Transact-SQL statements that will execute as a group. BEGIN...END
blocks can be nested.
GOTO
Alters the flow of execution to a label. The Transact-SQL statement or statements that follow
GOTO are skipped and processing continues at the label. GOTO statements and labels can be
used anywhere within a procedure, batch, or statement block. GOTO statements can be
nested.

DECLARE @Counter int;


SET @Counter = 1;
WHILE @Counter < 10
BEGIN

SELECT @Counter
SET @Counter = @Counter + 1
IF @Counter = 4 GOTO Branch_One --Jumps to the first branch.
IF @Counter = 5 GOTO Branch_Two --This will never execute.
END
Branch_One:
SELECT 'Jumping To
GOTO Branch_Three;
Branch_Two:
SELECT 'Jumping To
Branch_Three:
SELECT 'Jumping To

Branch One.'
--This will prevent Branch_Two from executing.
Branch Two.'
Branch Three.'

IF...ELSE
IF Boolean_expression
{ sql_statement | statement_block }
[ ELSE
{ sql_statement | statement_block } ]

RETURN
Exits unconditionally from a query or procedure. RETURN is immediate and complete and
can be used at any point to exit from a procedure, batch, or statement block. Statements that
follow RETURN are not executed.
RETURN [ integer_expression ]

When used with a stored procedure, RETURN cannot return a null value. If a procedure tries
to return a null value (for example, using RETURN @status when @status is NULL), a
warning message is generated and a value of 0 is returned.
The return status value can be included in subsequent Transact-SQL statements in the batch
or procedure that executed the current procedure, but it must be entered in the following
form: EXECUTE @return_status = <procedure_name>.
THROW (new feature in sql server 2012)
Raises an exception and transfers execution to a CATCH block of a TRYCATCH
construct in SQL Server 2012.
THROW [ { error_number | @local_variable },
{ message | @local_variable },
{ state | @local_variable } ]
[ ; ]

The statement before the THROW statement must be followed by the semicolon (;) statement
terminator.
If a TRYCATCH construct is not available, the session is ended. The line number and
procedure where the exception is raised are set. The severity is set to 16.

If the THROW statement is specified without parameters, it must appear inside a CATCH
block. This causes the caught exception to be raised. Any error that occurs in a THROW
statement causes the statement batch to be ended.
USE tempdb;
GO
CREATE TABLE dbo.TestRethrow
(
ID INT PRIMARY KEY
);
BEGIN TRY
INSERT dbo.TestRethrow(ID) VALUES(1);
-- Force error 2627, Violation of PRIMARY KEY constraint to be raised.
INSERT dbo.TestRethrow(ID) VALUES(1);
END TRY
BEGIN CATCH
PRINT 'In catch block.';
THROW;
END CATCH;

Here is the result set.


PRINT 'In catch block.';
Msg 2627, Level 14, State 1, Line 1
Violation of PRIMARY KEY constraint 'PK__TestReth__3214EC272E3BD7D3'. Cannot
insert duplicate key in object 'dbo.TestRethrow'.
The statement has been terminated.
TRY...CATCH

Implements error handling for Transact-SQL that is similar to the exception handling in the
Microsoft Visual C# and Microsoft Visual C++ languages. A group of Transact-SQL
statements can be enclosed in a TRY block. If an error occurs in the TRY block, control is
passed to another group of statements that is enclosed in a CATCH block.
BEGIN TRY
{ sql_statement | statement_block }
END TRY
BEGIN CATCH
[ { sql_statement | statement_block } ]
END CATCH
[ ; ]

A TRYCATCH construct catches all execution errors that have a severity higher than 10
that do not close the database connection.

A TRY block must be immediately followed by an associated CATCH block. Including any
other statements between the END TRY and BEGIN CATCH statements generates a syntax
error.
A TRYCATCH construct cannot span multiple batches. A TRYCATCH construct
cannot span multiple blocks of Transact-SQL statements. For example, a TRYCATCH
construct cannot span two BEGINEND blocks of Transact-SQL statements and cannot
span an IFELSE construct.
If there are no errors in the code that is enclosed in a TRY block, when the last statement in
the TRY block has finished running, control passes to the statement immediately after the
associated END CATCH statement. If there is an error in the code that is enclosed in a TRY
block, control passes to the first statement in the associated CATCH block. If the END
CATCH statement is the last statement in a stored procedure or trigger, control is passed back
to the statement that called the stored procedure or fired the trigger.
When the code in the CATCH block finishes, control passes to the statement immediately
after the END CATCH statement. Errors trapped by a CATCH block are not returned to the
calling application. If any part of the error information must be returned to the application,
the code in the CATCH block must do so by using mechanisms such as SELECT result sets
or the RAISERROR and PRINT statements. For more information about how to use
RAISERROR with TRYCATCH, see Using TRY...CATCH in Transact-SQL.
TRYCATCH constructs can be nested. Either a TRY block or a CATCH block can contain
nested TRYCATCH constructs. For example, a CATCH block can contain an embedded
TRYCATCH construct to handle errors encountered by the CATCH code.
Errors encountered in a CATCH block are treated like errors generated anywhere else. If the
CATCH block contains a nested TRYCATCH construct, any error in the nested TRY
block will pass control to the nested CATCH block. If there is no nested TRYCATCH
construct, the error is passed back to the caller.
TRYCATCH constructs catch unhandled errors from stored procedures or triggers
executed by the code in the TRY block. Alternatively, the stored procedures or triggers can
contain their own TRYCATCH constructs to handle errors generated by their code. For
example, when a TRY block executes a stored procedure and an error occurs in the stored
procedure, the error can be handled in the following ways:

If the stored procedure does not contain its own TRYCATCH construct, the error
returns control to the CATCH block associated with the TRY block that contains the
EXECUTE statement.
If the stored procedure contains a TRYCATCH construct, the error transfers control
to the CATCH block in the stored procedure. When the CATCH block code finishes,
control is passed back to the statement immediately after the EXECUTE statement
that called the stored procedure.

GOTO statements cannot be used to enter a TRY or CATCH block. GOTO statements can be
used to jump to a label inside the same TRY or CATCH block or to leave a TRY or CATCH
block.

The TRYCATCH construct cannot be used in a user-defined function.


Retrieving Error Information
In the scope of a CATCH block, the following system functions can be used to obtain
information about the error that caused the CATCH block to be executed:

ERROR_NUMBER() returns the number of the error.


ERROR_SEVERITY() returns the severity.
ERROR_STATE() returns the error state number.
ERROR_PROCEDURE() returns the name of the stored procedure or trigger where
the error occurred.
ERROR_LINE() returns the line number inside the routine that caused the error.
ERROR_MESSAGE() returns the complete text of the error message. The text
includes the values supplied for any substitutable parameters, such as lengths, object
names, or times.

These functions return NULL if they are called outside the scope of the CATCH block. Error
information can be retrieved by using these functions from anywhere within the scope of the
CATCH block. For example, the following script shows a stored procedure that contains
error-handling functions. In the CATCH block of a TRYCATCH construct, the stored
procedure is called and information about the error is returned.
USE AdventureWorks2008R2;
GO
-- Verify that the stored procedure does not already exist.
IF OBJECT_ID ( 'usp_GetErrorInfo', 'P' ) IS NOT NULL
DROP PROCEDURE usp_GetErrorInfo;
GO
-- Create procedure to retrieve error information.
CREATE PROCEDURE usp_GetErrorInfo
AS
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_LINE() AS ErrorLine
,ERROR_MESSAGE() AS ErrorMessage;
GO
BEGIN TRY
-- Generate divide-by-zero error.
SELECT 1/0;
END TRY
BEGIN CATCH
-- Execute error retrieval routine.
EXECUTE usp_GetErrorInfo;
END CATCH;

Errors Unaffected by a TRYCATCH Construct


TRYCATCH constructs do not trap the following conditions:
Warnings or informational messages that have a severity of 10 or lower.
Errors that have a severity of 20 or higher that stop the SQL Server Database Engine
task processing for the session. If an error occurs that has severity of 20 or higher and
the database connection is not disrupted, TRYCATCH will handle the error.
3. Attentions, such as client-interrupt requests or broken client connections.
4. When the session is ended by a system administrator by using the KILL statement.
1.
2.

The following types of errors are not handled by a CATCH block when they occur at the
same level of execution as the TRYCATCH construct:

Compile errors, such as syntax errors, that prevent a batch from running.
Errors that occur during statement-level recompilation, such as object name resolution
errors that occur after compilation because of deferred name resolution.

These errors are returned to the level that ran the batch, stored procedure, or trigger.
If an error occurs during compilation or statement-level recompilation at a lower execution
level (for example, when executing sp_executesql or a user-defined stored procedure) inside
the TRY block, the error occurs at a lower level than the TRYCATCH construct and will
be handled by the associated CATCH block. For more information, see Using TRY...CATCH
in Transact-SQL.
The following example shows how an object name resolution error generated by a SELECT
statement is not caught by the TRYCATCH construct, but is caught by the CATCH block
when the same SELECT statement is executed inside a stored procedure.
USE AdventureWorks2008R2;
GO
BEGIN TRY
-- Table does not exist; object name resolution
-- error not caught.
SELECT * FROM NonexistentTable;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_MESSAGE() AS ErrorMessage;
END CATCH

The error is not caught and control passes out of the TRYCATCH construct to the next
higher level.
Running the SELECT statement inside a stored procedure will cause the error to occur at a
level lower than the TRY block. The error will be handled by the TRYCATCH construct.
-- Verify that the stored procedure does not exist.
IF OBJECT_ID ( N'usp_ExampleProc', N'P' ) IS NOT NULL
DROP PROCEDURE usp_ExampleProc;

GO
-- Create a stored procedure that will cause an
-- object resolution error.
CREATE PROCEDURE usp_ExampleProc
AS
SELECT * FROM NonexistentTable;
GO
BEGIN TRY
EXECUTE usp_ExampleProc;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_MESSAGE() AS ErrorMessage;
END CATCH;

Uncommittable Transactions and XACT_STATE


If an error generated in a TRY block causes the state of the current transaction to be
invalidated, the transaction is classified as an uncommittable transaction. An error that
ordinarily ends a transaction outside a TRY block causes a transaction to enter an
uncommittable state when the error occurs inside a TRY block. An uncommittable
transaction can only perform read operations or a ROLLBACK TRANSACTION. The
transaction cannot execute any Transact-SQL statements that would generate a write
operation or a COMMIT TRANSACTION. The XACT_STATE function returns a value of 1 if a transaction has been classified as an uncommittable transaction. When a batch finishes,
the Database Engine rolls back any active uncommittable transactions. If no error message
was sent when the transaction entered an uncommittable state, when the batch finishes, an
error message will be sent to the client application. This indicates that an uncommittable
transaction was detected and rolled back.

Examples
A.Using TRYCATCH
The following example shows a SELECT statement that will generate a divide-by-zero error.
The error causes execution to jump to the associated CATCH block.
USE AdventureWorks2008R2;
GO
BEGIN TRY
-- Generate a divide-by-zero error.
SELECT 1/0;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumber

,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_LINE() AS ErrorLine
,ERROR_MESSAGE() AS ErrorMessage;
END CATCH;
GO

B. Using TRYCATCH in a transaction


The following example shows how a TRYCATCH block works inside a transaction. The
statement inside the TRY block generates a constraint violation error.
USE AdventureWorks2008R2;
GO
BEGIN TRANSACTION;
BEGIN TRY
-- Generate a constraint violation error.
DELETE FROM Production.Product
WHERE ProductID = 980;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_LINE() AS ErrorLine
,ERROR_MESSAGE() AS ErrorMessage;
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH;
IF @@TRANCOUNT > 0
COMMIT TRANSACTION;
GO

C. Using TRYCATCH with XACT_STATE


The following example shows how to use the TRYCATCH construct to handle errors that
occur inside a transaction. The XACT_STATE function determines whether the transaction
should be committed or rolled back. In this example, SET XACT_ABORT is ON. This
makes the transaction uncommittable when the constraint violation error occurs.
USE AdventureWorks2008R2;
GO
-- Check to see whether this stored procedure exists.
IF OBJECT_ID (N'usp_GetErrorInfo', N'P') IS NOT NULL
DROP PROCEDURE usp_GetErrorInfo;
GO
-- Create procedure to retrieve error information.
CREATE PROCEDURE usp_GetErrorInfo

AS
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_LINE () AS ErrorLine
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_MESSAGE() AS ErrorMessage;
GO
-- SET XACT_ABORT ON will cause the transaction to be uncommittable
-- when the constraint violation occurs.
SET XACT_ABORT ON;
BEGIN TRY
BEGIN TRANSACTION;
-- A FOREIGN KEY constraint exists on this table. This
-- statement will generate a constraint violation error.
DELETE FROM Production.Product
WHERE ProductID = 980;
-- If the DELETE statement succeeds, commit the transaction.
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
-- Execute error retrieval routine.
EXECUTE usp_GetErrorInfo;
-- Test XACT_STATE:
-- If 1, the transaction is committable.
-- If -1, the transaction is uncommittable and should
-be rolled back.
-- XACT_STATE = 0 means that there is no transaction and
-a commit or rollback operation would generate an error.
-- Test whether the transaction is uncommittable.
IF (XACT_STATE()) = -1
BEGIN
PRINT
N'The transaction is in an uncommittable state.' +
'Rolling back transaction.'
ROLLBACK TRANSACTION;
END;
-- Test whether the transaction is committable.
IF (XACT_STATE()) = 1
BEGIN
PRINT
N'The transaction is committable.' +
'Committing transaction.'
COMMIT TRANSACTION;
END;
END CATCH;
GO

WAITFOR

Blocks the execution of a batch, stored procedure, or transaction until a specified time or time
interval is reached, or a specified statement modifies or returns at least one row.
WAITFOR
{
DELAY 'time_to_pass'
| TIME 'time_to_execute'
| [ ( receive_statement ) | ( get_conversation_group_statement ) ]
[ , TIMEOUT timeout ]
}

While executing the WAITFOR statement, the transaction is running and no other requests
can run under the same transaction.
The actual time delay may vary from the time specified in time_to_pass, time_to_execute, or
timeout and depends on the activity level of the server. The time counter starts when the
thread associated with the WAITFOR statement is scheduled. If the server is busy, the thread
may not be immediately scheduled; therefore, the time delay may be longer than the specified
time.
WAITFOR does not change the semantics of a query. If a query cannot return any rows,
WAITFOR will wait forever or until TIMEOUT is reached, if specified.
Cursors cannot be opened on WAITFOR statements.
Views cannot be defined on WAITFOR statements.
When the query exceeds the query wait option, the WAITFOR statement argument can
complete without running. For more information about the configuration option, see query
wait Option. To see the active and waiting processes, use sp_who.
Each WAITFOR statement has a thread associated with it. If many WAITFOR statements are
specified on the same server, many threads can be tied up waiting for these statements to run.
SQL Server monitors the number of threads associated with WAITFOR statements, and
randomly selects some of these threads to exit if the server starts to experience thread
starvation.
You can create a deadlock by running a query with WAITFOR within a transaction that also
holds locks preventing changes to the rowset that the WAITFOR statement is trying to
access. SQL Server identifies these scenarios and returns an empty result set if the chance of
such a deadlock exists.

A.Using WAITFOR TIME


The following example executes the stored procedure sp_update_job at 10:20 P.M. (22:20).
USE msdb;
EXECUTE sp_add_job @job_name = 'TestJob';
BEGIN
WAITFOR TIME '22:20';
EXECUTE sp_update_job @job_name = 'TestJob',
@new_name = 'UpdatedJob';
END;
GO

B. Using WAITFOR DELAY


The following example executes the stored procedure after a two-hour delay.
BEGIN
WAITFOR DELAY '02:00';
EXECUTE sp_helpdb;
END;
GO

WHILE
Sets a condition for the repeated execution of an SQL statement or statement block. The
statements are executed repeatedly as long as the specified condition is true. The execution of
statements in the WHILE loop can be controlled from inside the loop with the BREAK and
CONTINUE keywords.
If two or more WHILE loops are nested, the inner BREAK exits to the next outermost loop.
All the statements after the end of the inner loop run first, and then the next outermost loop
restarts.
USE AdventureWorks2008R2;
GO
WHILE (SELECT AVG(ListPrice) FROM Production.Product) < $300
BEGIN
UPDATE Production.Product
SET ListPrice = ListPrice * 2
SELECT MAX(ListPrice) FROM Production.Product
IF (SELECT MAX(ListPrice) FROM Production.Product) > $500
BREAK
ELSE
CONTINUE
END
PRINT 'Too much for the market to bear';

--End of control of flow

Cursors

Syntax iso format


DECLARE cursor_name [ INSENSITIVE ] [ SCROLL ] CURSOR
FOR select_statement
[ FOR { READ ONLY | UPDATE [ OF column_name [ ,...n ] ] } ]
[;]

INSENSITIVE
Defines a cursor that makes a temporary copy of the data to be used by the cursor. All
requests to the cursor are answered from this temporary table in tempdb; therefore,
modifications made to base tables are not reflected in the data returned by fetches
made to this cursor, and this cursor does not allow modifications. When ISO syntax is
used, if INSENSITIVE is omitted, committed deletes and updates made to the
underlying tables (by any user) are reflected in subsequent fetches.
SCROLL
Specifies that all fetch options (FIRST, LAST, PRIOR, NEXT, RELATIVE,
ABSOLUTE) are available. If SCROLL is not specified in an ISO DECLARE
CURSOR, NEXT is the only fetch option supported. SCROLL cannot be specified if
FAST_FORWARD is also specified.
READ ONLY
Prevents updates made through this cursor. The cursor cannot be referenced in a
WHERE CURRENT OF clause in an UPDATE or DELETE statement. This option
overrides the default capability of a cursor to be updated.
UPDATE [OF column_name [,...n]]
Defines updatable columns within the cursor. If OF column_name [,...n] is specified,
only the columns listed allow modifications. If UPDATE is specified without a
column list, all columns can be updated.

Transact-SQL Extended Syntax


DECLARE cursor_name CURSOR [ LOCAL | GLOBAL ]
[ FORWARD_ONLY | SCROLL ]
[ STATIC | KEYSET | DYNAMIC | FAST_FORWARD ]
[ READ_ONLY | SCROLL_LOCKS | OPTIMISTIC ]
[ TYPE_WARNING ]
FOR select_statement
[ FOR UPDATE [ OF column_name [ ,...n ] ] ]
[;]

READ_ONLY

Prevents updates made through this cursor. The cursor cannot be referenced in a
WHERE CURRENT OF clause in an UPDATE or DELETE statement. This option
overrides the default capability of a cursor to be updated.

Temp table VS Table variables


Temp tables provide work space for the intermediate result sets when processing data within
a batch or procedure. They are also used to pass a table from table valued function.
If you are doing more complex processing on temporary data or likely to use more than
reasonably small amounts of data in them, then temp tables are likely to be a better choice.
Table variables behave like other variables in their scoping rules. Once out of scope, they are
disposed of.
Table variables triggers fewer recompiles, compared to temporary tables.
You cant refer an externally-defined table variable within dynamic SQL but can access temp
tables and table valued parameters. But can declare and use the table variables in the dynamic
sql. These table variables will be out of scope after execution of dynamic sql.
You cant create indexes explicitly on table variables. To partially get around the index
restriction, you can use constraints to do the same thing. Most essential is the Primary Key
constraint which allows you to impose a clustered index, but unique constraints are useful for
performance.
The biggest problem with table variables is that statistics arent maintained on the columns.
This means that the query optimiser has to make a guess as to the size and distribution of the
data and if it gets it wrong, then youre going to see poor performance on joins:
Both table variables and temp tables can be used in the from clause and in joins.
Select * into #temp - this works but this will not work in case of table variable
Below are the scenarios where we can use temporary tables:

When we are doing large number of row manipulation in stored procedures.


This is useful to replace the cursor. We can store the result set data into a temp table,
then we can manipulate the data from there.
When we are having a complex join operation.

Tablevariable is always useful for less data. If the result set returns a large number of records,
we need to go for temp table.
Table variables are limited to the scope of a batch but not the temp tables
Ex .

begin

declare @var table(id int,data varchar(44))


create table #temp(id int)
insert into #temp
select 1
insert into @var
select 1,''
end
go
select * from @var -cant refer
select * from #temp can refer

Summary when to use table variables and temp tables


If data is large temp tables otherwise table variables
If we are processing transaction dependent data then go for temp tables other wise table
variables
If we want to refer data in dynamic sql from out side then temp tables other wise table
variables
As a rule of thumb, for small to medium volumes of data and simple usage scenarios you
should use table variables. (This is an overly broad guideline with of course lots of exceptions
- see below and following articles.)
Some points to consider when choosing between them:

Temporary Tables are real tables so you can do things like CREATE INDEXes, etc. If
you have large amounts of data for which accessing by index will be faster then
temporary tables are a good option.
Table variables can have indexes by using PRIMARY KEY or UNIQUE constraints.
(If you want a non-unique index just include the primary key column as the last
column in the unique constraint. If you don't have a unique column, you can use an
identity column.)
Table variables don't participate in transactions, logging or locking. This means
they're faster as they don't require the overhead, but conversely you don't get those
features. So for instance if you want to ROLLBACK midway through a procedure
then table variables populated during that transaction will still be populated!
Temp tables might result in stored procedures being recompiled, perhaps often. Table
variables will not.

You can create a temp table using SELECT INTO, which can be quicker to write
(good for ad-hoc querying) and may allow you to deal with changing datatypes over
time, since you don't need to define your temp table structure upfront.
You can pass table variables back from functions, enabling you to encapsulate and
reuse logic much easier (eg make a function to split a string into a table of values on
some arbitrary delimiter).
Using Table Variables within user-defined functions enables those functions to be
used more widely (see CREATE FUNCTION documentation for details). If you're
writing a function you should use table variables over temp tables unless there's a
compelling need otherwise.
Both table variables and temp tables are stored in tempdb. This means you should be
aware of issues such as COLLATION problems if your database collation is different
to your server collation; temp tables and table variables will by default inherit the
collation of the server, causing problems if you want to compare data in them with
data in your database.
Global Temp Tables (##tmp) are another type of temp table available to all sessions
and users.
When using a #temp table within a user transaction locks are held longer than for
table variables and also it can prevent truncation of the tempdb transaction log until
the user transaction ends.

Truncate Vs Delete
TRUNCATE is a DDL command and logged at the page allocation level, whereas DELETE is a DML
command logged at the row level. But essentially both are logged and can be rolled back if required.

Performance (TRUNCATE is quicker)


Re-seeding identity columns (only done by TRUNCATE)
Deallocation of space used by the table (only done by TRUNCATE)
Triggers not fired by TRUNCATE
TRUNCATE not possible on tables referenced by a foreign key

Delete
Removes rows from a table or view.
DELETE statements delete rows one at a
time, logging each row in the transaction log,
as well as maintaining log sequence number
(LSN) information.

You may use DELETE statement against a


view (with some limitations).
You can specify a WHERE clause in a
DELETE FROM statement-it is all or
selected records.
Does not reset identity value of the table
Records removed using DELETE can be roll
backed and can be restored point in time.
Triggers get executed on Delete statement.

Truncate
Removes all rows from a table without
logging the individual row deletions.
TRUNCATE TABLE is similar to the
DELETE statement with no WHERE clause;
however, TRUNCATE TABLE is faster and
uses fewer system and transaction log
resources.
You cant use TRUNCATE statement against
a view.
You can not specify a WHERE clause in a
TRUNCATE TABLE statement. It is all or
nothing
Reset identity value of the table.
Records removed using TRUNCATE can
ALSO be roll backed.
Triggers
does
NOT
executed
on

You can use DELETE statement on a parent


table and if CASCADE ON DELETE is
enabled then data from child table also get
deleted. If CASCADE ON DELETE is NOT
enabled and any of the child table has related
then you cant delete records from parent
table.
DELETE statement can be used even if you
have Replication/CDC enabled for the
table.
Log shipping has NO impact on DELETE.

TRUNCATE statement.
You cant truncate a parent table irrespective
of whether the child table has any record or
not. Truncate table statement will fail for
parent table even if CASCADE ON
DELETE is enabled.

TRUNCATE statement can NOT be used if


you have Replication/ CDC enabled for the
table.
Log shipping has NO impact on
TRUNCATE.
DELETE permissions default to members You need to be db_owner, ddl_admin, or
of the sysadmin fixed server role, the owner of the table to be able to fire a
db_owner and db_datawriter fixed TRUNCATE statement.
database roles, and the table owner.
Minimum permission required is ALTER
Minimum permission required is DELETE table.
permissions on the target table. SELECT
permissions are also required if the
statement contains a WHERE clause.
TRUNCATE is classified as DDL operation.
DELETE is classified as DML operation.
Compared to the DELETE statement, TRUNCATE TABLE has the following advantages:

Less transaction log space is used.


The DELETE statement removes rows one at a time and records an entry in the
transaction log for each deleted row. TRUNCATE TABLE removes the data by
deallocating the data pages used to store the table data and records only the page
deallocations in the transaction log.

Fewer locks are typically used.


When the DELETE statement is executed using a row lock, each row in the table is
locked for deletion. TRUNCATE TABLE always locks the table and page but not
each row.

Without exception, zero pages are left in the table.


After a DELETE statement is executed, the table can still contain empty pages. For
example, empty pages in a heap cannot be deallocated without at least an exclusive
(LCK_M_X) table lock. If the delete operation does not use a table lock, the table
(heap) will contain many empty pages. For indexes, the delete operation can leave
empty pages behind, although these pages will be deallocated quickly by a
background cleanup process.

TRUNCATE TABLE removes all rows from a table, but the table structure and its columns,
constraints, indexes, and so on remain. To remove the table definition in addition to its data,
use the DROP TABLE statement.
If the table contains an identity column, the counter for that column is reset to the seed value
defined for the column. If no seed was defined, the default value 1 is used. To retain the
identity counter, use DELETE instead.

Restrictions
You cannot use TRUNCATE TABLE on tables that:

Are referenced by a FOREIGN KEY constraint. (You can truncate a table that has a
foreign key that references itself.)
Participate in an indexed view.
Are published by using transactional replication or merge replication.

How to reset identity value


DBCC CHECKIDENT
(
table_name
[, { NORESEED | { RESEED [, new_reseed_value ] } } ]
)
[ WITH NO_INFOMSGS ]

Ex- DBCC checkident (employee,reseed,0)

sp_executesql VS EXEC
use the sp_executesql stored procedure instead of the EXECUTE statement. Because this
stored procedure supports parameter substitution, sp_executesql is more versatile than
EXECUTE; and because sp_executesql generates execution plans that are more likely to be
reused by SQL Server, sp_executesql is more efficient than EXECUTE.

Self-contained Batches

When either sp_executesql or the EXECUTE statement executes a string, the string is
executed as its own self-contained batch. SQL Server compiles the Transact-SQL statement
or statements in the string into an execution plan that is separate from the execution plan of
the batch that contained the sp_executesql or the EXECUTE statement. The following rules
apply for self-contained batches:

The Transact-SQL statements in the sp_executesql or EXECUTE string are not


compiled into an execution plan until sp_executesql or the EXECUTE statement are
executed. The strings are not parsed or checked for errors until they are executed. The
names referenced in the strings are not resolved until they are executed.
The Transact-SQL statements in the executed string do not have access to any
variables declared in the batch that contains sp_executesql or the EXECUTE
statement. The batch that contains sp_executesql or the EXECUTE statement does
not have access to variables or local cursors defined in the executed string.
If the executed string contains a USE statement that changes the database context, the
change to the database context only lasts until sp_executesql or the EXECUTE
statement has finished running.
Substituting Parameter Values

sp_executesql supports the substitution of parameter values for any parameters that are
specified in the Transact-SQL string, but the EXECUTE statement does not. Therefore, the
Transact-SQL strings that are generated by sp_executesql are more similar than those
generated by the EXECUTE statement. The SQL Server query optimizer will probably match
the Transact-SQL statements from sp_executesql with execution plans from the previously
executed statements, saving the overhead of compiling a new execution plan.
With the EXECUTE statement, all parameter values must be converted to character or
Unicode and made a part of the Transact-SQL string.
If the statement is executed repeatedly, a completely new Transact-SQL string must be built
for each execution, even when the only differences are in the values supplied for the
parameters. This generates additional overhead in the following ways:

The ability of the SQL Server query optimizer to match the new Transact-SQL string
with an existing execution plan is hampered by the constantly changing parameter
values in the text of the string, especially in complex Transact-SQL statements.
The whole string must be rebuilt for each execution.
Parameter values (other than character or Unicode values) must be cast to a character
or Unicode format for each execution.

sp_executesql supports setting of parameter values separately from the Transact-SQL string:
DECLARE @IntVariable INT;
DECLARE @SQLString NVARCHAR(500);
DECLARE @ParmDefinition NVARCHAR(500);
/* Build the SQL string one time. */
SET @SQLString =
N'SELECT * FROM AdventureWorks2008R2.Sales.Store WHERE SalesPersonID =
@SalesID';
/* Specify the parameter format one time. */
SET @ParmDefinition = N'@SalesID int';
/* Execute the string with the first parameter value. */
SET @IntVariable = 275;
EXECUTE sp_executesql @SQLString, @ParmDefinition,
@SalesID = @IntVariable;
/* Execute the same string with the second parameter value. */

SET @IntVariable = 276;


EXECUTE sp_executesql @SQLString, @ParmDefinition,
@SalesID = @IntVariable;

sp_executesql offers the following additional benefits:

Because the actual text of the Transact-SQL statement does not change between
executions, the query optimizer should match the Transact-SQL statement in the
second execution with the execution plan generated for the first execution. Therefore,
SQL Server does not have to compile the second statement.
The Transact-SQL string is built only one time.
The integer parameter is specified in its native format. Conversion to Unicode is not
required.

Object names in the statement string must be fully qualified for SQL Server to reuse the
execution plan.

Reusing Execution Plans


sp_executesql can be used instead of stored procedures when executing a Transact-SQL
statement several times, when the only variation is in the parameter values supplied to the
Transact-SQL statement. Because the Transact-SQL statements themselves remain constant
and only the parameter values change, the SQL Server query optimizer is likely to reuse the
execution plan it generates for the first execution.
The following example builds and executes a DBCC CHECKDB statement for every
database on a server, except for the four system databases.

Procedure VS Functions

Procedures can have input/output parameters for it whereas functions can have only
input parameters.
Procedure allows select as well as DML statement in it whereas function allows only
select statement in it.
Functions can be called from procedure whereas procedures cannot be called from
function.
Exception can be handled by try-catch block in a procedure whereas try-catch block
cannot be used in a function.
We can go for transaction management in procedure whereas we can't go in function.
Procedures can not be utilized in a select statement whereas function can be
embedded in a select statement.
UDF can be used in the SQL statements anywhere in the WHERE/HAVING/SELECT section
where as Stored procedures cannot be.
UDFs that return tables can be treated as another rowset. This can be used in JOINs with
other tables.

Functions cannot run side-effects commands, such as update, delete, alter, open, etc.
Syntax of functions
CREATE FUNCTION schema_name.function_name (@para1 as datatype)
RETURNS varchar(50) AS
BEGIN
--code here
RETURN @var
END
--table valued function
CREATE FUNCTION schema_name.function_name (@para1 as datatype)
RETURNS @table TABLE (id int,data varchar)
AS
BEGIN
--code here
RETURN
END

Syntax for trigger

CREATE TRIGGER triggername


ON Table_Name
AFTER <Data_Modification_Statements, ,
INSERT,DELETE,UPDATE>
AS
BEGIN
END
GO

Identifiers
1. The first character of an identifier must be one of the following
A letter
The underscore (_), at sign (@), or number sign (#).
A regular identifier that starts with the at sign always denotes a local variable or
parameter and cannot be used as the name of any other type of object.
2. Subsequent characters can include the following:

Letters as defined in the Unicode Standard 3.2.


Decimal numbers from either Basic Latin or other national scripts.
The at sign, dollar sign ($), number sign, or underscore.

3. The identifier must not be a Transact-SQL reserved word.


4. Embedded spaces or special characters are not allowed.

Views
A view can be thought of as either a virtual table or a stored query. Unless a view is indexed,
its data is not stored in the database as a distinct object. What is stored in the database is a
SELECT statement.
Type of views

Standard views
Indexed views(materialized views)
Partitioned views

Scenarios for using views


1. To focus on specific data
2. To simplify data manipulation (frequently used joins can be written as a view and can
be reused this view or frequently used joins, aggregations, sub queries)
3. To provide backward compatability (suppose if we normalized the existing table, then
to avoid the re written of objects code, we can create the view with the old table name
by writing the join condition in the view)
4. To combine the partitioned data across server
5. To import and export data
Indexed views
1. The view must not reference any other views, only base tables.
2. All base tables referenced by the view must be in the same database as the view and
have the same owner as the view.
3. The view must be created with the SCHEMABINDING option. Schema binding binds
the view to the schema of the underlying base tables.

4. User-defined functions referenced in the view must have been created with the
SCHEMABINDING option.
5. Tables and user-defined functions must be referenced by two-part names in the view.
One-part, three-part, and four-part names are not allowed.
6. All functions referenced by expressions in the view must be deterministic.
7. The SELECT statement in the view cannot contain the following Transact-SQL
syntax elements:
A derived table.
A common table expression (CTE).
Rowset functions.
UNION, EXCEPT or INTERSECT operators.
Subqueries.
Outer or self joins.
TOP clause.
ORDER BY clause.
DISTINCT keyword.
The CROSS APPLY or OUTER APPLY operators.
The PIVOT or UNPIVOT operators
Modifying data through a view
You can modify the data of an underlying base table through a view, in the same
manner as you modify data in a table by using UPDATE, INSERT and DELETE
statements or by using the bcp utility and BULK INSERT statement
Restrictions

Any modifications, including UPDATE, INSERT, and DELETE statements, must


reference columns from only one base table.
We can delete from the view only if view definition contains only one table.

Schema Binding
Schema binding binds the view to the schema of the underlying base tables
When SCHEMABINDING is specified, the base table or tables cannot be modified in a way
that would affect the view definition. The view definition itself must first be modified or
dropped to remove dependencies on the table that is to be modified. When you use
SCHEMABINDING, the select_statement must include the two-part names (schema.object)
of tables, views, or user-defined functions that are referenced. All referenced objects must be
in the same database.
Views or tables that participate in a view created with the SCHEMABINDING clause cannot
be dropped unless that view is dropped or changed so that it no longer has schema binding.
Otherwise, the Microsoft SQL Server 2005 Database Engine raises an error. Also, executing
ALTER TABLE statements on tables that participate in views that have schema binding fail
when these statements affect the view definition.

Fragmentation
Fragmentation exists when indexes have pages in which the logical ordering, based on the
key value, does not match the physical ordering inside the data file. Heavily fragmented
indexes can degrade query performance
Fragmentation can be detected by using sys.dm_db_index_physical_stats function.
Syntax to rebuild /reorganize indices
ALTER INDEX index_name[ALL] ON table_name REORGANIZE / REBUILD
Index Rebuild : This process drops the existing Index and Recreates the index.
Index Reorganize : This process physically reorganizes the leaf nodes of the index.

Indexes
An index is an on-disk structure associated with a table or view that speeds retrieval of rows
from the table or view. An index contains keys built from one or more columns in the table or
view. These keys are stored in a structure (B-tree) that enables SQL Server to find the row or
rows associated with the key values quickly and efficiently.

Clustered
o Clustered indexes sort and store the data rows in the table or view based on
their key values. These are the columns included in the index definition. There
can be only one clustered index per table, because the data rows themselves
can be sorted in only one order.
o The only time the data rows in a table are stored in sorted order is when the
table contains a clustered index. When a table has a clustered index, the table
is called a clustered table. If a table has no clustered index, its data rows are
stored in an unordered structure called a heap.
Nonclustered
o Nonclustered indexes have a structure separate from the data rows. A
nonclustered index contains the nonclustered index key values and each key
value entry has a pointer to the data row that contains the key value.
o The pointer from an index row in a nonclustered index to a data row is called a
row locator. The structure of the row locator depends on whether the data
pages are stored in a heap or a clustered table. For a heap, a row locator is a
pointer to the row. For a clustered table, the row locator is the clustered index
key.
o You can add nonkey columns to the leaf level of the nonclustered index to bypass existing index key limits, 900 bytes and 16 key columns, and execute
fully covered, indexed, queries. For more information, see Index with Included
Columns.
How indexes are used by query optimizer

Well-designed indexes can reduce disk I/O operations and consume fewer system resources
therefore improving query performance.

When performing a table scan, the query optimizer reads all the rows in the table, and
extracts the rows that meet the criteria of the query. A table scan generates many disk I/O
operations and can be resource intensive. However, a table scan could be the most efficient
method if, for example, the result set of the query is a high percentage of rows from the table.
When the query optimizer uses an index, it searches the index key columns, finds the storage
location of the rows needed by the query and extracts the matching rows from that location.
Generally, searching the index is much faster than searching the table because unlike a table,
an index frequently contains very few columns per row and the rows are in sorted order.

Types of Indexes

Clustered
Non clustered
Unique (A unique index ensures that the index key contains no duplicate values and
therefore every row in the table or view is in some way unique.Both clustered and non
clustered indexes can be unique.)
Index with included columns (A nonclustered index that is extended to include
nonkey columns in addition to the key columns.)
Full-text (It provides efficient support for sophisticated word searches in character
string data.)

Index FILLFACTOR
Sets the percentage of free space in the leaf level of each index page during index
creation.
Index Online
You can create, rebuild, or drop indexes online. The ONLINE option allows concurrent
user access to the underlying table or clustered index data and any associated
nonclustered indexes during these index operations. For example, while a clustered index
is being rebuilt by one user, that user and others can continue to update and query the
underlying data.

Index with Included Columns


You can extend the functionality of nonclustered indexes by adding nonkey columns to the
leaf level of the nonclustered index. By including nonkey columns, you can create
nonclustered indexes that cover more queries. This is because the nonkey columns have the
following benefits:

They can be data types not allowed as index key columns.


They are not considered by the Database Engine when calculating the number of
index key columns or index key size.

An index with included nonkey columns can significantly improve query performance when
all columns in the query are included in the index either as key or nonkey columns.
Performance gains are achieved because the query optimizer can locate all the column values
within the index; table or clustered index data is not accessed resulting in fewer disk I/O
operations.
You can include nonkey columns in a nonclustered index to avoid exceeding the current
index size limitations of a maximum of 16 key columns and a maximum index key size of
900 bytes.
When an index contains all the columns referenced by the query it is typically
referred to as covering the query.

Identity
Syntax

IDENTITY [ ( seed , increment ) ]


You must specify both the seed and increment or neither. If neither is specified, the default is (1,1).

SET IDENTITY_INSERT
Syntax

SET IDENTITY_INSERT [ database. [ owner. ] ] { table } { ON | OFF }

Index scan VS Table scan


An Index SCAN is scanning all the rows of the table, just like a table scan -- it's just
doing so by reading index leaves, rather than the base table data itself. There's a
performance advantage to an index scan, but not because of the number of rows examined
(they're identical), but rather simply because an index tends to be much narrower than the
full table column.

Derived tables
An alternative approach for some data problems is to use derived tables, also known as
inline views. A derived table is a virtual table that is created within the scope of a query.
The table is created with a SELECT statement of its own and is given an alias using the
AS clause. It's contents can then be used within the query but become unavailable once
the query has completed. The result is similar to when you use a temporary table but does
not have the overhead of creating and dropping the temporary table and filling it with data
using INSERT and UPDATE statements.
Scope query only

Unit Testing Procedures


To unit test stored procedure all you need is your requirements and access to SQL server with
SSMS.
First analyse your requirements and figure out what is given and what is expected?
Your business requirements will have information about these. Then build a test case with
steps. To verify you may need to write SQl queries to check the data.
Choose your test data to support positive and negative testing.
Finally execute the proc and verify the results.

Table valued parameters


You can use table-valued parameters to send multiple rows of data to a Transact-SQL
statement or a routine, such as a stored procedure or function, without creating a
temporary table or many parameters.

Restrictions
Table-valued parameters have the following restrictions:

SQL Server does not maintain statistics on columns of table-valued parameters.


Table-valued parameters must be passed as input READONLY parameters to
Transact-SQL routines. You cannot perform DML operations such as UPDATE,
DELETE, or INSERT on a table-valued parameter in the body of a routine.
You cannot use a table-valued parameter as target of a SELECT INTO or INSERT
EXEC statement. A table-valued parameter can be in the FROM clause of SELECT
INTO or in the INSERT EXEC string or stored-procedure.

USE AdventureWorks2008R2;
GO
/* Create a table type. */
CREATE TYPE LocationTableType AS TABLE
( LocationName VARCHAR(50)
, CostRate INT );
GO
/* Create a procedure to receive data for the table-valued parameter. */
CREATE PROCEDURE usp_InsertProductionLocation
@TVP LocationTableType READONLY
AS
SET NOCOUNT ON
INSERT INTO [AdventureWorks2008R2].[Production].[Location]
([Name]
,[CostRate]
,[Availability]
,[ModifiedDate])

SELECT *, 0, GETDATE()
FROM @TVP;
GO
/* Declare a variable that references the type. */
DECLARE @LocationTVP
AS LocationTableType;
/* Add data to the table variable. */
INSERT INTO @LocationTVP (LocationName, CostRate)
SELECT [Name], 0.00
FROM
[AdventureWorks2008R2].[Person].[StateProvince];
/* Pass the table variable data to a stored procedure. */
EXEC usp_InsertProductionLocation @LocationTVP;
GO

New features in sql server 2008


DateTime - sql server 2008 introduces 4 new data type for date and time
1.
2.
3.
4.

Date
Time
Datetime2
Datetimeoffset

Spatial DataTypes
SQL Server 2008 introduces two spatial data types: geometry and geography.
User Defined Table Types
In SQL Server 2008, a user-defined table type is a user-defined type that represents the
definition of a table structure. You can use a user-defined table type to declare table-valued
parameters for stored procedures or functions, or to declare table variables that you want to
use in a batch or in the body of a stored procedure or function.

Table-Valued Parameters
The Database Engine introduces a new parameter type that can reference user-defined table types.
Table-valued parameters can send multiple rows of data to a SQL Server statement or routine (such
as a stored procedure or function) without creating a temporary table.

New features in sql server 2012


Throw Function
Raises an exception and transfers execution to a CATCH block of a TRYCATCH construct in SQL
Server 2012.
THROW [ { error_number | @local_variable },

{ message | @local_variable },
{ state | @local_variable } ]
[ ; ]

The statement before the THROW statement must be followed by the semicolon (;) statement
terminator.
If a TRYCATCH construct is not available, the session is ended. The line number and
procedure where the exception is raised are set. The severity is set to 16.
If the THROW statement is specified without parameters, it must appear inside a CATCH
block. This causes the caught exception to be raised. Any error that occurs in a THROW
statement causes the statement batch to be ended.

String Functions
Char(integer expression) - Converts an int ASCII code to a character.
CHARINDEX ( expression1 ,expression2 [ , start_location ] ) - Searches expression2 for

expression1 and returns its starting position if found. The search starts at start_location.
PATINDEX ( '%pattern%' , expression ) - Returns the starting position of the first occurrence of a

pattern in a specified expression, or zeros if the pattern is not found, on all valid text and
character data types.
PATINDEX is CHARINDEX + WildCard Search. Use either of them depending on your need.
SUBSTRING (value_expression ,start_expression ,length_expression ) - Returns part of a

character, binary, text, or image expression.


CAST Vs Convert Both are almost same. Cast is ansi standard
REPLACE ( string_expression , string_pattern , string_replacement ) - Replaces all
occurrences of a specified string value with another string value.
STUFF ( character_expression , start , length ,character_expression ) - The STUFF
function inserts a string into another string. It deletes a specified length of characters in the
first string at the start position and then inserts the second string into the first string at the
start position.

How to find out a column is having number or not


ISNUMERIC ( expression )- Determines whether an expression is a valid numeric type.

How to find out a column is having string or not


Use patindex - PATINDEX('%[a-z]%',column_name)

Summarizing Data Using CUBE


The CUBE operator generates a result set that is a multidimensional cube. A
multidimensional cube is an expansion of fact data, or data that records individual events.
The expansion is based on columns that the user wants to analyze. These columns are called
dimensions. The cube is a result set that contains a cross tabulation of all the possible
combinations of the dimensions.

Summarizing Data Using ROLLUP


The ROLLUP operator is useful in generating reports that contain subtotals and totals. The ROLLUP
operator generates a result set that is similar to the result sets generated by the CUBE operator.

Following are the specific differences between CUBE and ROLLUP:

CUBE generates a result set that shows aggregates for all combinations of values in
the selected columns.
ROLLUP generates a result set that shows aggregates for a hierarchy of values in the
selected columns.

The result set of a ROLLUP operation has functionality similar to that returned by a
COMPUTE BY. However, ROLLUP has the following advantages:

ROLLUP returns a single result set while COMPUTE BY returns multiple result sets
that increase the complexity of application code.
ROLLUP can be used in a server cursor while COMPUTE BY cannot.
The query optimizer can sometimes generate more efficient execution plans for
ROLLUP than it can for COMPUTE BY.

SELECT CASE WHEN (GROUPING(Item) = 1) THEN 'ALL'


ELSE ISNULL(Item, 'UNKNOWN')
END AS Item,
CASE WHEN (GROUPING(Color) = 1) THEN 'ALL'
ELSE ISNULL(Color, 'UNKNOWN')
END AS Color,
SUM(Quantity) AS QtySum
FROM Inventory
GROUP BY Item, Color WITH ROLLUP
Item
-------------------Chair
Chair
Chair
Table
Table
Table
ALL
(7 row(s) affected)

Color
-------------------Blue
Red
ALL
Blue
Red
ALL
ALL

QtySum
-------------------------101.00
210.00
311.00
124.00
223.00
347.00
658.00

If the ROLLUP keyword in the query is changed to CUBE, the CUBE result set is the same, except
these two additional rows are returned at the end:
ALL
ALL

Blue
Red

225.00
433.00

Summarizing Data Using COMPUTE and COMPUTE BY


A COMPUTE BY clause allows you to see both detail and summary rows with one SELECT
statement. You can calculate summary values for subgroups, or a summary value for the
whole result set.
USE AdventureWorks
SELECT SalesOrderID, UnitPrice, UnitPriceDiscount
FROM Sales.SalesOrderDetail
ORDER BY SalesOrderID
COMPUTE SUM(UnitPrice), SUM(UnitPriceDiscount)

--compute by
USE AdventureWorks
SELECT SalesOrderID, UnitPrice, UnitPriceDiscount
FROM Sales.SalesOrderDetail
ORDER BY SalesOrderID
COMPUTE SUM(UnitPrice), SUM(UnitPriceDiscount) BY SalesOrderID

What errors generally comes while loading data from source to


destinations

Data truncation errors


Data conversion errors
Varcahr to datetime conversion
Data integrity issues
Access issues

decimal and numeric


decimal[ (p[ ,s] )] and numeric[ (p[ ,s] )]
Fixed precision and scale numbers. When maximum precision is used, valid values are from 10^38 +1 through 10^38 - 1. The ISO synonyms for decimal are dec and dec(p, s). numeric is
functionally equivalent to decimal.
p (precision)
The maximum total number of decimal digits that will be stored, both to the left and
to the right of the decimal point. The precision must be a value from 1 through the
maximum precision of 38. The default precision is 18.

s (scale)
The number of decimal digits that will be stored to the right of the decimal point. This
number is substracted from p to determine the maximum number of digits to the left of the
decimal point. Scale must be a value from 0 through p. Scale can be specified only if
precision is specified.
Triggers
If constraints exist on the trigger table, they are checked after the INSTEAD OF trigger execution but
prior to the AFTER trigger execution. If the constraints are violated, the INSTEAD OF trigger actions
are rolled back and the AFTER trigger is not executed.
A table can have multiple AFTER triggers of a given type provided they have different names;
A table can have only one INSTEAD OF trigger of a given type
INSTEAD OF DELETE and INSTEAD OF UPDATE triggers cannot be defined on a table that has a
foreign key defined with a DELETE or UPDATE action.
A DML trigger cannot be created on a temporary or system table, although DML triggers can
reference temporary tables. System tables should not be referenced;
DDL trigger example

create trigger [backup_objects]


on database
for create_procedure, alter_procedure,
drop_procedure,
create_table, alter_table, drop_table,
create_function, alter_function, drop_function
as
BEGIN
set nocount on
declare @data xml
set @data = EVENTDATA()
insert into
siteshare3appindus.dbo.changelog(databasename,
eventtype,
objectname, objecttype, sqlcommand, loginname)
values(
@data.value('(/EVENT_INSTANCE/DatabaseName)[1]',
'varchar(256)'),
@data.value('(/EVENT_INSTANCE/EventType)[1]',
'varchar(50)'),

@data.value('(/EVENT_INSTANCE/ObjectName)[1]',
'varchar(256)'),
@data.value('(/EVENT_INSTANCE/ObjectType)[1]',
'varchar(25)'),
@data.value('(/EVENT_INSTANCE/TSQLCommand)[1]',
'varchar(max)'),
@data.value('(/EVENT_INSTANCE/LoginName)[1]',
'varchar(256)')
)
END
GO
Information about an event that fires a DDL trigger is captured by using the EVENTDATA
function. This function returns an xml value. The XML schema includes information about
the following:

The time of the event.


The System Process ID (SPID) of the connection when the trigger executed.
The type of event that fired the trigger.
IsDate()
Returns 1 if the expression is a valid date, time, or datetime value; otherwise, 0.
Select isDate()
DatePart()

select
select
select
select
select
select
select
select
select

YEAR(GETDATE())
month(GETDATE())
datepart(dd,getdate())
datepart(mm,getdate())
datepart(year,getdate())
datepart(mi,getdate()) --minutes
datepart(s,getdate()) --seconds
datepart(MILLISECOND,getdate())
datepart(MICROSECOND,getdate())

SET TRANSACTION ISOLATION LEVEL


Controls the locking and row versioning behaviour of Transact-SQL statements issued by a
connection to SQL Server.
SET TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED
| READ COMMITTED
| REPEATABLE READ
| SNAPSHOT
| SERIALIZABLE
}
[ ; ]

READ UNCOMMITTED
Specifies that statements can read rows that have been modified by other transactions
but not yet committed.
READ COMMITTED
Specifies that statements cannot read data that has been modified but not committed
by other transactions. This prevents dirty reads. Data can be changed by other
transactions between individual statements within the current transaction, resulting in
nonrepeatable reads or phantom data. This option is the SQL Server default.
SNAPSHOT
Specifies that data read by any statement in a transaction will be the transactionally
consistent version of the data that existed at the start of the transaction. The
transaction can only recognize data modifications that were committed before the start
of the transaction. Data modifications made by other transactions after the start of the
current transaction are not visible to statements executing in the current transaction.
The effect is as if the statements in a transaction get a snapshot of the committed
data as it existed at the start of the transaction.
REPEATABLE READ
Specifies that statements cannot read data that has been modified but not yet
committed by other transactions and that no other transactions can modify data that
has been read by the current transaction until the current transaction completes.
SERIALIZABLE
Specifies the following:

Statements cannot read data that has been modified but not yet committed by
other transactions.
No other transactions can modify data that has been read by the current
transaction until the current transaction completes.

Other transactions cannot insert new rows with key values that would fall in
the range of keys read by any statements in the current transaction until the
current transaction completes.
Diff. Between repeatable read and serializable

In a Repeatable Read isolation level, new rows can be inserted into the dataset.
In a Serializable isolation level all the rows are locked for the duration of the transaction, no
insert,update or delete is allowed.

Define candidate key, alternate key, and composite key.


A candidate key is one that can identify each row of a table uniquely. Generally a candidate key
becomes the primary key of the table. If the table has more than one candidate key, one of them will
become the primary key, and the rest are called alternate keys. A key formed by combining at least
two or more columns is called composite key.
1. created job to know the fragmentation of indices
2. Used dmvs
3. used sql server profiler and database tuning adviser
4. Rewritten queries
5. Analysed execution plans

1.Monitoring and Tuning for Performance Overview


To monitor any component of SQL Server effectively, follow these steps:
1.
2.
3.
4.
5.
6.

Determine your monitoring goals.


Select the appropriate tool.
Identify components to monitor.
Select metrics for those components.
Monitor the server.
Analyze the data.
2.Tools for Performance Monitoring and Tuning

2.1 sp_trace_setfilter
2.2 Monitoring Resource Usage (Performance Monitor)
When you monitor SQL Server and the Microsoft Windows operating system to investigate
performance-related issues, concentrate your initial efforts in three main areas:
A.
B.

Disk activity
Processor utilization

C.

Memory usage

A. Disk activity Monitoring disk activity involves two areas of focus:

Monitoring Disk I/O and Detecting Excess Paging


Isolating Disk Activity That SQL Server Creates

Monitoring Disk I/O and Detecting Excess Paging


Two counters that can be monitored to determine disk activity are:

PhysicalDisk: % Disk Time


PhysicalDisk: Avg. Disk Queue Length

In System Monitor, the PhysicalDisk: % Disk Time counter monitors the percentage of time
that the disk is busy with read/write activity. If the PhysicalDisk: % Disk Time counter is
high (more than 90 percent), check the PhysicalDisk: Current Disk Queue Length counter
to see how many system requests are waiting for disk access. The number of waiting I/O
requests should be sustained at no more than 1.5 to 2 times the number of spindles that make
up the physical disk. Most disks have one spindle, although redundant array of independent
disk (RAID) devices usually have more than one spindle. A hardware RAID device appears
as one physical disk in System Monitor. RAID devices created through software appear as
multiple instances in System Monitor.
Use the values of the Current Disk Queue Length and % Disk Time counters to detect
bottlenecks within the disk subsystem. If Current Disk Queue Length and % Disk Time
counter values are consistently high, consider doing one of the following:

Using a faster disk drive.


Moving some files to an additional disk or server.
Adding disks to a RAID array, if one is being used.

If you are using a RAID device, the % Disk Time counter can indicate a value greater than
100 percent. If it does, use the PhysicalDisk: Avg. Disk Queue Length counter to determine
how many system requests, on average, are waiting for disk access.
Applications and systems that are I/O-bound may keep the disk constantly active.
Monitor the Memory: Page Faults/sec counter to make sure that the disk activity is not
caused by paging. In Windows, paging is caused by:

Processes configured to use too much memory.


File system activity.

If you have more than one logical partition on the same hard disk, use the Logical Disk
counters rather than the Physical Disk counters. Look at the logical disk counters to help
determine which files are frequently accessed. After you have found the disks with high
levels of read/write activity, look at the read-specific and write-specific counters to learn the

type of disk activity that causes the load on each logical volume; for example, Logical Disk:
Disk Write Bytes/sec.
Isolating Disk Activity Created by SQL Server
Two counters that can be monitored to determine the amount of I/O generated by SQL Server
components are:

SQL Server:Buffer Manager:Page reads/sec


SQL Server:Buffer Manager:Page writes/sec

In System Monitor, these counters monitor the amount of I/O generated by SQL Server
components by examining the following performance areas:

Writing pages to disk


Reading pages from disk

If the values for these counters approach the capacity limit of the hardware I/O subsystem, try
to reduce the values by tuning your application or database to reduce I/O operations (such as
index coverage, better indexes, or normalization), increasing the I/O capacity of the
hardware, or adding memory. For example, you can use Database Engine Tuning Advisor to
analyze typical SQL Server workloads and produce recommendations for indexes, indexed
views, and partitioning to improve server performance.
B. Monitoring CPU Usage
An efficient way to determine CPU usage is to use the Processor:% Processor Time counter
in System Monitor. This counter monitors the amount of time the CPU spends executing a
thread that is not idle. A consistent state of 80 percent to 90 percent may indicate the need to
upgrade your CPU or add more processors. For multiprocessor systems, monitor a separate
instance of this counter for each processor. This value represents the sum of processor time
on a specific processor. To determine the average for all processors, use the System: %Total
Processor Time counter instead.
Optionally, you can also monitor the following counters to monitor processor usage:

Processor: % Privileged Time


Corresponds to the percentage of time the processor spends on execution of Microsoft
Windows kernel commands, such as processing of SQL Server I/O requests. If this
counter is consistently high when the Physical Disk counters are high, consider
installing a faster or more efficient disk subsystem.
Note
Different disk controllers and drivers use different amounts of kernel processing time.
Efficient controllers and drivers use less privileged time, leaving more processing
time available for user applications, increasing overall throughput.

Processor: %User Time

Corresponds to the percentage of time that the processor spends on executing user
processes such as SQL Server.

System: Processor Queue Length


Corresponds to the number of threads waiting for processor time. A processor
bottleneck develops when threads of a process require more processor cycles than are
available. If more than a few processes attempt to utilize the processor's time, you
might need to install a faster processor. Or, if you have a multiprocessor system, you
could add a processor.

When you examine processor usage, consider the type of work that the instance of SQL
Server performs. If SQL Server performs many calculations, such as queries involving
aggregates or memory-bound queries that require no disk I/O, 100 percent of the processor's
time can be used. If this causes the performance of other applications to suffer, try changing
the workload. For example, dedicate the computer to running the instance of SQL Server.
C. Monitoring Memory Usage
By default, SQL Server changes its memory requirements dynamically, on the basis of
available system resources. If SQL Server needs more memory, it queries the operating
system to determine whether free physical memory is available and uses the available
memory. If SQL Server does not need the memory currently allocated to it, it releases the
memory to the operating system. However, you can override the option to dynamically use
memory by using the min server memory, and max server memory server configuration
options. For more information, see Server Memory Options.
To monitor the amount of memory that SQL Server uses, examine the following performance
counters:

Process: Working Set


SQL Server: Buffer Manager: Buffer Cache Hit Ratio
SQL Server: Buffer Manager: Total Pages
SQL Server: Memory Manager: Total Server Memory (KB)

The Working Set counter shows the amount of memory that is used by a process. If this
number is consistently below the amount of memory that is set by the min server memory
and max server memory server options, SQL Server is configured to use too much memory.
The Buffer Cache Hit Ratio counter is specific to an application. However, a rate of 90
percent or higher is desirable. Add more memory until the value is consistently greater than
90 percent. A value greater than 90 percent indicates that more than 90 percent of all requests
for data were satisfied from the data cache.
Buffer Cache Hit Ratio - Indicates the percentage of pages found in the buffer cache
without having to read from disk.
Page life
expectancy

Indicates the number of seconds a page will stay in the buffer pool
without references.

If the Total Server Memory (KB) counter is consistently high compared to the amount of
physical memory in the computer, it may indicate that more memory is required.
Creating a SQL Server Database Alert
You can use System Monitor to create an alert that is raised when a threshold value for a
System Monitor counter has been reached. In response to the alert, System Monitor launches
an application, such as a custom application written to handle the alert condition. For
example, you could create an alert that is raised when the number of deadlocks exceeds a
specific value
3. System stored procedures
Sp_who
Provides information about current users, sessions, and processes in an instance of the
Microsoft SQL Server Database Engine. The information can be filtered to return only those
processes that are not idle, that belong to a specific user, or that belong to a specific session.
sp_who [ [ @loginame = ] 'login' | session ID | 'ACTIVE' ]

sp_who returns a result set with the following information.


Spid, status(process status), loginname, hostname, blk(session id for the blocking process),
dbname
A blocking process, which may have an exclusive lock, is one that is holding resources that
another process needs.
In SQL Server 2000 and later, all orphaned distributed transactions are assigned the session
ID value of '-2'. Orphaned distributed transactions are distributed transactions that are not
associated with any session ID.
Examples
EXEC sp_who 'active';
EXEC sp_who 'janetl';
EXEC sp_who;

Sp_monitor
Displays statistics about Microsoft SQL Server like total_read (number of reads by sql
server),total_writr(number of writes by sql server),cpu_busy(Number of seconds that the
server computer's CPU has been doing SQL Server work.),io_busy(Number of seconds that
SQL Server has spent doing input and output operations.).
4.Database Engine Tuning Advisor

Database Engine Tuning Advisor is a tool that analyzes the performance effects of workloads
run against one or more databases. A workload is a set of Transact-SQL statements that
executes against databases you want to tune. After analyzing the effects of a workload on
your databases, Database Engine Tuning Advisor provides recommendations to add, remove,
or modify physical design structures in Microsoft SQL Server databases. These physical
performance structures include clustered indexes, nonclustered indexes, indexed views, and
partitioning. When implemented, Database Engine Tuning Advisor recommendations enable
the query processor to perform workload tasks in the shortest amount of time.

Isolating Performance Problems


SQL Server Profiler can be used to monitor and troubleshoot Transact-SQL and applicationrelated problems. System Monitor can be used to monitor hardware and other system-related
problems.
You can monitor the following areas to troubleshoot problems:

SQL Server stored procedures or batches of Transact-SQL statements submitted by


user applications.
User activity, such as blocking locks or deadlocks.
Hardware activity, such as disk usage.

Problems can include:

Application development errors involving incorrectly written Transact-SQL


statements.
Hardware errors, such as disk- or network-related errors.
Excessive blocking due to an incorrectly designed database.
Following are five key areas to monitor when tracking server performance to identify
bottlenecks.

Identifying Bottlenecks
Possible
bottleneck
area

Effects on the server

Insufficient memory allocated or available to Microsoft SQL Server degrades


performance. Data must be read from the disk rather than directly from the
Memory usage
data cache. Microsoft Windows operating systems perform excessive paging
by swapping data to and from the disk as the pages are needed.
CPU
A chronically high CPU utilization rate may indicate that Transact-SQL
utilization
queries need to be tuned or that a CPU upgrade is needed.
Disk
Transact-SQL queries can be tuned to reduce unnecessary I/O; for example,
input/output
by employing indexes.
(I/O)
User
Too many users may be accessing the server simultaneously causing

connections

performance degradation.
Incorrectly designed applications can cause locks and hamper concurrency,
Blocking locks
thus causing longer response times and lower transaction throughput rates.
Deadlocking
A deadlock occurs when two or more tasks permanently block each other by each task having
a lock on a resource which the other tasks are trying to lock. For example:

Transaction A acquires a share lock on row 1.


Transaction B acquires a share lock on row 2.
Transaction A now requests an exclusive lock on row 2, and is blocked until
transaction B finishes and releases the share lock it has on row 2.
Transaction B now requests an exclusive lock on row 1, and is blocked until
transaction A finishes and releases the share lock it has on row 1.

Transaction A cannot complete until transaction B completes, but transaction B is blocked by


transaction A. This condition is also called a cyclic dependency: Transaction A has a
dependency on transaction B, and transaction B closes the circle by having a dependency on
transaction A.
Both transactions in a deadlock will wait forever unless the deadlock is broken by an external
process. The Microsoft SQL Server Database Engine deadlock monitor periodically
checks for tasks that are in a deadlock. If the monitor detects a cyclic dependency, it chooses
one of the tasks as a victim and terminates its transaction with an error. This allows the other
task to complete its transaction. The application with the transaction that terminated with an
error can retry the transaction, which usually completes after the other deadlocked transaction
has finished.
Minimizing Deadlocks
Although deadlocks cannot be completely avoided, following certain coding conventions can
minimize the chance of generating a deadlock.
To help minimize deadlocks:

Access objects in the same order.


Avoid user interaction in transactions.
Keep transactions short and in one batch.
Use a lower isolation level.

SQL Statement Processing


The basic steps that SQL Server uses to process a single SELECT statement include the
following:

1. The parser scans the SELECT statement and breaks it into logical units such as
keywords, expressions, operators, and identifiers.
2. A query tree, sometimes referred to as a sequence tree, is built describing the logical
steps needed to transform the source data into the format required by the result set.
3. The query optimizer analyzes different ways the source tables can be accessed. It then
selects the series of steps that returns the results fastest while using fewer resources.
The query tree is updated to record this exact series of steps. The final, optimized
version of the query tree is called the execution plan.
4. The relational engine starts executing the execution plan. As the steps that require
data from the base tables are processed, the relational engine requests that the storage
engine pass up data from the rowsets requested from the relational engine.
5. The relational engine processes the data returned from the storage engine into the
format defined for the result set and returns the result set to the client.

Optimizing SELECT Statements


A SELECT statement is nonprocedural; it does not state the exact steps that the database
server should use to retrieve the requested data. This means that the database server must
analyze the statement to determine the most efficient way to extract the requested data. This
is referred to as optimizing the SELECT statement. The component that does this is called the
query optimizer. The input to the optimizer consists of the query, the database schema (table
and index definitions), and the database statistics. The output of the optimizer is a query
execution plan, sometimes referred to as a query plan or just a plan. The contents of a query
plan are described in more detail later in this topic.
The inputs and outputs of the query optimizer during optimization of a single SELECT
statement are illustrated in the following diagram:

A SELECT statement defines only the following:

The format of the result set. This is specified mostly in the select list. However, other
clauses such as ORDER BY and GROUP BY also affect the final form of the result
set.
The tables that contain the source data. This is specified in the FROM clause.
How the tables are logically related for the purposes of the SELECT statement. This
is defined in the join specifications, which may appear in the WHERE clause or in an
ON clause following FROM.
The conditions that the rows in the source tables must satisfy to qualify for the
SELECT statement. These are specified in the WHERE and HAVING clauses.

A query execution plan is a definition of the following:

The sequence in which the source tables are accessed.


Typically, there are many sequences in which the database server can access the base
tables to build the result set. For example, if the SELECT statement references three
tables, the database server could first access TableA, use the data from TableA to
extract matching rows from TableB, and then use the data from TableB to extract
data from TableC. The other sequences in which the database server could access the
tables are:
TableC, TableB, TableA, or
TableB, TableA, TableC, or
TableB, TableC, TableA, or
TableC, TableA, TableB

The methods used to extract data from each table.


Generally, there are different methods for accessing the data in each table. If only a
few rows with specific key values are required, the database server can use an index.
If all the rows in the table are required, the database server can ignore the indexes and
perform a table scan. If all the rows in a table are required but there is an index whose
key columns are in an ORDER BY, performing an index scan instead of a table scan
may save a separate sort of the result set. If a table is very small, table scans may be
the most efficient method for almost all access to the table.

The process of selecting one execution plan from potentially many possible plans is referred
to as optimization. The query optimizer is one of the most important components of a SQL
database system. While some overhead is used by the query optimizer to analyze the query
and select a plan, this overhead is typically saved several-fold when the query optimizer picks
an efficient execution plan. For example, two construction companies can be given identical
blueprints for a house. If one company spends a few days at the beginning to plan how they
will build the house, and the other company begins building without planning, the company
that takes the time to plan their project will probably finish first.
The SQL Server query optimizer is a cost-based optimizer. Each possible execution plan has
an associated cost in terms of the amount of computing resources used. The query optimizer
must analyze the possible plans and choose the one with the lowest estimated cost. Some
complex SELECT statements have thousands of possible execution plans. In these cases, the
query optimizer does not analyze all possible combinations. Instead, it uses complex
algorithms to find an execution plan that has a cost reasonably close to the minimum possible
cost.
The SQL Server query optimizer does not choose only the execution plan with the lowest
resource cost; it chooses the plan that returns results to the user with a reasonable cost in
resources and that returns the results the fastest. For example, processing a query in parallel
typically uses more resources than processing it serially, but completes the query faster. The

SQL Server optimizer will use a parallel execution plan to return results if the load on the
server will not be adversely affected.
The query optimizer relies on distribution statistics when it estimates the resource costs of
different methods for extracting information from a table or index. Distribution statistics are
kept for columns and indexes. They indicate the selectivity of the values in a particular index
or column. For example, in a table representing cars, many cars have the same manufacturer,
but each car has a unique vehicle identification number (VIN). An index on the VIN is more
selective than an index on the manufacturer. If the index statistics are not current, the query
optimizer may not make the best choice for the current state of the table.

Query Tuning

Locking and Row Versioning


The SQL Server Database Engine uses the following mechanisms to ensure the integrity of
transactions and maintain the consistency of databases when multiple users are accessing data
at the same time:

Locking
Each transaction requests locks of different types on the resources, such as rows,
pages, or tables, on which the transaction is dependent. The locks block other
transactions from modifying the resources in a way that would cause problems for the
transaction requesting the lock. Each transaction frees its locks when it no longer has
a dependency on the locked resources.

Row versioning
When a row versioning-based isolation level is enabled, the Database Engine
maintains versions of each row that is modified. Applications can specify that a
transaction use the row versions to view data as it existed at the start of the transaction

or query instead of protecting all reads with locks. By using row versioning, the
chance that a read operation will block other transactions is greatly reduced.
Locking and row versioning prevent users from reading uncommitted data and prevent
multiple users from attempting to change the same data at the same time. Without locking or
row versioning, queries executed against that data could produce unexpected results by
returning data that has not yet been committed in the database.
Users can control row versioning implementation by enabling or disabling database options.
1.1 Managing Concurrent Data Access
Concurrency Effects
If a data storage system has no concurrency control, users could see the following side
effects:

Lost updates

Lost updates occur when two or more transactions select the same row and then update the
row based on the value originally selected. Each transaction is unaware of the other
transactions. The last update overwrites updates made by the other transactions, which results
in lost data.

Uncommitted dependency (dirty read)


occurs when a second transaction selects a row that is being updated by another
transaction. The second transaction is reading data that has not been committed yet
and may be changed by the transaction updating the row.Inconsistent analysis
(nonrepeatable read)

Nonrepeatable read
Inconsistent analysis occurs when a second transaction accesses the same row several
times and reads different data each time. Inconsistent analysis is similar to
uncommitted dependency in that another transaction is changing the data that a
second transaction is reading. However, in inconsistent analysis, the data read by the
second transaction was committed by the transaction that made the change. Also,
inconsistent analysis involves multiple reads (two or more) of the same row, and each
time the information is changed by another transaction; thus, the term nonrepeatable
read.

Phantom reads
Phantom reads occur when an insert or delete action is performed against a row that
belongs to a range of rows being read by a transaction. The transaction's first read of
the range of rows shows a row that no longer exists in the second or succeeding read
as a result of a deletion by a different transaction. Similarly, the transaction's second

or succeeding read shows a row that did not exist in the original read as the result of
an insertion by a different transaction.

Missing and double reads caused by row updates

1.2 Types of Concurrency Control


When many people attempt to modify data in a database at the same time, a system of
controls must be implemented so that modifications made by one person do not adversely
affect those of another person. This is called concurrency control.
Concurrency control theory has two classifications for the methods of instituting concurrency
control:

Pessimistic concurrency control


A system of locks prevents users from modifying data in a way that affects other
users. After a user performs an action that causes a lock to be applied, other users
cannot perform actions that would conflict with the lock until the owner releases it.
This is called pessimistic control because it is mainly used in environments where
there is high contention for data, where the cost of protecting data with locks is less
than the cost of rolling back transactions if concurrency conflicts occur.

Optimistic concurrency control


In optimistic concurrency control, users do not lock data when they read it. When a
user updates data, the system checks to see if another user changed the data after it
was read. If another user updated the data, an error is raised. Typically, the user
receiving the error rolls back the transaction and starts over. This is called optimistic
because it is mainly used in environments where there is low contention for data, and
where the cost of occasionally rolling back a transaction is lower than the cost of
locking data when read.

1.3 Isolation Levels in the Database Engine


Transaction isolation levels control:

Whether locks are taken when data is read, and what type of locks are requested.
How long the read locks are held.
Whether a read operation referencing rows modified by another transaction:
o Blocks until the exclusive lock on the row is freed.
o Retrieves the committed version of the row that existed at the time the
statement or transaction started.
o Reads the uncommitted data modification.

Choosing a transaction isolation level does not affect the locks acquired to protect data
modifications. A transaction always gets an exclusive lock on any data it modifies, and holds
that lock until the transaction completes, regardless of the isolation level set for that
transaction. For read operations, transaction isolation levels primarily define the level of
protection from the effects of modifications made by other transactions.

A lower isolation level increases the ability of many users to access data at the same time, but
increases the number of concurrency effects (such as dirty reads or lost updates) users might
encounter. Conversely, a higher isolation level reduces the types of concurrency effects that
users may encounter, but requires more system resources and increases the chances that one
transaction will block another. Choosing the appropriate isolation level depends on balancing
the data integrity requirements of the application against the overhead of each isolation level.
The highest isolation level, serializable, guarantees that a transaction will retrieve exactly the
same data every time it repeats a read operation, but it does this by performing a level of
locking that is likely to impact other users in multi-user systems. The lowest isolation level,
read uncommitted, may retrieve data that has been modified but not committed by other
transactions. All of the concurrency side effects can happen in read uncommitted, but there is
no read locking or versioning, so overhead is minimized.
The ISO standard defines the following isolation levels, all of which are supported by the
SQL Server Database Engine:

Read uncommitted (the lowest level where transactions are isolated only enough to
ensure that physically corrupt data is not read)
Read committed (Database Engine default level)
Repeatable read
Serializable (the highest level, where transactions are completely isolated from one
another)
The following table shows the concurrency side effects enabled by the different
isolation levels.

Isolation level
Read uncommitted
Read committed
Repeatable read
Snapshot
Serializable

Dirty read
Yes
No
No
No
No

Nonrepeatable read
Yes
Yes
No
No
No

Phantom
Yes
Yes
Yes
No
No

Lock Modes
The following table shows the resource lock modes that the Database Engine uses.
Lock mode

Description
Used for read operations that do not change or update data, such as a SELECT
Shared (S)
statement.
Used on resources that can be updated. Prevents a common form of deadlock
Update (U) that occurs when multiple sessions are reading, locking, and potentially
updating resources later.
Used for data-modification operations, such as INSERT, UPDATE, or
Exclusive
DELETE. Ensures that multiple updates cannot be made to the same resource at
(X)
the same time.
Intent
Used to establish a lock hierarchy. The types of intent locks are: intent shared

Schema

(IS), intent exclusive (IX), and shared with intent exclusive (SIX).
Used when an operation dependent on the schema of a table is executing. The
types of schema locks are: schema modification (Sch-M) and schema stability
(Sch-S).

Bulk
Update
(BU)

Used when bulk copying data into a table and the TABLOCK hint is specified.

Key-range

Protects the range of rows read by a query when using the serializable
transaction isolation level. Ensures that other transactions cannot insert rows
that would qualify for the queries of the serializable transaction if the queries
were run again.

Shared (S) locks allow concurrent transactions to read (SELECT) a resource under
pessimistic concurrency control. No other transactions can modify the data while shared (S)
locks exist on the resource.
Update (U) locks prevent a common form of deadlock. In a repeatable read or serializable
transaction, the transaction reads data, acquiring a shared (S) lock on the resource (page or
row), and then modifies the data, which requires lock conversion to an exclusive (X) lock. If
two transactions acquire shared-mode locks on a resource and then attempt to update data
concurrently, one transaction attempts the lock conversion to an exclusive (X) lock. The
shared-mode-to-exclusive lock conversion must wait because the exclusive lock for one
transaction is not compatible with the shared-mode lock of the other transaction; a lock wait
occurs. The second transaction attempts to acquire an exclusive (X) lock for its update.
Because both transactions are converting to exclusive (X) locks, and they are each waiting for
the other transaction to release its shared-mode lock, a deadlock occurs.
To avoid this potential deadlock problem, update (U) locks are used. Only one transaction
can obtain an update (U) lock to a resource at a time. If a transaction modifies a resource, the
update (U) lock is converted to an exclusive (X) lock.
Exclusive (X) locks prevent access to a resource by concurrent transactions. With an
exclusive (X) lock, no other transactions can modify data; read operations can take place only
with the use of the NOLOCK hint or read uncommitted isolation level.
Lock Compatibility
Lock compatibility controls whether multiple transactions can acquire locks on the same
resource at the same time. If a resource is already locked by another transaction, a new lock
request can be granted only if the mode of the requested lock is compatible with the mode of
the existing lock. If the mode of the requested lock is not compatible with the existing lock,
the transaction requesting the new lock waits for the existing lock to be released or for the
lock timeout interval to expire. For example, no lock modes are compatible with exclusive
locks. While an exclusive (X) lock is held, no other transaction can acquire a lock of any kind
(shared, update, or exclusive) on that resource until the exclusive (X) lock is released.
Alternatively, if a shared (S) lock has been applied to a resource, other transactions can also
acquire a shared lock or an update (U) lock on that item even if the first transaction has not

completed. However, other transactions cannot acquire an exclusive lock until the shared lock
has been released.
http://technet.microsoft.com/en-us/library/ms184286%28v=sql.105%29.aspx

Importing and Exporting Bulk data


BCP The bcp utility (Bcp.exe) is a command-line tool that uses the Bulk Copy Program (BCP)
API. The bcp utility performs the following tasks:

Bulk exports data from a SQL Server table into a data file.
Bulk exports data from a query.
Bulk imports data from a data file into a SQL Server table.
Generates format files.

The bcp utility is accessed by the bcp command.


bcp {[[database_name.][schema].]{table_name | view_name} | "query"}
{in | out | queryout | format} data_file
[-m max_errors] [-f format_file] [-x] [-e err_file]
[-F first_row] [-L last_row] [-b batch_size]
[-d database_name] [-n] [-c] [-N] [-w] [-V (70 | 80 | 90 )]
[-q] [-C { ACP | OEM | RAW | code_page } ] [-t field_term]
[-r row_term] [-i input_file] [-o output_file] [-a packet_size]
[-S [server_name[\instance_name]]] [-U login_id] [-P password]
[-T] [-v] [-R] [-k] [-E] [-h"hint [,...n]"]

bcp vtt_site_data out G:\BCP_data\dbo.vtt_site_data_2 -S 10.240.20.155 -U isq_read -P


tarantula@1 n
-n
Performs the bulk-copy operation using the native (database) data types of the data.
This option does not prompt for each field; it uses the native values.
-T
Specifies that the bcp utility connects to SQL Server with a trusted connection using
integrated security. The security credentials of the network user, login_id, and
password are not required. If T is not specified, you need to specify U and P to
successfully log in.
-E
Specifies that identity value or values in the imported data file are to be used for the
identity column. If -E is not given, the identity values for this column in the data file
being imported are ignored, and SQL Server automatically assigns unique values
based on the seed and increment values specified during table creation.

Bulk Insert statement


BULK INSERT loads data from a data file into a table. This functionality is similar to that
provided by the in option of the bcp command; however, the data file is read by the SQL
Server process.
BULK INSERT AdventureWorks2008R2.Sales.SalesOrderDetail
FROM 'f:\orders\lineitem.tbl'
WITH
(
FIELDTERMINATOR =' |',
ROWTERMINATOR =' |\n'
)

BULK INSERT or OPENROWSET(BULK...)


The OPENROWSET bulk rowset provider is accessed by calling the OPENROWSET
function and specifying the BULK option. The OPENROWSET(BULK) function allows
you to access remote data by connecting to a remote data source, such as a data file, through
an OLE DB provider.
To bulk import data, call OPENROWSET(BULK) from a SELECTFROM clause within
an INSERT statement. The basic syntax for bulk importing data is:
INSERT ... SELECT * FROM OPENROWSET(BULK...)

SSIS
1.
2.
3.
4.

control flow
data flow
event handler
package explorer

SDLC

Project planning, feasibility study: Establishes a high-level view of the intended


project and determines its goals.
Systems analysis, requirements definition: Refines project goals into defined
functions and operation of the intended application. Analyzes end-user information
needs.
Systems design: Describes desired features and operations in detail, including screen
layouts, business rules, process diagrams, pseudocode and other documentation.
Implementation: The real code is written here.
Integration and testing: Brings all the pieces together into a special testing
environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where
the software is put into production and runs actual business.
Maintenance: What happens during the rest of the software's life: changes,
correction, additions, moves to a different computing platform and more. This, the
least glamorous and perhaps most important step of all, goes on seemingly forever.

What is the purpose of using SET ANSI NULLS ON?


The purpose of using SET ANSI_NULLS ON to follow the ISO Standard. Acording to this =
and <> should not be used for null comparison. Instead we use null and is not null how ever
if you will use = null it will return zero rows. If we want to use = or <> for null comparison
use SET ANSI_NULLS OFF it means do not follow ISO Standard. SET ANSI_NULLS
should be set to ON for executing distributed queries for maintaining compatibility of queries
across Servers.
Difference between cluster and non cluster index in sql?
A clustered index is a special type of index that reorders the way records in the table are
physically stored. Therefore table can have only one clustered index. The leaf nodes of a
clustered index contain the data pages.
A non clustered index is a special type of index in which the logical order of the index does
not match the physical stored order of the rows on disk. The leaf node of a non clustered
index does not consist of the data pages. Instead, the leaf nodes contain index rows.
Can we create non primary key as cluster index?
Yes we can do this on non-primary key column but that column must be unique and the
primary key column of that table must have non-clustered index because there is one cluster
index in table. By default primary key column contains clustered index so its recommended
to create such non-primary key clustered index column first and then should create primary
key column so in such case the primary key on that column will be with non-clustered. But its
highly recommended to create primary key column as a clustered indexed column.
Can we call a Trigger in store procedure?
A Trigger is also a special kind of Stored Procedure which will fire automatically on the
happening of an event like before or after insert, update or delete. We cannot call a trigger
explicitly from a Stored Procedure.
Difference Between GETDATE and SYSDATETIME?
When we use GETDATE the precision is till miliseconds and in case of SYSDATETIME the
precision is till nanoseconds.

Get top two records without Top keyword.


[SQL]
set rowcount 2
select Column1, Column2 from TableName

Difference between Set and Select.


-Set is a ANSI standard for variable assignment. It assigns value to only one variable at a
time.
-Select is a Non-ANSI standard when assigning variables. It assigns multiple variable at a
time.
-When assigning from a query that returns more than one value, SET will fail with an error.
-When assigning from a query that returns more than one value, SELECT will assign the last
value returned by the query and hide the fact that the query returned more than one row.
How to get number of Maximum connection can be establish to SQL?
select @@MAX_Connections
Why we use SET ROWCOUNT in Sql?
This syntax is used in SQL Server to stop processing the query after the specified number of
rows are returned.
What are the Global Temporary Tables?
We can create global temporary tables but these are not using much in sql an the name of
these table start with two pound signs. For example, ##globaltbl is a global temporary table.
As the name suggest these table is Global temporary tables and visible to all SQL Server
connections. When we create any one of these all users can see it.
What is a View in SQL?
View is just a virtual table nothing else which is based or we can say develop with SQL
SELECT query.So we can say that its a real database table (it has columns and rows just like
a regular table),but one difference is that real tables store data, but views can''t. View data is
generated dynamically when the view is referenced. And view can also references one or
more existing database tables or other views. We can say that it is filter of database.
Why Group BY and Order By clause are so expensive?
Both Group By and Order By clause requires Temporary table to process the result of query
so these are expensive.
What is the use of SET NOCOUNT ON?
When we use SELECT and DML statement in SQL. SQL server return a message which
specify the number of rows effected by these statements. This information helps coder when
they are debugging the code other wise this is not useful we can disable this by typing SET
NOCOUNT ON. It is very helpful when we are doing on store procedure contains lots of
statements, loops its also increase in performance and boost network traffic.
What are the differences between SQL and PL/SQL?
We can get modify, Retrieve by single command or statement in SQL but PL/SQL process all
SQL statements one at a time. With PL/SQL, an entire block of statement process in a single
command line. SQL is structured query language, various queries are used to handle the

database in a simplified manner. While PL/SQL is procedural language contains various


types of variables, functions and procedures and other major diffrence is Sql as the name
suggest it is just structured query language wheareas PLSQL is a combination of
Programming language & SQL.
What is a join? List different types of joins
Joins are used in queries to explain how different tables are related. Joins also let you select
data from a table depending upon data from another table.
Types of joins:
-INNER JOIN
-OUTER JOIN (OUTER JOIN is further classified as LEFT OUTER JOINS, RIGHT
OUTER JOINS and FULL OUTER JOINS)
-CROSS JOINs
What is a Cursor?
Cursor is a database object used by applications to manipulate data in a set on a row-by-row
basis, instead of the typical SQL commands that operate on all the rows in the set at one time.
For example, you can use cursor to include a list of all user databases and make multiple
operations against each database by passing each database name as a variable.
Difference between stored procedure and user defined function
1>Procedure can return zero or n values whereas function can return one value which is
mandatory.
2>Procedures can have input, output parameters for it whereas functions can have only input
parameters.
3>Procedure allow select as well as DML statement in it whereas function allow only select
statement in it.
4>Functions can be called from procedure whereas procedures cannot be called from
function.
5>Exception can be handled by try-catch block in a procedure whereas try-catch block cannot
be used in a function.
6>We can go for transaction management in procedure whereas we can''t go in function.
7>Procedures can not be utilized in a select statement whereas function can be embedded in a
select statement.

Table variables can not have Non-Clustered Indexes


You can not create constraints in table variables
You can not create default values on table variable columns
Statistics can not be created against table variables

Similarities with temporary tables include:

Instantiated in tempdb
Clustered indexes can be created on table variables and temporary tables
Both are logged in the transaction log

Just as with temp and regular tables, users can perform all Data Modification Language
(DML) queries against a table variable: SELECT, INSERT, UPDATE, and DELETE.

Potrebbero piacerti anche