Hi all!
I'm in the starting phase on planning a cluster enviorment. I'm really a newbie at clustering. I have one question that I will be very glad if you could help me with.
I thinking of configuring a 2 node, single instance cluster. The reason for the cluster if of course high availability. To achive the high availability demands we need to make sure that we can do maintenance on our servers without taking them down. The mo
st specific case is that we want to upgrade SQL Server servicepacks and hotfixes while users still can access the databases(useing the other node).
Is this how it works? Upgrade the passive node, switch passive node to active, upgrade the passive node? How does the cluster handle the fact that after the passive node has been upgraded with let's say SP3A and put in active mode, it will "connect" to
the database files that are on a different servicepack level?
Hope you understand what I'm thinking and that you have some info for me.
Thanks!!
/Fredrik
Unfortunately, it doesn't work that way. SQL requires single-user access
during the SP or Hotfix to update system objects within the database. It is
possible to do a 'binary-only' application of a SP or Hotfix, but that is
only when a node is repaired or replaced. SQL must already have the SP or
Hotfix applied to the current host node. For now, you will have to schedule
downtime to apply a SP or a hotfix. I suspect this may be addressed in the
next version since many people have complained about the downtime
requirement.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Fredrik" <anonymous@.discussions.microsoft.com> wrote in message
news:0C99300E-22B6-4B0B-9B00-2FC4241DE899@.microsoft.com...
> Hi all!
> I'm in the starting phase on planning a cluster enviorment. I'm really a
newbie at clustering. I have one question that I will be very glad if you
could help me with.
> I thinking of configuring a 2 node, single instance cluster. The reason
for the cluster if of course high availability. To achive the high
availability demands we need to make sure that we can do maintenance on our
servers without taking them down. The most specific case is that we want to
upgrade SQL Server servicepacks and hotfixes while users still can access
the databases(useing the other node).
> Is this how it works? Upgrade the passive node, switch passive node to
active, upgrade the passive node? How does the cluster handle the fact that
after the passive node has been upgraded with let's say SP3A and put in
active mode, it will "connect" to the database files that are on a different
servicepack level?
> Hope you understand what I'm thinking and that you have some info for me.
> Thanks!!
> /Fredrik
Showing posts with label nodes. Show all posts
Showing posts with label nodes. Show all posts
Wednesday, March 7, 2012
Saturday, February 25, 2012
Different regional settings discovered in SQL cluster nodes!
We have advertantly failed to verify correct regional settings on both (Win2
003) Cluster nodes prior to installing SQL Server 2000 Ent Ed. SQL Server is
installed in an Active Passive config with System Databases installed to a
shared disk (Drive G
Nod
e 1 has US English regional setings (date = mm/dd/yyyy) and US English input
Locale
Node 2 has Australian English regional (date=dd/mm/yyyy) and US English inpu
t locale
Our (mission critical production) database was detached from its old server
(AustralianEnglish regional and US English Locale) and moved to this clust
er 2 days ago. Testing and failovers work fine and the solution went live. W
e have only just discovered
the date discrapency. As the current date is (day & month) is still below 13
, nothing has blown up yet but we are 2 days away from the 13th!
The sysadmins are content to change the regional settings on node 1 to Engli
sh Australian and leave it like that. They failed-over the SQLService over t
o the second node and have scanned the systems databases and tables for date
s showing abnormal (future)
dates and found nothing. They believe there will not be a problem in simply
changing over Node 1's date settings to English Aust.
Sorry for the long note but I need to describe this as clearly as possible.
I am concerned that we have overlooked something. Can anyone tell me if it i
s safe to just change the system regional settings to English Australian? Wi
ll SQL server cope with the
date format change past 13Feb 13/2/2004 in AustEnglish format (dd/mm/yyyy)?
Should we rebuild the node with the correct regional settings and reinstall
SQL server on it? (In order to do this, SQL Server will need to be uninstall
ed from both nodes and the
master db deleted as the master db was created via node 1 US English to star
t with).
Thanks.
NRAs long as you have changed regional settings and you do not have code that
uses set dateformat otherwise this willbe ok. No datetime issues will be exp
erienced thereafter.|||Thanks for your reply, Olu. We did the change but found that SQLServer still
had problems on that node, and this was after we also fixed up the user pro
files to ensure the regional settings were correctly set.
We are attempting tonight to uninstall SQL reinstall, this time from the sec
ond node which was initially set with EngAust regional settings. We'll know
soon if that worked.
NR|||NR can U please keep me posted . . and what errors did you get on the node
after U changed regional settings'
003) Cluster nodes prior to installing SQL Server 2000 Ent Ed. SQL Server is
installed in an Active Passive config with System Databases installed to a
shared disk (Drive G

e 1 has US English regional setings (date = mm/dd/yyyy) and US English input
Locale
Node 2 has Australian English regional (date=dd/mm/yyyy) and US English inpu
t locale
Our (mission critical production) database was detached from its old server
(AustralianEnglish regional and US English Locale) and moved to this clust
er 2 days ago. Testing and failovers work fine and the solution went live. W
e have only just discovered
the date discrapency. As the current date is (day & month) is still below 13
, nothing has blown up yet but we are 2 days away from the 13th!
The sysadmins are content to change the regional settings on node 1 to Engli
sh Australian and leave it like that. They failed-over the SQLService over t
o the second node and have scanned the systems databases and tables for date
s showing abnormal (future)
dates and found nothing. They believe there will not be a problem in simply
changing over Node 1's date settings to English Aust.
Sorry for the long note but I need to describe this as clearly as possible.
I am concerned that we have overlooked something. Can anyone tell me if it i
s safe to just change the system regional settings to English Australian? Wi
ll SQL server cope with the
date format change past 13Feb 13/2/2004 in AustEnglish format (dd/mm/yyyy)?
Should we rebuild the node with the correct regional settings and reinstall
SQL server on it? (In order to do this, SQL Server will need to be uninstall
ed from both nodes and the
master db deleted as the master db was created via node 1 US English to star
t with).
Thanks.
NRAs long as you have changed regional settings and you do not have code that
uses set dateformat otherwise this willbe ok. No datetime issues will be exp
erienced thereafter.|||Thanks for your reply, Olu. We did the change but found that SQLServer still
had problems on that node, and this was after we also fixed up the user pro
files to ensure the regional settings were correctly set.
We are attempting tonight to uninstall SQL reinstall, this time from the sec
ond node which was initially set with EngAust regional settings. We'll know
soon if that worked.
NR|||NR can U please keep me posted . . and what errors did you get on the node
after U changed regional settings'
Different regional settings discovered in SQL cluster nodes!
We have advertantly failed to verify correct regional settings on both (Win2003) Cluster nodes prior to installing SQL Server 2000 Ent Ed. SQL Server is installed in an Active Passive config with System Databases installed to a shared disk (Drive G:) Node 1 has US English regional setings (date = mm/dd/yyyy) and US English input Local
Node 2 has Australian English regional (date=dd/mm/yyyy) and US English input local
Our (mission critical production) database was detached from its old server (AustralianEnglish regional and US English Locale) and moved to this cluster 2 days ago. Testing and failovers work fine and the solution went live. We have only just discovered the date discrapency. As the current date is (day & month) is still below 13, nothing has blown up yet but we are 2 days away from the 13th!
The sysadmins are content to change the regional settings on node 1 to English Australian and leave it like that. They failed-over the SQLService over to the second node and have scanned the systems databases and tables for dates showing abnormal (future) dates and found nothing. They believe there will not be a problem in simply changing over Node 1's date settings to English Aust
Sorry for the long note but I need to describe this as clearly as possible. I am concerned that we have overlooked something. Can anyone tell me if it is safe to just change the system regional settings to English Australian? Will SQL server cope with the date format change past 13Feb 13/2/2004 in AustEnglish format (dd/mm/yyyy)? Should we rebuild the node with the correct regional settings and reinstall SQL server on it? (In order to do this, SQL Server will need to be uninstalled from both nodes and the master db deleted as the master db was created via node 1 US English to start with)
Thanks
NAs long as you have changed regional settings and you do not have code that uses set dateformat otherwise this willbe ok. No datetime issues will be experienced thereafter.|||Thanks for your reply, Olu. We did the change but found that SQLServer still had problems on that node, and this was after we also fixed up the user profiles to ensure the regional settings were correctly set
We are attempting tonight to uninstall SQL reinstall, this time from the second node which was initially set with EngAust regional settings. We'll know soon if that worked
NR|||NR can U please keep me posted . . and what errors did you get on the node after U changed regional settings'
Node 2 has Australian English regional (date=dd/mm/yyyy) and US English input local
Our (mission critical production) database was detached from its old server (AustralianEnglish regional and US English Locale) and moved to this cluster 2 days ago. Testing and failovers work fine and the solution went live. We have only just discovered the date discrapency. As the current date is (day & month) is still below 13, nothing has blown up yet but we are 2 days away from the 13th!
The sysadmins are content to change the regional settings on node 1 to English Australian and leave it like that. They failed-over the SQLService over to the second node and have scanned the systems databases and tables for dates showing abnormal (future) dates and found nothing. They believe there will not be a problem in simply changing over Node 1's date settings to English Aust
Sorry for the long note but I need to describe this as clearly as possible. I am concerned that we have overlooked something. Can anyone tell me if it is safe to just change the system regional settings to English Australian? Will SQL server cope with the date format change past 13Feb 13/2/2004 in AustEnglish format (dd/mm/yyyy)? Should we rebuild the node with the correct regional settings and reinstall SQL server on it? (In order to do this, SQL Server will need to be uninstalled from both nodes and the master db deleted as the master db was created via node 1 US English to start with)
Thanks
NAs long as you have changed regional settings and you do not have code that uses set dateformat otherwise this willbe ok. No datetime issues will be experienced thereafter.|||Thanks for your reply, Olu. We did the change but found that SQLServer still had problems on that node, and this was after we also fixed up the user profiles to ensure the regional settings were correctly set
We are attempting tonight to uninstall SQL reinstall, this time from the second node which was initially set with EngAust regional settings. We'll know soon if that worked
NR|||NR can U please keep me posted . . and what errors did you get on the node after U changed regional settings'
Subscribe to:
Posts (Atom)