Hi,
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these databases
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breaking
points.
Thanks
HuiSeems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/info_generate_script.asp
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able to
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remove
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also know
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:
> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/info_generate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> > Hi,
> >
> > We had log shipping from LA to New York for our mission critical databases.
> > However, the log shipping breaks all the time because some of these databases
> > or tran logs are huge.
> >
> > Afer re-evaluation we found that some DBs we don't really need the data
> > replicated but we do need to keep the schema and objects up to date:
> > everything except the huge volume of data. It does not need to be real time,
> > we could do this once a day.
> > Could someone suggests us what are the better options of doing this? Some
> > way that is simple without a lot of maintenance issues and potential breaking
> > points.
> >
> > Thanks
> >
> > Hui
> >
> >
> >
> >
>
>sql
Showing posts with label critical. Show all posts
Showing posts with label critical. Show all posts
Tuesday, March 27, 2012
Best schema for replicate a DB without replicate Data
Hi,
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these databases
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breaking
points.
Thanks
Hui
Seems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/inf...ate_script.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>
|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>
|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able to
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remove
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also know
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:
> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/inf...ate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
>
>
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these databases
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breaking
points.
Thanks
Hui
Seems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/inf...ate_script.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>
|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:
> Hi,
> We had log shipping from LA to New York for our mission critical databases.
> However, the log shipping breaks all the time because some of these databases
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real time,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential breaking
> points.
> Thanks
> Hui
>
>
|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able to
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remove
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also know
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:
> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/inf...ate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
>
>
Best schema for replicate a DB without replicate Data
Hi,
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these database
s
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breakin
g
points.
Thanks
HuiSeems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/in...rate_script.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases
.
> However, the log shipping breaks all the time because some of these databa
ses
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real tim
e,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential break
ing
> points.
> Thanks
> Hui
>
>|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:
> Hi,
> We had log shipping from LA to New York for our mission critical databases
.
> However, the log shipping breaks all the time because some of these databa
ses
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real tim
e,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential break
ing
> points.
> Thanks
> Hui
>
>|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able t
o
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remov
e
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also kno
w
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:
> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/in...rate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
>
>
We had log shipping from LA to New York for our mission critical databases.
However, the log shipping breaks all the time because some of these database
s
or tran logs are huge.
Afer re-evaluation we found that some DBs we don't really need the data
replicated but we do need to keep the schema and objects up to date:
everything except the huge volume of data. It does not need to be real time,
we could do this once a day.
Could someone suggests us what are the better options of doing this? Some
way that is simple without a lot of maintenance issues and potential breakin
g
points.
Thanks
HuiSeems you simply want to generate schema at regular intervals?
http://www.karaszi.com/SQLServer/in...rate_script.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
> Hi,
> We had log shipping from LA to New York for our mission critical databases
.
> However, the log shipping breaks all the time because some of these databa
ses
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real tim
e,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential break
ing
> points.
> Thanks
> Hui
>
>|||check out DB Ghost - http://www.dbghost.com
"Christine C" wrote:
> Hi,
> We had log shipping from LA to New York for our mission critical databases
.
> However, the log shipping breaks all the time because some of these databa
ses
> or tran logs are huge.
> Afer re-evaluation we found that some DBs we don't really need the data
> replicated but we do need to keep the schema and objects up to date:
> everything except the huge volume of data. It does not need to be real tim
e,
> we could do this once a day.
> Could someone suggests us what are the better options of doing this? Some
> way that is simple without a lot of maintenance issues and potential break
ing
> points.
> Thanks
> Hui
>
>|||Sorry, I did not describe the full requirement:
1. We need to copy all changes in the databases (including sysusers, stored
procedures, views, udf, ...etc) except the data. Of course sysusers we do
need the data because we need all the users replicated.
2. One challenges we have is that there are objects (views, stored proc)
that are cross databases. Therefore whatever tools we used need to be able t
o
not error out because of the dependencies.
3. One of our developers are trying the SQL-DMO APIs to do the
copyalltables. Here are the uncertains for us:
a. He is not sure if SQL-DMO allows him to copy the users, views, and
stored procedures separately as well.
b. Tthe entire extract for replicating three databases (without data) took
50 minutes. Which means the entire time the destination databases are going
to be unusable for a long time.
Common question to all tools in your link:
c. what we need is for the tool to take care of the delta of the source and
destination. The objects that no longer exist in the source, how do we remov
e
them in the destination if the scripts are driving from the source?
d. The tools suggested in your link, are they mostly scripting tools for
DDLs only (we don't care the data) or some of them can transfer users as
well?
e. Do they require manually adding or changing the script defination
everytime a DB has changed (schema or stored proc)? Can those tools also kno
w
to remove all objects before it proceeds?
I know the list of questions are long, but these are critical processes we
want to setup in production. The problems that we encountered might not be
standards and having huge databases need to replicate to New York for DR
complicates the issue too.
Thank you for your patience in replying.
"Tibor Karaszi" wrote:
> Seems you simply want to generate schema at regular intervals?
> http://www.karaszi.com/SQLServer/in...rate_script.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
> http://www.sqlug.se/
>
> "Christine C" <ChristineC@.discussions.microsoft.com> wrote in message
> news:87C67A1A-52DF-4069-AD9B-A8637ADD3B35@.microsoft.com...
>
>
Sunday, March 11, 2012
Best practice for SQL cluster and domains
Hi All,
We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
domain. As hardware is getting old, and NT4 domain is going to disappear in
the near future, the cluster has to be re-newed. There is also a trusted
Active Directory domain, which holds about all user accounts and groups.
These accounts and groups have been assigned appropriate rights to SQL and
application generated reports.
What makes this a bit more difficult, is that the company is also going to
split, as is network and AD. The split will take place within few months,
but the new AD (where the users finally will be located) is expected to be
in place and fully functional within one year. However, the new cluster
should be up and running within two months. The cluster will be built on
Windows server 2003 Enterprise.
What I should do, is to provide best scenario for implementing new cluster,
so that it minimizes work when AD domains in question change.
As far as I am concerned, if you change a cluster domain membership, you
need to rebuild the whole cluster. This is not what we want to do. We are
prepared to re-assign all appropriate user right and roles as users' domain
changes.
I see following scenarios:
1. join new cluster to present AD domain
2. install new cluster nodes as domain controllers for new "domainlet" or
domain and create trust relationships as needed
3. install separate domain controllers, and join cluster to this domain,
create trust relationships as needed
4. something else?
In scenario 1 I see most work; rebuilding the whole cluster within a year or
so. About scenarios 2 and 3 I'd like to have comments, especially about
using domainlets
(http://www.microsoft.com/windows2000...cluster/domain
lets.asp). Or, there might be a lot better option, which I have not come to
think about.
Please share your opinions and comments,
John
Great questions.
I like option 1, have you read http://support.microsoft.com/?id=319016, no
need to rebuild the cluster and start all over. Pretty easy actually.
Have you read http://support.microsoft.com/?id=298570, so option 2 is not
looking good.
Option 3 will work, but I hate extra trusts, if I can avoid them.
Go with number 1, that is what I would do
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"John" <someone@.microsoft.com> wrote in message
news:41f50ef2@.usenet01.boi.hp.com...
> Hi All,
> We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
> domain. As hardware is getting old, and NT4 domain is going to disappear
> in
> the near future, the cluster has to be re-newed. There is also a trusted
> Active Directory domain, which holds about all user accounts and groups.
> These accounts and groups have been assigned appropriate rights to SQL and
> application generated reports.
> What makes this a bit more difficult, is that the company is also going to
> split, as is network and AD. The split will take place within few months,
> but the new AD (where the users finally will be located) is expected to be
> in place and fully functional within one year. However, the new cluster
> should be up and running within two months. The cluster will be built on
> Windows server 2003 Enterprise.
> What I should do, is to provide best scenario for implementing new
> cluster,
> so that it minimizes work when AD domains in question change.
> As far as I am concerned, if you change a cluster domain membership, you
> need to rebuild the whole cluster. This is not what we want to do. We are
> prepared to re-assign all appropriate user right and roles as users'
> domain
> changes.
> I see following scenarios:
> 1. join new cluster to present AD domain
> 2. install new cluster nodes as domain controllers for new "domainlet" or
> domain and create trust relationships as needed
> 3. install separate domain controllers, and join cluster to this domain,
> create trust relationships as needed
> 4. something else?
> In scenario 1 I see most work; rebuilding the whole cluster within a year
> or
> so. About scenarios 2 and 3 I'd like to have comments, especially about
> using domainlets
> (http://www.microsoft.com/windows2000...cluster/domain
> lets.asp). Or, there might be a lot better option, which I have not come
> to
> think about.
> Please share your opinions and comments,
> John
>
|||Rod,
thanks really, this was great information. I'll investigate the options
again in the light of your recent information, the scenario 1 looks now
actually quite good. If you have something to add, please do not hesitate to
share it
Cheers, John
"Rodney R. Fournier [MVP]" <rod@.die.spam.die.nw-america.com> wrote in
message news:%23z6TlkjAFHA.3592@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> Great questions.
> I like option 1, have you read http://support.microsoft.com/?id=319016, no
> need to rebuild the cluster and start all over. Pretty easy actually.
> Have you read http://support.microsoft.com/?id=298570, so option 2 is not
> looking good.
> Option 3 will work, but I hate extra trusts, if I can avoid them.
> Go with number 1, that is what I would do
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://msmvps.com/clustering - Blog
> "John" <someone@.microsoft.com> wrote in message
> news:41f50ef2@.usenet01.boi.hp.com...
and[vbcol=seagreen]
to[vbcol=seagreen]
months,[vbcol=seagreen]
be[vbcol=seagreen]
are[vbcol=seagreen]
or[vbcol=seagreen]
year[vbcol=seagreen]
(http://www.microsoft.com/windows2000...cluster/domain
>
We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
domain. As hardware is getting old, and NT4 domain is going to disappear in
the near future, the cluster has to be re-newed. There is also a trusted
Active Directory domain, which holds about all user accounts and groups.
These accounts and groups have been assigned appropriate rights to SQL and
application generated reports.
What makes this a bit more difficult, is that the company is also going to
split, as is network and AD. The split will take place within few months,
but the new AD (where the users finally will be located) is expected to be
in place and fully functional within one year. However, the new cluster
should be up and running within two months. The cluster will be built on
Windows server 2003 Enterprise.
What I should do, is to provide best scenario for implementing new cluster,
so that it minimizes work when AD domains in question change.
As far as I am concerned, if you change a cluster domain membership, you
need to rebuild the whole cluster. This is not what we want to do. We are
prepared to re-assign all appropriate user right and roles as users' domain
changes.
I see following scenarios:
1. join new cluster to present AD domain
2. install new cluster nodes as domain controllers for new "domainlet" or
domain and create trust relationships as needed
3. install separate domain controllers, and join cluster to this domain,
create trust relationships as needed
4. something else?
In scenario 1 I see most work; rebuilding the whole cluster within a year or
so. About scenarios 2 and 3 I'd like to have comments, especially about
using domainlets
(http://www.microsoft.com/windows2000...cluster/domain
lets.asp). Or, there might be a lot better option, which I have not come to
think about.
Please share your opinions and comments,
John
Great questions.
I like option 1, have you read http://support.microsoft.com/?id=319016, no
need to rebuild the cluster and start all over. Pretty easy actually.
Have you read http://support.microsoft.com/?id=298570, so option 2 is not
looking good.
Option 3 will work, but I hate extra trusts, if I can avoid them.
Go with number 1, that is what I would do
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://msmvps.com/clustering - Blog
"John" <someone@.microsoft.com> wrote in message
news:41f50ef2@.usenet01.boi.hp.com...
> Hi All,
> We have a critical 24x7 SQL cluster (W2K), which is a member of an NT 4
> domain. As hardware is getting old, and NT4 domain is going to disappear
> in
> the near future, the cluster has to be re-newed. There is also a trusted
> Active Directory domain, which holds about all user accounts and groups.
> These accounts and groups have been assigned appropriate rights to SQL and
> application generated reports.
> What makes this a bit more difficult, is that the company is also going to
> split, as is network and AD. The split will take place within few months,
> but the new AD (where the users finally will be located) is expected to be
> in place and fully functional within one year. However, the new cluster
> should be up and running within two months. The cluster will be built on
> Windows server 2003 Enterprise.
> What I should do, is to provide best scenario for implementing new
> cluster,
> so that it minimizes work when AD domains in question change.
> As far as I am concerned, if you change a cluster domain membership, you
> need to rebuild the whole cluster. This is not what we want to do. We are
> prepared to re-assign all appropriate user right and roles as users'
> domain
> changes.
> I see following scenarios:
> 1. join new cluster to present AD domain
> 2. install new cluster nodes as domain controllers for new "domainlet" or
> domain and create trust relationships as needed
> 3. install separate domain controllers, and join cluster to this domain,
> create trust relationships as needed
> 4. something else?
> In scenario 1 I see most work; rebuilding the whole cluster within a year
> or
> so. About scenarios 2 and 3 I'd like to have comments, especially about
> using domainlets
> (http://www.microsoft.com/windows2000...cluster/domain
> lets.asp). Or, there might be a lot better option, which I have not come
> to
> think about.
> Please share your opinions and comments,
> John
>
|||Rod,
thanks really, this was great information. I'll investigate the options
again in the light of your recent information, the scenario 1 looks now
actually quite good. If you have something to add, please do not hesitate to
share it
Cheers, John
"Rodney R. Fournier [MVP]" <rod@.die.spam.die.nw-america.com> wrote in
message news:%23z6TlkjAFHA.3592@.TK2MSFTNGP11.phx.gbl...[vbcol=seagreen]
> Great questions.
> I like option 1, have you read http://support.microsoft.com/?id=319016, no
> need to rebuild the cluster and start all over. Pretty easy actually.
> Have you read http://support.microsoft.com/?id=298570, so option 2 is not
> looking good.
> Option 3 will work, but I hate extra trusts, if I can avoid them.
> Go with number 1, that is what I would do
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://msmvps.com/clustering - Blog
> "John" <someone@.microsoft.com> wrote in message
> news:41f50ef2@.usenet01.boi.hp.com...
and[vbcol=seagreen]
to[vbcol=seagreen]
months,[vbcol=seagreen]
be[vbcol=seagreen]
are[vbcol=seagreen]
or[vbcol=seagreen]
year[vbcol=seagreen]
(http://www.microsoft.com/windows2000...cluster/domain
>
Subscribe to:
Posts (Atom)