# SQL 2000 to 2005 migration: execution plan change issue.

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

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.
{"ft_lang_label":"__label__en","ft_lang_prob":0.7336784,"math_prob":0.86648,"size":3350,"snap":"2020-24-2020-29","text_gpt3_token_len":970,"char_repetition_ratio":0.11924686,"word_repetition_ratio":0.14683545,"special_character_ratio":0.31462687,"punctuation_ratio":0.18721461,"nsfw_num_words":0,"has_unicode_error":false,"math_prob_llama3":0.97100365,"pos_list":[0],"im_url_duplicate_count":[null],"WARC_HEADER":"{\"WARC-Type\":\"response\",\"WARC-Date\":\"2020-07-09T05:02:48Z\",\"WARC-Record-ID\":\"<urn:uuid:d456f8ad-76a5-4230-82c9-84f947c23713>\",\"Content-Length\":\"33397\",\"Content-Type\":\"application/http; msgtype=response\",\"WARC-Warcinfo-ID\":\"<urn:uuid:39e81707-cd5c-4a00-b952-fa339dd28c63>\",\"WARC-Concurrent-To\":\"<urn:uuid:45fcc36e-eec5-48e7-8b27-1d38d65cf3a9>\",\"WARC-IP-Address\":\"96.7.23.136\",\"WARC-Target-URI\":\"https://docs.microsoft.com/en-us/archive/blogs/ikovalenko/sql-2000-to-2005-migration-execution-plan-change-issue\",\"WARC-Payload-Digest\":\"sha1:DOJEJMNZCNNHERB4LNF4F733Q3MY74TS\",\"WARC-Block-Digest\":\"sha1:6S6MSECFVPWDJSNWRLG56LV7GVIAFCNS\",\"WARC-Identified-Payload-Type\":\"text/html\",\"warc_filename\":\"/cc_download/warc_2020/CC-MAIN-2020-29/CC-MAIN-2020-29_segments_1593655898347.42_warc_CC-MAIN-20200709034306-20200709064306-00393.warc.gz\"}"}