Personally ... if everyone knows a database is going to be (re)loaded (ie, all current connections are going to get killed one way or another), I'm not going to put much effort into trying to figure out why/how an application (or user) is in the target database; I'm going to let 'dbcc dbreboot()' kill any/all offending spids so that I can proceed with loading the database. Having said that ...
----------------------
Using the output provided from your first post:
- spid 359 has a status of 'send sleep', which means the dataserver was in the process of sending data to the client and but delayed while waiting for acknowledgement from the client before sending the next batch of data; spid 359 was likely in the midst of sending data for a SELECT back to the client
- the SQL being run by spid 359 could likely be found in master..monProcessSQLText; the query plan of the that query may have also been visible by running query 'sp_showplan 359'
- if spid 359 was running a query inside a stored proc or trigger, you could get details from master..sysprocesses (dbid/id == use to get proc/trigger name; linenum == line number of SQL batch or proc/trigger code); for proc/trigger names you could probably also get details from master..monProcessProcedures (provides a list of the proc/trigger execution stack)
- 'sp_lock 359' is showing shared locks on 3 different objects; tends to support assumption that spid 359 is running a SELECT statement and in the process of sending data back to the client
Besides checking sysprocesses.dbid and sp_locks, I'd also want to check for any open transactions in the database (mastesr..syslogshold, master..systransactions), as well as take a look at the SELECT/query currently being processed to see if it is referencing any tables in the TEST database.
One possible scenario ... SELECT statement references at least 4 different objects ... 3 in the UAT_DB database (per the sp_lock output) ... and 1 object in the TEST database, but perhaps the TEST object's access is intermittent based on the results of the join between the 3 other tables (eg, the TEST db object is only accessed when a specific conditional is true so TEST db locks are intermittent and/or short lived).
----------------------
One other idea, though you'll need to do a little parsing of the output ... dbcc pss().
====================
dbcc traceon(3604)
go
/* NOTE: there are 6 different options for the 3rd arg, and depending on your
actual query and its associated query plan, some of these commands will generate
duplicate output, so fwiw ...
*/
dbcc pss(0,<spid>,0)
dbcc pss(0,<spid>,1)
dbcc pss(0,<spid>,2)
dbcc pss(0,<spid>,3)
dbcc pss(0,<spid>,4)
dbcc pss(0,<spid>,5)
go
====================
While running the following query from the master database (and hitting ^s to suspend the scrolling of output to my console => ie, put my spid in a state of 'send sleep') ...
select o.*,i.*,c.* from sysobjects o, sybsystemprocs..sysindexes i, tempdb..syscolumns c
... I ran the above dbcc pss() commands (from a different spid/session) and the output had references to all 3 databases of interest (master, sybsystemprocs, tempdb).