You are currently offline, waiting for your internet to reconnect

FIX: Modification Queries May Take Too Long to Compile if Halloween Protection is Required for Multiple Tables

This article was previously published under Q294860
This article has been archived. It is offered "as is" and will no longer be updated.
BUG #: 353206 (SHILOH_bugs)
BUG #: 352955 (SHILOH_bugs)
SYMPTOMS
A query that performs a modification (an INSERT, UPDATE, or DELETE) that involves more than one (1) table, and needs Halloween Protection, may spend an excessive amount of time trying to compile a query plan. The additional time is usually not noticeable unless there are fairly large numbers of tables involved in the query.
CAUSE
In cases that involve multiple tables, the code to determine whether proper Halloween protection is being provided by the plan incorrectly indicates that the protection is not sufficient. Consequently, the optimizer continues its search for another query plan, and spends unnecessary time in optimization.
RESOLUTION
To resolve this problem, obtain the latest service pack for Microsoft SQL Server 2000. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
290211 INF: How to Obtain the Latest SQL Server 2000 Service Pack

Hotfix

NOTE: The following hotfix was created prior to Microsoft SQL Server 2000 Service Pack 1.

The English version of this fix should have the following file attributes or later:
   Version     File name     Platform   ----------------------------------   8.00.277    s80277i.exe   x86				
NOTE: Due to file dependencies, the most recent hotfix or feature that contains the preceding files may also contain additional files.
STATUS
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Microsoft SQL Server 2000 Service Pack 1.
MORE INFORMATION
Halloween protection is needed to prevent a situation where the physicallocation of a row within a table changes due to a modification operation. As a result, the same row may be revisited multiple times within the context of a single logical operation, which should not occur. For example, this type of problem might occur if the query is modifying one of the indexed columns, and that index is being used as part of the query.

The following code is an example of a query that exhibits this problem:
UPDATE	dbo.EIM_ACCOUNTSET 	ACCNT_BI = 		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = ACCNT_BU),	CURRRA_PRI_LST_BI  = 		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = CURRRA_PRI_LST_BU),	CURR_PRI_LST_BI =		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = CURR_PRI_LST_BU) ,	FULFL_INVLOC_BI = 		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = FULFL_INVLOC_BU) ,	PAR_ACCNT_BI =		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = PAR_ACCNT_BU),	POSTN_DIVNID =		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = POSTN_DIVN) ,	PRTNR_ACCNT_BI = 		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = PRTNR_ACCNT_BU) ,	PRTNR_ID =		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = PRTNR_NAME) ,	TP_POS_DIV_ID = 		(select min(OI.ROW_ID) from dbo.S_ORG_INT OI where OI.NAME = TP_POSTN_DIVN)WHERE (IF_ROW_BATCH_NUM = 21)				

NOTE: For the sake of optimization, every time dbo.S_ORG_INT is referenced in a subquery dbo.S_ORG_INT is considered a different table, so the preceding query is considering Halloween Protection for ten (10) tables (nine [9] references to dbo.S_ORG_INT, and one [1] reference to dbo.EIM_ACCOUNT).
Properties

Article ID: 294860 - Last Review: 01/16/2015 22:11:57 - Revision: 3.1

Microsoft SQL Server 2000 Standard Edition

  • kbnosurvey kbarchive kbbug kbfix kbqfe kbsqlserv2000sp1fix KB294860
Feedback