I have 2 goals to accomplish:1. Continuously and atomically migrate data from a primary table to an archive table.2. Ensure that a VIEW of a UNION ALL between the primary and the archive tables never shows duplicate rows. Current results:1. Code working correctly. 2. Code NOT working correctly. This is a subset of the data migration query executed continuously as a SQL Agent job. AUDITMSG is the primary table. OLDAUDIT is the archive table:[code="sql"]DECLARE @DayCount INT = 90;DECLARE @DayCutOff DATETIME = DATEADD(day, -@DayCount, GETDATE());DECLARE @TempTable TABLE (ID INT NOT NULL);BEGIN TRY WHILE(1 = 1) BEGIN SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; BEGIN TRANSACTION INSERT INTO @TempTable SELECT TOP 10 ID FROM AUDITMSG WHERE TRANS_DATE < @DayCutoff; INSERT INTO OLDAUDIT( ORIGINAL_ID, Vendorid ) SELECT ID, Vendorid FROM AUDITMSG WHERE ID IN (SELECT ID FROM @TempTable); DELETE FROM AUDITMSG WHERE ID IN (SELECT ID FROM @TempTable); COMMIT TRANSACTION; DELETE FROM @TempTable; WAITFOR DELAY '00:00:01.000'; ENDEND TRYBEGIN CATCH DECLARE @ErrorMessage VARCHAR(255); SET @ErrorMessage = ERROR_MESSAGE(); ROLLBACK TRANSACTION; RAISERROR(@ErrorMessage, 20, 0) WITH LOG; RETURN; END CATCH [/code]Below is a test query designed to prove that duplicate rows do not exist in either table:[code="sql"]SELECT COUNT(*) FROM AUDITMSG aINNER JOIN OLDAUDIT o ON o.ORIGINAL_ID = a.ID[/code]When the SQL Agent job is not executing, the result returned is always zero rows, which means no duplicate rows were found in either table.When the SQL Agent job is executing, the result returned is 30, 40, or 50 rows, which indicates that the rows exist simultaneously in both tables and the VIEW of both tables, AUDITMSG and OLDAUDIT, can show duplicates. This is not the way I expected the SERIALIZABLE transaction isolation level to work.From Books Online:[quote]SERIALIZABLE - Specifies the following:[b]Statements cannot read data that has been modified but not yet committed by other transactions.[/b]No other transactions can modify data that has been read by the current transaction until the current transaction completes.Other transactions cannot insert new rows with key values that would fall in the range of keys read by any statements in the current transaction until the current transaction completes.Range locks are placed in the range of key values that match the search conditions of each statement executed in a transaction. This blocks other transactions from updating or inserting any rows that would qualify for any of the statements executed by the current transaction. This means that if any of the statements in a transaction are executed a second time, they will read the same set of rows. The range locks are held until the transaction completes. This is the most restrictive of the isolation levels because it locks entire ranges of keys and holds the locks until the transaction completes. Because concurrency is lower, use this option only when necessary. [b]This option has the same effect as setting HOLDLOCK on all tables in all SELECT statements in a transaction.[/b] [/quote]What have I overlooked?What do I need to change to prevent the VIEW'ing of duplicate rows?
↧