performance

#31

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:

Quote:

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" <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 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

#32

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

Quote:

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" <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
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

#33

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

Quote:

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" <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
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

#34

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

Quote:

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" <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
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

#35

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

Quote:

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" <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
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

#36

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

Quote:

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" <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
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

#37

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

Quote:

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" <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
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

#38

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

Quote:

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" <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
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

#39

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

Quote:

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" <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
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

#40

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

Quote:

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" <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
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