Re: New install of SBS and where to put SQL and exchange

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

It's not really half on one and half on the other. Databases have two sets
of files for both speed and redundancy - log files (which record the
"writes" which are later merged in the DB) and the DB itself. Most vendors
recommend those should be on different spindles (ie: different arrays) with
the logs on RAID1 and the DB on RAID5 or 10 -- this gives you both safety
and speed. The partitions don't matter as much, it is which array they are
on that counts.

One thing to add about partitions though - shadow copy also has a bearing on
how you partition these days. You don't want to shadow copy your OS or
database drives so those should be separate from user data which you do want
shadows of.

In the end it won't make much difference in SBS with only 75 users maximum.
Don't forget these applications are designed for thousands of users.
--
Allan Williams



"Joe" <Joe@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FE859EDB-9999-4F1E-9F73-8F0CCC90EE0F@xxxxxxxxxxxxxxxx
Both raid arrays are physically different, one controler of course. They
are
very fast though, each drive is an SAS 15K rpm.

One thing I wonder about. SBS is one busy machine, exchange and sql, are
both resoursre hogs. Why bother trying to split both on different drive
sets
with one array having to also handle the OS as well. It seems by splitting
them both each is having to contend with the others resourses to run 1/2
of
itself???

I'm having a little diffucilty expressing my thoughts here. If you put
half
of exchange on "A", 1/2 of SQL on "A", plus the OS on "A", then you put
the
other half of Exchange and SQL on "B", is there really any gain in the
split
vs letting Exchange and the OS be on one drive and SQL being on the other
(in
this install SQL gets more work I think than exchange)??

"Al Williams" wrote:

Yes - you are going to get a lot of opinions here...

Partitions are good for organizing data and splitting things up to make
data
recovery faster/easier and to prevent an issue with one partition from
affecting others. I always like to keep the OS entirely separate from
the
data, and keeping databases like exchange and SQL separate has its
benefits
too. One downside though is if you make your partitions too restrictive
it
can cause one to overflow before the others (this isn't that big of deal
with non-boot partitions though as you can resize them fairly easily).

One thing to note though is partitions on the same physical drive do not
make things faster. Are your RAID1 and RAID5 arrays on completely
separate
drives with a multi-channel RAID controller? If so then the best
performance for any database (exchange, sqlserver, etc.) is to put the
log
files on the RAID1 and the databases on the RAID5 (or RAID10).
Separating
these files onto different "spindles" allows the fastest SQL transactions
as
the logs are commited first followed by the database. I usually create a
"LOG" partition for just this purpose on the RAID1 and a DATABASE
partition
on the RAID5.

--
Allan Williams



"Joe" <Joe@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:D58CB689-CCE8-4757-9E33-975AA676C0A4@xxxxxxxxxxxxxxxx
I almost hate to ask this question because Everyones opinon is valid and
the
ways are manafold BUT I want to try anyway.

With the advent of servers with Daul Quad processors, 4 gigs of ram two
cheap not to purchase, 15K rpm SAS drives reasonably priced we have a
WHOLE
log more performance than ever before.

I'm wondering if it isnt just simpler to put all of exchange in one
partition, all SQL in another, all user data in one, and the OS in
another?

For example on one server I am building I have a RAID 1 with 2 partions
and
a raid 5 with 2 partitions.

It would seem reasonable for an premium SBS install to put my OS and
Exchange on the Raid 1 (but seperate partitions), and put the SQL and
users
info on the other RAID 5 drive (seperate partitions). This customer
uses
Soloman for his business. By puting exchange on one drive and SQL on
the
other would that not prettly well split the performance hogs on
seperate
physical drives and make backing up and restore and just keeping track
of
where everything is easier?

Fire away!!!!!!

Joe





.

Relevant Pages

  • Re: Advice Requested : Disaster Recovery with 2 Drives (No Raid) with SQL Server 2008
    ... so we need frequent copies of the database for testing, ... Andrew J. Kelly SQL MVP ... But by placing the backups on the same drive as the data or logs you risk loosing data if one of the drives crashes since you will loose backups and either the log or data files. ...
    (microsoft.public.sqlserver.programming)
  • Re: New install of SBS and where to put SQL and exchange
    ... Both raid arrays are physically different, ... SBS is one busy machine, exchange and sql, are ... Partitions are good for organizing data and splitting things up to make data ... drives with a multi-channel RAID controller? ...
    (microsoft.public.windows.server.sbs)
  • Proper way to move Log files to another drive
    ... For speed, I have separate drives for OS, SWAP, APPS, SQL, and LOGS. ... the APPS drive, and it created its database, and log file, in the default ...
    (microsoft.public.sqlserver.setup)
  • Re: Mapped Drive
    ... SQL does not support mapped drives for database or transaction log ... I support the Professional Association for SQL Server ...
    (microsoft.public.sqlserver.server)
  • Re: IIS/SQL Server Hardware Recommendations?
    ... > settings for SQL 2000. ... All drives RAID via controller card, ... Set the database sizes bigger than you need, ...
    (microsoft.public.inetserver.iis)