Showing posts with label plan. Show all posts
Showing posts with label plan. Show all posts

Friday, March 30, 2012

renaming drive letter

I want to add a new drive to replace an existing drive used by SQL
server(cluster installation).
My plan is to
1. stop sql related services.
2. copy sql db files to new drive...
3. Rename new drive with existing drive letter.
4. start sql.
My question is - will the change of drive letter work normally for cluster
installations or do i need to take any special care?If the drive letter is the same, the original files and directories are put
back, and the account running SQL Server has permissions to the files then
SQL won't detect any difference and be fine. However,
the cluster service may be a different story.
"Bharath" <Bharath@.discussions.microsoft.com> wrote in message
news:DD1F651A-F5D2-49B0-A220-3BD6343E815D@.microsoft.com...
>I want to add a new drive to replace an existing drive used by SQL
> server(cluster installation).
> My plan is to
> 1. stop sql related services.
> 2. copy sql db files to new drive...
> 3. Rename new drive with existing drive letter.
> 4. start sql.
> My question is - will the change of drive letter work normally for cluster
> installations or do i need to take any special care?|||Hi
Changing a drive letter in a cluster becomes a lot more complicated as the
cluster services depend on it.
You have to between steps 2 and 3, remove the dependency in cluster manager,
then re-name the letter, establish the dependencies in cluster manager and
then start SQL Server.
It is best to take SQL Server and Agent offline, and then reboot each node
to make sure the groups and resources fail over correctly. Then bring SQL
Server online again.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Bharath" <Bharath@.discussions.microsoft.com> wrote in message
news:DD1F651A-F5D2-49B0-A220-3BD6343E815D@.microsoft.com...
>I want to add a new drive to replace an existing drive used by SQL
> server(cluster installation).
> My plan is to
> 1. stop sql related services.
> 2. copy sql db files to new drive...
> 3. Rename new drive with existing drive letter.
> 4. start sql.
> My question is - will the change of drive letter work normally for cluster
> installations or do i need to take any special care?

renaming drive letter

I want to add a new drive to replace an existing drive used by SQL
server(cluster installation).
My plan is to
1. stop sql related services.
2. copy sql db files to new drive...
3. Rename new drive with existing drive letter.
4. start sql.
My question is - will the change of drive letter work normally for cluster
installations or do i need to take any special care?
If the drive letter is the same, the original files and directories are put
back, and the account running SQL Server has permissions to the files then
SQL won't detect any difference and be fine. However,
the cluster service may be a different story.
"Bharath" <Bharath@.discussions.microsoft.com> wrote in message
news:DD1F651A-F5D2-49B0-A220-3BD6343E815D@.microsoft.com...
>I want to add a new drive to replace an existing drive used by SQL
> server(cluster installation).
> My plan is to
> 1. stop sql related services.
> 2. copy sql db files to new drive...
> 3. Rename new drive with existing drive letter.
> 4. start sql.
> My question is - will the change of drive letter work normally for cluster
> installations or do i need to take any special care?
|||Hi
Changing a drive letter in a cluster becomes a lot more complicated as the
cluster services depend on it.
You have to between steps 2 and 3, remove the dependency in cluster manager,
then re-name the letter, establish the dependencies in cluster manager and
then start SQL Server.
It is best to take SQL Server and Agent offline, and then reboot each node
to make sure the groups and resources fail over correctly. Then bring SQL
Server online again.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Bharath" <Bharath@.discussions.microsoft.com> wrote in message
news:DD1F651A-F5D2-49B0-A220-3BD6343E815D@.microsoft.com...
>I want to add a new drive to replace an existing drive used by SQL
> server(cluster installation).
> My plan is to
> 1. stop sql related services.
> 2. copy sql db files to new drive...
> 3. Rename new drive with existing drive letter.
> 4. start sql.
> My question is - will the change of drive letter work normally for cluster
> installations or do i need to take any special care?
sql

renaming drive letter

I want to add a new drive to replace an existing drive used by SQL
server(cluster installation).
My plan is to
1. stop sql related services.
2. copy sql db files to new drive...
3. Rename new drive with existing drive letter.
4. start sql.
My question is - will the change of drive letter work normally for cluster
installations or do i need to take any special care?If the drive letter is the same, the original files and directories are put
back, and the account running SQL Server has permissions to the files then
SQL won't detect any difference and be fine. However,
the cluster service may be a different story.
"Bharath" <Bharath@.discussions.microsoft.com> wrote in message
news:DD1F651A-F5D2-49B0-A220-3BD6343E815D@.microsoft.com...
>I want to add a new drive to replace an existing drive used by SQL
> server(cluster installation).
> My plan is to
> 1. stop sql related services.
> 2. copy sql db files to new drive...
> 3. Rename new drive with existing drive letter.
> 4. start sql.
> My question is - will the change of drive letter work normally for cluster
> installations or do i need to take any special care?|||Hi
Changing a drive letter in a cluster becomes a lot more complicated as the
cluster services depend on it.
You have to between steps 2 and 3, remove the dependency in cluster manager,
then re-name the letter, establish the dependencies in cluster manager and
then start SQL Server.
It is best to take SQL Server and Agent offline, and then reboot each node
to make sure the groups and resources fail over correctly. Then bring SQL
Server online again.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Bharath" <Bharath@.discussions.microsoft.com> wrote in message
news:DD1F651A-F5D2-49B0-A220-3BD6343E815D@.microsoft.com...
>I want to add a new drive to replace an existing drive used by SQL
> server(cluster installation).
> My plan is to
> 1. stop sql related services.
> 2. copy sql db files to new drive...
> 3. Rename new drive with existing drive letter.
> 4. start sql.
> My question is - will the change of drive letter work normally for cluster
> installations or do i need to take any special care?

Wednesday, March 21, 2012

rename aspnetdb ?

Hello,

I have a shared hosting plan which already has aspnetdb.mdf on the server so of course I cannot use that db name for my site...

I have renamed the db and now I get an errorCould not find stored procedure 'dbo.aspnet_CheckSchemaVersion

My question is, how can I make this thing work? All help is greatly appreciated!

Hello my friend,

The aspnet.mdf database is intended for development and testing only, not for production due to performance reasons. When moving into production, you should change your site to use a real full heavyweight SQL Server database. Besides the aspnet tables existing in a different database, there is virtually no difference in terms of the application so you do not need to worry about changing your pages/code. I assume your different sites that you will be hosting will use different databases so this problem you are having will not occur when this has been sorted.

Kind regards

Scotty

|||

Scotty,

Ok, so let's say that what you say is true... how do you get all of the membership and users from aspnetdb into another db so that it can be used with my SQL Enterprise edition or any other for that matter

thanks!

|||

Hello again my friend,

I usually give the full answer to questions instead of referring to urls but I feel the following url demonstrates it better than I have time to explain: -

http://www.beansoftware.com/ASP.NET-Tutorials/Security-Features.aspx

You might find it useful to take advantage of the ApplicationName property if you wish the different sites that you are hosting to use the same database. Personally, I would always use a a separate database for each application.

Kind regards

Scotty

|||

Scotty,

So far so good... I haven't uploaded the new db yet but I have a feeling that this will work...

Question: where does the machine.config come into play on the hosting/production server?

Is that something that needs to be ftp'd over also?

KS

|||

Hello again my friend,

If you have installed .NET on the production server, the machine.config file should be there already. You should not need to change any settings in here. Besides, if you did, you override them using your web.config file in your website.

Machine.config is the top of the tree, its contents apply to all applications. When you create an application, you can overrule these settings by specifying settings in your web.config file. Further down, a web.config file in a subfolder of your application can overrule some settings in your web.config file in your application's root folder. This can go several subfolders deep. Finally, a web page in a folder can overrule some settings in the web.config file of that folder. One such setting is whether to use debugging or not.

Kind regards

Scotty

|||

Scotty,

Alright... sounds good... well, I have uploaded the site and db and now I am getting the error:

Could not find stored procedure 'dbo.aspnet_CheckSchemaVersion'

I am not sure what that means other than a connection was not made somewhere...

Maybe my connection string is wrong:

<connectionStrings>
<remove name="LocalSqlServer" />
<add name="ConnectionString" connectionString="Server=(local);Database=mff;User ID=xxxx;Password=xxxx;" />
<add name="LocalSqlServer" connectionString="Server=(local);Database=mff;User ID=xxxx;Password=xxxx;" />

</connectionStrings>

I am just not sure... let me know what you think

|||

Hello again,

Have you tried logging on to the SQL Server Management Studio/Enterprise Manager directly with the same credentials that you are using in the web.config? Do this to test the connection, it could be a SQL Server issue; wrong username or password. When you get it working directly, then try it with the website. If you are ever unsure about connection strings, a good resource on this iswww.connectionstrings.com.

Kind regards

Scotty

|||

I can't figure out how to give the database a user and password... maybe that is some of the problem...

When I log into SQL Server I do not need any password or user it is set to windows authentication

thanks for all your help bro'

|||

Scotty,

Alright... I got into the db using the credentials and it appears that I can get in fine, BUT when I do... there are no tables... what is going on there? Any ideas?

Kevin

|||

Hi - I have the exact same problem, i.e. have been learning and designing a site using membershio, so default database (ASPNETDB.MDF) created.

All working fine on loical PC but just signed up with hosting company and tried to create database but told that ASPNETDB.MDF already in use, so I have to rename my membership database.

After reading the correspondence on this topic, I still don't understand what I need to do.

Are you saying that with the SQL Express 2005 edition I can't get it to use a different name for the default database?

Are you saying that with a different SQL version (which one - the Developer edition for $49?) that I can?

With whatever version I need, is it a complicated job (remember - I'm a beginner).

I'd really appreciate feedback on this.

Regards,

Garrett

|||

Garrett,

Are you uploading your db directly onto a server as an mdf file OR are you scripting this db to a hosting account? If you are scripting this db to a host, which I assume you are, this will be as simple as changing the name of the db via the script before scripting to the host...

let me know

|||

I understand all that now.

I posted the same question in a different part of the forum and got the response I needced.

http://forums.asp.net/p/1200251/2087698.aspx#2087698

Thanks to everyone for the help.

Garrett

Friday, March 9, 2012

Removing old transaction log backup files

My organization is running SQL Server 2000 on a Windows 2000 server. We have
a maintenance plan set up to perform a daily backup of several database
files. The full database backup runs each day at 2:00 a.m. The transaction
log backup runs every four hours. It is setup in the maintenance plan that
the checkbox for both the data file and transaction log that says "Remove
files older than" is checked and set for 2 days. However, the old transaction
log backup files (*.TRN) are not being automatically removed. The regular
database files (*.BAK) are removed just fine. Any suggestions?
Hello
You should have some more information in the Maintenance Plan output file.
You can configure the Maint plan to produce output from the Maint Plan
properties window.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
|||Below KB might help:
http://support.microsoft.com/default...&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"AscentSQLAdmin" <AscentSQLAdmin@.discussions.microsoft.com> wrote in message
news:9A971D9F-D439-4F0F-B1E9-BAB6F42D73B3@.microsoft.com...
> My organization is running SQL Server 2000 on a Windows 2000 server. We have
> a maintenance plan set up to perform a daily backup of several database
> files. The full database backup runs each day at 2:00 a.m. The transaction
> log backup runs every four hours. It is setup in the maintenance plan that
> the checkbox for both the data file and transaction log that says "Remove
> files older than" is checked and set for 2 days. However, the old transaction
> log backup files (*.TRN) are not being automatically removed. The regular
> database files (*.BAK) are removed just fine. Any suggestions?

Removing old transaction log backup files

My organization is running SQL Server 2000 on a Windows 2000 server. We have
a maintenance plan set up to perform a daily backup of several database
files. The full database backup runs each day at 2:00 a.m. The transaction
log backup runs every four hours. It is setup in the maintenance plan that
the checkbox for both the data file and transaction log that says "Remove
files older than" is checked and set for 2 days. However, the old transactio
n
log backup files (*.TRN) are not being automatically removed. The regular
database files (*.BAK) are removed just fine. Any suggestions?Hello
You should have some more information in the Maintenance Plan output file.
You can configure the Maint plan to produce output from the Maint Plan
properties window.
Thank you for using Microsoft newsgroups.
Sincerely
Pankaj Agarwal
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Below KB might help:
http://support.microsoft.com/defaul...2&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"AscentSQLAdmin" <AscentSQLAdmin@.discussions.microsoft.com> wrote in message
news:9A971D9F-D439-4F0F-B1E9-BAB6F42D73B3@.microsoft.com...
> My organization is running SQL Server 2000 on a Windows 2000 server. We ha
ve
> a maintenance plan set up to perform a daily backup of several database
> files. The full database backup runs each day at 2:00 a.m. The transaction
> log backup runs every four hours. It is setup in the maintenance plan that
> the checkbox for both the data file and transaction log that says "Remove
> files older than" is checked and set for 2 days. However, the old transact
ion
> log backup files (*.TRN) are not being automatically removed. The regular
> database files (*.BAK) are removed just fine. Any suggestions?

Wednesday, March 7, 2012

removing index scan and table scan

How can I remove index scan to occure in my SPROC's execution plan.
I would like to replace them with index seek.
~Alok.
hi Alok,
"Alok" <itsalok2040@.hotmail.com> ha scritto nel messaggio
news:ekDgnzvhEHA.2624@.TK2MSFTNGP12.phx.gbl...
> How can I remove index scan to occure in my SPROC's execution plan.
> I would like to replace them with index seek.
the plan you get when the actual statement is executed depends on your
actual data and metaschema involved in the query...you can submit a hint in
the SELECT statement to force SQL Server to use a particular index, but you
can not force it to perform an actual index seek instead of an index scan...
you can try fine tuning your database uisng the Index Tuning Wizard in order
to see eventual feedback from your workload(s), which could hints for
additional index(es) to better fullfill your statements
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.8.0 - DbaMgr ver 0.54.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply

Saturday, February 25, 2012

Removing Domain Controller status from a SQL server

Aloha -
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.
Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.
|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:

> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan
|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>

Removing Domain Controller status from a SQL server

Aloha -
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
--
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>

Removing Domain Controller status from a SQL server

Aloha -
I have a sick server (HOKU) which doubles as a domain controller and a SQL
server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
member server, remove it from the domain then do away with it.
The plan is to demote it this weekend. Then in a couple weeks move the SQL
once testing is done. Is there danger in "de-domain controlering" a SQL
server that is used to being on a DC? At this point I know enough to know
that we're making a fairly major change, but I don't know enough to know
exactly what I am nervous about.Hi
From a SQL Server point of view, I don't see any problems in demoting a SQL
server. SQL server don't use anything from the Domain Controller as such, so
as long as you have your domain fully functional there shouldn't be any
problems.
Depending on how your users connect to the databases, there might be some
fiddling around when you move the SQL server, since you most likely will
change the server name and/or IP adress.
Regards
Steen
Kahonu wrote:
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and
> a SQL server. The plan is to move SQL to a new server (SQL1), demote
> HOKU to a member server, remove it from the domain then do away with
> it.
> The plan is to demote it this weekend. Then in a couple weeks move
> the SQL once testing is done. Is there danger in "de-domain
> controlering" a SQL server that is used to being on a DC? At this
> point I know enough to know that we're making a fairly major change,
> but I don't know enough to know exactly what I am nervous about.|||Kahonu wrote on Wed, 1 Jun 2005 19:03:18 -0700:

> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
I demoted a W2K Server to a member server with SQL Server 2000 just 2 weeks
ago, no ill effects as yet. I needed to rename the server prior to running
in production, and I'd be running it as a domain controller while migrating
from NT4 to 2K. The demotion was painless, it was the renaming that was the
fun part :\
Dan|||I have also demoted as you are doing, and like the others had no problems...
In fact, it is a bad practice to put SQL on a domain controller anyway - so
you are doing a good thing and improving security by your actions as well.
Wayne Snyder MCDBA, SQL Server MVP
Mariner, Charlotte, NC
(Please respond only to the newsgroup.)
I support the Professional Association for SQL Server ( PASS) and it's
community of SQL Professionals.
"Kahonu" <Kahonu@.discussions.microsoft.com> wrote in message
news:FE165EC2-B09B-4D40-9782-D8C54CB036C7@.microsoft.com...
> Aloha -
> I have a sick server (HOKU) which doubles as a domain controller and a SQL
> server. The plan is to move SQL to a new server (SQL1), demote HOKU to a
> member server, remove it from the domain then do away with it.
> The plan is to demote it this weekend. Then in a couple weeks move the SQL
> once testing is done. Is there danger in "de-domain controlering" a SQL
> server that is used to being on a DC? At this point I know enough to know
> that we're making a fairly major change, but I don't know enough to know
> exactly what I am nervous about.
>

Monday, February 20, 2012

Removing a SQL cluster node

Could someone point me to some documentation on the best way to remove a
node from a SQL cluster.
It's a two node, two instance cluster, and I plan to rebuild one node, fail
to the rebuilt one, then rebuild the remaining node.
-Karl
From the BOL:
"In this scenario, failure is caused by hardware failure in Node 1 of a
two-node cluster. This hardware failure could be caused, for example, by the
failure of a small computer system interface (SCSI) card or the operating
system.
1.. After Node 1 fails, the Microsoft SQL Server 2000 failover cluster
fails over to Node 2.
2.. Run SQL Server Setup and remove Node 1. For more information, see How
to remove a failover clustered instance .
3.. Evict Node 1 from Microsoft Cluster Service (MSCS). To evict a node
from MSCS, from Node 2, right-click on the node to remove, and then click
Evict Node.
4.. Install new hardware to replace the failed hardware in Node 1.
5.. Install the operating system. For more information about which
operating system to install and specific instructions on how to do this, see
Before Installing Failover Clustering.
6.. Install MSCS and join the existing cluster. For more information, see
Before Installing Failover Clustering.
7.. Run the Setup program on Node 2 and add Node 1 back to the failover
cluster. For more information, see How to add nodes to an existing virtual
server (Setup). "
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinpub.com
..
"Karl" <karl@.nospam.postalias> wrote in message
news:uzFVttDfFHA.3936@.TK2MSFTNGP14.phx.gbl...
Could someone point me to some documentation on the best way to remove a
node from a SQL cluster.
It's a two node, two instance cluster, and I plan to rebuild one node, fail
to the rebuilt one, then rebuild the remaining node.
-Karl
|||In addition, you will need to re-run any Service Packs and HotFixes on the
new node to update the binaries. Read the README file included with the
service pack for detailed instructions on how to apply the SP to a newly
added cluster node.
Geoff N. Hiten
Microsoft SQL Server MVP
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23udWQyDfFHA.1412@.TK2MSFTNGP09.phx.gbl...
> From the BOL:
> "In this scenario, failure is caused by hardware failure in Node 1 of a
> two-node cluster. This hardware failure could be caused, for example, by
> the
> failure of a small computer system interface (SCSI) card or the operating
> system.
> 1.. After Node 1 fails, the Microsoft SQL Server 2000 failover cluster
> fails over to Node 2.
>
> 2.. Run SQL Server Setup and remove Node 1. For more information, see How
> to remove a failover clustered instance .
>
> 3.. Evict Node 1 from Microsoft Cluster Service (MSCS). To evict a node
> from MSCS, from Node 2, right-click on the node to remove, and then click
> Evict Node.
>
> 4.. Install new hardware to replace the failed hardware in Node 1.
>
> 5.. Install the operating system. For more information about which
> operating system to install and specific instructions on how to do this,
> see
> Before Installing Failover Clustering.
>
> 6.. Install MSCS and join the existing cluster. For more information, see
> Before Installing Failover Clustering.
>
> 7.. Run the Setup program on Node 2 and add Node 1 back to the failover
> cluster. For more information, see How to add nodes to an existing virtual
> server (Setup). "
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> .
> "Karl" <karl@.nospam.postalias> wrote in message
> news:uzFVttDfFHA.3936@.TK2MSFTNGP14.phx.gbl...
> Could someone point me to some documentation on the best way to remove a
> node from a SQL cluster.
> It's a two node, two instance cluster, and I plan to rebuild one node,
> fail
> to the rebuilt one, then rebuild the remaining node.
> -Karl
>
|||I'm unclear about step #2. Following the BOL topic "How to remove a failover
clustered instance" appears to lead me down the path of removing the
instance entirely from the virtual server. The virtual server/instance is
working fine on node 2. I'm afraid to proceed because the prompts appear to
indicate that I'd be uninstalling the entire instance from the virtual
server.
Is it possible that if a node fails, there is no need to run SQL setup? Just
to go remaining node's MSCS and evict the unresponsive node (regardless if
its still online or not), reinstall and rejoin MSCS?
"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:%23udWQyDfFHA.1412@.TK2MSFTNGP09.phx.gbl...
> From the BOL:
> "In this scenario, failure is caused by hardware failure in Node 1 of a
> two-node cluster. This hardware failure could be caused, for example, by
> the
> failure of a small computer system interface (SCSI) card or the operating
> system.
> 1.. After Node 1 fails, the Microsoft SQL Server 2000 failover cluster
> fails over to Node 2.
>
> 2.. Run SQL Server Setup and remove Node 1. For more information, see How
> to remove a failover clustered instance .
>
> 3.. Evict Node 1 from Microsoft Cluster Service (MSCS). To evict a node
> from MSCS, from Node 2, right-click on the node to remove, and then click
> Evict Node.
>
> 4.. Install new hardware to replace the failed hardware in Node 1.
>
> 5.. Install the operating system. For more information about which
> operating system to install and specific instructions on how to do this,
> see
> Before Installing Failover Clustering.
>
> 6.. Install MSCS and join the existing cluster. For more information, see
> Before Installing Failover Clustering.
>
> 7.. Run the Setup program on Node 2 and add Node 1 back to the failover
> cluster. For more information, see How to add nodes to an existing virtual
> server (Setup). "
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Columnist, SQL Server Professional
> Toronto, ON Canada
> www.pinpub.com
> .
> "Karl" <karl@.nospam.postalias> wrote in message
> news:uzFVttDfFHA.3936@.TK2MSFTNGP14.phx.gbl...
> Could someone point me to some documentation on the best way to remove a
> node from a SQL cluster.
> It's a two node, two instance cluster, and I plan to rebuild one node,
> fail
> to the rebuilt one, then rebuild the remaining node.
> -Karl
>
|||Hi Karl,
In step#2 we should refer to the "How to remove a node from an existing
failover cluster" topic:
http://msdn.microsoft.com/library/en...ering_7hyq.asp
It appears that "see How to remove a failover clustered instance" in the
"How to recover from failover cluster failure in Scenario 1" topic is
incorrect, I've sent a feedback to the appropriate team. The remain part is
correct and we need to follow every step.
Please let me know if you have any other questions.
Sincerely,
William Wang
Microsoft Online Partner Support
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
This posting is provided "AS IS" with no warranties, and confers no rights.
|||It does appear ambigious in the docs. When you remove SQL, you will remove
it from the dead node only. That will clean up the SQL clustering
information on the remaining node(s). Once the new or newly
rebuild/repaired node is rejoined to the cluster, you still have to install
SQL on it. This means installing local binaries and configuring the cluster
to recognize it as a possible host for the SQL resource group. That is what
the SQL installation steps do. It is not enough to just add the node to the
cluster.
Again, don't forget to apply any service packs or hotfixes after adding the
node back.
BUG: Correcting Mismatched Binaries on SQL Clustered Virtual Server
http://support.microsoft.com/default...b;en-us;295589
I agree that the docs are incorrect in that they do not describe how to
remove a node from a SQL cluster without uninstalling the entire virtual
server . Since William already reported it, I will leave it alone.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Karl" <karl@.nospam.postalias> wrote in message
news:eXQQcFAiFHA.1244@.TK2MSFTNGP14.phx.gbl...
> I'm unclear about step #2. Following the BOL topic "How to remove a
> failover clustered instance" appears to lead me down the path of removing
> the instance entirely from the virtual server. The virtual server/instance
> is working fine on node 2. I'm afraid to proceed because the prompts
> appear to indicate that I'd be uninstalling the entire instance from the
> virtual server.
> Is it possible that if a node fails, there is no need to run SQL setup?
> Just to go remaining node's MSCS and evict the unresponsive node
> (regardless if its still online or not), reinstall and rejoin MSCS?
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:%23udWQyDfFHA.1412@.TK2MSFTNGP09.phx.gbl...
>
|||Thanks to Geoff and William for pointing me to the right procedures. I've
rebuilt the node from scratch and have added it back to the cluster. I have
a question related to patching and mismatched binaries - and avoiding
reboots.
I want to apply SQL2000-KB815495-8.00.0818-ENU.exe hotfix to the new node
but I don't want to reboot the good/production node which is currently
hosting the instance.
I attempt to run the hotfix on the passive node but it says it has to run on
the active node. Attempting the install on the active node reports that it
will take the resource offline.
Is it possible to copy binaries into the passive node so as not to incur any
SQL downtime? So far the entire rebuild of this passive node has had no
effect on the active production instance. I'd hate to ruin the record this
late in the game!
-Karl
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:OV61RWHiFHA.1464@.TK2MSFTNGP14.phx.gbl...
It does appear ambigious in the docs. When you remove SQL, you will remove
it from the dead node only. That will clean up the SQL clustering
information on the remaining node(s). Once the new or newly
rebuild/repaired node is rejoined to the cluster, you still have to install
SQL on it. This means installing local binaries and configuring the cluster
to recognize it as a possible host for the SQL resource group. That is what
the SQL installation steps do. It is not enough to just add the node to the
cluster.
Again, don't forget to apply any service packs or hotfixes after adding the
node back.
BUG: Correcting Mismatched Binaries on SQL Clustered Virtual Server
http://support.microsoft.com/default...b;en-us;295589
I agree that the docs are incorrect in that they do not describe how to
remove a node from a SQL cluster without uninstalling the entire virtual
server . Since William already reported it, I will leave it alone.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Karl" <karl@.nospam.postalias> wrote in message
news:eXQQcFAiFHA.1244@.TK2MSFTNGP14.phx.gbl...
> I'm unclear about step #2. Following the BOL topic "How to remove a
> failover clustered instance" appears to lead me down the path of removing
> the instance entirely from the virtual server. The virtual server/instance
> is working fine on node 2. I'm afraid to proceed because the prompts
> appear to indicate that I'd be uninstalling the entire instance from the
> virtual server.
> Is it possible that if a node fails, there is no need to run SQL setup?
> Just to go remaining node's MSCS and evict the unresponsive node
> (regardless if its still online or not), reinstall and rejoin MSCS?
> "Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
> news:%23udWQyDfFHA.1412@.TK2MSFTNGP09.phx.gbl...
>
|||The old installer sometimes let you do a "binary-only upgrade" to a node
that is not currently hosting the target SQL instance. That has caused
issues in the past and was removed at build 977 when the new hotfix
installer debuted. A hotfix typically takes about 5-10 minutes to run and
yes, the instance does have to go offline.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Karl" <karl@.nospam.postalias> wrote in message
news:udt6OmYrFHA.3788@.TK2MSFTNGP12.phx.gbl...
> Thanks to Geoff and William for pointing me to the right procedures. I've
> rebuilt the node from scratch and have added it back to the cluster. I
> have
> a question related to patching and mismatched binaries - and avoiding
> reboots.
> I want to apply SQL2000-KB815495-8.00.0818-ENU.exe hotfix to the new node
> but I don't want to reboot the good/production node which is currently
> hosting the instance.
> I attempt to run the hotfix on the passive node but it says it has to run
> on
> the active node. Attempting the install on the active node reports that it
> will take the resource offline.
> Is it possible to copy binaries into the passive node so as not to incur
> any
> SQL downtime? So far the entire rebuild of this passive node has had no
> effect on the active production instance. I'd hate to ruin the record this
> late in the game!
> -Karl
>
> "Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
> news:OV61RWHiFHA.1464@.TK2MSFTNGP14.phx.gbl...
> It does appear ambigious in the docs. When you remove SQL, you will
> remove
> it from the dead node only. That will clean up the SQL clustering
> information on the remaining node(s). Once the new or newly
> rebuild/repaired node is rejoined to the cluster, you still have to
> install
> SQL on it. This means installing local binaries and configuring the
> cluster
> to recognize it as a possible host for the SQL resource group. That is
> what
> the SQL installation steps do. It is not enough to just add the node to
> the
> cluster.
> Again, don't forget to apply any service packs or hotfixes after adding
> the
> node back.
> BUG: Correcting Mismatched Binaries on SQL Clustered Virtual Server
> http://support.microsoft.com/default...b;en-us;295589
> I agree that the docs are incorrect in that they do not describe how to
> remove a node from a SQL cluster without uninstalling the entire virtual
> server . Since William already reported it, I will leave it alone.
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Karl" <karl@.nospam.postalias> wrote in message
> news:eXQQcFAiFHA.1244@.TK2MSFTNGP14.phx.gbl...
>
>
|||To clarify, when adding a node to an existing virtual server, the SQL
Instance will come OffLine for about 5-10 minutes while the binaries are
written? Thanks for the input as we may be replacing a node as well.
John
Geoff N. Hiten wrote:[vbcol=seagreen]
>The old installer sometimes let you do a "binary-only upgrade" to a node
>that is not currently hosting the target SQL instance. That has caused
>issues in the past and was removed at build 977 when the new hotfix
>installer debuted. A hotfix typically takes about 5-10 minutes to run and
>yes, the instance does have to go offline.
>[quoted text clipped - 106 lines]
|||Yes. The hotfix will be applied to all nodes and any update scripts will
get re-run. The instance may stop and start several times in single-user
mode to apply updates. I have found that if you have a very large memory
system (16GB or more), it speeds things up considerably to lower the memory
settings before applying the hotfix and increase them after it has
completed.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"John via droptable.com" <forum@.droptable.com> wrote in message
news:53AB45D140ED3@.droptable.com...[vbcol=seagreen]
> To clarify, when adding a node to an existing virtual server, the SQL
> Instance will come OffLine for about 5-10 minutes while the binaries are
> written? Thanks for the input as we may be replacing a node as well.
> John
> Geoff N. Hiten wrote: