Question About Scalability of Reporting Services

We use SQL Server 2000 Reporting Services to represent reports for our company.

Our boss complained to me about the poor performance of Reporting Services when he viewed reports. He suspected that RS Server is a single-thread server and can not be scaled up by adding more CPUs or memories to increase the reports process speed.

Is my boss correct?

And how can we increase the performance of Reporting Servces?

Traditional scale up can resolve the issue?

Appreciate your precious reply.

Your boss is not correct :)

We will scale up with more CPUs. Most of Reporting Services is managed code, so we are subject to whatever memory constraints are in place by the CLR. So on 32-bit machines we will use up to 2GB of memory, and we will use more on 64-bit platforms.

You can check the execution log to see which reports in particular are taking a long time to execute and what phases of those executions are long running:

http://msdn2.microsoft.com/en-us/library/ms159110.aspx

See Tudor's blog entry on performance here as well:

http://blogs.msdn.com/tudortr/archive/2004/06/28/167969.aspx

It has good tips for optimizing a poorly performing report.

|||

Excellent!

Thanks alot!

Question about converting bigint field to int field

We made a poor decision a long time ago when designing our database
structure. We used bigint data types as the identity keys for many of
our base tables. For many reasons I would like to change these fields
to int at the largest. The largest data in these fields is around
200,000. I know that int can easily store this.

What should I be worried about when changing these fields from bigint
to int? If anything. Your help is appreciated. I did several
searches without much luck.I think you've covered the one biggy - make sure your existing data will
fit!

Others...

a) Make sure anything you join with are the same type, basically make
sure you change it everywhere including your foreign keys table.
b) Remember to do the stored procedures, udfs, triggers that may use them
as parameter.
c) You'll need to drop any constraints on your column definied with the
identity property, see example problem...

drop table t

create table t (
mycol bigint identity primary key,
t char(1) )

insert t ( t) values( 'a' )

alter table t alter column mycol int not null

Tony.

--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials

<mamorgan1@.gmail.com> wrote in message
news:1137768775.133857.115810@.g44g2000cwa.googlegr oups.com...
> We made a poor decision a long time ago when designing our database
> structure. We used bigint data types as the identity keys for many of
> our base tables. For many reasons I would like to change these fields
> to int at the largest. The largest data in these fields is around
> 200,000. I know that int can easily store this.
> What should I be worried about when changing these fields from bigint
> to int? If anything. Your help is appreciated. I did several
> searches without much luck.|||Just curious... What problems are there with having bigint as an
identity column?|||There aren't any problems - it works just fine.

--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials

"pb648174" <google@.webpaul.net> wrote in message
news:1138052526.544803.80680@.z14g2000cwz.googlegro ups.com...
> Just curious... What problems are there with having bigint as an
> identity column?|||I think its because
Bigint takes 8 bytes storage and Int takes 4 bytes.
SQL Server will not automatically promote other integer data types
(tinyint, smallint, and int) to bigint.

Regards
Amish Shah|||> What problems are there with having bigint as an identity column?

extra storage space causing slower performance of everything