Re: Server Configuration

It's always a good idea to separate the log from the data files onto
different physical drive arrays when possible. Both from a performance and
DR standpoint. In your case you may or may not see a noticeable performance
increase now but who is to say you won't sometime down the road as traffic
increases.

--
Andrew J. Kelly SQL MVP


"C Barnhart" <CBarnhart@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1AD7AC6C-BE8D-4D39-B3BF-9ED134793B83@xxxxxxxxxxxxxxxx
> Thanks for the reply.
>
> It sounds like segregating the OS/app/Tr Log from the data is not that
> much
> of a concern in an environment like mine, where the transaction rate is
> not
> that high (or heavy) or, more importantly, a little server down time is
> not
> job-threatening. The information I have read recommends putting each
> (OS/App,
> Tr Log, and Data) on separate RAIDs--that would be 3 RAIDs in one box!
>
> In situations where there are thousands or millions of transactions per
> minute, this migh be reasonable. However, in my situation, there might be
> 100s/min. So we are more concerned with fast-running queries than
> transaction
> rate and fault tolerance (tr log is backed up hourly and database is
> backed
> up nightly). But since we have the opportunity to purchase a new server, I
> wanted to do it "right".
>
> It sounds like, from your answer, there IS something to gain by locating
> the
> OS, App, and Tr Log on one RAID and the database on the other.
>
> Thanks for your clarification.
>
> Charles Barnhart
>
>
> "Andrew J. Kelly" wrote:
>
>> It really depends on the type and volume of transactions. The more you
>> do
>> or the heavier they are the more you can usually see a difference over
>> having the log file on the same drive as the data. Since the OS is
>> rarely
>> used on a properly configured machine with only SQL Server running it can
>> be
>> more beneficial to place the log with the OS vs. the data. As for the
>> data
>> RAID you might want to see if you can't do a RAID 1+0 instead of 5.
>>
>> --
>> Andrew J. Kelly SQL MVP
>>
>>
>> "C Barnhart" <CBarnhart@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:DB30BA10-8584-4C36-B308-8005A8934296@xxxxxxxxxxxxxxxx
>> > Does storing the Transaction Log on the same mirrored disk set as the
>> > OS
>> > negate any benefit of storing on a separate physical drive from the
>> > database?
>> > I am about to purchase a new server and would like to address the "log
>> > on
>> > separate physical disk" issue.
>> >
>> > Planning to purchase an HP DL380 with two raid configurations:
>> > (1) RAID 1 for OS, app and Tr Log (2 - 36GB mirrored drives)
>> > (2) RAID 5 for database (4 - 72GB)
>>
>>
>>


.

Relevant Pages

  • Re: Should Trans-Log be on its own RAID volume?
    ... The transaction log does not truncate after each transaction. ... do with the reason why you should strive to place the log file on a separate ... We have 8 disk drives and we're trying to decide how to set up RAID. ...
    (microsoft.public.sqlserver.server)
  • RE: table structure
    ... As far as the table structures, each transaction can ... possibly each hour for each day as a separate line ... Keep your company and schedule tables the ... tables for sales and purchases, ...
    (microsoft.public.access.tablesdbdesign)
  • Re: sqlserver 2005: indexes on raid-0?
    ... located on a raid-5 arrayand the transaction log is on the same ... AND hourly log backups to the same disk array, ... decided to place the busiest/largest tables on separate drives. ...
    (comp.databases.ms-sqlserver)
  • Re: question about drives configuration
    ... This can impact cache performance since ... RAID 1+0 layoud for best performance. ... > Looking for a SQL Server replication book? ...
    (microsoft.public.sqlserver.clustering)
  • Re: SATA RAID 5 Performance
    ... RAID5 certainly isn't designed to perform write operations as fast as ... but then again writes aren't written transactionally to disk on ... but RAID5 often cuts the mustard for many small to mid range transaction ... Are there any RAID vendors I should look ...
    (microsoft.public.sqlserver.server)