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.
>> >
Showing posts with label creation. Show all posts
Showing posts with label creation. Show all posts
Wednesday, March 28, 2012
Monday, March 12, 2012
how long does it take to create a database in 2005 ?
I thought database creation was pretty fast in SQL 2005 and there was no
zero initialization
I ran a create database to create one with an initial size of 25GB for data
file and 25 GB of log file and it ran for 11 mins.
I have the dev edition. Could that be the reason ?The service account need certain Windows privileges to do fast init. Also fa
st init is only for data
files (not log files). I've mentioned a few words about it at:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"SQL Server 2005:
SQL Server 2005 has "instant file initialization" which means that database
files can be created and
also grow very fast since Windows doesn't "zero out" the data in the databas
e file. Instant file
initialization is only available for data files, not log files. Also, instan
ce file initialization
requires that the service account for the SQL Server service has the SE_MANA
GE_VOLUME_NAME windows
privilige, which can be assigned using the Perform Volume Maintenance Tasks
security policy. This is
by default only granted to Administrators."
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Hassan" <hassan@.hotmail.com> wrote in message news:eiiizunkHHA.4872@.TK2MSFTNGP03.phx.gbl...
>I thought database creation was pretty fast in SQL 2005 and there was no ze
ro initialization
> I ran a create database to create one with an initial size of 25GB for dat
a file and 25 GB of log
> file and it ran for 11 mins.
> I have the dev edition. Could that be the reason ?
>
>
zero initialization
I ran a create database to create one with an initial size of 25GB for data
file and 25 GB of log file and it ran for 11 mins.
I have the dev edition. Could that be the reason ?The service account need certain Windows privileges to do fast init. Also fa
st init is only for data
files (not log files). I've mentioned a few words about it at:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"SQL Server 2005:
SQL Server 2005 has "instant file initialization" which means that database
files can be created and
also grow very fast since Windows doesn't "zero out" the data in the databas
e file. Instant file
initialization is only available for data files, not log files. Also, instan
ce file initialization
requires that the service account for the SQL Server service has the SE_MANA
GE_VOLUME_NAME windows
privilige, which can be assigned using the Perform Volume Maintenance Tasks
security policy. This is
by default only granted to Administrators."
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Hassan" <hassan@.hotmail.com> wrote in message news:eiiizunkHHA.4872@.TK2MSFTNGP03.phx.gbl...
>I thought database creation was pretty fast in SQL 2005 and there was no ze
ro initialization
> I ran a create database to create one with an initial size of 25GB for dat
a file and 25 GB of log
> file and it ran for 11 mins.
> I have the dev edition. Could that be the reason ?
>
>
how long does it take to create a database in 2005 ?
I thought database creation was pretty fast in SQL 2005 and there was no
zero initialization
I ran a create database to create one with an initial size of 25GB for data
file and 25 GB of log file and it ran for 11 mins.
I have the dev edition. Could that be the reason ?
The service account need certain Windows privileges to do fast init. Also fast init is only for data
files (not log files). I've mentioned a few words about it at:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"SQL Server 2005:
SQL Server 2005 has "instant file initialization" which means that database files can be created and
also grow very fast since Windows doesn't "zero out" the data in the database file. Instant file
initialization is only available for data files, not log files. Also, instance file initialization
requires that the service account for the SQL Server service has the SE_MANAGE_VOLUME_NAME windows
privilige, which can be assigned using the Perform Volume Maintenance Tasks security policy. This is
by default only granted to Administrators."
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Hassan" <hassan@.hotmail.com> wrote in message news:eiiizunkHHA.4872@.TK2MSFTNGP03.phx.gbl...
>I thought database creation was pretty fast in SQL 2005 and there was no zero initialization
> I ran a create database to create one with an initial size of 25GB for data file and 25 GB of log
> file and it ran for 11 mins.
> I have the dev edition. Could that be the reason ?
>
>
zero initialization
I ran a create database to create one with an initial size of 25GB for data
file and 25 GB of log file and it ran for 11 mins.
I have the dev edition. Could that be the reason ?
The service account need certain Windows privileges to do fast init. Also fast init is only for data
files (not log files). I've mentioned a few words about it at:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"SQL Server 2005:
SQL Server 2005 has "instant file initialization" which means that database files can be created and
also grow very fast since Windows doesn't "zero out" the data in the database file. Instant file
initialization is only available for data files, not log files. Also, instance file initialization
requires that the service account for the SQL Server service has the SE_MANAGE_VOLUME_NAME windows
privilige, which can be assigned using the Perform Volume Maintenance Tasks security policy. This is
by default only granted to Administrators."
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Hassan" <hassan@.hotmail.com> wrote in message news:eiiizunkHHA.4872@.TK2MSFTNGP03.phx.gbl...
>I thought database creation was pretty fast in SQL 2005 and there was no zero initialization
> I ran a create database to create one with an initial size of 25GB for data file and 25 GB of log
> file and it ran for 11 mins.
> I have the dev edition. Could that be the reason ?
>
>
how long does it take to create a database in 2005 ?
I thought database creation was pretty fast in SQL 2005 and there was no
zero initialization
I ran a create database to create one with an initial size of 25GB for data
file and 25 GB of log file and it ran for 11 mins.
I have the dev edition. Could that be the reason ?The service account need certain Windows privileges to do fast init. Also fast init is only for data
files (not log files). I've mentioned a few words about it at:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"SQL Server 2005:
SQL Server 2005 has "instant file initialization" which means that database files can be created and
also grow very fast since Windows doesn't "zero out" the data in the database file. Instant file
initialization is only available for data files, not log files. Also, instance file initialization
requires that the service account for the SQL Server service has the SE_MANAGE_VOLUME_NAME windows
privilige, which can be assigned using the Perform Volume Maintenance Tasks security policy. This is
by default only granted to Administrators."
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Hassan" <hassan@.hotmail.com> wrote in message news:eiiizunkHHA.4872@.TK2MSFTNGP03.phx.gbl...
>I thought database creation was pretty fast in SQL 2005 and there was no zero initialization
> I ran a create database to create one with an initial size of 25GB for data file and 25 GB of log
> file and it ran for 11 mins.
> I have the dev edition. Could that be the reason ?
>
>
zero initialization
I ran a create database to create one with an initial size of 25GB for data
file and 25 GB of log file and it ran for 11 mins.
I have the dev edition. Could that be the reason ?The service account need certain Windows privileges to do fast init. Also fast init is only for data
files (not log files). I've mentioned a few words about it at:
http://www.karaszi.com/SQLServer/info_dont_shrink.asp
"SQL Server 2005:
SQL Server 2005 has "instant file initialization" which means that database files can be created and
also grow very fast since Windows doesn't "zero out" the data in the database file. Instant file
initialization is only available for data files, not log files. Also, instance file initialization
requires that the service account for the SQL Server service has the SE_MANAGE_VOLUME_NAME windows
privilige, which can be assigned using the Perform Volume Maintenance Tasks security policy. This is
by default only granted to Administrators."
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Hassan" <hassan@.hotmail.com> wrote in message news:eiiizunkHHA.4872@.TK2MSFTNGP03.phx.gbl...
>I thought database creation was pretty fast in SQL 2005 and there was no zero initialization
> I ran a create database to create one with an initial size of 25GB for data file and 25 GB of log
> file and it ran for 11 mins.
> I have the dev edition. Could that be the reason ?
>
>
Subscribe to:
Posts (Atom)