How Much More Can I Put on This SQL Server?

It depends on kind of db applications you are running,
database design, overall size of databases in GB etc. A
database which is not bulky (for example more than 50gb)
in size, where most tables have a pk, and pre-defined
queries fetch one or few records at a time based on a
unique where condition, you could have few hundreds
simulaneious connections. Whereas in a data warehouse
application where you have really huge tables, users are
allowed to create and run queries as they like, and each
query ususally reads through millions of records, few
simulatneious users can saturate the system, and sometime
even one user can dominate the whole system.
Based on the information you have given, your db server
falls more into the first category, 150 or more
simultaneous users could stress the system. If possible,
you should run a stress test to see when the cpu hits 90%
or more utilization, that will be the saturation point.
i hope this answers your question to some extent. Let us
know if you have further questions.

>--Original Message--
>We have a 4 processor (Xeon 700mhz), 3GB, SQL Server 2000
Standard Edition,
>Win2K Standard, with 3 RAID Array's. Currently running
about 20 databases,
>75 concurrent connections. Performance monitor readings
look good,
>processor rarely goes above 35 percent, memory looks
good, the disk drives
>spike but are usually not too busy.
>My question is how much more can I load on this thing
(ballpark) before it
>starts to get even medium stress. I'm looking for anyone
with a similar
>configuration, with much bigger numbers to get some idea
of how fare I can
>go with this machine. I have looked on www.tpc.org site
and similar
>configurations list 67,000 concurrent users and 87,000
tmp, but that just
>doesn't seem real.
>Thanks for any info.
>Steven Berringer
>
>.
>Thanks for the feedback. I guess I was hoping to hear from someone who had
a similar configuration and had X number of users connected and running at
the same time. I understand the OLTP versus OLAP and good database design,
and all that, but 150 is a far cry from the 67,000 listed on the tpm web
site for a 4 processor box.
Does anyone have any real world stories?
Thanks
Steven
<anonymous@.discussions.microsoft.com> wrote in message
news:1401701c3f7c3$8b5961c0$a501280a@.phx
.gbl...
> It depends on kind of db applications you are running,
> database design, overall size of databases in GB etc. A
> database which is not bulky (for example more than 50gb)
> in size, where most tables have a pk, and pre-defined
> queries fetch one or few records at a time based on a
> unique where condition, you could have few hundreds
> simulaneious connections. Whereas in a data warehouse
> application where you have really huge tables, users are
> allowed to create and run queries as they like, and each
> query ususally reads through millions of records, few
> simulatneious users can saturate the system, and sometime
> even one user can dominate the whole system.
> Based on the information you have given, your db server
> falls more into the first category, 150 or more
> simultaneous users could stress the system. If possible,
> you should run a stress test to see when the cpu hits 90%
> or more utilization, that will be the saturation point.
> i hope this answers your question to some extent. Let us
> know if you have further questions.
>
>
> Standard Edition,
> about 20 databases,
> look good,
> good, the disk drives
> (ballpark) before it
> with a similar
> of how fare I can
> and similar
> tmp, but that just

how move data from informix, continuously

Dear Friends,
There is an "informix" dbserver, with a table that acts as cache for
continuously generated information ( an applications fills it continuously
in UNIX env).
I want to transfer(move) data from above informix table to my mssql table.
I find two way to do above movement
1- write an application that selects some info from Informix and insert
records to destination mssql then delete source records based on last
identity field
2- use schedule "Import Data" to copy data, simple but can't delete copied
data upto moved records not newer records
is there any other method? can I improve 2nd method to delete copied record
also?
thanks for any suggestions
TarvirdiHi Tarvirdi,
I need a wee bit more info to suggest something. What is the version of
Informix you are using, also you refer to a cache table, can you be more
specific? Hopefully you are not trying to examine/manipulate the internal
logging tables which control Informix data cahing and replication - chances
are you will break them.
Also some food for thought. Even when one undertakes continuous replication
from one informix instance to another, the drain on resources is quite
significant and also forces checkpointing to occur at the end of every commit
work statement. Typically one wouldn't attempt to do continuous replication
unless the application was so crucial that automatic and immediate failover
was required - which isn't possible with SQLServer anyway and arguably not a
great idea in Informix (don't the users want to know that something has just
gobe crach-bang?).
Gice me some more info and I'll try and help.
"Tarvirdi" wrote:
> Dear Friends,
> There is an "informix" dbserver, with a table that acts as cache for
> continuously generated information ( an applications fills it continuously
> in UNIX env).
> I want to transfer(move) data from above informix table to my mssql table.
> I find two way to do above movement
> 1- write an application that selects some info from Informix and insert
> records to destination mssql then delete source records based on last
> identity field
> 2- use schedule "Import Data" to copy data, simple but can't delete copied
> data upto moved records not newer records
> is there any other method? can I improve 2nd method to delete copied record
> also?
> thanks for any suggestions
> Tarvirdi
>
>sql

how move data from informix, continuously

Dear Friends,
There is an "informix" dbserver, with a table that acts as cache for
continuously generated information ( an applications fills it continuously
in UNIX env).
I want to transfer(move) data from above informix table to my mssql table.
I find two way to do above movement
1- write an application that selects some info from Informix and insert
records to destination mssql then delete source records based on last
identity field
2- use schedule "Import Data" to copy data, simple but can't delete copied
data upto moved records not newer records
is there any other method? can I improve 2nd method to delete copied record
also?
thanks for any suggestions
TarvirdiHi Tarvirdi,
I need a wee bit more info to suggest something. What is the version of
Informix you are using, also you refer to a cache table, can you be more
specific? Hopefully you are not trying to examine/manipulate the internal
logging tables which control Informix data cahing and replication - chances
are you will break them.
Also some food for thought. Even when one undertakes continuous replication
from one informix instance to another, the drain on resources is quite
significant and also forces checkpointing to occur at the end of every commi
t
work statement. Typically one wouldn't attempt to do continuous replication
unless the application was so crucial that automatic and immediate failover
was required - which isn't possible with SQLServer anyway and arguably not a
great idea in Informix (don't the users want to know that something has just
gobe crach-bang?).
Gice me some more info and I'll try and help.
"Tarvirdi" wrote:

> Dear Friends,
> There is an "informix" dbserver, with a table that acts as cache for
> continuously generated information ( an applications fills it continuously
> in UNIX env).
> I want to transfer(move) data from above informix table to my mssql table.
> I find two way to do above movement
> 1- write an application that selects some info from Informix and insert
> records to destination mssql then delete source records based on last
> identity field
> 2- use schedule "Import Data" to copy data, simple but can't delete copie
d
> data upto moved records not newer records
> is there any other method? can I improve 2nd method to delete copied recor
d
> also?
> thanks for any suggestions
> Tarvirdi
>
>