performance

This is just a general question if the cilent is having database any object
problem and we don't want to touch production box, is there any way we can
produce the database problem to point on another box which is a snapshort of
primary database or any other solution which doesn't point the production
server, hope you understand what I am trying to say.

Thanks

"Linchi Shea" wrote in message

> There is almost always a way to find what a problem may be without hurting
> a
> production system. But you may want to be a bit more specific about the
> nature of your problem. Can you elaborate on what you meant by 'having
> problem to access the one of our application module'? Did the client have
> a
> problem accessing SQL Server? Any error message from SQL Server?
>
> Linchi
>
> "Smith" wrote:
>
>>
>> I have a quick question, I have a production sql server 2005 box and one
>> of
>> the client is having problem to access the one of our application module
>> and
>> I want to debug the problem but i don't want to hurt production database
>> peformance, is there any way how I can fulfill this, is there any other
>> approach which I can taken place in real time enviornment.
>>
>> Thanks
>>
 >> Stay informed about: performance 

Reproducing the problem on a separate server is a common practice. Often, you
can simply restore from a backup taken on the production to a QA or Dev
server, and then try to reproduce the problem there. If you maintain a warm
standby, you may choose to break the standby and do your troubleshooting on
the standby. This will leave your prod exposed. Is the root cause analysis
important enough for me to risk exposing my production? Or can I break the
standby and still keep regular log backups going so my risk is minimal? It's
a call you have to make. Sometimes, using a separate server may not give you
the expected results if the problem depends very much on the dynamics of the
system at time.

Linchi

"Smith" wrote:

> This is just a general question if the cilent is having database any object
> problem and we don't want to touch production box, is there any way we can
> produce the database problem to point on another box which is a snapshort of
> primary database or any other solution which doesn't point the production
> server, hope you understand what I am trying to say.
>
> Thanks
>
> "Linchi Shea" wrote in message
>
> > There is almost always a way to find what a problem may be without hurting
> > a
> > production system. But you may want to be a bit more specific about the
> > nature of your problem. Can you elaborate on what you meant by 'having
> > problem to access the one of our application module'? Did the client have
> > a
> > problem accessing SQL Server? Any error message from SQL Server?
> >
> > Linchi
> >
> > "Smith" wrote:
> >
> >>
> >> I have a quick question, I have a production sql server 2005 box and one
> >> of
> >> the client is having problem to access the one of our application module
> >> and
> >> I want to debug the problem but i don't want to hurt production database
> >> peformance, is there any way how I can fulfill this, is there any other
> >> approach which I can taken place in real time enviornment.
> >>
> >> Thanks
> >>
>
 >> Stay informed about: performance 

Thanks... I am working on Real Time Trading Enviornment that's why I am bit
worry about it.

"Linchi Shea" wrote in message

> Reproducing the problem on a separate server is a common practice. Often,
> you
> can simply restore from a backup taken on the production to a QA or Dev
> server, and then try to reproduce the problem there. If you maintain a
> warm
> standby, you may choose to break the standby and do your troubleshooting
> on
> the standby. This will leave your prod exposed. Is the root cause analysis
> important enough for me to risk exposing my production? Or can I break the
> standby and still keep regular log backups going so my risk is minimal?
> It's
> a call you have to make. Sometimes, using a separate server may not give
> you
> the expected results if the problem depends very much on the dynamics of
> the
> system at time.
>
> Linchi
>
> "Smith" wrote:
>
>> This is just a general question if the cilent is having database any
>> object
>> problem and we don't want to touch production box, is there any way we
>> can
>> produce the database problem to point on another box which is a snapshort
>> of
>> primary database or any other solution which doesn't point the production
>> server, hope you understand what I am trying to say.
>>
>> Thanks
>>
>> "Linchi Shea" wrote in message
>>
>> > There is almost always a way to find what a problem may be without
>> > hurting
>> > a
>> > production system. But you may want to be a bit more specific about the
>> > nature of your problem. Can you elaborate on what you meant by 'having
>> > problem to access the one of our application module'? Did the client
>> > have
>> > a
>> > problem accessing SQL Server? Any error message from SQL Server?
>> >
>> > Linchi
>> >
>> > "Smith" wrote:
>> >
>> >>
>> >> I have a quick question, I have a production sql server 2005 box and
>> >> one
>> >> of
>> >> the client is having problem to access the one of our application
>> >> module
>> >> and
>> >> I want to debug the problem but i don't want to hurt production
>> >> database
>> >> peformance, is there any way how I can fulfill this, is there any
>> >> other
>> >> approach which I can taken place in real time enviornment.
>> >>
>> >> Thanks
>> >>
>>
 >> Stay informed about: performance