"Jim" <ilmm555@yahoo.com> wrote in message
news:eMz1vgVhHHA.1388@TK2MSFTNGP05.phx.gbl...
> OK, while RAC's original intent is to be a scale out feature, it's also
> very much an HA feature...as if a node dies, other nodes press
> on...there's no notion of "failover", thus eliminating the need to
> failover.
>
> I disagree with it being "a factor of how much money you wish to
> spend"...as regardless of how much you spend, the best you'll get SQL to
> is seconds of downtime (with mirroring, likely 10s of seconds-minutes with
> clustering)...thus, if you were to patch once a month (between SQL and
> Windows this is certainly not out of the realm of possibility), that's
> twelve failovers per year, at (at best...10 seconds of downtime each
> failover)...so you're at 120 seconds a year...99.999% availability is
> 52.256 seconds...so you're already down to under 5 9's availability for
> the year. In this shop, there's no notion of "unplanned downtime"...we're
> 24x7...it's ALL downtime.
>
> As for mirroring with SAN replicaiton for DR...below I mention no data
> loss, so you'd be talking about synchronous mirroing WITH synchronous SAN
> replication...while I said perf isn't the highest priority...I wonder how
> slow it would be with effectively 3 writes for each write (one to the
> primary SQL, one to the secondary SQL, one to the DR site...and since this
> is all synchronous...all writes have to be completed before the
> transaction's commited)...plus, now you're using SQL failover
> functionality and SAN failover functionality...I certainly wonder how
> (operationally) feasible this all will be...I'm sure it will be feasible,
> but certainly not seamless...
>
>
> "Andrew J. Kelly" <sqlmvpnooospam@shadhawk.com> wrote in message
> news:uPErZcShHHA.4064@TK2MSFTNGP02.phx.gbl...
>> RAC is by no means a High Availability feature so I am confused as to the
>> subject. There is no SQL Server RAC equivalent in the current release for
>> a read write database. However there are several HA / DR features that
>> SQL Server has that people use every day to satisfy their HA / DR needs.
>> How fast the recovery and how little down time is usually more a factor
>> of how much money you wish to spend. For instance you can do mirroring to
>> get fast up time and use the SAN's features to do DR. This is just a
>> simple example and it will really depend on what you want, what you have
>> to work with and how much time and money youa re willing to put into it.
>> You might want to start here:
>>
>> http://www.microsoft.com/sql/technologies/highavailability/default.mspx
>>
>>
>>
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "Jim" <ilmm555@yahoo.com> wrote in message
>> news:uimO$QJhHHA.4980@TK2MSFTNGP02.phx.gbl...
>>> Using Windows clustering requires too long a failover time for my
>>> company's uptime requirements. While SQL 2005's mirroring decreases the
>>> failover time, it also only allows me to mirror to one server, thus
>>> putting me in a rough spot for DR.
>>>
>>> Is there any Oracle RAC type equivalent functionality (i.e. shared
>>> cache) planned for future versions of SQL 2005, or available via some
>>> 3rd party today for use with SQL 2005 today? The net is, I need as
>>> little downtime as possible, both within a site, and across to my DR
>>> site (and as little to no data loss as possible to that DR site)...all
>>> the while (of course) minimizing the perf hit all of this
>>> requires...though while perf needs to still fall in acceptable ranges,
>>> better perf is not as important as faster failover and no data loss.
>>>
>>> Any help is appeciated.
>>>
>>> Thanks
>>
>>
>

"Jim" <ilmm555@yahoo.com> wrote in message
news:uimO$QJhHHA.4980@TK2MSFTNGP02.phx.gbl...
> Using Windows clustering requires too long a failover time for my
> company's uptime requirements. While SQL 2005's mirroring decreases the
> failover time, it also only allows me to mirror to one server, thus
> putting me in a rough spot for DR.
>
> Is there any Oracle RAC type equivalent functionality (i.e. shared cache)
> planned for future versions of SQL 2005, or available via some 3rd party
> today for use with SQL 2005 today? The net is, I need as little downtime
> as possible, both within a site, and across to my DR site (and as little
> to no data loss as possible to that DR site)...all the while (of course)
> minimizing the perf hit all of this requires...though while perf needs to
> still fall in acceptable ranges, better perf is not as important as faster
> failover and no data loss.
>
> Any help is appeciated.
>
> Thanks