SQL, Analysis Services & related stories. : SQL Server 2005

SQL 2000 to SQL 2005 migration: temporary tables reuse issue.

Igor Kovalenko — Sat, 28 Apr 2007 19:55:00 GMT

During the same project the next issue was found: temporary table reuse. Here is an example on “how to reproduce”:

USE tempdb

CREATE PROCEDURE dbo.usp_step_one

BEGIN

CREATE TABLE #temp (ID INT NOT NULL, NUM INT)

ALTER TABLE #temp ADD CONSTRAINT PK_ID PRIMARY KEY (ID)

INSERT INTO #temp SELECT 1, 1

END

CREATE PROCEDURE dbo.usp_step_two

BEGIN

CREATE TABLE #temp (ID INT NOT NULL, NUM INT)

INSERT INTO #temp SELECT 1, 1

END

BEGIN TRAN

EXEC dbo.usp_step_one

PRINT 'step one 1'

EXEC dbo.usp_step_one

PRINT 'step one 2'

EXEC dbo.usp_step_two

PRINT 'step two 1'

COMMIT

DROP PROCEDURE dbo.usp_step_one

DROP PROCEDURE dbo.usp_step_two

SQL 2000 will process this batch without errors, but SQL 2005 will get you the following results:

step one 1

Msg 2714, Level 16, State 4, Procedure usp_step_one, Line 6

There is already an object named 'PK_ID' in the database.

Msg 1750, Level 16, State 0, Procedure usp_step_one, Line 6

Could not create constraint. See previous errors.

The problem is in temporary tables caching during transaction. In SQL 2000 it always used to drop local temp tables as soon as they get out of scope. In SQL 2005, the drop is delayed until the transaction is gone (rollback / commit). You can find some more details about temp tables caching here. As a workaround you can:

- Use table variables instead of temporary tables

- Avoid named constraint creation on temporary objects like

CREATE TABLE #temp (ID INT NOT NULL PRIMARY KEY CLUSTERED, NUM INT)

SQL 2000 to 2005 migration: execution plan change issue.

Igor Kovalenko — Sat, 28 Apr 2007 19:01:00 GMT

Last week I was engaged on SQL 2000 to SQL 2005 migration project, and we had identified some issues related to significant changes in execution plans. Before migration we tested the application with using Upgrade Advisor (test passed without any caution), but hopefully we also had made an additional “trace replace” test. During this stage it was found that some stored procedures works fine in SQL 2000 but always failed in SQL 2005. Here is a script on “how to reproduce” :

declare @xmlDoc int

exec sp_xml_preparedocument @xmlDoc output, '<?xml version=''1.0'' encoding=''windows-1251'' ?><filter><first-name></first-name><mid-name></mid-name><last-name>John</last-name><table-number></table-number><login></login><active>1</active></filter>'

select * into #temp_xml from openxml(@xmlDoc, '/filter')

exec sp_xml_removedocument @xmlDoc

select a.attr_id, b.attr_val_id

from

(

select t1.id id, cast(cast(t2.text as varchar(10)) as int) attr_id

from #temp_xml t1

join #temp_xml t2 on t1.id = t2.parentid

where t1.localname = 'AttributeID'

and t2.localname = '#text'

) a

left outer join

(

select t1.parentid parentid, cast(cast(t2.text as varchar(10)) as int) attr_val_id

from #temp_xml t1

join #temp_xml t2 on t1.id = t2.parentid

where t1.localname = 'AttrValueID'

and t2.localname = '#text'

) b on a.id = b.parentid

where a.attr_id is not null

order by a.attr_id

drop table #temp_xml

As mentioned above, SQL 2000 gives us an empty resultset, but SQL 2005 failed with

Msg 245, Level 16, State 1, Line 14

Conversion failed when converting the varchar value 'John' to data type int.

We compared execution plans, and it was found, that the following part has different execution rule for different SQL version.

select t1.id id, cast(cast(t2.text as varchar(10)) as int) attr_id

from #temp_xml t1

join #temp_xml t2 on t1.id = t2.parentid

where t1.localname = 'AttributeID'

and t2.localname = '#text'

SQL 2000 gives us the following:

|--Compute Scalar(DEFINE:([Expr1002]=Convert(Convert([t2].[text]))))

|--Hash Match(Inner Join, HASH:([t1].[id])=([t2].[parentid]), RESIDUAL:([t2].[parentid]=[t1].[id]))

|--Filter(WHERE:([t1].[localname]='AttributeID'))

| |--Table Scan(OBJECT:([tempdb].[dbo].[aaa] AS [t1]))

|--Filter(WHERE:([t2].[localname]='#text'))

|--Table Scan(OBJECT:([tempdb].[dbo].[aaa] AS [t2]))

SQL 2005’s version:

|--Hash Match(Inner Join, HASH:([t1].[id])=([t2].[parentid]), RESIDUAL:([tempdb].[dbo].[aaa].[parentid] as [t2].[parentid]=[tempdb].[dbo].[aaa].[id] as [t1].[id]))

|--Table Scan(OBJECT:([tempdb].[dbo].[aaa] AS [t1]), WHERE:([tempdb].[dbo].[aaa].[localname] as [t1].[localname]=N'AttributeID'))

|--Compute Scalar(DEFINE:([Expr1006]=CONVERT(int,CONVERT(varchar(10),[tempdb].[dbo].[aaa].[text] as [t2].[text],0),0)))

|--Table Scan(OBJECT:([tempdb].[dbo].[aaa] AS [t2]), WHERE:([tempdb].[dbo].[aaa].[localname] as [t2].[localname]=N'#text'))

As we can see SQL 2000 include two additional steps, but absolutely correct. SQL 2005 is much shorter, but absolutely incorrect and far from optimal (because of CONVERT applied to much more records than necessary). Tested with public 9.0.3159 version.

Summary: Upgrade advisor will never give you a 100% guaranty on safe migration. If possible please always collect some traces and replace it during testing phase of migration project.

Workaround for “Unable to set Default Schema for a group”.

Igor Kovalenko — Sat, 27 Jan 2007 23:02:00 GMT

Let assume you are using Windows Authentication with SQL Server 2005, you've added a new server account for domain group and would like to give it a default schema. The properties window is the same for users and groups but the default schema field is enabled only for user entities. As a result you cannot add a default schema to a group. So if any member of [domain]\TestGroup will try to create table without explicit schema pointed in a statement (like CREATE TABLE t1 (ID int)), (s)he will always get an error.

You can see a long thread about this issue here

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=79418&SiteID=1&PageID=0

I’d like to show you a simple workaround.

Before testing please create a Windows group like [domain]\TestGroup, create a dummy user [domain]\TestUser and make this user be a member of TestGroup.

USE [master]
GO

-- create login for the group
CREATE LOGIN [FCOD\TestGroup] FROM WINDOWS WITH DEFAULT_DATABASE=[Northwind]

-- switch to database
USE Northwind

-- create dummy schema

CREATE SCHEMA [dummy] – this is a schema for testing.

-- create a database user for TestGroup (Windows group)
CREATE USER [TestGroup] FOR LOGIN [FCOD\TestGroup]

ALTER AUTHORIZATION ON SCHEMA::[dummy] TO [TestGroup]

-- grant CREATE TABLE privilege, if you need others – please assign theirs here.
GRANT CREATE TABLE TO [TestGroup]

That’s all. Now TestUser can connect to SQL Server, Northwind database, and create table. Please reboot your computer, logon like TestUser and connect to SQL Server. When you will run

CREATE TABLE t1 ( ID int )

you’ll see, that SQL engine will automatically:

- create [domain]\TestUser schema in Northwind

- create [domain]\TestUser database user in Northwind

- create table [domain\TestUser].t1 in Northwind

Any user (member of [domain]\TestGroup) currently can connect to desired server, work with database and even create own tables in own schemas. No other actions required, and no rules required for any new member of TestGroup.

If you like all table be created in dummy schema, you can use explicit schema like

CREATE TABLE dummy.t1 ( ID int )

ALTER DATABASE ... ALTER COLLATION (FORCED).

Igor Kovalenko — Sun, 03 Dec 2006 01:29:00 GMT

As all of you know Microsoft has made a small problem for all SQL DBA and developers. If you have a database with any of SQL_xxxxx collations (for more details please have a look at the TERTIARY_WEIGHTS() function here), you will defenetily have a significant problem with index search and ordering performance if you'll try to upgrade your SQL Server with 2005 version. Some of developers was excited when first time reading this article, really :-).

Suddenly ALTER DATABASE .. ALTER COLLATION command will change database collation for you, but all objects will stay "as is" with old collation (by design). The only way to change collation for all existing objects is to create a new empty database with new desired collation and copy data into this new database (copy wizzard, for example).

To sort this issue out i created this small script (in attachment). It was tested both manually and with using VSTS DBPro, and i can confirm that you can change the collation of your database without any problem and manual work. As an input you should provide it with database with one collation, and as output you will have the same database with another (desired) collation. So as for me this is an analoque of ALTER DATABASE ... ALTER COLLATION FORCED command :-). How it works:

- you should use sqlcmd or SSMS in sqlcmd mode,

- specify database name as a parameter,

- specify desired collation as a parameter,

- run it and wait for results.

What is not covered by the script: table and index partitioning. I guess that if you are using these advanced options, you are smart enough to change this script to add required feature. Mostly i created this script for the following scenario: (1) detach database from SQL Server 6.5/7.0/200 version; (2) attach it to SQL Server 2005; (3) run this script; (4) use your database asap.

Some words about performance: than more tables with computed columns (computed column not at the end of the table) you have than more time you will have to wait. 100 Gigabyte db can be easily transformed within one hour on AI64 4way with EVA8000.

Also it is possible to use this script to study SQL 2005 system views and relationship between them.

Many thanks for any reply and comments.

---- January 2008

Many thanks to WaitForPete, script updated to fix these (and some other) issues.