Bug in DBCC SQLPerf ?

I've noticed that running DBCC SQLPERF(Threads) shows the login name
truncated to 10 characters, which is a tiny problem if you use Windows
authentication, as all you seem to get is the first 10 characters of the
domain name. This leaves you guessing as to which pesky user is using all
that resource. Anybody know of any useful workarounds?
Thanks.Having thought about it a little harder, I can get the desired result by
loading the data from DBCC SQLPERF(Threads) and sp_who into #tables and
joining them on their respective SPIDs. I suppose the only danger is that
the SPIDS change user between the two calls.
"BarryC" wrote:
> I've noticed that running DBCC SQLPERF(Threads) shows the login name
> truncated to 10 characters, which is a tiny problem if you use Windows
> authentication, as all you seem to get is the first 10 characters of the
> domain name. This leaves you guessing as to which pesky user is using all
> that resource. Anybody know of any useful workarounds?
> Thanks.|||Why use DBCC SQLPERF(THREADS) which is undocumented and unsupported if you
have all information in a documented table (sysprocesses)?
select spid as [Spid],
kpid as [Thread ID],
loginame as [LoginName],
status as [Status],
physical_io as [IO],
cpu as [CPU],
memusage as [MemUsage]
from master.dbo.sysprocesses
GertD@.SQLDev.Net
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
Copyright © SQLDev.Net 1991-2005 All rights reserved.
"BarryC" <BarryC@.discussions.microsoft.com> wrote in message
news:A4D03A1F-6CAF-4881-82F5-7F6BC8BEDF3A@.microsoft.com...
> Having thought about it a little harder, I can get the desired result by
> loading the data from DBCC SQLPERF(Threads) and sp_who into #tables and
> joining them on their respective SPIDs. I suppose the only danger is that
> the SPIDS change user between the two calls.
> "BarryC" wrote:
>> I've noticed that running DBCC SQLPERF(Threads) shows the login name
>> truncated to 10 characters, which is a tiny problem if you use Windows
>> authentication, as all you seem to get is the first 10 characters of the
>> domain name. This leaves you guessing as to which pesky user is using
>> all
>> that resource. Anybody know of any useful workarounds?
>> Thanks.|||A perfectly reasonable question to which I'm sure there is an excellent
answer. Just makes me feel like a man, I guess.
Thanks, though - you're quite right of course...
"Gert E.R. Drapers" wrote:
> Why use DBCC SQLPERF(THREADS) which is undocumented and unsupported if you
> have all information in a documented table (sysprocesses)?
> select spid as [Spid],
> kpid as [Thread ID],
> loginame as [LoginName],
> status as [Status],
> physical_io as [IO],
> cpu as [CPU],
> memusage as [MemUsage]
> from master.dbo.sysprocesses
>
> GertD@.SQLDev.Net
> Please reply only to the newsgroups.
> This posting is provided "AS IS" with no warranties, and confers no rights.
> You assume all risk for your use.
> Copyright © SQLDev.Net 1991-2005 All rights reserved.
> "BarryC" <BarryC@.discussions.microsoft.com> wrote in message
> news:A4D03A1F-6CAF-4881-82F5-7F6BC8BEDF3A@.microsoft.com...
> > Having thought about it a little harder, I can get the desired result by
> > loading the data from DBCC SQLPERF(Threads) and sp_who into #tables and
> > joining them on their respective SPIDs. I suppose the only danger is that
> > the SPIDS change user between the two calls.
> >
> > "BarryC" wrote:
> >
> >> I've noticed that running DBCC SQLPERF(Threads) shows the login name
> >> truncated to 10 characters, which is a tiny problem if you use Windows
> >> authentication, as all you seem to get is the first 10 characters of the
> >> domain name. This leaves you guessing as to which pesky user is using
> >> all
> >> that resource. Anybody know of any useful workarounds?
> >>
> >> Thanks.
>
>