| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 334.1 | | CSC32::HOEPNER | A closed mouth gathers no feet | Mon Feb 03 1997 12:22 | 11 |
|
Huh?
400GB for the entire system? For one database? For one file?
What version NT is he talking about?
SQL Server supports over a terabyte.
Where did your customer get his information?
|
| 334.2 | certain statements make me suspicious... | DECWET::LENOX | Attack the future! | Tue Feb 04 1997 13:15 | 9 |
|
from .1 CSC32::HOEPNER wrote:
> SQL Server supports over a terabyte
Has anyone ever really run something this large?
From what I've heard around DECwest, it doesn't
sound like anyone has much experience with
a server this large (and that should include
Bill's evil empire).
|
| 334.3 | | CSC32::HOEPNER | A closed mouth gathers no feet | Tue Feb 04 1997 14:20 | 15 |
|
I certainly haven't seen or heard of a SQL Server db that large.
And under the current features of SQL Server I hope I don't see
one that large. ;-}
Most folks figure about the largest functional SQL Server is
a max of 100 gig. I have customers that are maxing at 10 gig and
have multiple dbs.
Someday if SQL Server becomes a multifile database, then the
maintenance and disaster recovery options would be more
enterprise-class friendly.
Mary Jo
|
| 334.4 | SQL Server is not an Enterprise product yet IMO | TBC001::DROVER | HEDGEHOG | Wed Feb 12 1997 10:13 | 14 |
| We are setting up a 1 T-byte benchmark at this very time, and just from
laying this one out on 2 clustered 8400s (using Oracle), I would not want
to try it on the current release of SQL Server. Hell I still can't find
a way to give SQL Server all 4 gig of ram on the 4100 here.
With all the talk of NT5, does anyone know of plans to take SQL Server
to the next (VLM) level? Or is it dependant on the O/S for memory
limitations?
As it is, I don't think SQL Server is there yet when compared to its
competitors. Too bad really because I prefer it. But when I think small
to low end systems, up to 30, 40 gigs of data I can think MS SQL
Server, when I think big installs with heavy transaction loads, I think
Oracle, Informix.....
|
| 334.5 | | CSC32::HOEPNER | A closed mouth gathers no feet | Wed Feb 12 1997 15:32 | 33 |
|
SQL Server will get there eventually.
2 Gig memory is MAX for WNT 3.51 and 4.0. And you need to give
SQL somewhat less than what is on the system.
From a practicle standpoint, most of the large databases I know of
and have worked with (Oracle and Oracle Rdb), we try to leave the
Terabyte databases as historical databases.
For an intense OLTP environment, most DBAs and system developers have
found that it is better from performance and disaster recovery to have
multiple smaller databases as part of one large schema. That way if
you lose a db, the rest can keep going.
Even with Rdb's feature of being able to restore just a page, it still
takes a bit of time to determine WHICH page to restore on a terabyte
db.
Again, if the database and application are well designed, the actual
size of the database does not concern me.
What is a BIG, BIG, BIG concern is disaster recovery. How do you
restore even parts of a terabyte sized database in a couple of hours?
In Oracle and Oracle Rdb, the area files are likely to be of rather
large sizes, the tables are likely to be of large sizes...
Eventually, I believe SQL Server will be multi-file, and with that we
should have better options to plan for disaster recovery. And we
should have better options for performance tuning.
Mary Jo
|
| 334.6 | for over a TeraByte of storage with NT & SQL, see | DECWET::montlake.zso.dec.com::lenox | Digital's suing Intel, best brand marketing there is | Tue May 13 1997 16:39 | 8 |
|
check out
www.alliance.digital.com/alliances/microsoft/scalability
The mention of 1TB of data means the database is larger
than 1TB. They don't mention which version of SQL they
are using in the page above but it isn't 6.5.
|
| 334.7 | kinda interesting | FLEXEM::HAGGERTY | Kevin, NSIS, Stow MA USA | Wed May 21 1997 11:24 | 4 |
| also
http://www.imc.das.dec.com/swrks/sw_mktg/presents/geron497.htm
for a presentation entitled "A TeraByte SQL Server Built on
StorageWorks" by Tom Barclay (MS) and Jim Geronaitis (DEC).
|
| 334.8 | SQL version is "Sphinx" | NESBIT::16.194.144.78::Sloan | Just Another Manic Monday | Wed May 21 1997 17:21 | 20 |
| re .6
>They don't mention which version of SQL they
>are using in the page above but it isn't 6.5.
The configuration for the Digital VLM demonstration was the
following:
2 Digital 8400 AlphaServers with 8 GB of RAM each, running Windows
NT� Server 5.0 and the upcoming "Sphinx" release of Microsoft SQL
Server. The VLM Server is using 64-bit memory addressing, enabling
use of the full 8 GB of RAM, while the non-VLM machine is limited to
use of the 2 GB of RAM available to 32-bit architectures.
For full details see:
http://www.microsoft.com/backoffice/scalability/sql.htm
/Shaun
|
| 334.9 | | DECWET::montlake.zso.dec.com::lenox | this note posted from NetNotes | Thu May 22 1997 10:35 | 11 |
|
The VLM demo was separate from the TB database demo.
They were using the next version of SQL for the TB database
demo but I couldn't find a public description of that to post
before the scalability day and I was not privy to what info
was public and what wasn't. I have gotten the chance to drool
over the amount of storage Digital has loaned to Microsoft for
it tho'. It is impressive to see many fully loaded storage cabs.
I don't think one should come away thinking that Microsoft/Digital
had an easy time setting up any of this.
|