Minimal configuration, suggestions wanted.

Minimal configuration.
(Performance is not an issue).
Dataloss should not happen. (But we do not account
for real dissasters, for example a big fire destroying
the complete production center, resulting
in the dataloss of 24 hours would be acceptable.)
The shop runs 7 x 24 hours.
Most is done during office hours.
Some is done during all day.
At night the system must be available but it is
used very limited.
Once a day a tape goes from the production machine to an
offsite safe.
The total amount of data has a disk footprint off
between 1 and 10 Gigabytes.
Offcourse there is a production machine and
a standby machine probably in another location.
(The second machine will be used for testing and
practicing procedures.)
Raid is required, raid protects agains single disks failures,
but what are the options for more protection ?
What configuration is considered minimal in these circumstances ?
Esspecially what to do with the disks ?
(OS / Logging / Data / Backupdata / Transactionlog backup) ?
What can be combined and what can not be combined ?
And how often to do the transactionlog backup ?
(Side question what "route" should the transactionlog(-backup)
take).
Keep in mind : We are looking for a minimal configuration.
Later on we will also looking for a 'larger' configuration with
more performance, a larger database etc. (But still no super
configuration. Something like 100-200 Gigabyte and more load).
Thanks for your thoughts,
ben brugman.Keep in mind that a server with a 200GB db and moderate load may not be the
same for a 10GB db with light load and this is addressing the latter as you
asked. A RAID 0+1 will give the most fault tolerate Raid with good
performance as well. If the load is light enough (not a lot of
transactions) then you can probably get away with a good size (meaning # of
disks not size of disks) RAID 0+1 or even 1+0 that has everything on it.
But it is usually best to place the logs on their own RAID 1 and separate
from the data for performance reasons. With a minimal configuration a good
raid is essential along with proper backups. A full backup once a night is
usually OK for most applications. The frequency of the log backups depend
on how much data you are willing to loose. If you can afford to loose up to
15 minutes worth of transactions then use a 15 minute interval etc. Just
ensure the backups are not done to the same drive the logs or data reside
on.
Andrew J. Kelly SQL MVP
"ben brugman" <ben@.niethier.nl> wrote in message
news:u1zBcW7GEHA.688@.tk2msftngp13.phx.gbl...
> Minimal configuration.
> (Performance is not an issue).
> Dataloss should not happen. (But we do not account
> for real dissasters, for example a big fire destroying
> the complete production center, resulting
> in the dataloss of 24 hours would be acceptable.)
> The shop runs 7 x 24 hours.
> Most is done during office hours.
> Some is done during all day.
> At night the system must be available but it is
> used very limited.
> Once a day a tape goes from the production machine to an
> offsite safe.
> The total amount of data has a disk footprint off
> between 1 and 10 Gigabytes.
> Offcourse there is a production machine and
> a standby machine probably in another location.
> (The second machine will be used for testing and
> practicing procedures.)
> Raid is required, raid protects agains single disks failures,
> but what are the options for more protection ?
> What configuration is considered minimal in these circumstances ?
> Esspecially what to do with the disks ?
> (OS / Logging / Data / Backupdata / Transactionlog backup) ?
> What can be combined and what can not be combined ?
> And how often to do the transactionlog backup ?
> (Side question what "route" should the transactionlog(-backup)
> take).
>
> Keep in mind : We are looking for a minimal configuration.
> Later on we will also looking for a 'larger' configuration with
> more performance, a larger database etc. (But still no super
> configuration. Something like 100-200 Gigabyte and more load).
> Thanks for your thoughts,
> ben brugman.
>|||Going with your suggestions,
suppose you have split the total RAID device in 3 groups
of disks (fysical separate), how would you place
1 OS
2 Logging
3 Data
4 Backupdata
5 Transactionlog backup
Have I missed anything ?
Or are 2 groups enough ?
Or do I need more groups ?

> on how much data you are willing to loose. If you can afford to loose up
to
> 15 minutes worth of transactions then use a 15 minute interval etc. Just
If I go from estimates of MTBF of disks the chance of
losing a mirrored disk is extremely small. So the chance
of loosing up to 15 minutes of data is extremely small.
Loosing the complete system because of a major
dissaster (fire for example) looks more likely and then
you loose everything since the last time you brought
the backup to outside of the 'box' or the computerroom.
Because for a minimal system bringing the data out of the
room more than once or twice a day would probably be a
problem.
(Calculation for 2 disks failing, assuming a MTBF of 300000 hours,
that a failed disk is spotted with in 24 hours. I get a failure of
two disks every once in 1/(24/300000)^2 days = 156250000 days)
Two of my problems :
1. Backup of the transaction log is not a 'backup' but a 'move' of the
'content',
so how do I protect the backup of the transaction log, because at that
moment
it is the only 'copy' of that data in existence. (Still mirrored I would
suggest).
2. If part of the chain of transactionlogs (active of backupped) is lost the
datafiles are worthless, so I do not understand that the datafiles
should be on a separate disk.
(Performance not being a consideration).
Thanks for your thoughts.
ben brugman
"Andrew J. Kelly" <sqlmvpnoooospam@.shadhawk.com> wrote in message
news:uRptBADHEHA.2260@.TK2MSFTNGP09.phx.gbl...
> Keep in mind that a server with a 200GB db and moderate load may not be
the
> same for a 10GB db with light load and this is addressing the latter as
you
> asked. A RAID 0+1 will give the most fault tolerate Raid with good
> performance as well. If the load is light enough (not a lot of
> transactions) then you can probably get away with a good size (meaning #
of
> disks not size of disks) RAID 0+1 or even 1+0 that has everything on it.
> But it is usually best to place the logs on their own RAID 1 and separate
> from the data for performance reasons. With a minimal configuration a
good
> raid is essential along with proper backups. A full backup once a night
is
> usually OK for most applications. The frequency of the log backups depend
> on how much data you are willing to loose. If you can afford to loose up
to
> 15 minutes worth of transactions then use a 15 minute interval etc. Just
> ensure the backups are not done to the same drive the logs or data reside
> on.
> --
> Andrew J. Kelly SQL MVP
>
> "ben brugman" <ben@.niethier.nl> wrote in message
> news:u1zBcW7GEHA.688@.tk2msftngp13.phx.gbl...
>|||It depends on how you will use the database. If you have a lot of
operations that use tempdb heavily you may wish to place tempdb on it's own
raid as well. Logs should be on their own array unless it is mostly read
only. A typical config for a moderate system is usually something like
this:
RAID 1 OS / SQL Binaries
RAID 1 SQL Transaction Logs
RAID 10 DATA, TempDB
Andrew J. Kelly SQL MVP
"ben brugman" <ben@.niethier.nl> wrote in message
news:c50moh$gtq$1@.reader11.wxs.nl...
> Going with your suggestions,
> suppose you have split the total RAID device in 3 groups
> of disks (fysical separate), how would you place
> 1 OS
> 2 Logging
> 3 Data
> 4 Backupdata
> 5 Transactionlog backup
> Have I missed anything ?
> Or are 2 groups enough ?
> Or do I need more groups ?
>
up
> to
> If I go from estimates of MTBF of disks the chance of
> losing a mirrored disk is extremely small. So the chance
> of loosing up to 15 minutes of data is extremely small.
> Loosing the complete system because of a major
> dissaster (fire for example) looks more likely and then
> you loose everything since the last time you brought
> the backup to outside of the 'box' or the computerroom.
> Because for a minimal system bringing the data out of the
> room more than once or twice a day would probably be a
> problem.
> (Calculation for 2 disks failing, assuming a MTBF of 300000 hours,
> that a failed disk is spotted with in 24 hours. I get a failure of
> two disks every once in 1/(24/300000)^2 days = 156250000 days)
> Two of my problems :
> 1. Backup of the transaction log is not a 'backup' but a 'move' of the
> 'content',
> so how do I protect the backup of the transaction log, because at that
> moment
> it is the only 'copy' of that data in existence. (Still mirrored I would
> suggest).
> 2. If part of the chain of transactionlogs (active of backupped) is lost
the
> datafiles are worthless, so I do not understand that the datafiles
> should be on a separate disk.
> (Performance not being a consideration).
> Thanks for your thoughts.
> ben brugman
>
>
>
> "Andrew J. Kelly" <sqlmvpnoooospam@.shadhawk.com> wrote in message
> news:uRptBADHEHA.2260@.TK2MSFTNGP09.phx.gbl...
> the
> you
> of
separate
> good
> is
depend
up
> to
reside
>|||>
> RAID 1 OS / SQL Binaries
> RAID 1 SQL Transaction Logs
> RAID 10 DATA, TempDB
>
What about :
I still have difficulty in understanding why different groups
offer more 'protection' than less different groups.
In your schema at least 8 disks are needed to realise
the solution. (1 each for the RAID 1 solution and at least
four for the RAID 10 solution. This is often the maximum
number of disks a 'simple' RAID box supports).
IF (this is supposed by me, so you can point out the
error or mistake in my reasoning.)
IF I put everything OS/Log/Data on a single group of
RAID disks the worst that can happen is that two mirrored
disks fail, resulting in the dataloss since the last backup and
move to outside the system.
But with the proposed system of having OS/Log/Data each on
their own group, the risk of losing the Log is the same because
losing the mirrored disk (with only the logs) gives us the
same amount of dataloss as with everything on the same group.
I very strongly feel that I AM MISSING SOME UNDERSTANDING
of this situation.
(Offcourse if the volumes of data and log become larger and
performance is an issue, I would go with more groups and understand
the reasons for this.).
My question is : Why is it wrong to put OS/Log/Data on a single
group of disks ?
(What is the risc of this ? Or why are there more riscs for this
than 3 groups of disks ?)
Everybody (books, discussions, usegroups) that this should
not be done, but except for performance the reason(s) is (are) not
explained.
Thanks again for your time,
and sorry to go on on this subject, but I really would like to
understand it.
ben brugman
> --
> Andrew J. Kelly SQL MVP
>
> "ben brugman" <ben@.niethier.nl> wrote in message
> news:c50moh$gtq$1@.reader11.wxs.nl...
> up
Just
> the
be
as
#
it.
> separate
night
> depend
> up
Just
> reside
>|||The main reason to separate them is for performance and scalability. While
there is some added protection for data loss with separate arrays over just
one it is secondary to performance and maintenance. If all your worried
about is a minimal configuration then use a single RAID 10 and be done with
it. This will suite many smaller applications just fine. If performance
becomes an issue and it is attributed to disk I/O you can look into adding
another RAID 1 for the logs etc.
Andrew J. Kelly SQL MVP
"ben brugman" <ben@.niethier.nl> wrote in message
news:eFLE5oUHEHA.2836@.TK2MSFTNGP11.phx.gbl...
> What about :
> I still have difficulty in understanding why different groups
> offer more 'protection' than less different groups.
> In your schema at least 8 disks are needed to realise
> the solution. (1 each for the RAID 1 solution and at least
> four for the RAID 10 solution. This is often the maximum
> number of disks a 'simple' RAID box supports).
> IF (this is supposed by me, so you can point out the
> error or mistake in my reasoning.)
> IF I put everything OS/Log/Data on a single group of
> RAID disks the worst that can happen is that two mirrored
> disks fail, resulting in the dataloss since the last backup and
> move to outside the system.
> But with the proposed system of having OS/Log/Data each on
> their own group, the risk of losing the Log is the same because
> losing the mirrored disk (with only the logs) gives us the
> same amount of dataloss as with everything on the same group.
> I very strongly feel that I AM MISSING SOME UNDERSTANDING
> of this situation.
> (Offcourse if the volumes of data and log become larger and
> performance is an issue, I would go with more groups and understand
> the reasons for this.).
> My question is : Why is it wrong to put OS/Log/Data on a single
> group of disks ?
> (What is the risc of this ? Or why are there more riscs for this
> than 3 groups of disks ?)
> Everybody (books, discussions, usegroups) that this should
> not be done, but except for performance the reason(s) is (are) not
> explained.
> Thanks again for your time,
> and sorry to go on on this subject, but I really would like to
> understand it.
> ben brugman
>
loose
> Just
would
lost
> be
> as
(meaning
> #
> it.
a
> night
loose
> Just
>|||"Andrew J. Kelly" <sqlmvpnoooospam@.shadhawk.com> wrote in message
news:ODHMefdHEHA.2948@.TK2MSFTNGP11.phx.gbl...
> The main reason to separate them is for performance and scalability.
While
> there is some added protection for data loss with separate arrays over
just
> one it is secondary to performance and maintenance. If all your worried
> about is a minimal configuration then use a single RAID 10 and be done
with
> it. This will suite many smaller applications just fine. If performance
> becomes an issue and it is attributed to disk I/O you can look into adding
> another RAID 1 for the logs etc.
>
Hello Andrew,
Thanks for your anwser,
We will probably go for a RAID 10 solution, were all
SQL-server data and log is stored on one diskgroup.
But we will probably have an offsite copy of this RAID 10
solution, which will be a hardware mirror of the first
RAID 10 box.
For the larger systems a SAN will be used, but this will
be to expensive for the smaller locations.
Thanks for your time.
ben brugman

> --
> Andrew J. Kelly SQL MVP
>
> "ben brugman" <ben@.niethier.nl> wrote in message
> news:eFLE5oUHEHA.2836@.TK2MSFTNGP11.phx.gbl...
> loose
etc.
the
that
> would
> lost
not
latter
good
> (meaning
on
configuration
> a
backups
> loose
etc.
?
>