February 21, 2008 at 1:17 pm
Hello, I have 3 SQL databases that we will be running at our office.
1 is the Great Plains Dynamics Accounting software. This database is about 8 Gigs (2 years worth of data).
We then have our companies database (orders, customers, products, data mining), lets say 10-15 gigs worth of data.
And finally we will have a third database for a CRM application (Approx 4 Gigs of data)
We have about 4-5 users that will be using Great Plains all the time, and about 8 users that will be using the CRM at all times. I have been leaning towards buying a HP iSCSI SAN to store all this data on a fast drive array, but I would like to hear some feedback on this first.
Also, would the recommendation be to have the data files and log files for each of the 3 databases on their own RAID 1 arrays, or using a large RAID 5 Array with all the data on the same partitions.
I've seen several articles that mention SAN can be good or bad, but none really get down to the level of where to place files in what type of arrays on the system.
One other thing to mention is that this san would also probably hold our exchange server data files as well. right now all our data is on a SATA raid, on a cheap controller, so all the raid functions are software based. I think most of our issues at this point are going to be related to disk IO.
February 21, 2008 at 4:22 pm
If you go with the SAN, get HP to help. I'd separate things out, but there are good reasons not to go with R5. Better to R1 and R10, even if you have to combine data files or log files from multiple databases.
SAN might be overkill for that few users, and be sure you have spare drives. More drives (SAN or not) = more failures. Good to have spares.
I might run this all on a 4-8 drive setup, using multiple R1 or R10 arrays. You're talking 30GB, not much data. Buy a big enough box, maybe look at an x64 with 8 or 16GB or RAM and the disks might barely matter.
February 21, 2008 at 4:27 pm
A lot of this will depend on actual usage patterns so some of these are based on past experience with clients with some similarity.
- Stay Hardware RAID, and stick to SCSI.
- If Performance is what you're after - I'd look at going RAID 10 instead (at least for some of the volumes). RAID 5 has a distinct write performance handicap.
- Going with multiple disk sets (one per DB) is great for performance, but probably overkill (due to size at this point). I would however put tempDB on its own, logs on their own, and data on their own.
Putting SQL Server and Exchange in the same SAN is often a "challenge". If not done correctly, it ends up hurting both products, since their usage patterns tend to get in each other's way and the end result is slower performance from BOTH apps (from my personal observation). Unless you plan on bringing in a storage expert specifically to deal with that setup - I'd stay clear of that. You'd be better off keeping SQL Server on its own dedicated disks.
And - If you're going x64 on the OS - invest in RAM. Amazing how much faster things can be if your entire database can fit in memory....:)
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
February 21, 2008 at 9:21 pm
Right now our company seems to have mostly entry level servers (without real raid sub systems).
I was hoping that consolidating all the disk IO (exchange and SQL) on the SAN would help everything out.
After hearing from you guys I think it may be a better idea just to spend that money on a nice dedicated SQL server.
How does this sound?
HP DL180 G5
8 15K RPM SAS drives (4 x Raid 1 Partitions for System, Data, Logs, and temp database)
Dual Quad Core Xeon E5430 2.66 Ghz
and 16 Gig's of ram
on one other note, I would assume that all these databases should be in the sql server same instance? Our great plains integrators had suggested the GP databases be in their own instance. Seems in efficient to me since they both try to grab whatever ram is available.
Thank you for your responses.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply