SQL Server 2008

DDL (Create/ Alter/ Drop/ Truncate) Top/ Apply

Data type Distinct/ All
Data Conversion Set operation
Constraints Sub-query
Temporary table CTE
Indexing
T-SQL Programming
DML (Insert/ Update/ Delete/ Merge) Cursor
Transaction, Locking and Blocking View
Bulk operation UDF
Variable and statement Procedure
Error Handling Trigger

DQL (Select) Advance Topic

Operator Query Tuning and optimization
Expression Distributed query
Null Full text search
Ranking function CLR
Ordering XML
Scalar function Service Broker
Aggregation and Pivoting File stream
Crosstab query Spatial Data
Join
Introduction
Q: Why is SQL pronounced “sequel?”
A: SQL is a descendant of IBM’s “SEQUEL” language. The pronunciation came from
this early name.

Q: Why SQL is called declarative language?

A: This mean that the sql query logically describes the question to the sql optimizer,
which then determines the best method to physically execute the query.

Q: SQL Server vs. Oracle

A: SQL Server is cheaper to buy than oracle
SQL server is easier to manage and install
Oracle support all known platform
SQL server connect multiple database whereas oracle connect single
PL/SQL is more powerful than T-SQL

T-SQL PL/SQL
Max. column per table 1024 1000
Max. table row length 8036 255000
Recursive subquery 40 64
Array Support No Yes

Q: Access vs. SQL Server

A: ->Access usage file server design and sql server usage the client/server model
->Reliability from file corruption, huge load demand, high transaction and
Supported by sql server
->In terms of cost and support Access is better

Q: What are the major difference between earlier version of sql server and current
version?
A: BI Tools, .Net Integration, Data partitioning and Mirroring

Q: What is Data Warehousing?

A: Data warehousing is combining data from multiple and usually varied sources into
one comprehensive and easily manipulated database.

Q: What is the new feature in sql server 2008?

A: SQL Server 2008 has many new features for the DBA, Database and BI developer.

DBA Enhancement:
- >New Installation center with different look and feel
->Compressed backup: since less data is being written to the disk, backup time is
usually reduced (priory this option was available for TPV such as Red Gate, Quest.
->Enhanced Configuration and Management of Audits using the new Change Data
Capture (CDC) feature. This new feature makes tracking down changes and auditing
much easier than it has been in the past.
->New table value parameter: The new table type can be passed to a stored procedure.
->File Stream data type: database engine will store all of the data associated with the
column in a disk file as opposed to the actual database.
->Sparse column support
->Encryption enhancement: Transparent data encryption (TDE) is available as opposed
to TPV such as NetLib. Also key management and encryption
->New high availability feature like hot add CPU and hot add memory. Also new failover
clustering enhancement is available.
->Internal Performance enhancement
->Performance data management tools
->Resource Governor is a nice new feature to help manage workload by limiting the
resources available to a process.
->Plan freezing is meant to offer greater predictability when it comes to executing a
particular query in SQL Server 2008.
->Declarative Management Framework (DMF). This is basically a new policy-based
management system for SQL Server 2008.

Developer Enhancement:
->LINQ Support: It’s basically a mapping of the database object to programming objects
->Merge Statement
->The MERGE statement performs insert, update, or delete operations on a target table
based on the results of a join to a source table.
->Spatial data type for storing location based data.

BI Enhancement:
->better cube designer, an improved dimension and attribute designer, and enhanced
data mining structures.
->Able to script in c# as well
->In SSRS the configuration has changed; for example, it now supports rich text format.
->SharePoint integration Reporting Services now will integrate closely with Microsoft
SharePoint.
->No longer require IIS.
->Export to word support
->Better graphing

Q: Will backup compression take longer to complete?

A: The answer to this is complicated. In general, the disk is the bottleneck, so in most
cases, backup compression will actually speed up your backups.

Q: We use an application that uses SQL 2005 DMVs. Will it work with SQL 2008?
A: For the most part the DMVs remain intact. However, you should test your application
to be certain.
Q: Using the Resource Governor, is it possible to limit the resources for a
particular application?
A: Yes, you would need to create a CLASSIFIER function that tests each new session
to see if the APP_NAME( ) is the name of the application you wish to limit. For sessions
with your applications name, the function should return the name of the Workload Group
to you along with the application to be associated with.
Data type

Q: What data type available in SQL Server 2008?

Numeric Character Dates and Times Other

Tinyint Char Datetime Binary
Smallint Nchar Smalldatetime Bit
Int Varchar Date Cursor
Bigint Nvarchar Datetime2 Xml
Smallmoney Text Datetimeoffet Smalldatetime
Money Ntext Time Varbinary
Decimal Timestamp Uniqueidentifier
Double Hierarchyid
Float Rowversion
Real Sql_variant
Image

Q: If the server won’t convert my datatype to hold fractions, what happens when I
get the sum of something too big to be held?
A: Suppose that you have a table of tinyints. The max value for a tinyint is 255. If the
sum is, say, 400, the server is smart enough to promote the datatype to an integer. It
skips right over smallint. In short, you don’t have to worry about datatype conversion
during sums.
Data Conversion
Q: Difference between Implicit and explicit data conversion?
A: Converting data from one data type to another data type is often handled
automatically by SQL server called implicit data conversion.
Those conversions that are explicit require cast and convert function.

Q: Difference between cast and convert?

A: Both are used for explicit data conversion but convert take the style parameter for
formatting. Also, convert is Non- ANSI SQL function.

Q: Which of the string functions, CONVERT( ) OR CAST( ), is ANSI compliant?

A: The CAST( ) function is ANSI compliant.

Q: What is boxing?
A: Boxing occurs when a value stored as a specific data type is converted or cast to a
different data type.

Q: What is unboxing?
A: Unboxing occurs when a value is converted back to its original data type after it had
been converted or cast to a data type other than the original data type.
Constraints

Q: Difference between Primary and Unique key?

A: 1) Unique key accept NULL value.
2) Primary key create clustered index.
3) One table can have only on primary key.

Q: What is Data Integrity?

A: Enforcing data integrity guarantees the quality of the data in the database. Data
integrity falls into the following categories:

Entity Integrity
Entity integrity defines a row as a unique entity for a particular table. Entity integrity
enforces the integrity of the identifier columns or the primary key of a table, through
UNIQUE indexes, UNIQUE constraints or PRIMARY KEY constraints.

Domain Integrity
Domain integrity is the validity of entries for a specific column. You can enforce domain
integrity to restrict the type by using data types, restrict the format by using CHECK
constraints and rules, or restrict the range of possible values by using FOREIGN KEY
constraints, CHECK constraints, DEFAULT definitions, NOT NULL definitions, and
rules.

Referential Integrity
Referential integrity preserves the defined relationships between tables when rows are
entered or deleted. In SQL Server, referential integrity is based on relationships
between foreign keys and primary keys or between foreign keys and unique keys,
through FOREIGN KEY and CHECK constraints. Referential integrity makes sure that
key values are consistent across tables. This kind of consistency requires that there are
no references to nonexistent values and that if a key value changes, all references to it
change consistently throughout the database.
When you enforce referential integrity, SQL Server prevents users from doing the
following:
Adding or changing rows to a related table if there is no associated row in the primary
table.
Changing values in a primary table that causes orphaned rows in a related table.
Deleting rows from a primary table if there are matching related rows.

For example, with the Sales.SalesOrderDetail and Production.Product tables in the

AdventureWorks database, referential integrity is based on the relationship between the
foreign key (ProductID) in the Sales.SalesOrderDetail table and the primary key
(ProductID) in the Production.Product table. This relationship makes sure that a sales
order can never reference a product that does not exist in the Production.Product table.
User-Defined Integrity
User-defined integrity lets you define specific business rules that do not fall into one of
the other integrity categories. All the integrity categories support user-defined integrity.
This includes all column-level and table-level constraints in CREATE TABLE, stored
procedures, and triggers.

Q: How to enforce data integrity or what is constraint?

A: Planning and creating tables requires identifying valid values for the columns and
deciding how to enforce the integrity of the data in the columns. SQL Server provides
the following mechanisms to enforce the integrity of the data in a column:

PRIMARY KEY Constraints

FOREIGN KEY Constraints
UNIQUE Constraints
CHECK Constraints
DEFAULT Definitions
Allowing Null Values

Primary Key
A table typically has a column or combination of columns that contain values that
uniquely identify each row in the table. This column, or columns, is called the primary
key (PK) of the table and enforces the entity integrity of the table. You can create a
primary key by defining a PRIMARY KEY constraint when you create or modify a table.
A table can have only one PRIMARY KEY constraint, and a column that participates in
the PRIMARY KEY constraint cannot accept null values. Because PRIMARY KEY
constraints guarantee unique data, they are frequently defined on an identity column.
When you specify a PRIMARY KEY constraint for a table, the Database Engine
enforces data uniqueness by creating a unique index for the primary key columns. This
index also permits fast access to data when the primary key is used in queries.
Therefore, the primary keys that are chosen must follow the rules for creating unique
indexes.
If a PRIMARY KEY constraint is defined on more than one column, values may be
duplicated within one column, but each combination of values from all the columns in
the PRIMARY KEY constraint definition must be unique.

Foreign Key
A foreign key (FK) is a column or combination of columns that is used to establish and
enforce a link between the data in two tables. You can create a foreign key by defining a
FOREIGN KEY constraint when you create or modify a table. In a foreign key reference,
a link is created between two tables when the column or columns that hold the primary
key value for one table are referenced by the column or columns in another table. This
column becomes a foreign key in the second table.

Unique Key
You can use UNIQUE constraints to make sure that no duplicate values are entered in
specific columns that do not participate in a primary key. Although both a UNIQUE
constraint and a PRIMARY KEY constraint enforce uniqueness, use a UNIQUE
constraint instead of a PRIMARY KEY constraint when you want to enforce the
uniqueness of a column, or combination of columns, that is not the primary key.
Multiple UNIQUE constraints can be defined on a table, whereas only one PRIMARY
KEY constraint can be defined on a table. Also, unlike PRIMARY KEY constraints,
UNIQUE constraints allow for the value NULL. However, as with any value participating
in a UNIQUE constraint, only one null value is allowed per column. A UNIQUE
constraint can be referenced by a FOREIGN KEY constraint.

Check Constraint
CHECK constraints enforce domain integrity by limiting the values that are accepted by
a column. They are similar to FOREIGN KEY constraints in that they control the values
that are put in a column. The difference is in how they determine which values are valid:
FOREIGN KEY constraints obtain the list of valid values from another table, and
CHECK constraints determine the valid values from a logical expression that is not
based on data in another column. For example, the range of values for a salary column
can be limited by creating a CHECK constraint that allows for only data that ranges from
$15,000 through $100,000. This prevents salaries from being entered beyond the
regular salary range

Default
When you load a row into a table with a DEFAULT definition for a column, you implicitly
instruct the Database Engine to insert a default value in the column when a value is not
specified for it. If a column does not allow for null values and does not have a DEFAULT
definition, you must explicitly specify a value for the column, or the Database Engine
returns an error that states that the column does not allow null values. The value
inserted into a column that is defined by the combination of the DEFAULT definition and
the nullability of the column can be summarized as shown in the following table.
 No entry, no No entry,
Column DEFAULT DEFAULT Enter a null
definition definition definition value
Allows null
values NULL Default value NULL
Disallows null
values Error Default value Error
.
NULL
The nullability of a column determines whether the rows in the table can contain a null
value for that column. A null value, or NULL, is different from zero (0), blank, or a zero-
length character string such as "". NULL means that no entry has been made. The
presence of NULL typically implies that the value is either unknown or undefined.

Q: How many Foreign key constraint is possible in a table?

A: SQL Server does not have a predefined limit on either the number of FOREIGN KEY
constraints a table can contain (which reference other tables), or the number of
FOREIGN KEY constraints owned by other tables that reference a specific table.
Nevertheless, the actual number of FOREIGN KEY constraints is limited by your
hardware configuration and by the design of your database and application. We
recommend that a table contain no more than 253 FOREIGN KEY constraints, and that
it be referenced by no more than 253 FOREIGN KEY constraints. Consider the cost of
enforcing FOREIGN KEY constraints when you design your database and applications.

Q: How indexing is useful in a foreign key?

A: Creating an index on a foreign key is often useful for the following reasons:

-> Changes to PRIMARY KEY constraints are checked with FOREIGN KEY constraints
in related tables.
-> Foreign key columns are frequently used in join criteria when the data from related
tables is combined in queries by matching the column or columns in the FOREIGN KEY
constraint of one table with the primary or unique key column or columns in the other
table. An index enables the Database Engine to quickly find related data in the foreign
key table. However, creating this index is not required. Data from two related tables can
be combined even if no PRIMARY KEY or FOREIGN KEY constraints are defined
between the tables, but a foreign key relationship between two tables indicates that the
two tables have been optimized to be combined in a query that uses the keys as its
criteria. For more information about using FOREIGN KEY constraints with joins

Q: How foreign key enforce referential integrity?

A: The constraint enforces referential integrity by guaranteeing that changes cannot be
made to data in the primary key table if those changes invalidate the link to data in the
foreign key table. If an attempt is made to delete the row in a primary key table or to
change a primary key value, the action will fail when the deleted or changed primary key
value corresponds to a value in the FOREIGN KEY constraint of another table. To
successfully change or delete a row in a FOREIGN KEY constraint, you must first either
delete the foreign key data in the foreign key table or change the foreign key data in the
foreign key table, which links the foreign key to different primary key data.

Q: Can a foreign key be self-referencing?

A: Yes, e.g. Employee and manager.

Q: Can you apply multiple check constraint to a single column?

A: Yes. You can also apply a single CHECK constraint to multiple columns

Q: What is limitation of check constraint?

A: CHECK constraints reject values that evaluate to FALSE. Because null values
evaluate to UNKNOWN, their presence in expressions may override a constraint. For
example, suppose you place a constraint on an int column MyColumn specifying that
MyColumn can contain only the value 10 (MyColumn = 10). If you insert the value NULL
into MyColumn, the Database Engine inserts NULL and does not return an error. A
CHECK constraint returns TRUE when the condition it is checking is not FALSE for any
row in the table. If a table that has just been created does not have any rows, any
CHECK constraint on this table is considered valid.
The CHECK constraint being added specifies that there must be at least one row in
table CheckTbl. However, because there are no rows in the table against which to
check the condition of this constraint, the ALTER TABLE statement succeeds.
CHECK constraints are not validated during DELETE statements. Therefore, executing
DELETE statements on tables with certain types of check constraints may produce
unexpected results.

Q: When I use the INSERT statement with values or a query, what happens if one
of the values already exists in the table, and the INSERT operation violates a
PRIMARY KEY or UNIQUE constraint?
A: The entire INSERT operation will fail and you will receive an error message like
"Violation of UNIQUE KEY constraint…Cannot insert duplicate key in object
'dbo.TableY'". The entire INSERT operation will be terminated, so no records will be
inserted, even if only one violates the constraint. If this is not the behavior you intend,
use the MERGE statement instead.
Table

Q Difference between temp and normal table?

Table 10.2. Summary of differences between temporary and normal tables.

Permanent Temp
Local Temp Table Global Temp Table Normal Table
Table

Created in any
Created in tempdb Created in tempdb Created in tempdb
database

Created like a normal Created in any

Use # to create Use ## to create
table, but in tempdb database

Reference using Reference using table

Reference using # Reference using ##
tempdb..tablename name

Last until connection

that created them is
Last until connection closed, or until all
Last until the server
that created them is connections have Last forever
reboots
closed stopped accessing the
table, whichever
comes last

Accessible from any Accessible from any Accessible from any

Accessible from
connection unless connection if connection if
connection that created
permissions have permissions have been permissions have been
it only
explicitly been revoked granted granted

Q: Define four part table name.

A: [Server.Database.Schema.Table]. The use of the four-part-name enable the
reusability of the query execution plan. Not only it cleaner programming practice, you
also reap performance benefits from specifying the table’s owner.

Q: Why would I want to use a temporary table to hold data if I can just go after the
base table?
A: There are two good reasons. First, if lots of users are altering data in the base table
and you are interested in a “snapshot” of the data, you can get that with a temp table. If
the base table is very “busy,” your table, usable only by you, will never require you to
wait while another user has pages locked. Second, tempdb is often placed on a fast
device, sometimes a solid state disk (an expensive bank of memory that acts just like a
disk drive), and sometimes placed in the server’s RAM.

Q: The ER diagram indicates a one-to-many relationship, and a one-to-one, but

how about one to “zero or more” or a “one to zero or one” relationship? Aren’t
these different?
A: Some diagrams do consider these types of relationships and use zero to indicate
them. Others lump these relationships in with “many.” For example, authors has a one-
to-many relationship with titleauthor which is really a “one to zero or more” relationship.
Diagrams that present this information do, in fact, present clearer images of the data
relationships between tables.

Q: What is a computed column?

A: A computed column is calculated from an expression that can use other columns in
the same table.

Q: I used sparse columns on the columns in my table, and my performance got

worse! What happened?
A: Sparse columns provide optimal storage only for columns with a large percentage of
the rows being NULL. Oddly, sparse columns actually take more space to store non-null
values than they would if they were not sparse. This means that columns where most
rows have values will actually increase their total storage rather than decrease. If there
are multiple columns like this, and a lot of rows, you can negatively impact the storage
of the table and thus performance.

Q: I created a table using sparse columns and a column set; now when I query
from the table, the sparse columns are missing!
A: When a table has a column set defined, individual sparse columns are not returned if
a SELECT∗is done on the table. However, you can reference the sparse columns by
name, and they will be returned.

Q: Can I insert new identity values explicitly?

A: If you own the table, you can set identity_insert on. This allows duplicate identity
values, however, so be careful that you do not introduce duplicates. This is helpful when
migrating an existing table to a new server, or if you want to move a row in the table to a
different identifier value that had been skipped.

Q Can I create a table with just a single identity column, and nothing else?
A: Strangely, yes, but you cannot insert data into it unless you set identity_insert on,
defeating the purpose of the identity column. This is because you cannot provide an
empty column list to insert.
Q: Can I create a null identity column?
A: No.

Q: Difference between Truncate and Delete command?

A: 1)Truncate is a DDL command whereas Delete is a DML command hence delete
operation can be rolled back.
2) Truncate command will delete the physical structure of the table and retains the
logical structure of same as for next usage.
3) No trigger fired associated with truncate a table
4) Truncate is fast but delete is not because delete have undo information.

Q: What is the difference between IDENTITY and uniqueidentifier columns?

A: IDENTITY is a special property that makes a numeric column automatically
increment its new values. You can specify a seed and an increment value for an
IDENTITY column. Identity columns are usually of the integer data type. Uniqueidentifier
is a special data type that holds GUID type values; for example, 6F9619FF-8B86-D011-
B42D-152C04FC964FF.

Indexing

Q: Which is better, a clustered or nonclustered index?

A: For most individual queries, if I had to choose between a clustered and nonclustered
index on the same column, I would choose the clustered index. But that’s not the real
choice. You only get one clustered index per table, so you use it to help queries that
perform range selections and sorts. Other queries are aided by nonclustered indexes on
other columns or sets of columns.

Q: What is the best indexing strategy?

A: Indexing strategies vary depending on your data access pattern and parameters
such as the size of your table. As a rule of thumb, it is recommended that you create a
clustered index on the PRIMARY KEY column and multiple nonclustered indexes for
other frequently searched-on columns.

Q: When should I use FILLFACTOR and PAD-INDEX options?

A: Use these options when creating or rebuilding an index. Bear in mind that
FILLFACTOR and PAD-INDEX optimize write performance but slightly decrease read
performance because more data pages have to be accessed. Do not bother padding
indexes based on identity columns. In these cases, new values will never go in the
middle of a page; they should always go at the end.

Q: If I compress a table, do all of its indexes get compressed as well?

A: No, each index would need to be created or altered to enable compression.
Q Doesn’t the overhead of keeping a clustered index slow everything down? Why keep
the data sorted that way? A Maintaining the physical sort during data modifications is
only a problem when (1) you are inserting rows into a table or (2) you are changing the
clustered index key of a row already in the table. During inserts, you need to find the
page where the new row belongs. Occasionally, you need to split the page to make
space for the new row. Only the page splits cause real performance problems.
Clustered indexes actually improve insert performance by distributing inserts in various
parts of the table, allowing multiple threads and multiple processors to add data to a
single table concurrently.
Changing the clustered index key during an update does incur a cost, so DBAs
are encouraged to choose nonvolatile columns as the basis of a clustered index.

Q How do I know if SQL Server is using an index and choosing the best plan?
A: Use showplan to display the optimization plan and determine whether the server is
using an index. Is the plan the best one? You will need to do some analysis. Look at the
size of the table (in pages and rows) and the selectivity of the various indexes available
for the query. If you think that the server isn’t choosing a good plan, try forcing a
different one and see if the statistics io output proves you right. If so, consider restating
the query or breaking it up into parts, using a temporary table to store an intermediate
result set.

Q: Does SQL Server warn you if your indexes aren’t useful?

A: No. The only warning you get is when your queries take forever. (One good
indication is that you’ve had to replace your stopwatch with a sundial or a calendar.)

Q: Are my tables large enough to make good use of indexes?

A: In the case of single-table queries, SQL Server will seldom use indexes on tables
consisting of fewer than four pages. If you are testing query optimization and
performance, try to build tables with at least a couple of thousand rows each before you
start. Otherwise, all the optimization behavior will be skewed.

Q: Can I audit index use?

A: Not really. You can use the SQL Audit tool to track user queries; then you can re-
execute the queries yourself with showplan to see how well those queries are being
optimized.

Q: How do I quickly see which tables have indexes?

A: The fastest way to list indexes is to query the system table, sysindexes:
select o.name, i.indid, i.name
from sysobjects o, sysindexes I
where o.type = “U” -- user tables only
and i.indid < 255 -- exclude text column structures
and i.id = o.id
order by o.name, i.indid
The indid column tells you the type of the index. A value of 0 means that the table has
no clustered index: it is a heap table. A value of 1 designates the clustered index on the
table. Note that each table will have a row in sysindexes with an indid value of 0 or 1. A
value of 2 or higher designates a nonclustered index.
Q Why not always force an index?
A The optimizer will be better than your application at adapting to new circumstances,
including an increase in the number of rows or a change in the data distribution. If the
optimizer isn’t adjusting well, look at your query; the problem is often there.

Q: What are the trade-offs with having Indexes.

A: 1) Faster select but slower update because in addition to update table you have to
update index.
2) Extra storage space to store indexes.

Q: What’s reformatting?
A: Sometimes SQL Server can’t resolve a query using the existing indexing resources,
or it decides that its own clustered index or temporary result set will work better than a
typical join given the table structure. In that case, the server can reformat the query. In
the showplan output, the server reports reformatting as a separate step in the query
plan, like this:
STEP 1
The type of query is INSERT
The update mode is direct
Worktable created for REFORMATTING
If important queries based on a particular table are consistently being reformatted, try
adding the index the server seems to be looking for. Often, reformatting takes time and
can result in poor query performance. (When it reformats, the server is creating a
nonreusable index for every query. If the same index were available, it wouldn’t need to
create it, so the query would have to be faster.) Sometimes, the only way to stop
reformatting is to change your clustered index. You will have to decide if it’s worth it.

Transaction/ Locking/ Blocking

Q: What is the default transaction isolation level that SQL Server uses?
A: Microsoft SQL Server uses the READ COMMITED transaction isolation level as the
default isolation level.

Q: If a stored procedure throws an error message will the statements all be rolled
back?
A: No, a stored procedure is not necessarily a single transaction. The only time a stored
procedure is a single transaction is when the BEGIN TRANSACTION and COMMIT
statements are explicitly within the procedure.

Q: If I want to run select statements without using table locking hints what
transaction isolation level should I use?
A: You will want to use the READ UNCOMMITED transaction isolation level as this will
allow SELECT statements to run without taking any locks and without requiring table
locking hints.

Q: I’m getting deadlocks on a server; how can I get more information about the
deadlocks?
A: You will want to enable trace flags 1204 and 1222. These flags will output
information about both statements that are involved in the deadlock to the ERRORLOG
file.

Q: What option is used to control the rollback priority when dealing with
deadlocks?
A: You will want to use the SET DEADLOCK_PRIORITY switch. You can either use
LOW, MEDIUM, and HIGH, or for more control use any whole value from –10 to 10,
giving you a total of 21 settings.

Q: What needs to be configured in order to allow a transaction to go between

servers?
A: You will need to configure the MSDTC service in order for transactions to be
escalated from local transactions to distributed transactions.

Q: Which are the transaction isolation levels that SQL Server offers?
A: READ UNCOMMITTED, READ COMMITTED, SNAPSHOT, REPEATABLE READ,
and SERIALIZABLE.

Q: Can I set user priorities so that some users requesting locks go to the head of
the line, while others have to wait?
A: No. This is an often requested feature, however, and may be implemented in a future
release.

Q Is there an exclusive page-level lock optimizer hint?

A: No, there is not. You can acquire update locks, instead, or an exclusive table lock.
Q: What happens if I begin a transaction, perform some changes on a table, and
log out before committing or rolling back?
A: If you lose your connection to the server for any reason while a transaction is active,
the server assumes some type of failure occurred and automatically rolls back the
transaction.

Q: What cardinal sins should I be sure to avoid when dealing with transactions?
A: Never allow user interaction during a transaction. Don’t perform unrelated work
inside the same transaction. Don’t nest transactions.

Q: If I want to control the transaction isolation level, do I have to use table hints?
A: No, generally the “Read Committed” default transaction isolation is the optimal
choice. If you need to change the isolation for your entire session, you should use the
SET TRANSACTION ISOLATION LEVEL setting. That will affect all statements
submitted by your session. The table level hints should only be used when a specific
table needs special locking behaviors in a statement.

Q: What service do you need to run when you need to initiate transactions in
Linked Servers?
A: Distributed Transaction Coordinator (DTC).

Q: I want to get locks that span multiple servers. How do multiserver transactions
work?
A: MS SQL Server 6.5 provides distributed transactions, which are transactions that
span servers. Distributed transactions are managed by the Distributed Transaction
Coordinator, or DTC, which was shipped first with Windows NT v. 3.51 and is a part of
NT 4.0 as well.
Distributed transactions are based on the traditional two-phase commit (2PC) method of
ensuring transactional integrity across distributed systems. The DTC informs each
server when it’s time to commit a transaction. The server commits once, partway, and
then tells the coordinator that the commit is ready to go through. When all of the servers
have completed the first phase of commit, the DTC releases the servers to finish the
commit process. If any server fails to complete the first commit phase, DTC orders all of
the servers to roll back.
Prior to this release of SQL Server, distributed transactions were only possible from a
client program written in C with the DB-Library API. The application was responsible for
handling all of the coordination of the commit process. Now 2PC is available to any
SQL-based or ODBC-based application.

Variable and statement

Q What is an order of execution?
A: When the server receives a batch of commands, it puts the SQL code through a five-
step process:

1.  Parse: Syntax—the commands are checked for syntactic validity. Do the commands
make sense?
2.  Parse: Object references—If the syntax is okay, check for referenced objects. Do the
referenced tables exist? Do you have permission to access them? Do the columns exist
in those tables?
3.  Optimize—The server considers different plans for getting and processing the data.
Are indexes available? Can they be used effectively, or would a table scan be faster?
This is a very complex process, which is being constantly improved. The result is a
query plan detailing how to access the data in the fastest way.
4.  Compile—The query plan is compiled.
5.  Execute—The compiled plan is executed at the server.

Q: Are the five steps of query execution always performed?

A: Not always. Stored procedures, discussed on Day 16, are parsed when they are
submitted. They are compiled once, the first time they are called by a user. Subsequent
procedure calls are simply passed through the execute phase.
If you have an application program that uses ODBC, the ODBC driver may be set to
generate stored procs for all of its queries. This causes the same query to be parsed
and compiled once, and only executed thereafter.

Q: Does SQL have a GOTO statement?

A: No. Well, OK, it does. I’ve never been a big fan of GOTO. Much later in the book,
there will be an example that uses GOTO to save some time and solve a problem with a
little more clarity. Generally speaking, however, GOTO creates more trouble than it’s
worth. You can write miles of great SQL without ever coming near GOTO. Concentrate
your efforts on mastering the other flow control statements, and you won’t be sorry.

Q: Can I create local arrays of variables?

A: No.

Q: Just WHILE and IF? Aren’t there CASE statements, DO UNTIL, FOR NEXT, any
of those commands?
A: No. You would be surprised how much work you can do with just IF and WHILE.
There is a CASE expression, but this is not used for flow control. The CASE expression
is most often used for conditional execution inside a SELECT or UPDATE statement.

Q: Is there a limit to the number of nested IF statements I can write?

A: As of MS SQL Server v6.5, there is a limit of 294 nested IF ’s. Practically speaking, if
you hit this limit in the normal course of SQL programming, something has gone horribly
wrong. There is no predefined limit to nesting levels of the IF statement, so this limit
may vary between platforms and versions of the SQL Server software.
Error Handling

Q: What types of errors does SQL Server have, and what are their differences?
A: SQL Server has two types of error messages: information and error. They differ in
severity level: information messages have a severity level from 0 to 10; error messages
have a severity from 11 to 25.

Q: Where does SQL Server store the messages that I add?

A: All messages are stored inside the sys.messages catalog view.

Q: What information tells me the seriousness of an error?

A: The severity level helps you to determine how critical an error is.

Q: How do I add custom error messages to SQL Server?

A: You can add custom messages to SQL Server using the sp_addmessage procedure.

Q: Can I make changes to SQL Server system error messages?

A: No, only user-defined error messages can be modified.

Q: Does SQL Server only support English error messages?

A: No, SQL Server has native support for 33 languages, and you can create different
language versions for user-defined error messages.

Q: What data types does a RAISERROR statement support in the text of a

message?
A: Only the following data types are supported: tinyint, smallint, int, char, varchar,
nchar, nvarchar, binary, and varbinary.

Q: Can I use a date value as an argument for a RAISERROR statement?

A: Yes, if you convert the date to an (N)CHAR or (N)VARCHAR before.

Q: What are the differences between the @@ERROR function and a TRY…
CATCH block?
A: The @@ERROR function provides a limited way to handle errors, and it works in
previous versions of SQL Server. TRY…CATCH blocks provide better error handling
capabilities, but they only work in versions 2005 and 2008 of SQL Server.

Q: When I am creating and testing localized error messages, how can I verify the
language of my session?
A: You can query the @@LANGUAGE function to determine your session’s language.

Q: What’s the difference between a raiserror and a print, and when would I use
them?
A: RAISERROR is used to indicate an exception. When things go wrong,
RAISERRORS give the user an idea about what happened, and how to fix it.
RAISERROR allows you to specify an error number, severity, and state. PRINT is used
to give supplemental information. You can use PRINT to confirm that things succeeded.
Operator
Q: Why would I use FREETEXT search function instead of multiple LIKE '%value
%' comparisons?
A: Using LIKE comparisons is a highly time- and resource-intensive operation that
always requires a table scan. The FREETEXT utilizes the full-text index structure and
delivers much better performance than the LIKE comparison.

Q: Does the case operator cause problems or create overhead?

A: I haven’t been able to measure any performance problems related to the case
operator. Avoid using it in a WHERE clause; the optimizer won’t be able to use indexes
to support queries with case.

Ranking function
Q: Do any of the ranking functions require an argument to be passed in?
A: Yes, the NTILE function requires that you supply the number of “tiles” you would like
to classify the rows by. None of the other ranking functions take an argument, however.

Q: When using a ranking function, is it required to use the OVER clause?

A: Yes, the OVER clause is required, and you must specify the ORDER BY clause as
well when using any of the ranking functions.

Q: Is ROW_NUMBER( ) the same as IDENTITY( )?

A: No, SQL Server does have a system function named IDENTITY( ) (which is different
from the IDENTITY property on column in a table), but it can only be used as a column
expression in a SELECT… INTO query. The ROW_NUMBER( ) function can be used in
any query and can generate partitioned row numbers.

Ordering
Q: Is there a limit to the number of columns I can list in a single select statement?
A: SQL does not impose a limit, but the most columns that a table can have is 255.

Q) Difference between order by and collection?

A) Besides determining the alphabet, the collection order also determines whether
accents, case and other alphabet properties are considered in the sort order.

Q: If I never specify a collation, what collation is being used?

A: When your instance of SQL Server was installed, a default collation was selected.
That collation was used for all the system databases and is the default collation for all
subsequent databases, columns, and expressions. You can override the collation using
the COLLATE clause when creating databases, columns, and expressions.

Q: I made my database using a case-sensitive collation. Now I can’t query from

my tables. Any ideas what is wrong?
A: When a database uses a case-sensitive collation, not only is your literal character
data case sensitive, but the object identifiers (table names, view names, proc names,
etc.) are also case sensitive. This is because their names are stored as data in the
system tables. Those system tables use the same collation as the database and are
therefore case sensitive as well.

Scalar function
Q: What is the use of quotename and how it differ from replace?
A: As a best practise, one should wrap the object names with QUOTENAME() when
using dynamic sql to avoid SQL Injection and more to follow on this
topic. QUOTENAME() works correctly for object names that are less than or equal to
128 characters in length but returns NULL if the length is more. This fact is incorrectly
shown as 258 on BOL so watchout when you are using QUOTENAME and
use REPLACE() instead. The only difference between these is QUOTENAME adds the
brackets automatically but using replace you have to manually add them.

Q: At what position does the CHARINDEX() function start if a starting position is

not supplied?
A: If a starting position is not supplied to the CHARINDEX() function, the function starts
at position 1 of the string.

Q: Where does the APP_NAME( ) function get its value from?

A: When an application opens a connection, it can provide various properties values for
the connection. One of those values is the “Application Name.” If the client application
provides it, APP_NAME( ) can show it. If, however, the client application does not
supply it, APP_NAME( ) will be empty.

Aggregation and Pivoting

Q: Where did CUBE and ROLLUP get their names?
A: The CUBE operator calculates superaggregates on all possible combinations of
groups and subgroups appearing in the GROUP BY clause. Mathematically, this
assemblage of combinations of all possible subgroups forms an n-dimensional cube.
The ROLLUP operator calculates running totals (or maximums, minimums, and so on),
which take the previous rows’ aggregates, and then “rolls them up” into a new
aggregate on its own row.

Q: What can the WHERE clause do that the HAVING clause cannot?
A: The WHERE clause restricts the rows that are used to evaluate a query. If a row
can’t pass the conditions in the WHERE clause, it is not used in the calculation of an
aggregate in the query.

Q: What can the HAVING clause do that the WHERE cannot?

A: Because HAVING operates on a result set, and not on the rows in tables, an
aggregate may appear in a HAVING clause. An aggregate may never appear in a
WHERE clause, although it may be part of a subquery that feeds the WHERE.
Subqueries are explored on Day 8.

Q: Because the rowcount coming back from an aggregate is always one, is there
any other way to determine on how many columns the aggregate acted?
A: The best way is to perform a count(<column>) in addition to your other aggregates.
This will return the number of columns that passed the WHERE test and are not null—
the same set of columns upon which any other aggregates in the query will have acted.

Join
Q: Is there a right outer join?
A: Yes, there are left, right, and full outer joins. The right outer join simply forces all the
rows to appear from the right-hand table in the join relationship rather than the left.

Q: Are there other types of self-joins?

A: The other major category of self-joins looks for matching data values. To find
matching values on a column, you set up an equality join between the tables on that
column. For example, here is a query that displays the names of authors living in the
same city:
select a1.au_lname, a2.au_lname, a1.city
from authors a1, authors a2
where a1.city = a2.city
and a1.id > a2.id
With matching self-joins, alias names don’t matter—the two tables are indistinguishable.
The a1.city column is drawn from the authors table, a1, but it could just as well be
drawn from the second version, a2. Notice that the query excludes matches where the
IDs are the same: rows should not match each other.
Matching queries can be useful for finding possible duplicate data, but otherwise they
are seldom used in production systems.

Q: Can I join other tables with a self-join?

A: Yes, a self-join can be used as part of a larger query involving many tables, and it
can be used in combination with any other SQL syntax.

Q: Do joins need to use the equals sign?

A: No. You can join tables on any mathematical operator (<, >, <>, and so on). This can
lead to some bizarre results. For example, what would you get if you asked for “all the
rows in titles where the title_id doesn’t match the title_id in sales”—a lot of useless
output! Still, these operators are used in some unusual circumstances.

Q: What is the maximum number of tables I can join in a single query?

A: The legal limit is 16 tables, but the practical limit is often much less. There are plenty
of queries that run well with 8, 10, or even 12 tables. Good performance often depends
on the characteristics of those tables and the way in which the tables are joined.
The optimizer analyzes tables in groups, considering possible join orders four tables at
a time. For joins consisting of more than four tables, the server decides on a join order
using an iterative process. First, the server tries to find a useful outer table, followed by
a useful second table, and so on, until only four tables are left to analyze. At that point, it
considers all possible join orders of those four tables and develops a final optimization
plan.
The problem with the iterative approach is that the server cannot see a large multitable
query through to completion at optimization time. Errors can creep into the estimation
process and result in a poor optimization plan.
What’s more, the optimizer can’t always find a good solution, and sometimes a good
solution just doesn’t exist. (A good solution means one that performs well. Except when
you stumble across a bug in SQL Server, you will always get a correct result. It just
might take a while.) In cases where there is no good solution, you might need to break
up the query into parts, building a temporary table from some of the tables, and then
joining that table back to other tables in the query. This will depend on your knowledge
of the data and some trial and error.

Q: What are the benefits to using ANSI or old style join syntax?
A: The ANSI syntax can prevent you from making a simple mistake. You cannot
accidentally create a cross join when you wanted an inner join, as you can do with the
old style syntax. ANSI style syntax makes the relationships between tables easier to
understand because it is explicitly spelled out for someone viewing the code. Also, it
requires you to specify join keys together with the tables to which they belong (instead
of separately, like with the old style). Finally, the ANSI join syntax is defined in the ANSI
SQL standard. If standards compliance is important to you and your company, this style
is guaranteed to be supported by MS SQL Server in future releases.
The old style syntax is less verbose than the ANSI style. It is more portable between
RDBMS’s because more of them recognize the old style. If you are using a combination
of MS 6.0 and 6.5 servers, the old style syntax will work on both, but the ANSI syntax
won’t. The old style syntax is also more recognizable by a wider range of people in the
industry (it has been around longer), so you will have an easier time getting help if you
use it.
There is no performance benefit to using one or the other join syntax.

Top/ Apply

Q: What is the purpose of TOP Clause?

A: TOP limit the number of rows affected by a query. It is generally used with an
ORDER BY clause. You can specify the quantity of rows you want in one of two ways:
as an exact number of rows, from TOP (0) to TOP(9223372036854775807) (the largest
BIGINT value), or as a percentage of rows, from TOP (0E0) PERCENT to TOP (100E0)
PERCENT, using a FLOAT value. SQL Server supports any self-contained expression,
not just constants, with TOP

Q: In which case TOP is used without ORDER BY

A: TOP query doesn’t require an ORDER BY clause. However, such a query is
nondeterministic. That is, running the same query twice against the same data might
yield different result sets, and both would be correct. A TOP query can be
nondeterministic even when an ORDER BY clause is specified if the ORDER BY list is
nonunique.
I can think of very few reasons to use SELECT TOP without ORDER BY, and I
don’t recommend it. One reason is to serve as a quick reminder of the structure or
column names of a table or to find out if the table contains any data at all. Another
reason is to create an empty table with the same structure as another table or query. In
this case, you can use SELECT TOP (0) <column list> INTO <table name> FROM . . . .
Obviously, you don’t need an ORDER BY clause to indicate “which zero rows” you want
to select!

Q: What are the ways to guarantee determinism in TOP?

A: One way to guarantee determinism is to add a tiebreaker that makes the ORDER BY
list unique—for example, the primary key
Another way to guarantee determinism is to use the WITH TIES option.

Q: TOP and SET ROWCOUNT

A: Before SQL Server 2005, the SET ROWCOUNT option provided the same capability
as some of TOP’s newer features. SET ROWCOUNT accepted a variable as input, and
it affected both data modifi cation statements and SELECT statements. Microsoft no
longer recommends SET ROWCOUNT as a way to affect INSERT, UPDATE, and
DELETE statements—in fact, SET ROWCOUNT enters a deprecation process, and in
the next planned release of SQL Server (SQL Server 11), it will not affect data modifi
cation statements at all. Use TOP to limit the number of rows affected by data modifi
cation statements. TOP is a Microsoft T-SQL extension to ANSI SQL and is not
portable. If the database must be migrated to another database platform, the use of top
will become a conversion problem. In contrast, the rowcount variable is portable.

Q: In which situation TOP with INSERT, UPDATE, DELETE is useful?

A: SQL Server supports the TOP option with modifi cation statements, allowing you to
limit the number or percentage of affected rows. A TOP specifi cation can follow the
keyword DELETE, UPDATE, or INSERT.

purging historic data might involve deleting millions of rows of data. Deleting such a
large set of rows in a single transaction has several drawbacks. A DELETE statement is
fully logged, and it will require enough space in the transaction log to accommodate the
whole transaction. During the delete operation (which can take a long time), no part of
the log from the oldest open transaction up to the current point can be overwritten.
Furthermore, if the transaction breaks in the middle for some reason, all the activity that
took place to that point will be rolled back, and this will take a while. Finally, when many
rows are deleted at once, SQL Server might escalate the individual locks held on the
deleted rows to an exclusive table lock, preventing both read and write access to the
target table until the DELETE is completed.

Distinct/ All

Q) Difference between distinct and all?

A) Distinct eliminate duplicate rows from the result set of the query. The opposite of
distinct is all which is the default.
Distinct as a stream aggregate operation, so distinct does require another step in the
query execution plan.

Set operation

Q: Difference between Union and Union all?

A: A UNION statement effectively does a SELECT DISTINCT on the results set. If you
know that all the records returned are unique from your union, use UNION ALL instead,
it gives faster results.

Q: What are the rules of set operation?

A: 1) The column names or aliases must be determined by the first select.
2) Every select must have the same number of columns, and each lineup of columns
must share the same data-type family.
3) Expressions may be added to the select statements to identify the source of the
row so long as the column is added to every select.
4) ORDER BY clause should be part of the last statement, which orders the results.
5) SELECT INTO should apply on first part of statement
6) Empty set may also reduce number of rows
7) Two NULLS are treated as equal

Sub-query

Q: Can I use more than one subquery, unnested, in a single statement?

A: Yes. You may use as many subqueries as you like, as long as the nesting level does
not exceed 16. For example, you could use this single query to retrieve the highest-
priced and lowest-priced book in the titles table:
select title, price
from titles
where price = (select max(price) from titles) or price = (select min(price) from titles)
order by price
title price
------------------------------- --------------------------
You Can Combat Computer Stress! 2.99
The Gourmet Microwave 2.99
But Is It User Friendly? 22.95
(3 row(s) affected)

Q: Can I mix the subquery and join syntax together in the same query?
A: Sure. Some users find that doing this helps them conceptualize how the server is
creating their result set. Remember the limitations that the subqueries place on you.
The 16-table limit still applies.

Q: What if a subquery returns null, or if it returns no rows?

A: If a subquery returns null, the outer query will simply compare to a null value. This
won’t cause an error, but it may not be the solution you want. You can perform a
subquery inside an ISNULL() function, too. So, if you want to avoid comparison to nulls,
you could use a query like this, which finds books that cost more than the average
UNDECIDED book. Because UNDECIDED books don’t have prices, the average would
be null, and because no price is greater than null (null is an unknown value), the query
would return 0 rows without the isnull. When a null price is returned for the
UNDECIDED type, this query plugs in the average price for all books:
select title
from titles
where price > isnull(
(
select avg(price)
from titles
where type = ‘UNDECIDED’
),
(
select avg(price) from titles
))
The first subquery gets a value for the average UNDECIDED book. If that is null (which
it is), it asks for the average price of any book (the second argument in isnull(). The
results of this query happen to be the same as if you asked for all books with prices
greater than the average price of all books. It just takes a little longer to get there.
CTE

Q: What is CTE?
A: CTE can be thought of as a temporary result set that is defined within the execution
scope of a single Select, Insert, Update, Delete or Create View statement.

Q: Similarities and differences between CTE and derived table

A: CTE is similar to derived table in that it is not stored as an object and lasts only for
the duration of the query. Also, both refer to variables declare in the same batch. Unlike
a derived table, a CTE can be self referencing and can be referenced multiple times in
the same query. But unlike derived tables, CTE can’t be nested directly i.e. you can’t
define a CTE within another CTE.

Q: Advantage of CTE.
A: Improved reliability and ease of maintenance of complex queries. CTE can be
defined in user defined routines, such as functions, procedure, triggers or views.

Q: Can a single Common Table Expression (CTE) be used by more than one
statement?
A: No, a CTE is only valid for the single SELECT, INSERT, UPDATE, or DELETE
statement that references it. If multiple queries want to use the same CTE, the CTE
must be restated for each subsequent query.

Q: Is there a performance benefit or cost when using CTEs?

A: Not necessarily. SQL Server normalizes, or standardizes, your statement before it
optimizes it. This process generally means that whether your query uses CTEs,
subqueries, or joins, the intention is likely the same, and often exactly the same plan will
be used. However, at certain times one style of syntax may yield a more efficient plan.
You should compare the plans of alternate syntaxes when they are available and
choose the one with the lowest cost.

Q: Can views be recursive like CTEs are?

A: No, views cannot be recursive to themselves, but they can contain a CTE that is
recursive.

Cursor
Q: Why is the cursor so maligned in the newsgroups, trades, and conventional
wisdom?
A: Cursors are the most often misused feature of SQL Server. When used properly and
sparingly, cursors complement SQL by providing an easy way to handle problems that
set processing makes very difficult. Many programmers who migrated to SQL from
xBase or COBOL (myself included) found the migration much easier when they
discovered cursors. As a result, newcomers to SQL used cursors for everything. Using
cursors for normal SELECT and DELETE operations is a recipe for horrendous
performance and unmaintainable cursor code.

Q: Can I use cursors inside triggers?

A: Have you been skipping ahead? Yes, you can use cursors inside triggers, but doing
so is strongly discouraged. Cursors require lots of overhead to create and destroy.
Triggers run every time an INSERT, UPDATE, or DELETE, runs on the table. Creating,
running, and destroying a cursor for each of those operations takes far longer than most
users want to wait.

Q: Have you ever used a cursor in a production environment?

A: In the years that I’ve spent finding answers to tough SQL problems, I’ve never used
a cursor for anything but a temporary solution in a development environment. This isn’t
to say cursors are always bad. It’s a lot like asking a structured programmer if they’ve
ever used GOTO.

Q: Can I fetch more than one row at a time?

A: No. Client cursors do allow multiple rows to be fetched at a single time, but server
cursors do not.

Q: Can I have more than one cursor active at the same time? On the same table?
A: Sure.

View

Q: What is view?
A: A View is a saved text of a select statement. View doesn’t store any data, it merely
refer to the data stored in tables.

Q: Why use View?

A: The goal when developing view is two-fold-to enable user to get to the data easily
and to protect the data from the users.
1) to present data in more usable format.
2) ensure data integrity by hiding complexity (join complexity)
3) Key component of data access architecture to isolate the physical schema from
dynamic SQL.
4) support ad hoc query.
5) change cryptic column name by aliases.
6) Include only the columns of interest.

Q: Similarity and difference between View and SP?

A: The database abstraction layer (which isolate physical schema from direct data
access) can be built using Views or SP. either can limit to execute views or SP and
restrict access to the physical tables.

For occasionally run queries, view perform well even when compared with SP.

View is a key component of data access architecture but I still prefer using SP for the
abstraction layer because they offer error handling, better transaction control and the
option of programmatic control.

If your application has a lot of dynamic SQL embedded within a .NET application, using
view to build a database abstraction layer may be easier than refactoring the application
to call SP. (I would see view directly access a table than allow dynamic SQL to do it)

SP don’t offer schema binding.

Performance issue involving views concerns the locks that views can place on the data.

When the data and execution plan are already in the cache, SP are slightly faster than
views; however, if the execution plan is not cached(mentioned than it has not been
executed recently), than views execute faster than SP. Best practice is to use views to
support users ad hoc queries, and SP for the applications data abstraction layer.

Q: View limitation.
A:
Q: How to modify data through view?
A:

Q: What is the advantage of using an updateable view over updating the table
directly, given that the updateable view will by definition always be based on a
single table?
A: A view is more flexible. For example, you may wish to restructure the underlying
tables without the need to change your client applications. You will only need to update
the view in this case, not everything that referenced the tables being restructured.

Q: If I delete a row from a view, does that change data in the table on which the
view is defined?
A: Yes. A view does not store data itself; it is simply a lens through which you can view,
in a different way, data that lives in normal tables.

Q: Why are there restrictions on the kind of views I can create an index on?
A: To make sure that it is logically possible to incrementally maintain the view, to restrict
the ability to create a view that would be expensive to maintain, and to limit the
complexity of the SQL Server implementation. A large set of views is nondeterministic
and context-dependent; their contents 'change' independently of DML operations.
These can't be indexed. Examples are any views that call GETDATE or
SUSER_SNAME in their definition.

Q: Why does the first index on a view have to be CLUSTERED and UNIQUE?
A: It must be UNIQUE to allow easy lookup of records in the view by key value during
indexed view maintenance, and to prevent creation of views with duplicates, which
would require special logic to maintain. It must be clustered because only a clustered
index can enforce uniqueness and store the rows at the same time.

Q: Why isn't my indexed view being picked up by the query optimizer for use in
the query plan?
A: There are three primary reasons the indexed view may not be being chosen by the
optimizer:

1) You are using a version other than Enterprise or Developer edition of SQL Server.
Only Enterprise and Developer editions support automatic query-to-indexed-view
matching. Reference the indexed view by name and include the NOEXPAND hint to
have the query processor use the indexed view in all other editions.
2) The cost of using the indexed view may exceed the cost of getting the data from the
base tables, or the query is so simple that a query against the base tables is fast and
easy to find. This often happens when the indexed view is defined on small tables. You
can use the NOEXPAND hint if you want to force the query processor to use the
indexed view. This may require you to rewrite your query if you don't initially reference
the view explicitly. You can get the actual cost of the query with NOEXPAND and
compare it to the actual cost of the query plan that doesn't reference the view. If they
are close, this may give you confidence that the decision of whether or not to use the
indexed view doesn't matter.
3) The query optimizer is not matching the query to the indexed view. Double-check the
definition of the view and the definition of the query to make sure that a structural match
between the two is possible. CASTS, converts, and other expressions that don't
logically alter your query result may prevent a match. Also, there are limits to the
expression normalization and equivalence and subsumption testing that SQL Server
performs. It may not be able to show that some equivalent expressions are the same, or
that one expression that is logically subsumed by the other is really subsumed, so it
may miss a match.

Q: I update my data warehouse once a week. Indexed views speed up my queries

a lot during the week, but slow down the weekly update. What should I do?
A: Consider dropping the indexed views before the weekly update, and creating them
again afterwards.

Q: My view has duplicates, but I really want to maintain it. What can I do?
A: Consider creating a view that groups by all the columns or expressions in the view
you want and adds a COUNT_BIG(*) column. Then create a unique clustered index on
the grouping columns. The grouping process ensures uniqueness. This isn't really the
same view, but it might satisfy your needs.

Q: I have a view defined on top of another view. SQL Server won't let me index the
top-level view. What can I do?
A: Consider expanding the definition of the nested view by hand into the top-level view
and then indexing it, indexing the innermost view, or not indexing the view.

Q: Why do indexed views have to be defined WITH SCHEMABINDING?

A: So that both of the following conditions are met:

1) All objects the view references are unambiguously identified using

schemaname.objectname, regardless of which user is accessing the view.
2) The objects referred to in the view definition can't be altered in a way that would
make the view definition illegal or force SQL Server to re-create the index on the view.

Q: Why can't I use OUTER JOIN in an indexed view?

A: Rows can logically disappear from an indexed view based on OUTER JOIN when
you insert data into a base table. This makes incrementally updating OUTER JOIN
views relatively complex to implement, and the performance of the implementation
would be slower than for views based on standard (INNER) JOIN.

UDF
Q: What are the types of functions, and how they are used?
A: Functions can be scalar or table-valued. A scalar function returns a single value,
whereas a table-valued function returns a table variable.

Q: What is an Inline Function?

A: It’s a special table-valued function that returns a table data type and can be used to
achieve the functionality of parameterized views.

Q: When is a function deterministic?

A: A function is deterministic when it always returns the same value any time for a
specific set of input values.

Q) How functions degrade the performance?

A) Using a function in a where condition forces the function to be calculated for every
row. Plan on storing the data in the way that it will be searched by a where condition,
rather than depending upon manipulation the data with function at query time.

Procedure
Q: What is stored procedure?
A: Transact-SQL stored procedure is a set of T-SQL code that is stored in a SQL
Server database and compiled when used.

Q: What are the benefits of Stored Procedure?

A: (1) SQL server compiles each proc once and then reutilizes the execution plan
(2) Executing the processing at the server instead of the desktop greatly reduces
the network traffic.
(3) Proc offer modularity and code reuse.
(4) Enhanced security control by direct access to the tables can be denied and all
Access to the data can be controlled.

Q: Can a procedure contain Create Procedure Statement?

A: A procedure can contain any valid Transact-SQL command except these: CREATE
DEFAULT, CREATE FUNCTION, CREATE PROC, CREATE RULE, CREATE
SCHEMA, CREATE TRIGGER, CREATE VIEW, SET SHOWPLAN_TEXT, and SET
SHOWPLAN_ALL.
some commands (such as CREATE PROCEDURE, CREATE VIEW, SET
SHOWPLAN_TEXT, SET SHOWPLAN_ALL, and so forth) must be the first (or only)
statement in a command batch, and therefore aren't allowed in stored procedures.

Q: What are the advantages of Proc over Ad hoc queries?

A: stored procedures have a number of advantages over ad hoc queries, including
Execution plan retention and reuse
Query auto parameterization
Encapsulation of business rules and policies
Application modularization
Sharing of application logic between applications
Access to database objects that is both secure and uniform
Consistent, safe data modification
Network bandwidth conservation
Support for automatic execution at system start-up

Q: What is Deferred Name resolution?

A: Generally, object names referenced by a procedure aren't resolved until it's
executed. In SQL Server parlance, this is known as deferred name resolution.

Q: Where does stored procedure code saves?

A: When you create a procedure is that its syntax is checked and its source code is
inserted into the syscomments system table.

Q: Can anyone execute procedure?

A: Only members of the sysadmin, db_owner, or db_ddladmin role (or those explicitly
granted CREATE PROC permission by a member of the appropriate role) can execute
CREATE PROCEDURE.

Q: What is the size and max number of parameter a procedure can have?
A: The maximum stored procedure size is 128MB. The maximum number of
parameters a procedure may receive is 1,024.

Q: How to view source code of procedure?

A: sp_helptext lists the source for a stored procedure.
Create a procedure using the WITH ENCRYPTION option if you want to keep its source
code from being viewable by users.

Q: Is it necessary to set QUOTED_IDENTIFIER, ANSI_NULLS, NOCOUNT within

stored procedure?
A: Set the QUOTED_IDENTIFIER and ANSI_NULLS options before you execute
CREATE PROCEDURE (in its own command batch) because they're reset to the values
they had at the time the procedure was created when it's executed (their values are
stored in the status column of the procedure's row in sysobjects). This change lasts only
for the duration of the procedure; afterward, they're restored to whatever they were
before you executed the procedure. Setting QUOTED_IDENTIFIER or ANSI_NULLS
inside a stored procedure has no effect on the execution of the stored procedure.
SET QUOTED_IDENTIFIER allows references to objects with names with embedded
spaces.
As a rule, SET NOCOUNT ON should be the first statement in every stored procedure
you create because it minimizes network traffic between SQL Server and client
applications. Setting NOCOUNT on disables DONE_IN_PROC messages—the
messages SQL Server normally sends to the client indicating the number of rows
affected by a T-SQL statement. Because these messages are very rarely used,
eliminating them conserves network bandwidth without really giving up any functionality
and can speed up applications considerably.
If ANSI_NULLS is actually off at the time of the SELECT, as the SET command inside
the procedure specifies, the SELECT should return all the rows in the Northwind
Customers table. As you can see, this is not what happens. Now change the SET
ANSI_NULLS command that precedes the CREATE PROCEDURE to turn ANSI null
handling OFF, and rerun the procedure.
SET ANSI_NULLS allows comparisons between variables or columns and NULL values
to work as you would expect.

Q: Is there any difference between create and alter procedure?

A: The advantage of using ALTER PROCEDURE to change a stored procedure is that
it preserves access permissions, whereas CREATE PROCEDURE doesn't. A key
difference between them is that ALTER PROCEDURE requires the use of the same
encryption and recompile options as the original CREATE PROCEDURE statement. If
you omit or change them when you execute ALTER PROCEDURE, they'll be omitted or
changed permanently in the actual procedure definition.
Q: How to create Proc, View, UDF within procedure?
A: You can create procedures, views, UDFs, and other objects from within stored
procedures by using sp_executesql and EXEC().

Q: Is it mandatory to call stored procedure with owner name?

A: Omitting the owner from a procedure call causes SQL Server to momentarily place a
compile lock on the procedure because it cannot locate it immediately in the procedure
cache. This lock is released once the procedure-sans-owner is located in the cache, but
can still cause problems in high-throughput environments

Q: Write down proc Execution Plan Compilation and Execution

A: When you execute a stored procedure for the first time, it's compiled into an
execution plan. This plan is not compiled into machine code or even byte codes, but is
pseudo-compiled in order to speed execution. By "pseudo-compiled" I mean that object
references are resolved, join strategies and indexing selections are made, and an
efficient plan for executing the work that the procedure is to carry out is rendered by the
SQL Server query optimizer. The optimizer compares a number of potential plans for
performing the procedure's work and selects the one it thinks will cost the least in terms
of total execution time. It bases this decision on a number of factors, including the
estimated I/O cost associated with each plan, the CPU cost, the memory requirements,
and so on.
Once an execution plan has been created, it's stored in the procedure cache for future
execution. This cache grows and contracts as necessary to store execution plans for
the stored procedures and ad hoc queries executed by the server. SQL Server balances
the need to supply adequate memory to the procedure cache with the server's other
memory requirements, such as providing adequate resources for the data cache.
Obviously, memory taken up by cached execution plans can't be used to cache data, so
the server manages this carefully. Caching execution plans in memory saves the
optimizer from having to construct a new plan each time a procedure is executed, and
can improve performance dramatically.

Q: Which one is efficient sp_executesql or EXEC()?

A: You can use sp_executesql rather than EXEC() to execute dynamic T-SQL.
execution plan for the dynamic T-SQL string the procedure creates and executes is not
cached. Note that there's no CacheMiss, CacheInsert, CacheHit, or ExecContextHit
event corresponding to the dynamic SQL query near the end of the trace log. Let's see
what happens when we change the EXEC() call to use sp_executesql instead.
CacheInsert event that occurs for the dynamic SELECT statement now that we are
calling it via sp_executesql. This indicates that the execution plan for the SELECT
statement has been inserted into the cache so that it can be reused later. Whether it
actually will be reused is another matter, but at least the possibility exists that it can be.
If you run the procedure a second time, you'll see that the call to sp_executesql itself
generates an ExecContextHit event rather than the CacheMiss event it causes the first
time around. By using sp_executesql, we've been able to use the procedure cache to
make the procedure run more efficiently. The moral of the story is this: sp_executesql is
generally a more efficient (and therefore faster) method of executing dynamic SQL than
EXEC().

Q: Can we force procedure recompilation plan?

A: You can also force a procedure's execution plan to be recompiled by
Creating the procedure using the WITH RECOMPILE option
Executing the procedure using the WITH RECOMPILE option
Using the sp_recompile system procedure to "touch" any of the tables the procedure
references (sp_recompile merely updates sysobjects' schema_ver column)
Once an execution plan is in the cache, subsequent calls to the procedure can reuse
the plan without having to rebuild it. This eliminates the query tree construction and plan
creation that normally occur when you execute a stored procedure for the first time, and
is the chief performance advantage stored procedures have over ad hoc T-SQL
batches.

Q: How to automatically load execution plan?

A: A clever way of loading execution plans into the cache at system start-up is to
execute them via an autostart procedure. Autostart procedures must reside in the
master database, but they can call procedures that reside in other databases, forcing
those procedures' plans into memory as well. If you're going to take this approach,
creating a single autostart procedure that calls the procedures you want to load into the
cache rather than autostarting each procedure individually will conserve execution
threads (each autostart routine gets its own thread).

Q: Executing a Stored Procedure via Remote Procedure Calls (RPC)

A: As an aside, one thing I should mention here is that the call to a stored procedure
need not be a T-SQL batch. The ADO/OLEDB, ODBC, and DB-Library APIs all support
executing stored procedures via RPC. Because it bypasses much of the usual
statement and parameter processing, calling stored procedures via the RPC interface is
more efficient than calling them via T-SQL batches. In particular, the RPC API facilitates
the repetitive invocation of a routine with different sets of parameters.
{ CALL dbo.ListCustomersByCity}

Q: Types of Procedure
A: User defined Stored Procedure-A Transact-SQL stored procedure is a set of T-
SQL code that is stored in a SQL Server database and compiled when used.
Temporary Procedures-You create temporary procedures the same way you create
temporary tables—a prefix of a single pound sign (#) creates a local temporary
procedure that is visible only to the current connection, whereas a double pound sign
prefix (##) creates a global temporary procedure all connections can access.
Temporary procedures are useful when you want to combine the advantages of using
stored procedures such as execution plan reuse and improved error handling with the
advantages of ad hoc code. Because you can build and execute a temporary stored
procedure at run-time, you get the best of both worlds. For the most part, sp_executesql
can alleviate the necessity for temporary procedures, but they're still nice to have
around when your needs exceed the capabilities of sp_executesql.
System Procedures-System procedures reside in the master database and are
prefixed with sp_. You can execute a system procedure from any database. When
executed from a database other than the master, a system procedure runs within the
context of that database. So, for example, if the procedure references the sysobjects
table (which exists in every database) it will access the one in the database that was
current when it was executed, not the one in the master database, even though the
procedure actually resides in the master.
Extended Stored Procedure-Extended procedures are routines residing in DLLs that
function similarly to regular stored procedures. They receive parameters and return
results via SQL Server's Open Data Services API and are usually written in C or C++.
They must reside in the master database and run within the SQL Server process space.
Although the two are similar, calls to extended procedures work a bit differently than
calls to system procedures. Extended procedures aren't automatically located in the
master database and they don't assume the context of the current database when
executed. To execute an extended procedure from a database other than the master,
you have to fully qualify the reference (e.g., EXEC master.dbo.xp_cmdshell 'dir').
Internal Procedures-A number of system-supplied stored procedures are neither true
system procedures nor extended procedures—they're implemented internally by SQL
Server. Examples of these include sp_executesql, sp_xml_preparedocument, most of
the sp_cursor routines, sp_reset_connection, and so forth. These routines have stubs in
master..sysobjects, and are listed as extended procedures, but they are actually
implemented internally by the server, not within an external ODS-based DLL. This is
important to know because you cannot drop these or replace them with updated DLLs.
They can be replaced only by patching SQL Server itself, which normally only happens
when you apply a service pack.

Q: System Objects versus System Procedures

A: User-created system procedures are listed as user objects rather than system
objects in Enterprise Manager. Why? Because the system bit of a procedure's status
column in sysobjects (0xC0000000) isn't set by default. You can call the undocumented
procedure sp_MS_marksystemobject to set this bit. The lone parameter taken by the
procedure is the name of the object with the system bit you wish to set. Many
undocumented functions and DBCC command verbs do not work properly unless called
from a system object. Check the IsMSShipped property of the OBJECTPROPERTY()
function to determine whether an object's system bit has been set.System procedures
and system objects are two different things.

Q: What is recursion in Stored procedure

A: Because Transact-SQL supports recursion, you can write stored procedures that call
themselves. Recursion can be defined as a method of problem solving wherein the
solution is arrived at by repetitively applying it to subsets of the problem.

Q: Why should I use stored procedures in preference to functions?

A: Stored procedures are usually used to perform an action, like update, insert, or
delete, whereas functions are usually used to perform calculations. Functions cannot be
used to execute DML statements.
Q: What is the differences and similarities between functions and stored
procedures?
A: Procedure and Function offer same functionality like code reuse, hiding the sql
details, compiled and optimized in the same way, and centralized maintenance

-> Functions cannot alter data or objects in a server. Procedures can manipulate data
and objects inside the database and server.
-> Proc called independently while function are called from within another sql statement.
-> Proc allow you to enhance application security
-> Function must always return value (either scalar or table) while proc returns value or
nothing at all.
-> Function parameter is differ from proc in that even if the default is desired, the
parameter is required to call the function.

Q: Can a stored procedure execute a return?

A: Yes, a stored procedure can return a value or a result set, using the OUTPUT option.

Q: Which operations can a stored procedure not perform?

A: USE, SET SHOWPLAN_TEXT, and SET SHOWPLAN_ALL cannot be performed
inside a procedure.

Q: Where are stored procedures stored?

A: A stored procedure is a database object, so it is stored in the database in which it is
created. There are references to a stored procedure in several system tables, including
sysobjects (one line per procedure), syscolumns (one line per parameter), sysdepends
(one line per referenced table, view, or procedure), and syscomments (one line per
block of 255 characters of source SQL).

Q: Is a stored procedure faster than a batch?

A: Tomorrow we’ll look more closely at procedure performance issues. For now, I’ll say,
“Yes, most of the time.”

Q: How do I get a list of all stored procedures in the system?

A: On a database-by-database basis, you can execute this statement to retrieve a list of
stored procedures:
select name
from sysobjects
where type = “P”

Q: How do I get a list of parameters for a procedure?

A: Use sp_help procedure-name.

Q: Can I write a system stored procedure?

A: Yes.
Q: What does “group number” refer to?
A: If you try to create a procedure whose name already exists, you get this error
message:
Msg 2729, Level 16, State 1
Object ‘oops’ group number 1 already exists in the database.
Choose another procedure name
Group numbering allows you to create sets of procedures with the same name, but
different sequence numbers. For instance, to add a procedure oops to group 2, I would
execute:
create proc oops;2
as
…
This creates a maintenance nightmare because (1) you can’t run any stored procedures
against the procedure, and (2) you have to drop all of the procedures belonging to a
group at once.
Don’t mess with it … it’s ugly.

Q: Why does the server need to keep multiple plans in memory for a single
procedure?
A: Each execution of a procedure needs a private execution space. That’s where
session information (temporary table names, local variable values, cursor information,
and global variables) is stored, and it’s where the procedure actually runs. In order to
allow multiple users to execute the same procedure concurrently, SQL Server needs to
load multiple versions of the procedure.

Q: Do I need to worry about exactly matching the data types of parameters to the
data types of referenced columns?
A: Absolutely. When you are planning to pass a stored proc parameter to a WHERE
clause, you should make certain that the parameter matches in both data type and
length. (Don’t worry about nullability: all parameters and variables allow null values.)
Take the time to look up the data type using the Enterprise Manager or sp_help. If you
fail to pass the proper data type, SQL Server may be forced to guess about
optimization, and that’s never a good thing.

Q: I thought that variables in the WHERE clause created an optimization problem.

How do I avoid variables in my queries within stored procedures? And what is the
point of using procedures if I can’t use variables??
A: On Day 15, we said that a query containing a local variable in the WHERE clause
would use the magic or guessing method of optimization, rather than referring to the
statistics page. For example, in this batch, SQL Server does not know the value of the
variable at optimization time, so it cannot look up its value and determine the selectivity
of the WHERE clause:
declare @start datetime, @end datetime
select @start = “1/1/97”, @end = “12/31/97”
select pubdate, price
from titles
where pubdate between @start and @end -- optimizer must
guess with local vars

If you perform the same query in a procedure where the start and end dates are
parameters, SQL Server knows the values of the parameters at optimization time, so it
substitutes them in the query to develop an optimization plan:
(@start datetime, @end datetime)
as
select pubdate, price
from titles
where pubdate between @start and @end -- optimizer can look up
parameter vals
return

Procedures solve the optimization problem by knowing the parameter values at

optimization time and using them to determine the selectivity of the WHERE clause.

Q: How do I guarantee the performance of an update procedure?

A: Updates are tricky. The problem is that you don’t want to update all columns in the
procedure if only one column is changing. Consider this example:
create proc pr_x_update
(@id int, @col1 int, @col2 int)
as
update x
set col1 = @col1,
col2 = @col2
where id = @id
return

The procedure works fine, but may perform horribly. The problem concerns the style of
update. Certain changes to a row cause SQL Server to perform a complete overhaul of
the row (a direct or deferred update), whereas other changes only cause a modification
of the changed column values (a direct update in place). The difference in performance
can be dramatic.
SQL Server decides what form of update to use at optimization time from your syntax
and from what it knows about the table. If the UPDATE statement in the stored
procedure modifies every column (even if the value hasn’t changed), update
performance may suffer. There are lots of workarounds, including coding every possible
variety of UPDATE statement in your procedure and running the one that corresponds
with the modified variables. A more modest approach would be to modify sets of related
data, especially in tables with many columns.

Q: How do applications retrieve information about errors and stored procedure

return status?
A: SQL Server returns error and return status information to the application in the same
network data packets as result sets and other communications. The interface software
(db-library or ODBC or some other system) works through the network data packets.
Errors and messages are filtered out of that data stream and forwarded to the error- and
message-handling routines your application designates. (The difficult part about dealing
with errors is developing a method of communicating error information between the
generic error and message routines and the part of the application that was running
when the error was generated.)
Return status is easier to retrieve. The server includes procedure return status in the
same data stream as result sets and errors. The return status is retrieved within the
same procedure as the query result, so the coordination of error checking and
application behavior is far simpler than using error messages.

Q: Procedures seem to require a lot of work, compared to ordinary SQL. Do their

benefits outweigh the work required?
A: Procedures provide performance benefits, including reduced network traffic and
stored optimizations. They also provide a method of storing units of well-tested, solid
SQL code that perform necessary functions. The fact is that much of the error-checking
and special handling required in stored procedures would have to be performed by your
application otherwise. So, yes, on the whole, stored procedures do provide an overall
benefit.

Q: Should I trap specific errors within stored procedures?

A: Not usually. Any non-zero error is a warning that something went wrong, causing a
process to fail. (Don’t use the RAISERROR method of communication with a non-zero
severity yourself unless something failed.) Your application can determine what the
error was and how to treat it. In the procedure, you should probably just clean up the
mess and exit.

Q: When I find an error inside my procedure, @@error is always 0 inside the error
trap. What’s going on?
A: You’ve written the error trap incorrectly. Your code probably looks like this:
declare @err int, @rcount int
-- variables to store error and rowcount
update titles -- statement that causes the error to occur
set title_id = “RR1234”
select @err = @@error, @rcount = @@rowcount
if (@err != 0) or (@rcount = 0)
-- check the error and rowcount
begin
raiserror (“Error in update. Error no is %d, rowcount is %d”,
0, 1, @err, @rcount)
return
end

Msg 2627, Level 14, State 1

Violation of PRIMARY KEY constraint ‘UPKCL_titleidind’:
Attempt to insert duplicate key in object ‘titles’.
Command has been aborted.
Error in update. Error no is 0, rowcount is 0

The first four lines of the output are generated by SQL Server. The error number is 2627
, and the message provides more detailed information. The last line of output is from our
RAISERROR message. Notice that the value of the error that was substituted is 0. The
global variable, @@error , reports the error code from the last statement executed . If
the statement succeeds, @@error is 0; any failure results in a non-zero error code. In
this case, the error code reported in our RAISERROR statement is the status of the if
@@error = 0 statement, which worked beautifully!

If you need to reuse the value of @@error , you must store it in a variable as soon as it
is available (This is also true of @@rowcount .) Here’s how to capture and report
@@error :
Msg 2627, Level 14, State 1
Violation of PRIMARY KEY constraint 'UPKCL_titleidind':
Attempt to insert duplicate key in object 'titles'.
Command has been aborted.
Error in update. Error no is 0, rowcount is 0

Msg 2627, Level 14, State 1

Violation of PRIMARY KEY constraint 'UPKCL_titleidind':
Attempt to insert duplicate key in object 'titles'.
Command has been aborted.
Error in update. Error no is 2627, rowcount is 0
The correct error number was reported.

Q: Which is faster, a stored procedure or a trigger?

A: Stored procedures and triggers use the same execution method to run, including the
use of procedure cache to store precompiled execution plans. So, technically speaking,
neither is faster.
On the other hand, you can often design a better performing system by using stored
procedures than by relying on triggers. The difference is in the order of execution.
Triggers fire only after the data is in the table. If any validation tests fail in a trigger, the
work already performed needs to be rolled back.
Stored procedures execute in the order you designate. You can check data validity first,
so data modifications are only performed on good data. This can reduce concurrency
problems and improve overall system performance.

Q: Temporary table lifetime in stored procedure.

A: Lifetime of a temporary table created inside of a stored procedure is the stored
procedure itself, ie. the temporary table no longer exists once the stored procedure
completes. In this case, the stored procedure that's scoping the temp table is
"sp_executesql". But... if proc A creates a temporary table and then (inside proc A) calls
proc B that reads it, that's fine. Because nested procs can see "temp" tables created
within outer scopes.
Q: How to select columns from stored procedure?
A: Using “openrowset”

SELECT * FROM
OPENROWSET('sqloledb','server_name';'user_name';'password','exec
database.owner.stored_procedure')

Q: How can we call stored procedures inside store procedures?

A:
Create procedure p1
as
exec sp_helptext p1

Q: Does storing of data in stored procedures increase the access time? Explain?
A: Data stored in stored procedures can be retrieved much faster than the data stored in
SQL database. Data can be precompiled and stored in Stored procedures. This reduces
the time gap between query and compiling as the data has been precompiled and
stored in the procedure. To avoid repetitive nature of the data base statement caches
are used.

Trigger

Q: What is trigger?
A: A trigger is a special kind of stored procedure that automatically executes when an
event occurs in the database server.

Q: Types of trigger.
A: DML-DML triggers execute when a user tries to modify data through a data
manipulation language (DML) event. DML events are INSERT, UPDATE, or DELETE
statements on a table or view.
DDL-DDL triggers execute in response to a variety of data definition language (DDL)
events. These events primarily correspond to Transact-SQL CREATE, ALTER, and
DROP statements, and certain system stored procedures that perform DDL-like
operations.
Logon trigger-Logon triggers fire in response to the LOGON event that is raised when a
user sessions is being established.

Q: Use of trigger.
A:
- prevent changes (e.g. prevent an invoice from being changed after it's been mailed
out)
- log changes (e.g. keep a copy of the old data)
- audit changes (e.g. keep a log of the users and roles involved in changes)
- enhance changes (e.g. ensure that every change to a record is time-stamped by the
server's clock, not the client's)
- enforce business rules (e.g. require that every invoice have at least one line item)
- execute business rules (e.g. notify a manager every time an employee's bank account
number changes)
- replicate data (e.g. store a record of every change, to be shipped to another database
later)
- enhance performance (e.g. update the account balance after every detail transaction,
for faster queries)
- DDL triggers can be used for auditing purposes.
- Use triggers only if logs for table needs to be maintained.

Q: Disadvantage of using trigger

A: SQL trigger only can provide extended validation and cannot replace all the
validations. Some simple validations can be done in the application level.  For example,
you can validate input check in the client side by using javascript or in the server side by
server script using PHP or ASP.NET.
SQL Triggers executes invisibly from client-application which connects to the database
server so it is difficult to figure out what happen underlying database layer.
SQL Triggers run every updates made to the table therefore it adds workload to the
database and cause system runs slower.

Q: Argument over SP
A: They will argue that all access to the database should go thru stored procedures
because it is more secure and shields applications from changing logic. The other side
will vehemently argue that you should avoid this because not all databases support this
and the way each supports it is different so your code is less portable.

Q: How trigger is different from SP

A: Triggers are first and foremost stored procedures in terms of how SQL Server treats
them internally. They undergo similar processing phases to stored procedures (parsing,
resolution, and optimization). However, triggers do not have an interface (input and
output parameters), and you cannot invoke them explicitly. They fire automatically as a
result of a statement submitted against the database server.

Q: Constraint and trigger

A: A database trigger is not the same as an integrity constraint. A database trigger
defined to enforce an integrity rule does not check data already loaded into a table.

Q: If I define multiple triggers on a single table, what is the order of the triggers
firing?
A: The triggers will execute in random order; you cannot rely on the order of triggers
firing.

Q: What are the types of triggers, and how are they used?
A: Triggers can be DML, DDL, or Logon types. DML triggers fire with insert, delete, and
update operations. DDL triggers fire with DDL operations, such as CREATE and
GRANT. Logon triggers fire when a login connects an instance.

Q: What are the types of DML triggers?

A: Triggers can be AFTER or INSTEAD OF types. You use an AFTER trigger when you
want a trigger to fire only after SQL Server completes all actions successfully. You use
an INSTEAD OF trigger when you want to perform a different operation from the
statement that fires that trigger.

Q: Can I create a trigger on a system table?

A: You can create a trigger on certain system tables and they will fire. (During my
casual testing, a trigger on sysusers fired after I executed sp_adduser; a trigger on
sysobjects did not fire after CREATE TABLE. You can easily test the behavior for any
operations on a table you would like to monitor. Be sure to conduct your tests in a
database you aren’t concerned about losing!)
There are some interesting applications for triggers on system tables. You can send
automated e-mail notifications to the dbo or sa if there are changes to important tables.
You can audit modifications to those tables.
If you are considering a trigger on a system table, you might find it easier to modify the
appropriate system procedures instead. Most modifications to system tables occur in
those procedures; it will certainly be easier to maintain a single unit of code (a
procedure) than two (a procedure and a trigger).
One word of caution: don’t try to put a trigger on syslogs (or make any direct
modifications to syslogs). Direct updates to syslogs can send the server into an infinite
loop!

Q: Are there actions you can’t perform in a trigger?

A: Some of the restrictions from earlier versions of SQL Server have been relaxed. In
general, you can’t do any work that alters the transaction logs or the structure of tables
or other objects. Here’s a brief list of what’s against the rules:
•  Creating objects or databases
•  Dropping objects or databases
•  Altering tables or databases
•  Truncating tables (this operation is minimally logged, so it could imperil the integrity of
the trigger and its transaction context)
•  Granting and revoking privileges
•  Updating statistics
•  Reconfiguring the server
•  Dumping databases and transactions (backing up data)
•  Loading databases and transactions (restoring from backup)
•  Generating disk statements (to create and manage devices)
With release 6.5, it’s now possible to use SELECT…INTO to create a temporary or
permanent table on the fly. (As it turns out, creating a permanent table on the fly won’t
be very effective because concurrent users will collide with each other on the object
name. If you think of a good application for creating a permanent table in a trigger,
please let us know!)
On the other hand, creating a temporary table with SELECT…INTO has many
applications in a trigger. Most importantly, you can use a temporary table as a space to
pass the contents of the inserted or deleted table to a stored procedure. Without this
capability, you need to use a permanent worktable to pass those values (remember,
procedure parameters are scalar values, not arrays), and that introduces complex
multiuser performance and concurrency issues.

Q: Can I use a trigger to assign a unique row ID?

A: Yes, but it’s probably not a good idea for a number of reasons. The most efficient
method of assigning unique counter values is to create an identity column for the table,
coupled with a unique index. Some people are reluctant to use identity columns
because identity columns are frequently “burned,” that is, used up without being
assigned to an actual row.
Here’s what the code would look like to manage counters in a trigger:
/* please don’t do this */
create trigger tr
on t
for insert
as
if @@rowcount = 0 return
declare c cursor for
select altid
from inserted
open c
declare @altid int
fetch c into @altid
while @@fetch_status = 0
begin
update counter_table
set @id = id = id + 1
update t
set id = @id
where altid = @altid
fetch c into @altid
end
close c
deallocate c
return

Several performance problems are introduced. First, the trigger needs to use a cursor to
handle multirow inserts. Cursors are slow, so updates will be slower and locking will be
more complex. Second, the use of the counter_table introduces another lock, and this
will be a far more intrusive lock than the one on your primary table. Each user
performing an insert will need to visit this table and will do so as a part of his or her
transaction. You will single-thread all inserts using this method. Contrast this with a
memory semaphore used to handle identity counters, where the locking of an identity
value is not part of the overall transaction locking function.
This method also requires the use of an alternate key, some other method of uniquely
identifying the row you want to update. Without an alternate identifier, it’s impossible to
correlate a row in the inserted table with the row in the base table that will obtain the
new counter value.
Finally, the additional update on the base table will triple the logging and memory-based
data management work versus the comparable trigger approach.

Query Tuning and optimization

Q: What’s happening when SQL Profiler reports missing events?
A: This happens occasionally with very busy servers when tracing to a table or to SQL
Profiler. In this situation the SQL Profiler tool is unable to keep up with the volume of
events that are generated. Consider using a server side trace and saving the trace to a
flat file, local to the database server.

Q: How big will the trace file grow?

A: The size of trace files is determined by the workload, events, and columns included
in the trace definition. A very busy server with only a few events defined can produce a
file as large as a quiet server with many events included. Be sure to monitor the growth
of trace files to ensure they don’t fill any drives, and if you’re leaving a trace unattended
(e.g., overnight) ensure that there is plenty of disk space to include activities such as
nightly maintenance or data loads.

Q: Is it safe to run Database Tuning Advisor on my production server?

A: No. It’s a good idea to run DTA on a test server because it can make heavy use of
the Query Optimizer to calculate alternative execution plans. Production performance
could suffer during this time.

Q: Why shouldn’t we use query hints in production code?

A: The optimizer usually does a better job of figuring out what to do than we can.
Occasionally, we can beat the optimizer and make it perform things more efficiently than
it might otherwise choose, but those cases are the exception, not the rule. In addition,
we often base our tests on unrealistic sample data. When real, more naturally
distributed data becomes available, or the nature of the data distribution changes over
time, the optimizer will in the long run likely make a better choice. In fact, when the data
changes, the hints we hard coded can then be causing a less efficient plan to be used.

Q: Why should I use the MERGE statement, when I can write the same
functionality with individual INSERT, UPDATE, and DELETE statements?
A: The MERGE statement is especially optimized, and results in better performance,
mainly due to locking optimizations. Also, a well-written MERGE statement will be
simpler to read and write than the equivalent expressed by the individual INSERT,
UPDATE, and DELETE statements.

Q: If I want to prevent a statement from running by setting the Query Governor

cost limit, how do I determine what cost value to set it to?
A: Enter the statement you wish to prevent from running into a query window in SQL
Server Management Studio. Display its estimated execution plan and read the total sub-
tree cost from the last step in the plan. Round down to the nearest integer and use that
as your cost.

Q: Don’t functions take CPU time to operate? Why didn’t you mention the
performance implications of that?
A: Functions do take time to operate, but in the SQL Server world, the bottleneck on
performance is almost always disk I/O. CPU time is cheap but data access is
expensive. If a function can save disk I/O, the small CPU hit is worth it. Remember,
however, that applying a function to a column in the WHERE clause prevents the server
from using an index to resolve the query.

Q: Does the order of the tables in the FROM clause affect performance?
A: The short answer is “No.” MS SQL 6.5 was improved to deal with multitable queries
in a better way than ever before. In previous versions, some queries that referenced
over four tables could, in rare cases, miss a possibility for better join performance.

Q: Is there a way to calculate the CPU processing impact of compression?

A: No, we can estimate the storage but not the CPU costs. You will have to create
compressed and noncompressed versions of a table and measure the performance
costs of working with both of them.

Q: Can I examine the contents of a server-generated worktable?

A: No. Even though the server uses space in tempdb to store worktables, you can’t find
any evidence of them or examine their contents.

CLR
Q: When should I choose to use the CLR over Transact-SQL to implement
database objects?
A: You should use the CLR only when the functionality you are trying to implement is
very difficult or impossible to write using Transact-SQL. For example, you simply cannot
use Transact-SQL to read files or the registry. Also, if your functionality requires a
cursor in Transact-SQL, you may get more simplicity and better performance out of a
CLR aggregate.

Q: Do I need to obtain and install Visual Studio to develop CLR integrated

objects?
A: No, you can create source files in Notepad and compile them using a command-line
compiler found in the .NET Framework SDK. However, Visual Studio offers an
integrated development environment with visual feedback and intelligence suggestions.
If you are undertaking a large-scale commercial development, you will benefit greatly
from Visual Studio features.

Q: What is the difference between managed and unmanaged code?

A: Managed code is written in a .NET language, and when it executes it is serviced by
the CLR. The CLR ensures that the code is stable (that the code does not attempt any
illegal operations) and applies code access security. Managed code accesses system
resources using the Base Class Library. Unmanaged code, also known as native code,
is written in a language like C or C++. This code accesses low-level resources such as
memory and the disk directly. It is not subject to safety or security checking. It is
possible to severely damage the system using unmanaged code, cause a Blue Screen
of Death, or compromise security in some unlikely cases. Basically, managed code is
more likely to be a good citizen on the system.

Q: Why is it a best practice that I use AUTHORIZATION dbo when registering

assemblies using CREATE ASSEMBLY?
A: The AUTHORIZATION parameter specifies the owner of the assembly. An assembly
cannot call another assembly that is owned by a different person. The one exception is
that any assembly can call assemblies owned by dbo. As you cannot register an
assembly twice, specifying a variety of owners for your assemblies will cause ownership
chaining issues. Therefore, it is a best practice to register your assemblies as
AUTHORIZATION dbo .

Q: How do I know whether an assembly is calling external resources using

P/Invoke, and therefore needs to be registered as UNSAFE?
A: To find P/Invoke calls, look in the assembly source code for functions declared as
extern and marked with the DllImport attribute. The easiest way is simply to look for the
keywords extern and DllImport using the Find feature of Visual Studio. If found, the
assembly is performing P/Invoke and must be registered as UNSAFE.

Q: For the exam, do I need to learn the syntax of a .NET language like Visual
Basic and C#?
A: No, you will not be required to write .NET code or find deliberate mistakes in .NET
code. You should be able to read the code, and understand what it is trying to do. Focus
your efforts on understanding SQL statements, and concepts related to CLR integration,
like CREATE ASSEMBLY , PERMISSION_SET , and EXTERNAL NAME .

XML
Q: Can I specify the format of an XML document using FORXML?
A: Yes. You need to use the EXPLICIT mode in the FORXML DDL.

Q: How many elements can be opened with sp_xml_preparedocument?

A: The number of elements that can be open at one time with
sp_xml_preparedocument is 256.

Q: Can I use XPath queries in my XQuery statements?

A: Yes. The query in an XQuery statement is an XPath query.

Q: What version of SQLXML is used in SQL Server 2008?

A: The version that is used is SQLXML 4.0.

Q: Are there some features of XPath language that are not supported?
A: Yes, in Microsoft SQLXML 4.0, some features are not supported. For example, the
arithmetic operator, mod, is not supported. You can see a list of Unsupported XPath
features in Books Online under Using XPath Queries in SQLXML4.0.

Q: If I don’t have a root tag in my XML document, is it still “well-formed”?

A: No. You must always have a root tag in your XML document.

SSIS
Q: Integration Services Architecture
(i) Integration Services Service: The Integration Services service, available in SQL
Server Management Studio, monitors running Integration Services packages and
manages the storage of packages.
(ii) Integration Services Object Model: The Integration Services object model includes
managed application programming interfaces (API) for accessing Integration Services
tools, command-line utilities, and custom applications.
(iii) Integration Services Runtime and the runtime executable: The Integration Services
runtime saves the layout of packages, runs packages, and provides support for logging,
breakpoints, configuration, connections, and transactions. The Integration Services run-
time executables are the package, containers, tasks, and event handlers that
Integration Services includes, and custom tasks.
(iv) Integration Services Data Flow: The Data Flow task encapsulates the data flow
engine and data flow components. The data flow engine provides the in-memory buffers
that move data from source to destination, and calls the sources that extract data from
files and relational databases. The data flow engine also manages the transformations
that modify data, and the destinations that load data or make data available to other
processes. Integration Services data flow components are the sources, transformations,
and destinations that Integration Services includes. You can also include custom
components in a data flow.

Q: Typical Uses of Integration Services

1) Merging Data from Heterogeneous Data Stores - Data is typically stored in many
different data storage systems, and extracting data from all sources and merging the
data into a single, consistent dataset is challenging.
2) Populating Data Warehouses and Data Marts - The data in data warehouses and
data marts is usually updated frequently, and the data loads are typically very large.
3) Cleaning and Standardizing Data - Whether data is loaded into an online transaction
processing (OLTP) or online analytic processing (OLAP) database, an Excel
spreadsheet, or a file, it needs to be cleaned and standardized before it is loaded.
4) Building Business Intelligence into a Data Transformation Process -
A data transformation process requires built-in logic to respond dynamically to the data
it accesses and processes.
5) Automating Administrative Functions and Data Loading - Administrators frequently
want to automate administrative functions such as backing up and restoring databases,
copying SQL Server databases and the objects they contain, copying SQL Server
objects, and loading data.

Q: Can you explain the SQL Server Integration Services functionality in

Management Studio?
-Login to the SQL Server Integration Services instance
-View the SSIS log
-View the packages that are currently running on that instance
-Browse the packages stored in MSDB or the file system
-Import or export packages
-Delete packages
-Run packages