Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion Groups
DB Engine
SQL ServerMSDESQL Server CE
Services
Analysis (Data Mining)Analysis (OLAP)DTSIntegration ServicesNotification ServicesReporting Services
Programming
CLRConnectivitySQLXML
Other Technologies
ClusteringEnglish QueryFull-Text SearchReplicationService Broker
General
Data WarehousingPerformanceSecuritySetupSQL Server ToolsOther SQL Server Topics
DirectoryUser Groups
Related Topics
MS AccessOther DB ProductsMS Server Products.NET DevelopmentVB DevelopmentJava DevelopmentMore Topics ...

SQL Server Forum / General / Data Warehousing / August 2005

Tip: Looking for answers? Try searching our database.

SQL Server on more than 4 CPUs??

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Peter Nolan - 21 Jun 2005 15:43 GMT
Hi All,
I was browsing for recent articles and saw the attached...

Unisys also released a benchmark TPC-H on a 16 processor windows
machine....

But my question is how well is win 2003/sql server 2005 scaling on
windows now? I've recently upgraded some software I developed to
provide unlimited scalability on unix systems (more processes running
but no more memory)....I understood win2000+ to still be limited to
about 3GB memory though there is ability to request more but colleagues
say it sometimes does not work so well...

I'd be intersted to hear from anyone who is really doing sizable DWs on
win2003 in 32 bit mode....or even if you are doing 64 bit mode it might
be interesting.....

I would like to hear purely on the basis that when my clients ask if
sql server can support them my current answer is that if they need more
than 4 CPUs to support the ETL or query load I am saying they should
probably pass and go for solaris/AIX...

Thanks

Peter Nolan.

http://biz.yahoo.com/prnews/050621/sftu040.html?.v=15
Danny - 07 Jul 2005 02:20 GMT
Peter,

I see no one has replied to your message.  We have run large data warehouses
on both SQL 2000 32 bit and 64 bit.  By large I mean the sources are over
1TB and the resulting DW is 300GB of primary data and 600GB of historical
data.  While it is true that Windows 2000 32 bit can only directly access up
to 3GB of RAM, it can access up to 64GB of RAM using PAE and AWE.  Yes its
slower and has limitations but still much faster than waiting on disk IO.
If you just need an RDBMS (not DTS) and are in the market for a new server,
I recommend the 64 bit SQL over the 32 bit.

So to answer your request... Yes there are companies that have large DWs in
production on SQL both 32 and 64 bit.

> Hi All,
> I was browsing for recent articles and saw the attached...
[quoted text clipped - 23 lines]
>
> http://biz.yahoo.com/prnews/050621/sftu040.html?.v=15
Peter Nolan - 08 Jul 2005 15:56 GMT
Hi Danny,
thanks for this...I was starting to wonder....even my friends at MSFT
did not answer that question..(LOL).

I would like to give 64 bit a run but alas I do not have a 64 bit
machine to give it a run on!!  I was not aware 64 bit sql server did
not come with DTS as well....so thanks for that tip as well....I have
written my own ETL software and implemented 'endless scalabilty' on
unix to make it usable in very large sites.....maybe I'll get to use it
on a large windows SQL Server site one day!!

Next time a client asks me if I have heard of large databases being
done on Windows I can say "I've heard of some".. ;-)....seems all my
large clients like to use Oracle/unix...

Best Regards

Peter Nolan
www.peternolan.com
Jeff Bond - 19 Aug 2005 21:41 GMT
jhslkafdslkafjdsal;kfdsajkl;fsad

> Hi All,
> I was browsing for recent articles and saw the attached...
[quoted text clipped - 23 lines]
>
> http://biz.yahoo.com/prnews/050621/sftu040.html?.v=15
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.