Any experience with really large, high transaction databases?

Most of my experience is with what I consider small, low transaction rate
databases. For example, the largest table in one DB has fewer than 100,000
rows (other tables have far fewer rows) with anywhere from 1 to 15 people
posting queries and updates at any given time. SQL Server handles this just
fine.
We are beginning to design a database for a new project. We haven't
determined how big the tables will be but at peak usage will have perhaps
100 people logged on at a time. There is pressure to use Oracle because of a
belief that SQL Server will not be up to the demands.
Solid, unbiased comparisons between Oracle and SQL Server are hard to come
by. Does anyone here have experience with large systems that would show what
SQL Server is really capable of?
Much obliged.
I can't give out many proprietary details but we are a SQL Server shop and
we handle databases > 1 TB with over 1000 simultaneous connections.
IMHO, your bottleneck is going to be the architecture and design of the
database and application, and more importantly hardware. You will not be
bound by the vendor choice.
http://www.aspfaq.com/
(Reverse address to reply.)
"Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in message
news:eJtzZ#dZEHA.3092@.tk2msftngp13.phx.gbl...
> Most of my experience is with what I consider small, low transaction rate
> databases. For example, the largest table in one DB has fewer than 100,000
> rows (other tables have far fewer rows) with anywhere from 1 to 15 people
> posting queries and updates at any given time. SQL Server handles this
just
> fine.
> We are beginning to design a database for a new project. We haven't
> determined how big the tables will be but at peak usage will have perhaps
> 100 people logged on at a time. There is pressure to use Oracle because of
a
> belief that SQL Server will not be up to the demands.
> Solid, unbiased comparisons between Oracle and SQL Server are hard to come
> by. Does anyone here have experience with large systems that would show
what
> SQL Server is really capable of?
> Much obliged.
>
|||100 concurrent users is piddly these days for SQL Server. Three years ago I
was doing over 100 Million Inserts / Updates or Deletes against a db with
over 1 Billion rows on what would be considered an obsolete box these days
with no problem what so ever. Here are some links but these are for VLDB's.
We are talking thousands of trans per second and up with Terabyte db's.
http://www.microsoft.com/sql/techinf...calability.asp
Andrew J. Kelly SQL MVP
"Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in message
news:eJtzZ%23dZEHA.3092@.tk2msftngp13.phx.gbl...
> Most of my experience is with what I consider small, low transaction rate
> databases. For example, the largest table in one DB has fewer than 100,000
> rows (other tables have far fewer rows) with anywhere from 1 to 15 people
> posting queries and updates at any given time. SQL Server handles this
just
> fine.
> We are beginning to design a database for a new project. We haven't
> determined how big the tables will be but at peak usage will have perhaps
> 100 people logged on at a time. There is pressure to use Oracle because of
a
> belief that SQL Server will not be up to the demands.
> Solid, unbiased comparisons between Oracle and SQL Server are hard to come
> by. Does anyone here have experience with large systems that would show
what
> SQL Server is really capable of?
> Much obliged.
>
|||Geoff,
The best example I can think of is Monster.com. They use SQL Server for
their entire jobs database, and get a lot more traffic than 100 people
logged on at a time!
One of the reasons, IMO, Oracle is often considered to be "more scalable"
than SQL Server is that companies tend to buy cheaper servers to run SQL
Server than to run Oracle. For instance, a recent employer of mine based
their entire product on SQL Server and our servers were dual Xeons with 2 gb
of RAM. The servers ran without too many problems, but management would
never spend a cent to upgrade them when we did have issues.
A consultant was hired for a totally new project and convinced management to
take it forward with Oracle. A pair of servers was purchased (QA and
Production), each with 8 Itanium processors and 64 gb of RAM. This, for an
unproven product that was making no money.
Why? Because for some reason, due to the way SQL Server is marketed vs. the
way Oracle is marketed, it's assumed that Oracle "should" sit on a huge
server whereas SQL Server will do better on a glorified desktop box. I'm
not sure how to best convince people of the truth... Good luck!
"Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in message
news:eJtzZ%23dZEHA.3092@.tk2msftngp13.phx.gbl...
> Most of my experience is with what I consider small, low transaction rate
> databases. For example, the largest table in one DB has fewer than 100,000
> rows (other tables have far fewer rows) with anywhere from 1 to 15 people
> posting queries and updates at any given time. SQL Server handles this
just
> fine.
> We are beginning to design a database for a new project. We haven't
> determined how big the tables will be but at peak usage will have perhaps
> 100 people logged on at a time. There is pressure to use Oracle because of
a
> belief that SQL Server will not be up to the demands.
> Solid, unbiased comparisons between Oracle and SQL Server are hard to come
> by. Does anyone here have experience with large systems that would show
what
> SQL Server is really capable of?
> Much obliged.
>
|||I agree with Aaron here, the architecture and design are key. We have over
1TB of data here and tables with over 1 billion records (horizontally
partitioned.) SQL Server can handle the workload if the project is done
correctly. Make sure to note if you don't have the enterprise version of
SQL you can't use more than 2 gigs of memory.
-John Oakes
"Aaron [SQL Server MVP]" <ten.xoc@.dnartreb.noraa> wrote in message
news:ui$E6CeZEHA.3304@.TK2MSFTNGP09.phx.gbl...
> I can't give out many proprietary details but we are a SQL Server shop and
> we handle databases > 1 TB with over 1000 simultaneous connections.
> IMHO, your bottleneck is going to be the architecture and design of the
> database and application, and more importantly hardware. You will not be
> bound by the vendor choice.
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>
> "Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in
message[vbcol=seagreen]
> news:eJtzZ#dZEHA.3092@.tk2msftngp13.phx.gbl...
rate[vbcol=seagreen]
100,000[vbcol=seagreen]
people[vbcol=seagreen]
> just
perhaps[vbcol=seagreen]
of[vbcol=seagreen]
> a
come
> what
>
|||Thanks Adam - Monster.com is a good example. Could you tell me how you know
they use SQL Server?
I wonder if the reason everyone thinks of SQL Server as being lower end is
two-fold: (1) it is cheaper to get a SQL license, and (2) Oracle has always
been associated with large servers, while MS is associated with the desktop.
"Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
news:eQZjlOeZEHA.2776@.TK2MSFTNGP10.phx.gbl...
> Geoff,
> The best example I can think of is Monster.com. They use SQL Server for
> their entire jobs database, and get a lot more traffic than 100 people
> logged on at a time!
> One of the reasons, IMO, Oracle is often considered to be "more scalable"
> than SQL Server is that companies tend to buy cheaper servers to run SQL
> Server than to run Oracle. For instance, a recent employer of mine based
> their entire product on SQL Server and our servers were dual Xeons with 2
gb
> of RAM. The servers ran without too many problems, but management would
> never spend a cent to upgrade them when we did have issues.
> A consultant was hired for a totally new project and convinced management
to
> take it forward with Oracle. A pair of servers was purchased (QA and
> Production), each with 8 Itanium processors and 64 gb of RAM. This, for
an
> unproven product that was making no money.
> Why? Because for some reason, due to the way SQL Server is marketed vs.
the
> way Oracle is marketed, it's assumed that Oracle "should" sit on a huge
> server whereas SQL Server will do better on a glorified desktop box. I'm
> not sure how to best convince people of the truth... Good luck!
>
> "Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in
message[vbcol=seagreen]
> news:eJtzZ%23dZEHA.3092@.tk2msftngp13.phx.gbl...
rate[vbcol=seagreen]
100,000[vbcol=seagreen]
people[vbcol=seagreen]
> just
perhaps[vbcol=seagreen]
of[vbcol=seagreen]
> a
come
> what
>
|||"Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in message
news:%23RVJG9eZEHA.912@.TK2MSFTNGP10.phx.gbl...
> Thanks Adam - Monster.com is a good example. Could you tell me how you
know
> they use SQL Server?
I interviewed there last year for a data architect position.
|||There are many larger sites with lots of users that use SQL Server.
Dell.com, CareerBuilder.com, Barnes & Nobles etc...
Andrew J. Kelly SQL MVP
"Geoff Pennington" <Geoffrey.Pennington@.tma.osd.mil.nospam> wrote in message
news:%23RVJG9eZEHA.912@.TK2MSFTNGP10.phx.gbl...
> Thanks Adam - Monster.com is a good example. Could you tell me how you
know
> they use SQL Server?
> I wonder if the reason everyone thinks of SQL Server as being lower end is
> two-fold: (1) it is cheaper to get a SQL license, and (2) Oracle has
always
> been associated with large servers, while MS is associated with the
desktop.[vbcol=seagreen]
>
> "Adam Machanic" <amachanic@.hotmail._removetoemail_.com> wrote in message
> news:eQZjlOeZEHA.2776@.TK2MSFTNGP10.phx.gbl...
scalable"[vbcol=seagreen]
based[vbcol=seagreen]
2[vbcol=seagreen]
> gb
management[vbcol=seagreen]
> to
> an
> the
I'm[vbcol=seagreen]
> message
> rate
> 100,000
> people
> perhaps
because[vbcol=seagreen]
> of
> come
show
>
|||SQL Server is not a punk anymore.
many of the ORACLE Folks still think of SQL Server as SQL Server 6.5.
if you want a Non-Biased opinion check out the TPC site.
www.tpc.org
The results speak for themselves (SQL Server can DEFINATELY Hold it's own AS
Can ORACLE and DB2).
Greg Jackson
PDX, Oregon
|||We HAVE had performance issues. HOWEVER every one of them were
"Architectural" in nature.
Cheers
Greg Jackson
PDX, Oregon