 | |
Monitoring Impact of a User in SQL Server
microsoft.public.sqlserver.tools microsoft.public.sqlserver.tools
 |
| | Thread Tools | Display Modes |
#31
 
| |||
| |||
|
Re: Monitoring Impact of a User in SQL Server -
05-28-2008
, 09:40 PM
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble  . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
#32
| |||
| |||
|
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
#33
| |||
| |||
|
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
#34
| |||
| |||
|
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
#35
| |||
| |||
|
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
#36
| |||
| |||
|
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
#37
| |||
| |||
|
|
Ha, yeah. I know we are kinda asking for trouble, but, question is really how much! The users will be using an access frontend so they cant do too much damage(!), but it would be nice to know how much of an impact it is having. Each user will be connecting using a generic read-only login account so just looking for a way to measure this and see if it is saturating the server. I will try what you have suggested. I didnt actually realise SQL Server had the available logging/performance tools to restrict and monitor activity in this way. So, i'll set up a trace and keep my fingers crossed. Thanks for the reply and advice. Cheers "Andrew J. Kelly" wrote: Anytime you allow direct adhoc access you run the risk of someone doing something that will impact performance. But that doesn't mean they will but adhoc query access is usually a path to trouble . If they will connectonce a day you can find out the SPID and then run a trace filtered on that SPID to see the reads and cpu their queries will use and go from there. -- Andrew J. Kelly SQL MVP Solid Quality Mentors "iaingblack" <iaingblack (AT) discussions (DOT) microsoft.com> wrote in message news:85A15AB9-62A2-48FD-96A5-9D4C13724B47 (AT) microsoft (DOT) com... Hi all, Quick question. At my current job, we are looking to install an Access frontend that connects to our main database. This would involve everyone using the front-end to access the main SQL Server using a read-only user account. The only concern is how this will affect performance. Is there any quick way to profile and monitor if this is creating a big drain on the database or if there is any problem in doing it this way? Thanks a lot. Iain |
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.