Using READ UNCOMMITTED with UNION ALL - sql

Question

I have a stored procedure that's in development, with multiple UNION ALL statements. This is historical data, and I've been instructed to use SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED. Setting aside the discussion over whether this is the right method, I'd like to know if I need to specify this ISOLATION LEVEL only once at the top of the stored procedure, or if I need to specify it after every UNION ALL, since they're different queries?
Example:
Alter procedure dbo.ExampleProcedure as
declare #StartDate datetime
declare #EndDate datetime
insert into myDB.DBO.InboundCalls
select I.Date, I.System, Count(*) as calls
from
(select Date, System, CallID from System1CallData C
Left Join someothertables as S on C.CallID = S.CallID
where (C.date >= #StartDate and C.date < #EndDate)) as I
Group by I.Date, I.System
Union ALL
select I.Date, I.System, Count(*) as calls
from
(select Date, System, CallID from System2CallData C
Left Join someothertables as S on C.CallID = S.CallID
where (C.date >= #StartDate and C.date < #EndDate)) as I
group by I.Date, I.System
Union ALL
select I.Date, I.System, Count(*) as calls
from
(select Date, System, CallID from System3CallData C
Left Join someothertables as S on C.CallID = S.CallID
where (C.date >= #StartDate and C.date < #EndDate)) as I
Group by I.Date, I.System
Order by I.Date asc, I.System asc, calls asc
So do I put SET TRANSACTION ISOLATION LEVEL after Alter Procedure dbo.ExampleProcedure as, or before the first SELECT, or before each nested SELECT? Thanks in advance for any guidance!

Answer 1

I'd like to know if I need to specify this ISOLATION LEVEL only once at the top of the stored procedure . . .
Only once at the top of the procedure, unless of course you're switching isolation levels within the procedure. The isolation level reverts to the previous level when the SP exits.
If you issue SET TRANSACTION ISOLATION LEVEL in a stored procedure or
trigger, when the object returns control the isolation level is reset
to the level in effect when the object was invoked. For example, if
you set REPEATABLE READ in a batch, and the batch then calls a stored
procedure that sets the isolation level to SERIALIZABLE, the isolation
level setting reverts to REPEATABLE READ when the stored procedure
returns control to the batch.
Using the "read uncommitted" isolation level probably isn't risky on historical data. I'd presume the person instructing you to use that isolation level knows the risks and has determined that it's safe.
Historical data usually either doesn't change at all, or it changes at known intervals. (Say, quarterly. Or daily at 1:00 am.) I'd expect relatively few people to have insert privileges on those tables, and almost nobody to have update and delete privileges.
You might also test running three separate insert statements within a single transaction, rather than inserting the union of three select statements. The ORDER BY clause is probably a bad idea in production.