Hi,
In your opinion, how much time would be a reasonable amount of time for a
DBA to spend on the creation of a DR plan for a set of two MS SQL Server 2000
databases (OSes, and so on...) - one production and one standby, without
using replication, log shipping, or cluster, but only SAN storage block level
synchronization?
-- Hoping this makes any sense Oskar.You omitted almost all DR elements from the list :)
It depends on your environment. You just did not add your list Database
Mirroring however this is not applicable in SQL Server 2000 already.
So, what kind of a DR is this? A Cold-Standby? Like Backup\Restore or
Attach\Detach?
--
Ekrem Ã?nsoy
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:D6ECA2B1-D6DE-4FD4-A983-2971115693F1@.microsoft.com...
> Hi,
> In your opinion, how much time would be a reasonable amount of time for a
> DBA to spend on the creation of a DR plan for a set of two MS SQL Server
> 2000
> databases (OSes, and so on...) - one production and one standby, without
> using replication, log shipping, or cluster, but only SAN storage block
> level
> synchronization?
> -- Hoping this makes any sense Oskar.
>|||If you are doing this from scratch, the up-front time into the project can be
substantial to ensure the whole thing works with rigorous tests and to
document the procedures.
Once this is established, ongoing maintenance should be minimal.
Linchi
"Oskar" wrote:
> Hi,
> In your opinion, how much time would be a reasonable amount of time for a
> DBA to spend on the creation of a DR plan for a set of two MS SQL Server 2000
> databases (OSes, and so on...) - one production and one standby, without
> using replication, log shipping, or cluster, but only SAN storage block level
> synchronization?
> -- Hoping this makes any sense Oskar.
>|||If something goes wrong i.e. either one "processing unit", one "storage
unit", or both of them go bust I switch to the remaining "processing unit"
and "storage unit". If that doesn't work (e.g. because of some kind of
"logical", "non-storage-level" fault that couldn't be detected) I recover
from the last full DB backup + the chain of transaction log backups up to the
point of corruption for affected areas.
"Ekrem Ã?nsoy" wrote:
> You omitted almost all DR elements from the list :)
> It depends on your environment. You just did not add your list Database
> Mirroring however this is not applicable in SQL Server 2000 already.
> So, what kind of a DR is this? A Cold-Standby? Like Backup\Restore or
> Attach\Detach?
> --
> Ekrem Ã?nsoy
>
> "Oskar" <Oskar@.discussions.microsoft.com> wrote in message
> news:D6ECA2B1-D6DE-4FD4-A983-2971115693F1@.microsoft.com...
> > Hi,
> > In your opinion, how much time would be a reasonable amount of time for a
> > DBA to spend on the creation of a DR plan for a set of two MS SQL Server
> > 2000
> > databases (OSes, and so on...) - one production and one standby, without
> > using replication, log shipping, or cluster, but only SAN storage block
> > level
> > synchronization?
> >
> > -- Hoping this makes any sense Oskar.
> >
>|||I'm not counting the time for testing, just the "paperwork". When you write
"substantial", do you mean weeks or months?
"Linchi Shea" wrote:
> If you are doing this from scratch, the up-front time into the project can be
> substantial to ensure the whole thing works with rigorous tests and to
> document the procedures.
> Once this is established, ongoing maintenance should be minimal.
> Linchi
> "Oskar" wrote:
> > Hi,
> > In your opinion, how much time would be a reasonable amount of time for a
> > DBA to spend on the creation of a DR plan for a set of two MS SQL Server 2000
> > databases (OSes, and so on...) - one production and one standby, without
> > using replication, log shipping, or cluster, but only SAN storage block level
> > synchronization?
> >
> > -- Hoping this makes any sense Oskar.
> >|||It's hard to separate 'the paper work' from tests since you need to have
performed the tests to have the info for your paper work. If you are just
talking about creating a plan for doing the DR tests, we are talking about
hours or at most days.
Linchi
"Oskar" wrote:
> I'm not counting the time for testing, just the "paperwork". When you write
> "substantial", do you mean weeks or months?
> "Linchi Shea" wrote:
> > If you are doing this from scratch, the up-front time into the project can be
> > substantial to ensure the whole thing works with rigorous tests and to
> > document the procedures.
> >
> > Once this is established, ongoing maintenance should be minimal.
> >
> > Linchi
> >
> > "Oskar" wrote:
> >
> > > Hi,
> > > In your opinion, how much time would be a reasonable amount of time for a
> > > DBA to spend on the creation of a DR plan for a set of two MS SQL Server 2000
> > > databases (OSes, and so on...) - one production and one standby, without
> > > using replication, log shipping, or cluster, but only SAN storage block level
> > > synchronization?
> > >
> > > -- Hoping this makes any sense Oskar.
> > >|||One week should be sufficient.
"Oskar" <Oskar@.discussions.microsoft.com> wrote in message
news:48706660-18A6-4DB2-98F3-5F36D7A9A7BC@.microsoft.com...
> I'm not counting the time for testing, just the "paperwork". When you
> write
> "substantial", do you mean weeks or months?
> "Linchi Shea" wrote:
>> If you are doing this from scratch, the up-front time into the project
>> can be
>> substantial to ensure the whole thing works with rigorous tests and to
>> document the procedures.
>> Once this is established, ongoing maintenance should be minimal.
>> Linchi
>> "Oskar" wrote:
>> > Hi,
>> > In your opinion, how much time would be a reasonable amount of time for
>> > a
>> > DBA to spend on the creation of a DR plan for a set of two MS SQL
>> > Server 2000
>> > databases (OSes, and so on...) - one production and one standby,
>> > without
>> > using replication, log shipping, or cluster, but only SAN storage block
>> > level
>> > synchronization?
>> >
>> > -- Hoping this makes any sense Oskar.
>> >
No comments:
Post a Comment