Limts of SQL 2005 Enterprise

I know this might seem like a strange question, but we currently have a
database that very few people have heard of TurboPower FlashFiler
(http://sourceforge.net/projects/tpflashfiler/). We have had issues with it
as we approach 100 users. We have installed SQL 2005 Enterprise for the
goal of moving the database from TurboPower FlashFiler to SQL. But now the
developer has introduced that thought of going to NexusDB (www.nexusdb.com)
instead of SQL. The question from managment was asked "How many users can
access SQL?" They want an acutal number. Is there any articles of
performance test that test the upper limits of SQL or anything like a case
study where a company had 10,000 users accessing a database, etc.
Thanks,
MarkHave a look here:
Performance and Scalability: SQL Server 2005 Enterprise Edition
Benchmarks
http://www.microsoft.com/sql/prodinfo/compare/benchmarks.mspx
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
SQL troubleshooting: http://sql.veranoest.net
___ please respond in newsgroup, NOT by private email ___
"M.Siler" <John.Doe@.NoSpam.com> wrote on 23 aug 2007 in
microsoft.public.sqlserver.server:
> I know this might seem like a strange question, but we currently
> have a database that very few people have heard of TurboPower
> FlashFiler (http://sourceforge.net/projects/tpflashfiler/). We
> have had issues with it as we approach 100 users. We have
> installed SQL 2005 Enterprise for the goal of moving the
> database from TurboPower FlashFiler to SQL. But now the
> developer has introduced that thought of going to NexusDB
> (www.nexusdb.com) instead of SQL. The question from managment
> was asked "How many users can access SQL?" They want an acutal
> number. Is there any articles of performance test that test
> the upper limits of SQL or anything like a case study where a
> company had 10,000 users accessing a database, etc.
> Thanks,
> Mark|||"M.Siler" <John.Doe@.NoSpam.com> wrote in message
news:eUvz8cc5HHA.5424@.TK2MSFTNGP02.phx.gbl...
>I know this might seem like a strange question, but we currently have a
>database that very few people have heard of TurboPower FlashFiler
>(http://sourceforge.net/projects/tpflashfiler/). We have had issues with it
>as we approach 100 users. We have installed SQL 2005 Enterprise for the
>goal of moving the database from TurboPower FlashFiler to SQL. But now the
>developer has introduced that thought of going to NexusDB (www.nexusdb.com)
>instead of SQL. The question from managment was asked "How many users can
>access SQL?" They want an acutal number. Is there any articles of
>performance test that test the upper limits of SQL or anything like a case
>study where a company had 10,000 users accessing a database, etc.
> Thanks,
> Mark
>
Tell management that there is no fixed limit on the number of users. There
is plenty of evidence for SQL Server supporting thousands of users and multi
terabytes of data. See:
http://www.microsoft.com/SQL/BIGDATA/default.mspx
http://www.tpc.org/
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||On Thu, 23 Aug 2007 16:50:26 -0400, "M.Siler" <John.Doe@.NoSpam.com>
wrote:
>I know this might seem like a strange question, but we currently have a
>database that very few people have heard of TurboPower FlashFiler
>(http://sourceforge.net/projects/tpflashfiler/). We have had issues with it
>as we approach 100 users. We have installed SQL 2005 Enterprise for the
>goal of moving the database from TurboPower FlashFiler to SQL. But now the
>developer has introduced that thought of going to NexusDB (www.nexusdb.com)
>instead of SQL. The question from managment was asked "How many users can
>access SQL?" They want an acutal number. Is there any articles of
>performance test that test the upper limits of SQL or anything like a case
>study where a company had 10,000 users accessing a database, etc.
Even a modest server should support 100+ rich clients if the software
and data model are halfway decent. OTOH, a bad app and a bad database
can bog with one.
On the third hand, via a middle tier, you can support thousands of
sessions at the same time, I've been there in many shops.
Nexusdb? Doesn't sound like it's even meant to be a server.
Josh|||> Nexusdb? Doesn't sound like it's even meant to be a server.
Sorry just to clarify that :)
Our biggest site that we support *ourselves* is an Australian based a debt
collection agency. They have established their own offshore call center and
developed their own software on the basis of NexusDB. At the moment this
software runs with approximately 200 concurrent users spread over Australia,
India and the UK with the central database server located in
Brisbane/Australia and is thus online 24x7. If you need we can arrange for
them to provide reference/testimonial for NexusDB.
NexusDB was designed for small to medium sized environments. It clearly has
its limits in scalability and SQL Server surely has many benefits that
NexusDB doesn't have, still we think it has several advantages over MS-SQL:
* cost: the normal NexusDB Server is royalty free and comes as
developer licenses. So after the initial costs there is no further
cost, not for you and not for your clients/customers no matter how
many applications you ship to how many clients/users you want.
* support: we are a small company that knows very well that we
depend on our customers being happy. In the case of problems you're
can talk directly to the developers of the system instead of
support reps that have less knowledge than yourself and just work
off their flow diagram. If you need it we optionally provide service
level agreements with guaranteed response times
* footprint: NexusDB server is a 4.5 mb executable including SQL
engine and that's all you need.
* resources: NexusDB server runs very well on any hardware running
WinNT4 starting from 256MB memory.
* server installation: NexusDB server is very easy to install. Copy
the exceutable and a premade ini-config and start
* zero admin: NexusDB server doesn't need a database administrator as
everything is readily available in the clear and simple user interface
* best of both worlds: table/cursor based and SQL access in one.
NexusDB allows to mix and match and thus use the best approach for
every single one of your needs.
* no runtime libraries: a NexusDB client doesn't need any additional
runtime files or database client installation. All you need is the
executable
* SQL2003 compliance: NexusDB sticks as close possible to the SQL2003
standard instead of using its own proprietary language. This makes
integration of other databases and tools much easier
* another big point in above case is that converting from a table based
flashfiler based application is very easy and should be doable in
just a few days or less (including testing). You will almost
certainly see a big improvement in speed and stability and possibly
save you from developing a completely new system right now
* full source: YES, you get the full source code of server and client
with your license. down to the last line.
There are a lot more advantages from a purely technical point of view
covering things like full extensibility, customizable data compression &
encryption and great flexibility. get more info on www.nexusdb.com if you
like.

Limitayion of indexes

Hello there
I've been heard that after amount of data on table (Approx 1,000,000 records
and more) according to the type of index, the index performance is become
mutch more slower.
Does someone knows what is the limitation and how can i handle of it?Roy,shalom
It depends on how often your table is acceseed (insert/update/deleted) .
What is a WHERE condion and how often is changed. I'd prefer to rebuild
indexes on all my user tables one a w.
"Roy Goldhammer" <roy@.hotmail.com> wrote in message
news:%23Cxk3h$SGHA.6084@.TK2MSFTNGP14.phx.gbl...
> Hello there
> I've been heard that after amount of data on table (Approx 1,000,000
> records and more) according to the type of index, the index performance is
> become mutch more slower.
> Does someone knows what is the limitation and how can i handle of it?
>|||Whell Uri
Have you ever worked with approx 10,000,000 records?
and i know that there is fill factor for this case.
Do you have any idea for what is use?
"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:%23HcZEl$SGHA.5828@.TK2MSFTNGP14.phx.gbl...
> Roy,shalom
> It depends on how often your table is acceseed (insert/update/deleted) .
> What is a WHERE condion and how often is changed. I'd prefer to rebuild
> indexes on all my user tables one a w.
>
> "Roy Goldhammer" <roy@.hotmail.com> wrote in message
> news:%23Cxk3h$SGHA.6084@.TK2MSFTNGP14.phx.gbl...
>|||Roy
> Have you ever worked with approx 10,000,000 records?
:-))) Yes , even much much more

> and i know that there is fill factor for this case.
Yes , FillFactor is created along with a creation of index on the table

> Do you have any idea for what is use?
Do you want to know what FILLFACTOR to put on the table?
"Roy Goldhammer" <roy@.hotmail.com> wrote in message
news:O%23Rwtu$SGHA.5736@.TK2MSFTNGP10.phx.gbl...
> Whell Uri
> Have you ever worked with approx 10,000,000 records?
> and i know that there is fill factor for this case.
> Do you have any idea for what is use?
>
> "Uri Dimant" <urid@.iscar.co.il> wrote in message
> news:%23HcZEl$SGHA.5828@.TK2MSFTNGP14.phx.gbl...
>|||Index fragmentation can increase the amount of I/O required to scan an
index, and this would be more likely and noticable on large tables. DBCC
SHOWCONTIG will reveal the amount of fragmentation and DBCC DBREINDEX or
DBCC INDEXDEFRAG can be occasionally run the correct the problem, which
typically accumulates over time.
Understanding SQL Server's DBCC SHOWCONTIG:
http://www.sql-server-performance.c..._showcontig.asp
Microsoft SQL Server 2000 Index Defragmentation Best Practices:
http://www.microsoft.com/technet/pr...n/ss2kidbp.mspx
"Roy Goldhammer" <roy@.hotmail.com> wrote in message
news:%23Cxk3h$SGHA.6084@.TK2MSFTNGP14.phx.gbl...
> Hello there
> I've been heard that after amount of data on table (Approx 1,000,000
> records and more) according to the type of index, the index performance is
> become mutch more slower.
> Does someone knows what is the limitation and how can i handle of it?
>