Mark Forums Read

Monitoring Impact of a User in SQL Server

Go Back

microsoft.public.sqlserver.tools microsoft.public.sqlserver.tools

Reply

Page 1 of 4

1

#1

Old

iaingblack

Posts: n/a

Monitoring Impact of a User in SQL Server - 05-26-2008 , 10:54 AM

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

Reply With Quote

#2

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#3

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#4

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#5

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#6

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#7

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#8

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#9

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

#10

Old

Andrew J. Kelly

Posts: n/a

Re: Monitoring Impact of a User in SQL Server - 05-26-2008 , 01:27 PM

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 connect
once 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

Quote:

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

Reply With Quote

Reply

Page 1 of 4

1

« Previous Thread | Next Thread »

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Posting Rules
You may not post new threads You may not post replies You may not post attachments You may not edit your posts vB code is On Smilies are On [IMG] code is On HTML code is Off

Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.