Thanks... I am working on Real Time Trading Enviornment that's why I am bit
worry about it.
"Linchi Shea" <LinchiShea (AT) discussions (DOT) microsoft.com> wrote
Reproducing the problem on a separate server is a common practice. Often, |
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
standby, you may choose to break the standby and do your troubleshooting
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?
a call you have to make. Sometimes, using a separate server may not give
the expected results if the problem depends very much on the dynamics of
system at time.
This is just a general question if the cilent is having database any
problem and we don't want to touch production box, is there any way we
produce the database problem to point on another box which is a snapshort
primary database or any other solution which doesn't point the production
server, hope you understand what I am trying to say.
"Linchi Shea" <LinchiShea (AT) discussions (DOT) microsoft.com> wrote in message
news:6C707065-A118-40BB-876A-04DA3A84FF6A (AT) microsoft (DOT) com...
There is almost always a way to find what a problem may be without
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
problem accessing SQL Server? Any error message from SQL Server?
I have a quick question, I have a production sql server 2005 box and
the client is having problem to access the one of our application
I want to debug the problem but i don't want to hurt production
peformance, is there any way how I can fulfill this, is there any
approach which I can taken place in real time enviornment.