\nYesterday I was working on a SSMS SQLCMD-mode script and I noticed that periodically my session_id changed across test executions. <\/span>I was tracking wait statistics based on specific session IDs, so I had to periodically add new session ids to my extended events session definition to make sure I captured my session’s wait stats accordingly. It was an isolated instance, so I could rely on the various session ids only being associated with my test.<\/font><\/font>\n<\/p>\n \nIt got me thinking about capturing session_id and scheduler assignment using SQLCMD mode. I wasn’t so much interested in the new session ids being used, but rather, I was interested in where my session ids were landing from a scheduler perspective. Certainly you could test this through an application, PowerShell script, etc. But SQLCMD mode offered a quick way to do this and I thought I would explore further.<\/font> <\/font><\/span><\/font>\n<\/p>\n \nThere are a few scenarios that I thought would be interesting, but for now I’ll just show one of them. For this scenario I had SQL Server instance (10.50.2500) with four visible schedulers and without<\/em> multiple NUMA nodes (stay tuned on that for another time). <\/span>I started off by creating a table in tempdb to track session_id, scheduler_id, parent_node_id, cpu_id and a counter of connects:<\/font><\/font>\n<\/p>\n \n:CONNECT CAESAR<\/font><\/font><\/span><\/span>\n<\/p>\n \nUSE<\/font><\/font><\/span> tempdb<\/font><\/span><\/font>;<\/font><\/span><\/span><\/font>\n<\/p>\n \n<\/font><\/font><\/span>\n<\/p>\n \nCREATE<\/font><\/font><\/span> TABLE<\/font><\/span> [dbo]<\/font><\/span>.<\/font><\/span>[SQLCMDRoundRobin]<\/font><\/span><\/font>(<\/font><\/span><\/span><\/font>\n<\/p>\n \n <\/font><\/span>[sqlcmdroundrobin_id]<\/font><\/span> [int]<\/font><\/span> NOT<\/font><\/span> NULL<\/font><\/span> PRIMARY<\/font><\/span> KEY<\/font><\/span> CLUSTERED<\/font><\/span> IDENTITY<\/font><\/span>(<\/font><\/span>1,<\/font><\/span>1<\/font>),<\/font><\/span><\/font><\/span>\n<\/p>\n \n <\/font><\/span>[session_id]<\/font><\/span> [smallint]<\/font><\/span> NOT<\/font><\/span> <\/font>NULL,<\/font><\/span><\/font><\/span>\n<\/p>\n \n <\/font><\/span>[scheduler_id]<\/font><\/span> [int]<\/font><\/span> NOT<\/font><\/span> <\/font>NULL,<\/font><\/span><\/font><\/span>\n<\/p>\n \n <\/font><\/span>[parent_node_id]<\/font><\/span> [int]<\/font><\/span> NOT<\/font><\/span> <\/font>NULL,<\/font><\/span><\/font><\/span>\n<\/p>\n \n <\/font><\/span>[cpu_id]<\/font><\/span> [smallint]<\/font><\/span> NOT<\/font><\/span> <\/font>NULL,<\/font><\/span><\/font><\/span>\n<\/p>\n \n <\/font><\/span>[connect_counter]<\/font><\/span> [int]<\/font><\/span> NOT<\/font><\/span> <\/font>NULL<\/font><\/span><\/font><\/span>\n<\/p>\n \n)<\/font><\/font><\/span> ON<\/font><\/span> [PRIMARY]<\/font><\/span><\/font>;<\/font><\/span><\/span><\/font>\n<\/p>\n \n<\/font><\/font><\/span>\n<\/p>\n \nGO<\/font><\/font><\/span>\n<\/p>\n \n<\/font><\/font>\n<\/p>\n \nBefore I executed my test, I launched a separate background set of query executions (looping) which put the system under CPU pressure across all schedulers.<\/font><\/font>\n<\/p>\n