Production debugging of SQL Server 2005 without VS 2005?

Hi,
Apparently Visual Studio 2005 is normally needed to debug
SQL Server 2005 problems. For example stored procedures
written in managed code. What is the recommended way to
do debugging on a production server that doesn't have VS
on it? Remote debugging from another machine on the
same LAN? What if that isn't possible? ADPlus, dump
files and the SOS debugger extension?
Thanks,
Alan Cobb
Hi
Usually you would not want to do this on a live system, but a copy, as
potentially you could cause havoc if you do this. Any code change should go
through a proper review/test/release process.
John
"Alan Cobb" wrote:

> Hi,
> Apparently Visual Studio 2005 is normally needed to debug
> SQL Server 2005 problems. For example stored procedures
> written in managed code. What is the recommended way to
> do debugging on a production server that doesn't have VS
> on it? Remote debugging from another machine on the
> same LAN? What if that isn't possible? ADPlus, dump
> files and the SOS debugger extension?
> Thanks,
> Alan Cobb
>
|||Hi John,
Let's say we've exhausted all the "non-live" approaches
and there is some bug (not just the stored procedure example)
that only happens on a particular live system.
Maybe "production debugging" just doesn't come up that much
in the SQL Server world, but in the ASP.NET world people do
have to occasionally debug problems on live ASP.NET servers.
Partly for security reasons people often don't want to install
Visual Studio's debugger on a production ASP.NET server, so
they capture dump files with ADPlus. Then they analyze the
dump files in a debugger somewhere else. But maybe that's
not as common in the SQL Server world?
Thanks,
Alan Cobb
On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
<jbellnewsposts@.hotmail.com> wrote:
[vbcol=seagreen]
>Hi
>Usually you would not want to do this on a live system, but a copy, as
>potentially you could cause havoc if you do this. Any code change should go
>through a proper review/test/release process.
>John
>"Alan Cobb" wrote:
|||Hi Alan
With backend systems control and auditability can be a mandatory requirement
depending on your circumstances. Also if a business' wellbeing it dependent
on such systems it would be outside of the remit for a developer to decide
what should/should not be done on these servers. This is obviously dependent
on the company and may well be different for yours.
If you have the web logs maybe you can recreate the problem by replaying
them using ACT. This may give you the opportunity to debug the application in
a controlled environment, alternatively if you can validate that you will not
get the issue one a set of hardware you may want to consider
changing/rebuilding the system.
John
"Alan Cobb" wrote:

> Hi John,
> Let's say we've exhausted all the "non-live" approaches
> and there is some bug (not just the stored procedure example)
> that only happens on a particular live system.
> Maybe "production debugging" just doesn't come up that much
> in the SQL Server world, but in the ASP.NET world people do
> have to occasionally debug problems on live ASP.NET servers.
> Partly for security reasons people often don't want to install
> Visual Studio's debugger on a production ASP.NET server, so
> they capture dump files with ADPlus. Then they analyze the
> dump files in a debugger somewhere else. But maybe that's
> not as common in the SQL Server world?
> Thanks,
> Alan Cobb
> On Thu, 26 Jan 2006 00:47:02 -0800, John Bell
> <jbellnewsposts@.hotmail.com> wrote:
>
>