DateTime2 is the new Data Type introduced in SQL Server 2008 for storing Date and Time value. Microsoft Suggests to use this new Data Type instead of DateTime that is mainly available for backwards compatibility. BOL says:

"Use the time, date, datetime2 and datetimeoffset data types for new work”

Since I can't see when in the near future DateTime will be removed from the product, I thought I'd highlight the main differences between DateTime and DateTime2.

Min\Max value

DateTime  -

BETWEEN ‘1753-01-01 00:00:00’ AND '’9999-12-31 23:59:59.997’

DateTime2 –

BETWEEN ‘0001-01-01 00:00:00’ AND ‘9999-12-31 23:59:59.9999999’

Storage Size

DateTime  - 8 Bytes

DateTime2(n) - 6 to 8 bytes

Note: Parameter n is optional and if it is not specified then fractional seconds precision is 7 digit and it can be from 0 to 7 digit.

For fractional seconds precision <3, takes 6 bytes.

For fractional seconds precision 3 or 4 it will take 7 bytes.

For fractional seconds precision >4 it will take 8 bytes.

Precision

DateTime  - only allows for precision up to every 3rd milisecond which essentially means that you can get rounding issues for times that are in fact different. The rounding is to increments of .000, .003, or .007 seconds.

DateTime2(n) - The precision scale is 0 to 7 digits, with an accuracy of 100 nanoseconds . The default precision is 7 digits.

Note: DateTime2 with fractional seconds precision of 3 is same as DateTime data type. And DateTime2(3) uses 7 bytes of storage instead of 8 byte which old DateTime datatype uses.

conclusion

I believe we should follow MSDN recommendation and use DateTime2 for any new work and thus, we will be safeguarded against future changes and benefit from a larger date range, less storage uses,larger default fractional precision, and optional user-specified precision.

Ever been in a crisis that your SQL Server had a spinloop, maxed out resources or severe corruption and  didn’t respond to standard connection requests, and  With pressure mounting to get SQL Server back online you thought that your  last resort was to reboot the server?

This probably because you either haven’t met or forgotten to turn on the DAC your secret backdoor Privilege connection that SQL server offers to us.

DAC? What’s That?

Since SQL Server 2005, Microsoft offers us new feature, the dedicated administrator connection (DAC) a special diagnostic connection for administrators. This diagnostic connection intended to serve as a last means of defense and access SQL Server to execute diagnostic queries and troubleshoot problems even when SQL Server is not responding to standard connection requests as opposed to rebooting the server and causing us long downtime and  possibly data loss, database corruption and/or access violations.

How the DAC works

SQL Server is keeping a backdoor open  resources available just for the DAC, it uses a special reserved scheduler (scheduler_id = 255)  which has one thread for processing requests.

We are all DBA’s and I know that to many of you the thought of abuse thus resources for your maintenance jobs on busy systems cross your mind. Seriously, just don’t go there.That one thread is just one thread, there’s no parallelism for queries running on the DAC. The DAC was not designed for high performance.

some restrictions

Because the DAC exists solely for diagnosing server problems, there are some restrictions on the connection:

Only One Sysadmin Can Ride This Horse At a Time.

SQL Server prohibits running parallel queries or commands with the DAC - For example statements like RESTORE and BACKUP.

Do not use the DAC to run resource-intensive queries - For example a complex join on large table or queries that may block.

Object Explorer Not available for DAC connection - That’s a good thing, we wouldn’t want the power to go to Object Explorer’s head.

Connecting with DAC

By default, the connection is only allowed  from a client running on the local machine. To enable remote clients to utilize the DAC, an option needs to be set which can be done using sp_configure:

   1: exec sp_configure 'remote admin connections', 1 

   2: reconfigure

it’s Highly recommended to enable the ‘remote admin connections’, Especially on clusters configuration. According to BOL servers in cluster configuration and with ‘remote admin connections’ not enable probably Not receive a DAC connection And you can not escape from rebooting the server.

You may need to get firewall ports opened as well, depending on your environment and where you intend to connect from. SQL Server listens for the DAC on TCP port 1434 if available or a TCP port dynamically assigned upon Database Engine startup. The error log contains the port number the DAC is listening on.

To use the DAC you can either access it using SQLCMD from a command prompt:

sqlcmd –A –d master (the -A uses the DAC and the -d connects to the master database)

sqlcmd –d DBname-E –S ServerName\InstanceName –A (the -E uses Windows authentication and the -S connects the server and instance)

Or The more convenient way is using SQL Management Studio with the ADMIN: option when connecting to the server:

- launch SQL Server Management Studio (don't connect to an instance of SQL Server yet)

- select Database Engine Query (icon right next to "New Query")

- put "ADMIN:" in front of the server\instance name

- use your regular Authentication procedures to connect

- select Connect

Note: Object Explorer can’t connect to the DAC. If you open SSMS and have Object Explorer connecting by default, the first connection prompt you see with be for that. If you try to tell that to connect to the DAC, it’ll fail.

conclusion

In previous versions of SQL Server it was often not possible to diagnose a SQL Server instance which was no longer accepting connections. With DAC an administrator has a guaranteed connection to the SQL Server, and is able to resolve problems without the need for a reboot, or restarting the SQL server instance.

For now check whether you have remote admin connections enabled in your environments and try to connect with the DAC in test environment

For many years, Microsoft SQL Server has supported the ability to create virtual tables known as views. Historically, these view served these main purposes:

-provide a security mechanism that restricts users to a certain subset of data in one or more base tables

-To provide a mechanism that allows developers to customize how users can logically view the data stored in base tables

When you create a view, you add a stored query to the database that can be read in the same manner as a table. The view acts as a virtual table that requires no additional storage space, as the information is read directly from the tables.

A view's performance can be significantly worse than that of a table, particularly when the view reads from several, joined tables. With SQL Server 2000, the functionality of SQL Server views was expanded to provide system performance benefits. It is possible to create a unique clustered index on a view, as well as non-unique and non-clustered indexes but only if a unique, clustered index exists , to improve data access performance on the most complex queries by precomputing and materializing the view. This is often particularly effective for aggregate views in decision support or data warehouse environments.

Creating a unique clustered index on a view changes it to an indexed view. The clustered index is stored in SQL Server and updated like any other clustered index, providing SQL Server with another place to look to potentially optimize a query utilizing the indexed view.

When the first index is added to a view, it is built using a b-tree structure similar to that of a table index. The b-tree includes the data from the columns that are present in the index. However, unlike a table index, all of the columns that are included in the view are also added to the data rows of the index. This can lead to large increases in the storage requirements for a database but improves the view's performance.

Queries that don’t specifically use the indexed view can even benefit from the existence of the clustered index from the view. In the developer and enterprise editions of SQL Server, the optimizer can use the indexes of views to optimize queries that do not specify the indexed view. In the other editions of SQL Server, however, the query must include the indexed view and specify the hint NOEXPAND to get the benefit of the index on the view.

Advantages of Indexed View

Indexed views improve the performance in the following ways:

-Joins and aggregations that process many rows.

-Join and aggregation operations that are frequently performed by  many queries.

-Decision support workloads.

-The real benefits of Indexed Views are when we have aggregates that are too expensive to compute in real time.

-Aggregations can be pre-computed and stored in the index to minimize expensive computations during query execution.

-Tables can be pre-joined and the resulting data set stored.

-Combinations of joins or aggregations can be stored.

-Indexed views may be substituted by the query optimizer if it is determined that the cost of the query will be less than using the base table.

For a standard view, the overhead of dynamically building the result set for each query that references a view can be significant for views that involve complex processing of large numbers of rows, such as aggregating lots of data, or joining many rows. If such views are frequently referenced in queries, we can improve performance by creating a unique clustered index on the view. When a unique clustered index is created on a view, the result set is stored in the database just like a table with a clustered index is stored.

Another benefit of creating an index on a view is that the optimizer starts using the view index in queries that do not directly name the view in the FROM clause. Existing queries can benefit from the improved efficiency of retrieving data from the indexed view without having to be recoded.

Disadvantages of Indexed View

To use an indexed view in all other editions, the NOEXPAND table hint must be used. Indexed views work best when the underlying data is infrequently updated. The maintenance of an indexed view can be greater than the cost of maintaining a table index. If the underlying data is updated frequently, the cost of maintaining the indexed view data may outweigh the performance benefits of using the indexed view.

Another cost of indexed views is that the data is actually stored. By applying the clustered index we are creating a copy of the data. So if we have several indexed views on a single table, we will have several copies of the data, along with the statistics of the data and the indexes and all of the overhead that goes with it.

Following are the disadvantages using index views that do not improve the performance:

-OLTP systems that have many writes to the disk.

-Databases that have many updates.

-Queries that do not involve aggregations or joins.

-High numbers of updates will most likely kill the benefit. If it is mainly reads then it will work fine.

-The overuse of indexed views can be like winding a watch with a wrench.

-Online index rebuilds are not supported for indexed views.

Limitations and Constraints of Indexed View

An index cannot be created on just any view. Several limitations and constraints exist that a view must meet in order for the index creation to be successful. The key restrictions\Constraints are listed below:

-The base tables must have been created with the proper ANSI_NULLS setting.

-The view must have been created with certain SET options, such as QUOTED_IDENTIFIER and CONCAT_NULL_YIELDS_NULL set to ON.

-Indexed views must be created using the SCHEMABINDING option. This option links the view to the schema elements that it uses, disallowing changes to the underlying tables that would break the view. If the   view references user-defined functions, these too must be created using the option.

-Indexed views may only select columns from base tables. They may not retrieve values from other views. The tables must be in the same database as the view and must have the same owner.

-The view must be deterministic (consistently providing the same result given  the same input).

-Any user-defined functions referenced by the view must have been created using WITH SCHEMABINDING and to be deterministic.

-On the content  of the view Must also meet with some requirements For instance, the view may not contain EXISTS or NOT EXISTS, OUTER JOIN, COUNT(*), MIN(), MAX(), subqueries, table hints, TOP, UNION.

-The result set of the view is physically stored in the database, thus storage space for the clustered index is also a constraint to consider.

creating indexed view

First let’s create some tables and put data into them:

   1: CREATE TABLE dbo.employees

   2:     (

   3:         id int NOT NULL, 

   4:         name varchar(255) NOT NULL, 

   5:         CONSTRAINT PK_employees PRIMARY KEY (id), 

   6:         CONSTRAINT UQ_employees UNIQUE (name)

   7:     ) ON PRIMARY

   8:  

   9: CREATE TABLE dbo.roles

  10:     (

  11:         id int NOT NULL, 

  12:         name varchar(255) NOT NULL, 

  13:         CONSTRAINT PK_roles PRIMARY KEY (id), 

  14:         CONSTRAINT UQ_roles UNIQUE (name)

  15:     ) ON PRIMARY

  16:  

  17: CREATE TABLE dbo.lnk_employee_roles

  18:     (

  19:         employee_id int NOT NULL, 

  20:         role_id int NOT NULL, 

  21:         CONSTRAINT PK_lnk_employee_roles PRIMARY KEY (employee_id, role_id), 

  22:         CONSTRAINT FK_lnk_employee_roles__employees FOREIGN KEY (employee_id) REFERENCES dbo.employees (id), 

  23:         CONSTRAINT FK_lnk_employee_roles__roles FOREIGN KEY (role_id) REFERENCES dbo.roles (id)

  24:     ) ON PRIMARY

  25:  

  26: INSERT INTO dbo.employees (id, name)

  27: VALUES 

  28:     (1, 'Employee 1'), 

  29:     (2, 'Employee 2'), 

  30:     (3, 'Employee 3')

  31:  

  32: INSERT INTO dbo.roles (id, name)

  33: VALUES 

  34:     (1, 'Role 1'), 

  35:     (2, 'Role 2'), 

  36:     (3, 'Role 3')

  37:  

  38: INSERT INTO lnk_employee_roles (employee_id, role_id)

  39: VALUES 

  40:     (1, 1), 

  41:     (1, 2), 

  42:     (1, 3), 

  43:     (3, 2), 

  44:     (3, 3)

  45: GO

   1: CREATE VIEW dbo.EmployeeRoles

   2: WITH SCHEMABINDING

   3: AS

   4: SELECT

   5:     e.id as employee_id,

   6:     e.name as employee_name,

   7:     r.id as role_id,

   8:     r.name as role_name

   9: FROM

  10:     dbo.employees e

  11:         INNER JOIN dbo.lnk_employee_roles er ON e.id = er.employee_id

  12:         INNER JOIN dbo.roles r ON r.id = er.role_id

  13: GO

  And finally let’s create the unique clustered index on the view making it an indexed view:

   1: CREATE UNIQUE CLUSTERED INDEX idx_EmployeeRoles

   2: ON dbo.EmployeeRoles (employee_id, role_id)

   3: ON INDEXES

   4: GO

Notice that I create the clustered index on anther filegroup, it to be very useful to store indexes in their own filegroup, especially Indexed Views.

What this means is that the base data (data in base tables) lives on one filegroup and the data for the indexes lives on another filegroup. If these filegroups live on separate storage (ideally separate hard drives with seperate controllers), writes to the base table do not contend with writes to the indexes.

Now let’s see the performance, check out the execution plan for the following query:

   1: SELECT employee_name, role_name FROM dbo.EmployeeRoles

You'll see an index scan on employees.UQ_employees and lnk_employeeroles.PK_lnk_employeeroles, plus a Clustered Index Seek on roles.PK_roles.

Now let’s use the Indexed Views and  compare the  execution plans, run that  query:

   1: SELECT employee_name, role_name

   2: FROM dbo.EmployeeRoles WITH (NOEXPAND)

You'll see only a clustered index scan on EmployeeRoles.idx_EmployeeRoles that provid better performance.

Conclusion

Using Indexed view in SQL Server comes with a cost. But there are places which it perfectly fits and gains up the performance. Be aware of the costs of creating indexed views in highly transactional environments. If your environment happens to be one of more querying than updating, however, indexed views might be just what the optimizer ordered.