April 24, 2010 at 11:17 pm
That's a bad, bad idea.
April 25, 2010 at 9:02 am
Robert Davis (4/23/2010)
400 databases? On how many servers?
Total of 2 servers (now) one main and one mirror. Right now we have 130 databases. Everything we read tells my boss that this is not an issue, because of: the point to point 1GB fiber connection between the two locations, the 64-bit operating system and 128GB RAM.
The rest of the staff have been unable to point out anything that can change his mind. He is really only looking at DR.
April 26, 2010 at 5:17 pm
How many logical processors? Is SQL Server Enterprise Edition or Standard Edition?
You do understand that the recommendation to limit the number of mirrored databases is due to thread consumption, right? Not network connection nor RAM.
April 26, 2010 at 10:10 pm
Robert Davis (4/24/2010)
That's a bad, bad idea.
Just my 2 cents, but when Robert Davis, the guy that wrote the book on what you are trying to do, says it is a very bad idea, you might want to consider other options.
April 27, 2010 at 5:49 am
How many applications will be using these databases?
David Bird
April 27, 2010 at 6:11 am
Maybe it wouldn't be such a bad idea to contact SQLCAT to get your calculations confirmed that would make mirroring the optimal solution for your case.
Another ref that may help you build your case may be
"SQL Server Consolidation Guidance" http://msdn.microsoft.com/en-us/library/ee819082.aspx
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
April 27, 2010 at 7:48 am
Robert Davis (4/26/2010)
How many logical processors? Is SQL Server Enterprise Edition or Standard Edition?You do understand that the recommendation to limit the number of mirrored databases is due to thread consumption, right? Not network connection nor RAM.
What is the effect of thread consumption - when I started this thread we had planned on upgrading to 2008, now we are staying with 2005 Standard 64 bit edition (for the short term).
We have 130 databases now, growth to 200-240 in the next 12 months. We have been upgrading servers about ever 24 months.
April 27, 2010 at 7:50 am
David Bird (4/27/2010)
How many applications will be using these databases?
one application - we build software for political campaigns. Each database is a political client.
April 27, 2010 at 8:26 am
More threads = more memory usage, more CPU required, and of course the number of cores will limit the number of concurrent active threads. If the threads can't do what they need to do then there will be a delay - in synchronous mirroring any delay on the mirror is reflected on the principal.
Whilst I agree with Robert's comment about thread consumption being the reason for the limit recommendation, it's ultimately all about resources and whether you have enough. In your case you are trying to do so much that you need to look at EVERY resource. Using SQL2005 means that you won't have the benefit of a compressed data stream - how much log do you generate during peak periods? Can you push that much data across your network? I am going to assume that you are using Enterprise edition.
If you are really stuck with the decision to mirror, splitting the databases over multiple principal and mirror servers may alleviate some issues - but even then you will need to do the resource analysis.
April 27, 2010 at 8:28 am
I'd tend to trust Robert on the thread issue here. The more databases you add, the more threads you use.
How large are these dbs and how much activity per day? Say how many MB of log activity in each one?
Is there some reason that you wouldn't just have 2-3 servers at each location and mirror the databases between them? Can the app point to separate connection strings for each event? Thinking rather than trying to get bigger and bigger boxes, maybe it makes sense to have a couple smaller ones.
April 27, 2010 at 8:45 am
It is 2005 64bit Standard Edition.
Since we use log shipping I can tell you the last 72 hours of logs - 2.53 GB (2,720,354,304 bytes) 133 Databases
A client that might be a rep sample has - 31.0 MB (32,600,064 bytes) in 286 files.
Most are under 20 MB.
Largest I could find was 163 MB (171,323,392 bytes) in 289 files.
Again this is the last 72 hours.
April 27, 2010 at 9:14 am
289 files? Do you mean 289 ndf files?
April 27, 2010 at 9:19 am
matt stockham (4/27/2010)
Whilst I agree with Robert's comment about thread consumption being the reason for the limit recommendation, it's ultimately all about resources and whether you have enough. In your case you are trying to do so much that you need to look at EVERY resource. Using SQL2005 means that you won't have the benefit of a compressed data stream - how much log do you generate during peak periods? Can you push that much data across your network? I am going to assume that you are using Enterprise edition.
I think our resources are pretty huge, because of: the point to point 1GB fiber connection between the two locations, the 64-bit operating system and 128GB RAM.
Why Enterprise?
April 27, 2010 at 9:36 am
Steve Jones - Editor (4/27/2010)
289 files? Do you mean 289 ndf files?
No, Log files.
Someone asked how big the transactions are, and the closest thing I could think of was the log files.
April 27, 2010 at 9:47 am
the main specs on the two new servers that just came in:
Dell R710
128GB Memory (16*8GB) 800 MHz dual Ranked RDIMMs for 2 processors, optimized
2 - Xeon E5630 2.53 Ghz, 12M Cache, Turbo, HT, 1066 MHz Max mem
6- 600GB 15K RPM SA SCSI 6Gbps 3.5 hot Plug Hard Drive
Raid 1 - not sure on the configureation might be 2 logical drives 600 and 1200 GB
2 - Broadcom GB Ethernet NICS
OS - Windows Server 2008R2
SQL - SQL Server 2005 64 bit - Standard edition
Viewing 15 posts - 31 through 45 (of 51 total)
You must be logged in to reply to this topic. Login to reply