Poor Performance - Identical DBs But Different Performance

Brian Tabios wrote:
> Any Ideas would help me greatly!
> Thanks,
> Brian T
>
> *** Sent via Developersdex http://www.codecomments.com ***
Is SQL configured the same way on both servers, same memory settings,
parallelism, etc.?
Does the query do a lot of sorting? How is TEMPDB configured between
the two machines?
Fire up Perfmon on the production machine and look at CPU, Avg. Disk
Queue Length when the query is running. Compare that to the development
machine.Hi Brian
Have you defragmented the indexes and updated statistics on the slower box?
When you defragmented the disc was SQL server running or not?
Have you checked sp_configure and sp_dboption values?
How did you time/execute the queries?
John
"Brian Tabios" wrote:

> Hello Everyone,
> I have a very complex performance issue with our production database.
> Here's the scenario. We have a production webserver server and a
> development web server. Both are running SQL Server 2000.
> I encounted various performance issues with the production server with a
> particular query. It would take approximately 22 seconds to return 100
> rows, thats about 0.22 seconds per row. Note: I ran the query in single
> user mode. So I tested the query on the Development server by taking a
> backup (.dmp) of the database and moving it onto the dev server. I ran
> the same query and found that it ran in less than a second.
> I took a look at the query execution plan and I found that they we're
> the exact same in both cases.
> Then I took a look at the various index's, and again I found no
> differences in the table indices.
> If both databases are identical, I'm assumeing that the issue is related
> to some external hardware issue like: disk space, memory etc. Or could
> it be OS software related issues, like service packs, SQL Server
> configuations etc.
> Here's what I've done to rule out some obvious hardware issues on the
> prod server:
> 1. Moved all extraneous files to a secondary harddrive to free up space
> on the primary harddrive. There is 55gb's of free space on the disk.
> 2. Applied SQL Server SP4 service packs
> 3. Defragmented the primary harddrive
> 4. Applied all Windows Server 2003 updates
>
> Here is the prod servers system specs:
> 2x Intel Xeon 2.67GHZ
> Total Physical Memory 2GB, Available Physical Memory 815MB
> Windows Server 2003 SE /w SP1
> Here is the dev serers system specs:
> 2x Intel Xeon 2.80GHz
> 2GB DDR2-SDRAM
> Windows Server 2003 SE /w SP1
> I'm not sure what else to do, the query performance is an order of
> magnitude difference and I can't explain it. To me its is a hardware or
> operating system
> related issue.
> Any Ideas would help me greatly!
> Thanks,
> Brian T
>
> *** Sent via Developersdex http://www.codecomments.com ***
>|||Brain,
I had similar problem in the past. It turned out that one of my DBA's was
shrinking the tempdb and also he left it on autogrow @. 1mb. The problem was
solved by configuring initial bigger TEMPDB and ofcourse, shrink job was
disabled.
--
Venkat
sql server admirer
"John Bell" wrote:
[vbcol=seagreen]
> Hi Brian
> Have you defragmented the indexes and updated statistics on the slower box
?
> When you defragmented the disc was SQL server running or not?
> Have you checked sp_configure and sp_dboption values?
> How did you time/execute the queries?
> John
> "Brian Tabios" wrote:
>|||Hello Everyone,
I have a very complex performance issue with our production database.
Here's the scenario. We have a production webserver server and a
development web server. Both are running SQL Server 2000.
I encounted various performance issues with the production server with a
particular query. It would take approximately 22 seconds to return 100
rows, thats about 0.22 seconds per row. Note: I ran the query in single
user mode. So I tested the query on the Development server by taking a
backup (.dmp) of the database and moving it onto the dev server. I ran
the same query and found that it ran in less than a second.
I took a look at the query execution plan and I found that they we're
the exact same in both cases.
Then I took a look at the various index's, and again I found no
differences in the table indices.
If both databases are identical, I'm assumeing that the issue is related
to some external hardware issue like: disk space, memory etc. Or could
it be OS software related issues, like service packs, SQL Server
configuations etc.
Here's what I've done to rule out some obvious hardware issues on the
prod server:
1. Moved all extraneous files to a secondary harddrive to free up space
on the primary harddrive. There is 55gb's of free space on the disk.
2. Applied SQL Server SP4 service packs
3. Defragmented the primary harddrive
4. Applied all Windows Server 2003 updates
Here is the prod servers system specs:
2x Intel Xeon 2.67GHZ
Total Physical Memory 2GB, Available Physical Memory 815MB
Windows Server 2003 SE /w SP1
Here is the dev serers system specs:
2x Intel Xeon 2.80GHz
2GB DDR2-SDRAM
Windows Server 2003 SE /w SP1
I'm not sure what else to do, the query performance is an order of
magnitude difference and I can't explain it. To me its is a hardware or
operating system
related issue.
Any Ideas would help me greatly!
Thanks,
Brian T
*** Sent via Developersdex http://www.codecomments.com ***|||Brian Tabios wrote:
> Any Ideas would help me greatly!
> Thanks,
> Brian T
>
> *** Sent via Developersdex http://www.codecomments.com ***
Is SQL configured the same way on both servers, same memory settings,
parallelism, etc.?
Does the query do a lot of sorting? How is TEMPDB configured between
the two machines?
Fire up Perfmon on the production machine and look at CPU, Avg. Disk
Queue Length when the query is running. Compare that to the development
machine.|||Hi Brian
Have you defragmented the indexes and updated statistics on the slower box?
When you defragmented the disc was SQL server running or not?
Have you checked sp_configure and sp_dboption values?
How did you time/execute the queries?
John
"Brian Tabios" wrote:

> Hello Everyone,
> I have a very complex performance issue with our production database.
> Here's the scenario. We have a production webserver server and a
> development web server. Both are running SQL Server 2000.
> I encounted various performance issues with the production server with a
> particular query. It would take approximately 22 seconds to return 100
> rows, thats about 0.22 seconds per row. Note: I ran the query in single
> user mode. So I tested the query on the Development server by taking a
> backup (.dmp) of the database and moving it onto the dev server. I ran
> the same query and found that it ran in less than a second.
> I took a look at the query execution plan and I found that they we're
> the exact same in both cases.
> Then I took a look at the various index's, and again I found no
> differences in the table indices.
> If both databases are identical, I'm assumeing that the issue is related
> to some external hardware issue like: disk space, memory etc. Or could
> it be OS software related issues, like service packs, SQL Server
> configuations etc.
> Here's what I've done to rule out some obvious hardware issues on the
> prod server:
> 1. Moved all extraneous files to a secondary harddrive to free up space
> on the primary harddrive. There is 55gb's of free space on the disk.
> 2. Applied SQL Server SP4 service packs
> 3. Defragmented the primary harddrive
> 4. Applied all Windows Server 2003 updates
>
> Here is the prod servers system specs:
> 2x Intel Xeon 2.67GHZ
> Total Physical Memory 2GB, Available Physical Memory 815MB
> Windows Server 2003 SE /w SP1
> Here is the dev serers system specs:
> 2x Intel Xeon 2.80GHz
> 2GB DDR2-SDRAM
> Windows Server 2003 SE /w SP1
> I'm not sure what else to do, the query performance is an order of
> magnitude difference and I can't explain it. To me its is a hardware or
> operating system
> related issue.
> Any Ideas would help me greatly!
> Thanks,
> Brian T
>
> *** Sent via Developersdex http://www.codecomments.com ***
>|||Brain,
I had similar problem in the past. It turned out that one of my DBA's was
shrinking the tempdb and also he left it on autogrow @. 1mb. The problem was
solved by configuring initial bigger TEMPDB and ofcourse, shrink job was
disabled.
--
Venkat
sql server admirer
"John Bell" wrote:
[vbcol=seagreen]
> Hi Brian
> Have you defragmented the indexes and updated statistics on the slower box
?
> When you defragmented the disc was SQL server running or not?
> Have you checked sp_configure and sp_dboption values?
> How did you time/execute the queries?
> John
> "Brian Tabios" wrote:
>

Please make the world all right again.

I have reported some SQL execution plan whackyness on this newsgroup
( http://shrinkster.com/984 ) where a stored proc ran very slowly when
called as a stored procedure. However, if I just pasted the sproc
source code into Query Analyzer, it ran like a champ on the same set of
data. I finally zeroed in on a particular query that was causing this
and, again, it was fast in Query Analyzer and a dog inside the stored
procedure. The 2 methods would also generate a completely different plan.
Anyway, my co-worker found a solution, which is ugly but works great.
He simply placed the query text into a varchar variable and ran it as
Dynamic SQL using EXEC inside the stored procedure. All of a sudden,
the execution plans were identical and the speed was back to normal.
This begs the question - why in the world is this happening? Running
SQL from an EXEC should slow things down, not speed them up. Afaik, it
goes against everything I've ever learned about databases. Is the
optimizer flawed in SQL Server 2000 SP3? Should we go to SP4?
Thanks.
Does your code query a remote server?
PRB: Distributed Queries That Are Wrapped in a Stored Procedure with Input
Parameters May Experience Performance Degradation
http://support.microsoft.com/default...b;en-us;320208
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Frank Rizzo" <none@.none.com> wrote in message
news:eTXPZfV6FHA.2192@.TK2MSFTNGP14.phx.gbl...
>I have reported some SQL execution plan whackyness on this newsgroup
> ( http://shrinkster.com/984 ) where a stored proc ran very slowly when
> called as a stored procedure. However, if I just pasted the sproc source
> code into Query Analyzer, it ran like a champ on the same set of data. I
> finally zeroed in on a particular query that was causing this and, again,
> it was fast in Query Analyzer and a dog inside the stored procedure. The
> 2 methods would also generate a completely different plan.
> Anyway, my co-worker found a solution, which is ugly but works great. He
> simply placed the query text into a varchar variable and ran it as Dynamic
> SQL using EXEC inside the stored procedure. All of a sudden, the
> execution plans were identical and the speed was back to normal.
> This begs the question - why in the world is this happening? Running SQL
> from an EXEC should slow things down, not speed them up. Afaik, it goes
> against everything I've ever learned about databases. Is the optimizer
> flawed in SQL Server 2000 SP3? Should we go to SP4?
> Thanks.
>
|||> This begs the question - why in the world is this happening? Running SQL
> from an EXEC should slow things down, not speed them up. Afaik, it goes
> against everything I've ever learned about databases. Is the optimizer
> flawed in SQL Server 2000 SP3? Should we go to SP4?
Tibor probably identified the culprit - do you take him up on the
suggestion?
|||Geoff N. Hiten wrote:
> Does your code query a remote server?
> PRB: Distributed Queries That Are Wrapped in a Stored Procedure with Input
> Parameters May Experience Performance Degradation
> http://support.microsoft.com/default...b;en-us;320208
>
Nope. Everything is on the same server.
|||Scott Morris wrote:
>
> Tibor probably identified the culprit - do you take him up on the
> suggestion?
Yes, I tried that but it didn't help. There is an article on this topic
which is very informative, but it didn't apply to my situation.
http://blogs.msdn.com/khen1234/archi...02/424228.aspx
|||> Yes, I tried that but it didn't help.
What did you try?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Frank Rizzo" <none@.none.com> wrote in message news:%23FAOPQW6FHA.3804@.TK2MSFTNGP14.phx.gbl...
> Scott Morris wrote:
> Yes, I tried that but it didn't help. There is an article on this topic
> which is very informative, but it didn't apply to my situation.
> http://blogs.msdn.com/khen1234/archi...02/424228.aspx
|||Tibor Karaszi wrote:
> What did you try?
I tried changing variables to parameters and also variables to hardwired
values.
|||Are you saying that when you have the code in a stored procedure, the code is slow compared to when
not? Even if the procedure doesn't have any parameters and you hard-wire the search arguments inside
the procedure code? So basically, you have your TSQL code which is fast, add CREATE PROC on top and
when you execute that proc it is slow? And it doesn't matter if you create the proc or executing the
proc using WITH RECOMPILE? If so, I suggest you open a case with MS.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Frank Rizzo" <none@.none.com> wrote in message news:eCBzAlX6FHA.1184@.TK2MSFTNGP12.phx.gbl...
> Tibor Karaszi wrote:
> I tried changing variables to parameters and also variables to hardwired values.
|||Tibor Karaszi wrote:
> Are you saying that when you have the code in a stored procedure, the
> code is slow compared to when not? Even if the procedure doesn't have
> any parameters and you hard-wire the search arguments inside the
> procedure code? So basically, you have your TSQL code which is fast, add
> CREATE PROC on top and when you execute that proc it is slow? And it
> doesn't matter if you create the proc or executing the proc using WITH
> RECOMPILE? If so, I suggest you open a case with MS.
Yes, that is precisely what I am saying. I am just a consultant here
and don't have the power to open a case, but I'll see who can take care
of this. Anyway, the problem was solved by executing the query dynamically.

Please make the world all right again.

I have reported some SQL execution plan whackyness on this newsgroup
( http://shrinkster.com/984 ) where a stored proc ran very slowly when
called as a stored procedure. However, if I just pasted the sproc
source code into Query Analyzer, it ran like a champ on the same set of
data. I finally zeroed in on a particular query that was causing this
and, again, it was fast in Query Analyzer and a dog inside the stored
procedure. The 2 methods would also generate a completely different plan.
Anyway, my co-worker found a solution, which is ugly but works great.
He simply placed the query text into a varchar variable and ran it as
Dynamic SQL using EXEC inside the stored procedure. All of a sudden,
the execution plans were identical and the speed was back to normal.
This begs the question - why in the world is this happening? Running
SQL from an EXEC should slow things down, not speed them up. Afaik, it
goes against everything I've ever learned about databases. Is the
optimizer flawed in SQL Server 2000 SP3? Should we go to SP4?
Thanks.Does your code query a remote server?
PRB: Distributed Queries That Are Wrapped in a Stored Procedure with Input
Parameters May Experience Performance Degradation
http://support.microsoft.com/default.aspx?scid=kb;en-us;320208
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Frank Rizzo" <none@.none.com> wrote in message
news:eTXPZfV6FHA.2192@.TK2MSFTNGP14.phx.gbl...
>I have reported some SQL execution plan whackyness on this newsgroup
> ( http://shrinkster.com/984 ) where a stored proc ran very slowly when
> called as a stored procedure. However, if I just pasted the sproc source
> code into Query Analyzer, it ran like a champ on the same set of data. I
> finally zeroed in on a particular query that was causing this and, again,
> it was fast in Query Analyzer and a dog inside the stored procedure. The
> 2 methods would also generate a completely different plan.
> Anyway, my co-worker found a solution, which is ugly but works great. He
> simply placed the query text into a varchar variable and ran it as Dynamic
> SQL using EXEC inside the stored procedure. All of a sudden, the
> execution plans were identical and the speed was back to normal.
> This begs the question - why in the world is this happening? Running SQL
> from an EXEC should slow things down, not speed them up. Afaik, it goes
> against everything I've ever learned about databases. Is the optimizer
> flawed in SQL Server 2000 SP3? Should we go to SP4?
> Thanks.
>|||> This begs the question - why in the world is this happening? Running SQL
> from an EXEC should slow things down, not speed them up. Afaik, it goes
> against everything I've ever learned about databases. Is the optimizer
> flawed in SQL Server 2000 SP3? Should we go to SP4?
Tibor probably identified the culprit - do you take him up on the
suggestion?|||Geoff N. Hiten wrote:
> Does your code query a remote server?
> PRB: Distributed Queries That Are Wrapped in a Stored Procedure with Input
> Parameters May Experience Performance Degradation
> http://support.microsoft.com/default.aspx?scid=kb;en-us;320208
>
Nope. Everything is on the same server.|||Scott Morris wrote:
>>This begs the question - why in the world is this happening? Running SQL
>>from an EXEC should slow things down, not speed them up. Afaik, it goes
>>against everything I've ever learned about databases. Is the optimizer
>>flawed in SQL Server 2000 SP3? Should we go to SP4?
>
> Tibor probably identified the culprit - do you take him up on the
> suggestion?
Yes, I tried that but it didn't help. There is an article on this topic
which is very informative, but it didn't apply to my situation.
http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx|||> Yes, I tried that but it didn't help.
What did you try?
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Frank Rizzo" <none@.none.com> wrote in message news:%23FAOPQW6FHA.3804@.TK2MSFTNGP14.phx.gbl...
> Scott Morris wrote:
>>This begs the question - why in the world is this happening? Running SQL
>>from an EXEC should slow things down, not speed them up. Afaik, it goes
>>against everything I've ever learned about databases. Is the optimizer
>>flawed in SQL Server 2000 SP3? Should we go to SP4?
>>
>> Tibor probably identified the culprit - do you take him up on the
>> suggestion?
> Yes, I tried that but it didn't help. There is an article on this topic
> which is very informative, but it didn't apply to my situation.
> http://blogs.msdn.com/khen1234/archive/2005/06/02/424228.aspx|||Tibor Karaszi wrote:
>> Yes, I tried that but it didn't help.
> What did you try?
I tried changing variables to parameters and also variables to hardwired
values.|||Are you saying that when you have the code in a stored procedure, the code is slow compared to when
not? Even if the procedure doesn't have any parameters and you hard-wire the search arguments inside
the procedure code? So basically, you have your TSQL code which is fast, add CREATE PROC on top and
when you execute that proc it is slow? And it doesn't matter if you create the proc or executing the
proc using WITH RECOMPILE? If so, I suggest you open a case with MS.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Frank Rizzo" <none@.none.com> wrote in message news:eCBzAlX6FHA.1184@.TK2MSFTNGP12.phx.gbl...
> Tibor Karaszi wrote:
>> Yes, I tried that but it didn't help.
>> What did you try?
> I tried changing variables to parameters and also variables to hardwired values.|||Tibor Karaszi wrote:
> Are you saying that when you have the code in a stored procedure, the
> code is slow compared to when not? Even if the procedure doesn't have
> any parameters and you hard-wire the search arguments inside the
> procedure code? So basically, you have your TSQL code which is fast, add
> CREATE PROC on top and when you execute that proc it is slow? And it
> doesn't matter if you create the proc or executing the proc using WITH
> RECOMPILE? If so, I suggest you open a case with MS.
Yes, that is precisely what I am saying. I am just a consultant here
and don't have the power to open a case, but I'll see who can take care
of this. Anyway, the problem was solved by executing the query dynamically.

Please make the world all right again.

I have reported some SQL execution plan whackyness on this newsgroup
( http://shrinkster.com/984 ) where a stored proc ran very slowly when
called as a stored procedure. However, if I just pasted the sproc
source code into Query Analyzer, it ran like a champ on the same set of
data. I finally zeroed in on a particular query that was causing this
and, again, it was fast in Query Analyzer and a dog inside the stored
procedure. The 2 methods would also generate a completely different plan.
Anyway, my co-worker found a solution, which is ugly but works great.
He simply placed the query text into a varchar variable and ran it as
Dynamic SQL using EXEC inside the stored procedure. All of a sudden,
the execution plans were identical and the speed was back to normal.
This begs the question - why in the world is this happening? Running
SQL from an EXEC should slow things down, not speed them up. Afaik, it
goes against everything I've ever learned about databases. Is the
optimizer flawed in SQL Server 2000 SP3? Should we go to SP4?
Thanks.Does your code query a remote server?
PRB: Distributed Queries That Are Wrapped in a Stored Procedure with Input
Parameters May Experience Performance Degradation
http://support.microsoft.com/defaul...kb;en-us;320208
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Frank Rizzo" <none@.none.com> wrote in message
news:eTXPZfV6FHA.2192@.TK2MSFTNGP14.phx.gbl...
>I have reported some SQL execution plan whackyness on this newsgroup
> ( http://shrinkster.com/984 ) where a stored proc ran very slowly when
> called as a stored procedure. However, if I just pasted the sproc source
> code into Query Analyzer, it ran like a champ on the same set of data. I
> finally zeroed in on a particular query that was causing this and, again,
> it was fast in Query Analyzer and a dog inside the stored procedure. The
> 2 methods would also generate a completely different plan.
> Anyway, my co-worker found a solution, which is ugly but works great. He
> simply placed the query text into a varchar variable and ran it as Dynamic
> SQL using EXEC inside the stored procedure. All of a sudden, the
> execution plans were identical and the speed was back to normal.
> This begs the question - why in the world is this happening? Running SQL
> from an EXEC should slow things down, not speed them up. Afaik, it goes
> against everything I've ever learned about databases. Is the optimizer
> flawed in SQL Server 2000 SP3? Should we go to SP4?
> Thanks.
>|||> This begs the question - why in the world is this happening? Running SQL
> from an EXEC should slow things down, not speed them up. Afaik, it goes
> against everything I've ever learned about databases. Is the optimizer
> flawed in SQL Server 2000 SP3? Should we go to SP4?
Tibor probably identified the culprit - do you take him up on the
suggestion?|||Geoff N. Hiten wrote:
> Does your code query a remote server?
> PRB: Distributed Queries That Are Wrapped in a Stored Procedure with Input
> Parameters May Experience Performance Degradation
> http://support.microsoft.com/defaul...kb;en-us;320208
>
Nope. Everything is on the same server.|||Scott Morris wrote:
>
> Tibor probably identified the culprit - do you take him up on the
> suggestion?
Yes, I tried that but it didn't help. There is an article on this topic
which is very informative, but it didn't apply to my situation.
http://blogs.msdn.com/khen1234/arch.../02/424228.aspx|||> Yes, I tried that but it didn't help.
What did you try?
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Frank Rizzo" <none@.none.com> wrote in message news:%23FAOPQW6FHA.3804@.TK2MSFTNGP14.phx.gbl.
.
> Scott Morris wrote:
> Yes, I tried that but it didn't help. There is an article on this topic
> which is very informative, but it didn't apply to my situation.
> http://blogs.msdn.com/khen1234/arch.../02/424228.aspx|||Tibor Karaszi wrote:
> What did you try?
I tried changing variables to parameters and also variables to hardwired
values.|||Are you saying that when you have the code in a stored procedure, the code i
s slow compared to when
not? Even if the procedure doesn't have any parameters and you hard-wire the
search arguments inside
the procedure code? So basically, you have your TSQL code which is fast, add
CREATE PROC on top and
when you execute that proc it is slow? And it doesn't matter if you create t
he proc or executing the
proc using WITH RECOMPILE? If so, I suggest you open a case with MS.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Frank Rizzo" <none@.none.com> wrote in message news:eCBzAlX6FHA.1184@.TK2MSFTNGP12.phx.gbl...
[vbcol=seagreen]
> Tibor Karaszi wrote:
> I tried changing variables to parameters and also variables to hardwired values.[/
vbcol]|||Tibor Karaszi wrote:
> Are you saying that when you have the code in a stored procedure, the
> code is slow compared to when not? Even if the procedure doesn't have
> any parameters and you hard-wire the search arguments inside the
> procedure code? So basically, you have your TSQL code which is fast, add
> CREATE PROC on top and when you execute that proc it is slow? And it
> doesn't matter if you create the proc or executing the proc using WITH
> RECOMPILE? If so, I suggest you open a case with MS.
Yes, that is precisely what I am saying. I am just a consultant here
and don't have the power to open a case, but I'll see who can take care
of this. Anyway, the problem was solved by executing the query dynamically.

Please help.. can't find how to administer userr accounts

I'm trying to administer permissions for other users so that reports can be
viewed remotely.
I'm told to go to http://myserver/reportserver but I get this error: The
permissions granted to user 'MyServer\IUSR_MyCompany' are insufficient for
performing this operation. (rsAccessDenied)
I'm told to go to http://myserver/reports and I do get a SSRS home page but
nothing on it to do anything with.
I'm told to launch SS Mgmt Studio, go into Reporting Services and
right-click on the Home folder and click Properties. I do this but then
there's nothing in there for me to work with.
Can anyone please tell me what's going on and how I can get in and
andminister user permissions?
Thanks for any help!
RonIt sounds to me like one of two things. Either you web has anonymous turned
on. If so, then all users are anonymous and no user can administer the
website.
Two, anyone who is in the local administrators group of the server can
administer RS. Are you a member of that group?
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Ronald S. Cook" <rcook@.westinis.com> wrote in message
news:u2JLWqaWHHA.3568@.TK2MSFTNGP06.phx.gbl...
> I'm trying to administer permissions for other users so that reports can
> be viewed remotely.
> I'm told to go to http://myserver/reportserver but I get this error: The
> permissions granted to user 'MyServer\IUSR_MyCompany' are insufficient for
> performing this operation. (rsAccessDenied)
> I'm told to go to http://myserver/reports and I do get a SSRS home page
> but nothing on it to do anything with.
> I'm told to launch SS Mgmt Studio, go into Reporting Services and
> right-click on the Home folder and click Properties. I do this but then
> there's nothing in there for me to work with.
> Can anyone please tell me what's going on and how I can get in and
> andminister user permissions?
> Thanks for any help!
> Ron
>
>
>
>|||Thanks Bruce.. I'll check those things. I appreciate the help.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%23WO9KwaWHHA.388@.TK2MSFTNGP04.phx.gbl...
> It sounds to me like one of two things. Either you web has anonymous
> turned on. If so, then all users are anonymous and no user can administer
> the website.
> Two, anyone who is in the local administrators group of the server can
> administer RS. Are you a member of that group?
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Ronald S. Cook" <rcook@.westinis.com> wrote in message
> news:u2JLWqaWHHA.3568@.TK2MSFTNGP06.phx.gbl...
>> I'm trying to administer permissions for other users so that reports can
>> be viewed remotely.
>> I'm told to go to http://myserver/reportserver but I get this error: The
>> permissions granted to user 'MyServer\IUSR_MyCompany' are insufficient
>> for performing this operation. (rsAccessDenied)
>> I'm told to go to http://myserver/reports and I do get a SSRS home page
>> but nothing on it to do anything with.
>> I'm told to launch SS Mgmt Studio, go into Reporting Services and
>> right-click on the Home folder and click Properties. I do this but then
>> there's nothing in there for me to work with.
>> Can anyone please tell me what's going on and how I can get in and
>> andminister user permissions?
>> Thanks for any help!
>> Ron
>>
>>
>>
>>
>