BlogmyQuery - BMQ » Sqlserver

Update Multiple Tables with one Statement

kranthi — Wed, 01 Jul 2009 21:02:22 +0000

In real time applications there might be situation where you need update details of one table using details of another or update two or tables using one statement. Below is Example of how you can do that in SQL Server

Update t1 Set t1.col1 = t2.col1 from Table t1 inner join Table t2 on t1.col = t2.col where Condtn

Below is MYSql Example

Update Table t1 inner join Table t2 on t1.col = t2.col Set t1.col1 = t2.col1 where Condtn

DateFirst in SQL Server

kranthi — Wed, 01 Jul 2009 20:07:28 +0000

Select @@DateFirst

returns the current value, for a session, of SET DATE FIRST, i.e it returns first day of week, TinyInt Value from 1 through 7 representing Monday to Sunday as shown Below.

1 for Monday
2 for Tuesday
3 for Wednesday
4 for Thursday
5 for Friday
6 for Saturday
7 for Sunday

For Example, If the first day of week is Sunday (US) , Then @@DateFirst would return 7.

If the first day of week is Monday (Europe), Then @@DateFirst Would return 1.

SET DateFirst = 3

The above statement would set Wednesday as first day of the week for the current Session.

‘July 1st 2009 is a wednesday

SET DateFirst = 1 -- or SET LANGUAGE Italian;
Select DATEPART(dw, '20090701')

would return 3 (since Wednesday is 3rd day from Monday)

SET DateFirst = 7 -- or SET LANGUAGE us_english;
Select DATEPART(dw, '20090701')

would return 4 (since Wednesday is 4th day from Sunday)

DATEPART return the weekday according @@DateFirst.

Calculate businessdays between two dates

jackjeetu1 — Wed, 01 Jul 2009 18:55:21 +0000

This Example shows how to calculate the calculate the workdays between two given dates.

CREATE FUNCTION dbo.GetBusinessDays
(
@startDate SMALLDATETIME,
@endDate SMALLDATETIME
)
RETURNS INT
AS
BEGIN
DECLARE @dateDiff INT;

SET @dateDiff = DATEDIFF(DAY, @startDate, @endDate)+1;

RETURN
(
SELECT @dateDiff/ 7 * 5 + CASE WHEN (@dateDiff % 7) = 0 THEN 0

ELSE

CASE
When (DATEPART(WEEKDAY, @endDate ) + @@DateFirst -1)%7 = 0 and (@dateDiff % 7) =1 Then (@dateDiff % 7)-1 –If it is sunday

When (DATEPART(WEEKDAY, @endDate ) + @@DateFirst -1)%7 = 0 and (@dateDiff % 7) <>1 Then (@dateDiff % 7)-2 –If it is sunday

When (DATEPART(WEEKDAY, @endDate ) + @@DateFirst -1)%7 =6 Then (@dateDiff % 7) – 1 –If it is Saturday

ELSE (@dateDiff % 7)
END — Inner Case

END

);
END

There are many other ways of achieving this , you can also look at the following examples

CREATE FUNCTION dbo.GetWorkingDays
(
@startDate SMALLDATETIME,
@endDate SMALLDATETIME
)
RETURNS INT
AS
BEGIN
DECLARE @range INT;

SET @range = DATEDIFF(DAY, @startDate, @endDate)+1;

RETURN
(
SELECT
@range / 7 * 5 + @range % 7 -
(
SELECT COUNT(*)
FROM
(
SELECT 1 AS d
UNION ALL SELECT 2
UNION ALL SELECT 3
UNION ALL SELECT 4
UNION ALL SELECT 5
UNION ALL SELECT 6
UNION ALL SELECT 7
) weekdays
WHERE d <= @range % 7
AND DATENAME(WEEKDAY, @endDate – d + 1)
IN
(
‘Saturday’,
‘Sunday’
)
)
);
END
GO

or this that i found on one of the forums

DECLARE @start_date DATETIME;
DECLARE @end_date DATETIME;

SET @start_date = '20080820';
SET @end_date = '20080825';

SELECT ((total_days / 7) * 5 + total_days % 7 -
CASE WHEN 6 BETWEEN start_weekday AND end_weekday
THEN 1 ELSE 0 END -
CASE WHEN 7 BETWEEN start_weekday AND end_weekday
THEN 1 ELSE 0 END)
FROM (SELECT total_days, start_weekday,
start_weekday + total_days % 7 - 1
FROM (SELECT DATEDIFF(day, @start_date, @end_date) + 1,
DATEPART(WEEKDAY, @start_date + @@DATEFIRST - 1)
) AS T(total_days, start_weekday)
) AS D(total_days, start_weekday, end_weekday);

NOTE : This example doesnot holidays other than saturday and sunday into account.

Migrating from MS SQL Server to MYSQL

kranthi — Sat, 14 Feb 2009 17:04:26 +0000

Migrating from MS SQL to MYSQL is a big pain. there are no good tools to use for migration of the all the datbase objects, right from tables , data to stored procedures. We all know that Microsoft SQL server has a very good User Interface but when we come back to MYSQL we donot enjoy the same previlages as we do in SQL server.

Coming to the tools available to download for a good GUI, we have very less options, MYSQL query , PHPadmin are some of them. There are some tools which can be used to migrate the tables and data from the MSSQL to MYSQL. The MYSQL migration tool is also available to migrate the tables. But iam not sure that we can also migrate the stored procedures, but when i tried to migrate a small application i totally failed to shift the stored procedures to MYSQL. I have to migrate them manually. I have to check the syntax manually for each and every line and then execute the procedure.
There are some points which we have to keep in mind while migrating the database from MSSQL to MYSQL. The MYSQL statements has to end with semi-colon , even the ending of the for loop has to closed by a semi-colon.

When we migrate the tables from MSSQL to MYSQL we do not get the perfect script which defines the primary keys and the default values. We have to turn them on manually.

So please be carefull while doing the application and choosing the database, the migration of the database is same as a small project.

wish you happy programmin

Get Number of Days in a Month Function

kranthi — Thu, 15 Jan 2009 03:35:40 +0000

This article shows the ways to get the number of days in a month in both sqlserver and mysql.

Getting the number of days in a month is quite easy because it is going to be either 30 or 31 days, with the exception of February, which can either have 28 or 29 days depending if it is a leap year or not.

January,March,May,July,August,October,December — 31 Days
April,June,September,November – 30 Days
February – 28 Days (Non Leap Year), 29 (Leap Year)

Leap year should be divisible by 4, should not be divisible by 100 or should be divisible by 400.

CREATE FUNCTION [dbo].[udf_GetDaysInMonth] ( @pDate    DATETIME )
RETURNS INT
AS
BEGIN

RETURN CASE WHEN MONTH(@pDate) IN (1, 3, 5, 7, 8, 10, 12) THEN 31
WHEN MONTH(@pDate) IN (4, 6, 9, 11) THEN 30
ELSE CASE WHEN (YEAR(@pDate) % 4    = 0 AND
YEAR(@pDate) % 100 != 0) OR
(YEAR(@pDate) % 400  = 0)
THEN 29
ELSE 28
END
END

END
GO

Here’s yet another way of determining the number of days in a month without knowing if it is a leap year. It is computed by getting the lastday of the month.

CREATE FUNCTION [dbo].[udf_GetDaysInMonth] ( @pDate    DATETIME )
RETURNS INT
AS
BEGIN
SET @pDate = @pDate - DAY(@pDate) + 1 -- Get the first date of the month
RETURN day(dateadd(dd,-1,@pDate))
END
GO

Get the number of days in month in MYSQL


select DAY(LAST_DAY('2004-02-05'))

A few maximum limitations for Sqlserver and MySql

jvanamali — Sat, 10 Jan 2009 04:50:46 +0000

Often people in newsgroups ask about maximum size of various objects defined in databases.

The following tables shows the maximum sizes and numbers of various objects defined in MYSql, SQL Server.

MySql Maximums
Char	255 Bytes
Varchar	65,535 Bytes
Binary	255 Bytes
Varbinary	65,535 Bytes
TinyBlob	255 Bytes
TinyText	255 Bytes
Blob	65,535 Bytes (2^16 -1)
Text	65,535 Bytes (2^16 -1)
Medium Blob	16,777,215 Bytes (2^24 -1)
Medium Text	16,777,215 Bytes (2^24 -1)
LongBlog	4,294,967,295 Bytes (2^32 -1)
LongText	4,294,967,295 Bytes (2^32 -1)
Bit	Range from 1 to 64
Tinyint	The signed range is -128 to 127. The unsigned range is 0 to 255.
BOOL, BOOLEAN	true or false
SmallInt	The signed range is -32768 to 32767. The unsigned range is 0 to 65535.
MediumInt	The signed range is -8388608 to 8388607. The unsigned range is 0 to 16777215.
Int/Integer	The signed range is -2147483648 to 2147483647. The unsigned range is 0 to 4294967295.
BigInt	The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.
Float	Allowable values are -3.402823466E+38 to -1.175494351E-38, 0, and 1.175494351E-38 to 3.402823466E+38.
Double	Allowable values are -1.7976931348623157E+308 to -2.2250738585072014E-308, 0, and 2.2250738585072014E-308 to 1.7976931348623157E+308.

Sqlserver Maximums
char	8,000 Char
nchar	4,000 char
varchar	8,000 char
nvarchar	8,000 char
varchar(max)	1,073,741,824 char
nvarchar(max)	536,870,912 char
Tinyint	The range is 0 to 255.
SmallInt	The signed range is -32768 to 32767.
BigInt	The signed range is -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807.
Int	The signed range is -2,147,483,648 to 2,147,483,647.
money	The signed range is -922,337,203,685,477.5808 to 922,337,203,685,477.5807.
smallmoney	Allowable values are -214,748.3648 to 214,748.3647.
bit	single bit.
binary	8,000 bytes.
varbinary	8,000 bytes.
varbinary(max)	2 GB Data.
image	2 GB Data.

Other Helpful Sql Maximums
Bytes per short string column	8,000
Bytes per GROUP BY, ORDER BY	8,060
Columns in GROUP BY, ORDER BY	Limited only by number of bytes
Bytes per index key	900
Bytes per foreign key	900
Bytes per primary key	900
Bytes per row	8,060
Bytes per varchar(max), varbinary(max), xml, text, or image column	2^31-1
Characters per ntext or nvarchar(max) column	2^30-1
Clustered indexes per table	1
Columns per index key	16
Columns per foreign key	16
Columns per primary key	16
Columns per base table	1,024
Columns per SELECT statement	4,096
Columns per INSERT statement	1,024
Connections per client	32,767
Database size	1,048,516 terabytes
Databases per instance of SQL Server	32,767
Filegroups per database	32,767
Files per database	32,767
File size (data)	16 terabytes
File size (log)	2 terabytes
Foreign key table references per table	253
Identifier length (in characters)	128
Instances per computer	50 (Workgroup Edition only 16)
Locks per connection	Maximum locks per server
Locks per instance of SQL Server	Up to 2,147,483,647
Nested stored procedure levels	32
Nested subqueries	32
Nested trigger levels	32
Nonclustered indexes per table	249
Parameters per stored procedure	2,100
Parameters per user-defined function	2,100
REFERENCES per table	253
Rows per table	Limited by available storage
Tables per database	Limited by number of objects in a database
Partitions per partitioned table or index	1,000
Statistics on non-indexed columns	2,000
Tables per SELECT statement	256
Triggers per table	Limited by number of objects in a database
UNIQUE indexes or constraints per table	249 nonclustered and 1 clustered
User connections	32,767
XML indexes	249

How to Read Statistics Profile

QueryOptTeam — Tue, 29 Aug 2006 19:56:00 +0000

(2006-09-01 added a paragraph on parallel query plans)

In SQL Server, “Statistics Profile” is a mode in which a query is run where you can see the number of invocations of each physical plan operator in the tree. Instead of running a query and just printing the output rows, this mode also collects and returns per-operator row counts. Statistics Profile is used by the SQL Query Optimizer Team to identify issues with a plan which can cause the plan to perform poorly. For example, it can help identify a poor index choice or poor join order in a plan. Oftentimes, it can help identify the needed solution, such as updating statistics (as in the histograms and other statistical information used during plan generation) or perhaps adding a plan hint. This document describes how to read the statistics profile information from a query plan so that you can also debug plan issues.

A simple example query demonstrates how to retrieve the statistics profile output from a query:

use nwind

set statistics profile on

select * from customers c inner join orders o on c.customerid = o.customerid;

The profile output has a number of columns and is a bit tricky to print in a regular document. The key pieces of information that it prints are the plan, which looks like this:

StmtText

------------------------------------------------------------------------------------------------------

select * from customers c inner join orders o on c.customerid = o.customerid

|--Hash Match(Inner Join, HASH:([c].[CustomerID])=([o].[CustomerID]),

|--Clustered Index Scan(OBJECT:([nwind].[dbo].[Customers].[aaaaa_PrimaryKey] AS [c]))

|--Clustered Index Scan(OBJECT:([nwind].[dbo].[Orders].[aaaaa_PrimaryKey] AS [o]))

Other pieces of useful information are the estimated row count and the actual row count for each operator and the estimated and actual number of invocations of this operator. Note that the actual rows and # of executions are physically listed as early columns, while the other columns are listed later in the output column list (so you typically have to scroll over to see them).

Rows Executes

-------------------- --------------------

1078 1

91 1

1078 1

EstimateRows

------------------------

1051.5834

91.0

1078.0

EstimateExecutions

------------------------

NULL

1.0

Other fields, such as the estimated cost of the subtree, the output columns, the average row size, also exist in the output (but are omitted for space in this document).

Note: The output from statistics profile is typically easiest to read if you set the output from your client (Query Analyzer or SQL Server Management Studio) to output to text, using a fixed-width font. You can then see the columns pretty easily and you can even move the results into a tool like Excel if you want to cluster the estimates and actual results near each other by rearranging the columns (SSMS also can let you do this).

There are a few key pieces of information needed to understand the output from Statistics profile. First, query plans are generally represented as trees. In the output, children are printed below their parents and are indented:

StmtText

------------------------------------------------------------------------------------------------------

select * from customers c inner join orders o on c.customerid = o.customerid

|--Hash Match(Inner Join, HASH:([c].[CustomerID])=([o].[CustomerID]),

|--Clustered Index Scan(OBJECT:([nwind].[dbo].[Customers].[aaaaa_PrimaryKey] AS [c]))

|--Clustered Index Scan(OBJECT:([nwind].[dbo].[Orders].[aaaaa_PrimaryKey] AS [o]))

In this example, the scan of Customers and Orders are both below a hash join operator. Next, the “first” child of the operator is listed first. So, the Customers Scan is the first child of the hash join. Subsequent operators follow, in order. Finally, query execution plans are executed in this “first” to “last” order. So, for this plan, the very first row is returned from the Customers table. (A more detailed discussion of operators will happen later in the article). Notice that the output from the graphical showplan is similar but slightly different:

(see attachment tree.jpg).

In this tree representation, both Scans are printed to the right on the screen, and the first child is above the other operators. In most Computer Science classes, trees are printed in a manner transposed from this:

Hash Join

/ \

Customers Orders

The transposition makes printing trees in text easier. In this classical view, the tree is evaluated left to right with rows flowing bottom to top.

With an understanding of the nuances of the query plan display, it is possible to understand what happens during the execution of this query plan. The query returns 1078 rows. Not coincidentally, there are also 1078 orders in this database. Since there’s a Foreign Key relationship between Orders and Customers, it requires that a match exist for each order to each customer. So, the 91 rows in Customers match the 1078 rows in Orders to return the result.

The query estimates that the join will return 1051.5834 rows. First, this is a bit less than the actual (1078) but is not a substantial difference. Given that the Query Optimizer is making educated guesses based on sampled statistical information that may itself be out-of-date, this estimate is actually pretty good. Second, the number is not an integer because we use floating point for our estimates to improve accuracy on estimates we make. For this query, the number of executions is 1 for both the estimate and actual. This won’t always be the case, but it happens to be true for this query because of the way hash joins work. In a hash join, the first child is scanned and a hash table is built. Once the hash join is built, the second child is then scanned and each row probes the hash table to see if there is a matching row.

Loops join does not work this way, as we’ll see in a slightly modified example.

select * from customers c with (index=1) inner loop join orders o with (index=1) on c.customerid = o.customerid

In this example, I’ve forced a loop join and the use of clustered indexes for each table. The plan now looks like this:

StmtText

-----------------------------------------------------------------

select * from customers c with (index=1) inner loop join orders o

|--Nested Loops(Inner Join, WHERE:([nwind].[dbo].[Orders].[Cust

|--Clustered Index Scan(OBJECT:([nwind].[dbo].[Customers].

|--Table Spool

|--Clustered Index Scan(OBJECT:([nwind].[dbo].[Orders

Beyond the different join algorithm, you’ll notice that there is now a table spool added to the plan. The spool is on the second child (also called the “inner” child for loops join because it is usually invoked multiple times). The spool scans rows from its child and can store them for future invocations of the inner child. The actual row count and execution count from the statistics profile is a bit different from the previous plan:

Rows Executes

-------------------- --------------------

1078 1

1078 1 <--- Loop Join

91 1 <--- Scan of Customers

98098 91 <--- Spool

1078 1 <--- Scan of Orders

In this plan, the second child of the loop join is scanned 91 times returning a total number of 98098 rows. For the actual executions, the total number of rows is to sum of all invocations of that operator, so it is 91*1078=98098. This means that the inner side of this tree is scanned 91 times. Nested Loops joins require rescans of the inner subtree (Hash Joins do not, as you saw in the first example). Note that the spool causes only one scan of the Orders table, and it only has one execution as a result. It isn’t hard to see that there are far more rows touched in this plan compared to the hash join, and thus it shouldn’t be a huge surprise that this plan runs more slowly.

Note: When comparing the estimated vs. actual number of rows, it is important to remember that the actual counts need to be divded by the actual number of executions to get a value that is comparable to the estimated number of rows returned. The estimate is the per-invocation estimate.

As a more complicated example, we can try something with a few more operators and see how things work on one of the TPC-H benchmark queries (Query 8, for those who are interested, on a small-scale 100MB database):

SELECT O_YEAR,

SUM(CASE WHEN NATION = 'MOROCCO'

THEN VOLUME

ELSE 0

END) / SUM(VOLUME) AS MKT_SHARE

FROM ( SELECT datepart(yy,O_ORDERDATE) AS O_YEAR,

L_EXTENDEDPRICE * (1-L_DISCOUNT) AS VOLUME,

N2.N_NAME AS NATION

FROM PART,

SUPPLIER,

LINEITEM,

ORDERS,

CUSTOMER,

NATION N1,

NATION N2,

REGION

WHERE P_PARTKEY = L_PARTKEY AND

S_SUPPKEY = L_SUPPKEY AND

L_ORDERKEY = O_ORDERKEY AND

O_CUSTKEY = C_CUSTKEY AND

C_NATIONKEY = N1.N_NATIONKEY AND

N1.N_REGIONKEY = R_REGIONKEY AND

R_NAME = 'AFRICA' AND

S_NATIONKEY = N2.N_NATIONKEY AND

O_ORDERDATE BETWEEN '1995-01-01' AND '1996-12-31' AND

P_TYPE = 'PROMO BURNISHED NICKEL' AND

L_SHIPDATE >= CONVERT(datetime,(1156)*(30),121) AND L_SHIPDATE < CONVERT(datetime,((1185)+(1))*(30),121)

) AS ALL_NATIONS

GROUP BY O_YEAR

ORDER BY O_YEAR

As the queries get more complex, it gets harder to print them in a standard page of text. So, I’ve truncated the plan somewhat in this example. Notice that the same tree format still exists, and the main operators in this query are Scans, Seeks, Hash Joins, Stream Aggregates, a Sort, and a Loop Join. I’ve also included the actual number of rows and actual number of executions columns as well.

Rows Executes Plan

0 0 Compute Scalar(DEFINE:([Expr1028]=[Expr1026]/[Expr1027]))

2 1 |--Stream Aggregate(GROUP BY:([Expr1024]) DEFINE:([Expr1026]=SUM([par

2 1 |--Nested Loops(Inner Join, OUTER REFERENCES:([N1].[N_REGIONKEY]

10 1 |--Stream Aggregate(GROUP BY:([Expr1024], [N1].[N_REGIONKEY

1160 1 | |--Sort(ORDER BY:([Expr1024] ASC, [N1].[N_REGIONKEY] A

1160 1 | |--Hash Match(Inner Join, HASH:([N2].[N_NATIONKEY

25 1 | |--Clustered Index Scan(OBJECT:([tpch100M].[

1160 1 | |--Hash Match(Inner Join, HASH:([N1].[N_NATI

25 1 | |--Index Scan(OBJECT:([tpch100M].[dbo].

1160 1 | |--Hash Match(Inner Join, HASH:([tpch10

1000 1 | |--Index Scan(OBJECT:([tpch100M].[

1160 1 | |--Hash Match(Inner Join, HASH:([t

1160 1 | |--Hash Match(Inner Join, HAS

1432 1 | | |--Hash Match(Inner Join

126 1 | | | |--Clustered Index

0 0 | | | |--Compute Scalar(D

224618 1 | | | |--Clustered I

0 0 | | |--Compute Scalar(DEFINE

45624 1 | | |--Clustered Index

15000 1 | |--Index Scan(OBJECT:([tpch10

2 10 |--Clustered Index Seek(OBJECT:([tpch100M].[dbo].[REGION].[

I’ll point out a few details about the statistics profile output. Notice that the Compute Scalars (also called Projects) return zero for both columns. Since Compute Scalar always returns exactly as many rows as it is given from its child, there isn’t any logic to count rows again in this operator simply for performance reasons. The zeros can be safely ignored, and the values for its child can be used instead. Another interesting detail can be seen in the last operator in this printout (the Seek into the Region table). In this operator, there are 10 executions but only 2 rows returned. This means that even though there were 10 attempts to find rows in this index, only two rows were ever found. The parent operator (the Nested Loops near the top) has 10 rows coming from its first (left) child and only 2 rows output by the operator, which matches what you see in the seek. Another interesting tidbit can be found if you look at the estimates for the Seek operator:

Est.# rows Est. #executes

1.0 20.106487

The SQL Server Query Optimizer will estimate a minimum of one row coming out of a seek operator. This is done to avoid the case when a very expensive subtree is picked due to an cardinality underestimation. If the subtree is estimated to return zero rows, many plans cost about the same and there can be errors in plan selection as a result. So, you’ll notice that the estimation is “high” for this case, and some errors could result. You also might notice that we estimate 20 executions of this branch instead of the actual 10. However, given the number of joins that have been evaluated before this operator, being off by a factor of 2 (10 rows) isn’t considered to be too bad. (Errors can increase exponentially with the number of joins).

SQL Server supports executing query plans in parallel. Parallelism can add complexity to the statistics profile output as there are different kinds of parallelism that have different impacts on the counters for each operator. Parallel Scans exist at the leaves of the tree, and these will count all rows from the table into each thread even through each thread only returns a fraction of the rows. The number of executions (the second column in the output) will also have 1 execution for each thread. So, it is typical to just divide the number of threads into the total number of rows to see how many rows were actually returned by the table. Parallel zones higher in the tree usually work the same way. These will have N (where N is the degree of parallelism) more executions than the equivalent non-parallel query. There are a few cases where we will broadcast one row to multiple threads. If you examine the type of the parallelism exchange operation, you can identify these cases and notice that one row becomes multiple rows through the counts in the statistics profile results.

The most common use of the statistics profile output is to identify areas where the Optimizer may be seeing and using incomplete or incorrect information. This is often the root cause of many performance problems in queries. If you can identify areas where the estimated and actual cardinality values are far apart, then you likely have found a reason why the Optimizer is not returning the “best” plan. The reasons for the estimate being incorrect can vary, but it can include missing or out-of-date statistics, too low of a sample rate on those statistics, correlations between data columns, or use of operators outside of the optimizer’s statistical model, to name a few common cases.

UPDATE STATISTICS undocumented options

QueryOptTeam — Fri, 21 Jul 2006 23:08:00 +0000

If you read the Books Online page describing the UPDATE STATISTICS command, you will see that there are some undocumented options.

UPDATE STATISTICS table | view
    [
        {
            { index | statistics_name }
          | ( { index |statistics_name } [ ,...n ] )
                }
    ]
    [    WITH
        [
            [ FULLSCAN ]
            | SAMPLE number { PERCENT | ROWS } ]
            | RESAMPLE
            | <update_stats_stream_option> [ ,...n ]
        ]
        [ [ , ] [ ALL | COLUMNS | INDEX ]
        [ [ , ] NORECOMPUTE ]
    ] ;

<update_stats_stream_option> ::=
    [ STATS_STREAM = stats_stream ]
    [ ROWCOUNT = numeric_constant ]
    [ PAGECOUNT = numeric contant ]

<update_stats_stream_option>

This syntax is for internal use only and is not supported. Microsoft reserves the right to change this syntax at any time.

There is a very good reason why these options are undocumented. They are meant for testing and debugging purposes, and should never ever be used on production systems.

However, these options can also be extremely helpful to create examples and sample scripts to demonstrate various features and behaviors of the Query Optimizer and the related query plan shapes. We decided to explain what ROWCOUNT and PAGECOUNT do, so that to be able to use these commands in examples we’ll be posting in some future. Feel free to use these options on development systems for experimental and educational purposes, but please do not play with fire and do not use them in production!

As the name of these options suggest, ROWCOUNT and PAGECOUNT alter the internal metadata of the specified table or index by overriding the counters containing the row and page counts of the object. These counters are in turn read by the Query Optimizer when processing queries that access the table and/or index in question. These commands can basically cheat the Optimizer into thinking that a table or index is extremely large.

SQL Server’s Query Optimization process is structured in multiple stages. Further optimization stages consider a progressively larger and more sophisticated set of possible tree transformations and query optimizations. Later stages of optimization are only entered when the estimated cost of the query is sufficiently high, in order to avoid wasting precious CPU cycles against simple queries that do not need that level of sophistication anyway. The multiple optimization stages are a mean to produce efficient query plans without consuming excessive amounts of CPU. Typically, in order to make the Optimizer “think” a lot and enter these later stages it is necessary to have big tables with a large number of rows and pages, which in turn take time and space to populate. Using ROWCOUNT and PAGECOUNT allows us to exercise these code paths with relatively simple scripts that do not require an extremely complex setup phase.

Here is an example. When running this simple script on your SQL 2005 instance you will likely see a different query plan for the two selects before and after updating the statistics. The recompile option is used to ensure that the query plans are regenerated. From the statistics profile, you’ll also see very different estimated row counts and consequently costs.

use tempdb

create table t1(i int, j int)

create table t2(h int, k int)

set statistics profile on

select distinct(i) from t1

select * from t1, t2 where i = k order by j + k

update statistics t1 with rowcount = 10000, pagecount = 10000

update statistics t2 with rowcount = 100000, pagecount = 100000

select distinct(i) from t1 option (recompile)

select * from t1, t2 where i = k order by j + k option (recompile)

Enjoy!

Stefano

Hints for DML queries

QueryOptTeam — Fri, 14 Jul 2006 23:30:00 +0000

Not everyone knows that query level hints (like loop join) will impact the entirety of a DML query plan. This includes foreign key validation and indexed view maintenance.

Let us look at an example with two tables involved in a foreign key constraint.

use tempdb

create table department(deptid int primary key clustered, deptname varchar(10))

create table employee(empid int primary key clustered, empname varchar(10), deptid int references department(deptid))

insert department values(1, 'Optimizer')

At first glance, it might seem useless to provide a join hint for a scalar insert - like when inserting a row to the employee table – because the query contains no joins. However, this can make sense in presence of foreign key validations, because the Optimizer will automatically augment the query plan with a join for the purpose of validating the constraint. For example, this insert statement here

insert employee select 1 empid, 'Stefano' empname, 1 deptid option (merge join)

will produce a plan with a merge join between the employee and department tables. The join will enforce that the value of the deptid column actually exists in the primary table, department. The “Assert” operator will raise an error if a matching row is not found.

|--Assert

|--Merge Join

|--Clustered Index Insert(employee)

|--Clustered Index Scan(department)

Unfortunately, this technique is restricted to only query (vs. table) level hints, so it's not possible for example to force the indexes being used when accessing the other table involved in the constraint (department in the example). Also, TSQL syntax does not allow specifying query level hints for scalar inserts, like "insert table values...", but the easy workaround is to rewrite the statement as "insert select" like in the example. Update and delete statements do regularly accept query level hints.

update employee set empname = 'Conor', deptid = 2 where empid = 1 option (loop join)

|--Assert

|--Nested Loops

|--Clustered Index Update(employee)

|--Clustered Index Seek(department)

Let us now look at slightly more complex example with an indexed view.

use tempdb

SET ANSI_NULLS ON

SET ANSI_PADDING ON

SET ANSI_WARNINGS ON

SET CONCAT_NULL_YIELDS_NULL ON

SET NUMERIC_ROUNDABORT OFF

SET QUOTED_IDENTIFIER ON

create table t1(i int, j int)

create table t2(h int, k int)

create view v with schemabinding as

select i, h, count_big(*) c from dbo.t1, dbo.t2

where j = k

group by i, h

create unique clustered index v_ih on v(i, h)

The changes to either table t1 or t2 need to be propagated to the indexed view v1, in order to keep it consistent at all times. Since the indexed view contains a join and an aggregation in its definition, the Optimizer will automatically augment DML query plans against t1 or t2 with joins and aggregations. Query level hints can be used to influence the join and/or grouping strategy employed by the Optimizer in the query plan.

insert into t1 select 1, 2 option (hash join, hash group)

|--Sequence

|--Table Spool

| |--Table Insert(t1)

|--Clustered Index Update(v)

|--Collapse

|--Sort

|--Compute Scalar

|--Hash Match(Right Outer Join)

|--Clustered Index Scan(v)

|--Hash Match(Aggregate)

|--Hash Match(Inner Join)

|--Table Spool

|--Table Scan(t2)

insert into t1 select 1, 2 option (loop join, order group)

|--Sequence

|--Table Spool

| |--Table Insert(t1)

|--Clustered Index Update(v)

|--Collapse

|--Sort

|--Compute Scalar

|--Nested Loops(Left Outer Join)

|--Stream Aggregate

| |--Sort

| |--Nested Loops(Inner Join)

| |--Table Spool

| |--Table Scan(t2)

|--Clustered Index Seek(v)

Needless to say, query hints are fully documented in Books Online – look for the “Query Hint (Transact-SQL)” topic.

Ciao,

Stefano

Non updating updates

QueryOptTeam — Fri, 07 Jul 2006 21:45:00 +0000

A question we are frequently asked is what happens when an update statement assigns a column to its same current value. For example,

use tempdb

create table t(i int, cc as i + 1)

create index t_cc on t(cc)

insert into t values(1)

update t set i = 1

update t set i = i

Columns do get updated even if the value does not change. However, to be honest, i wouldn't worry too much about it. The runtime cost for updating a row is roughly equal to

a) locating the row in the heap or B-Tree

b) locking the row

c) changing the updated column values

d) logging the change.

For updates to columns that fit in the 8Kb page, i don't think that avoiding part of the copy would make too much of a difference. Realistically, performing a comparison to tell what changed with memcmp would roughly cost as much as changing the value with memcpy. And this cost would surely be overshadowed by a) + b) + d). Updates to columns that don't fit in the 8Kb page are inherently slower, and i think it is up to the application to avoid making unnecessary changes to these. Now a), b), c) and d) need to be performed for every index carrying one or more columns being modified. So a major factor for the runtime cost of an update query is the number of nonclustered indexes that need to be maintained. In SQL 2005 we introduced an optimization to skip nonclustered index maintenance if none of the updated columns stored in the index actually changed. The reasoning is that running the comparison for only the modified columns stored in one or more nonclustered indexes introduces a runtime overhead that is very small, and surely significantly lower than a), b) and d). Given that columns stored in an index are typically pretty small in size, it is very easy to break even if the optimization actually saves a small minority of nonclustered index row updates. The optimization does not apply to the clustered index, as we want to ensure to always exclusively lock the affected rows even if no columns are really changing. You can see the new optimization in action by comparing the statistics profile output for one of the update statements in the previous example in SQL 2000 and 2005 (see attached image). set statistics profile on go update t set i = i

In SQL 2000, the lack of the optimization leads to updating the nonclustered index even if the value is not changing.

In the SQL 2005 plan, it is possible to appreciate

- a “Compute Scalar” operator that compares the current value and new value of the column being modified

- a new filter operator that on a row by row basis will determine whether the nonclustered index is being affected or not

- the fact that nonclustered index maintenance is now bypassed

This new SQL 2005 optimization allows to better address the problem of maintaining a diverse set of columns across multiple recurring update statements against a certain table. In SQL 2000 there was a tradeoff between building dynamic SQL statements and possibly incur in frequent compilations, to only maintain the modified columns vs. using a parameterized and standard statement that updated all the columns, but would also maintain all the nonclustered indexes all the time. Like i said before, special precautions should still be taken for columns that don't fit the 8Kb page limit.

Ciao,

Stefano

Source : http://blogs.msdn.com/queryoptteam/default.aspx