Dear fellows,
Sometimes when I obtain a script for tables and then I copy them to another
Sql Server, collation at field level is lost. Why?
Thank you very much,If no specifiy coallation is named on the column, it wont be scripted.
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
"Enric" <Enric@.discussions.microsoft.com> schrieb im Newsbeitrag
news:6322A9EB-4603-43C6-BC2C-09DBB81F45D3@.microsoft.com...
> Dear fellows,
> Sometimes when I obtain a script for tables and then I copy them to
> another
> Sql Server, collation at field level is lost. Why?
> Thank you very much,
Showing posts with label copy. Show all posts
Showing posts with label copy. Show all posts
Sunday, March 25, 2012
Thursday, March 22, 2012
collation conflict
Hi, all
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
Elizabeta
Elizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>
|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
[vbcol=seagreen]
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
ening.
>
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
Elizabeta
Elizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>
|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
[vbcol=seagreen]
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
ening.
>
collation conflict
Hi, all
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
> >Hi, all
> >
> >I am doing testing of my application, actualy one Store Procedure at the moment.
> >
> >I have development database.
> >
> >I copy tables that I need for the testing.
> >
> >The same queries that run on live database fail here wth the message
> >'cannot resolve collation conflict...'
> >
> >I discovered that it is due to all copied tables have other collation in char columns.
> >
> >When I change them to database default setting, the stored procedure works OK.
> >
> >My question is:
> >
> >how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
> >
> >I am very grateful for any helpful information.
> >
> >TIA
> >
> >Elizabeta
> >
> >
>
I am doing testing of my application, actualy one Store Procedure at the moment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in char columns.
When I change them to database default setting, the stored procedure works OK.
My question is:
how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the moment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in char columns.
>When I change them to database default setting, the stored procedure works OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "script
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
> >Hi, all
> >
> >I am doing testing of my application, actualy one Store Procedure at the moment.
> >
> >I have development database.
> >
> >I copy tables that I need for the testing.
> >
> >The same queries that run on live database fail here wth the message
> >'cannot resolve collation conflict...'
> >
> >I discovered that it is due to all copied tables have other collation in char columns.
> >
> >When I change them to database default setting, the stored procedure works OK.
> >
> >My question is:
> >
> >how can I avoid to have collation in new copied tables, although the databases have it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as objects, always the same problem. Is there any setting on SQL server to avoid this happening.
> >
> >I am very grateful for any helpful information.
> >
> >TIA
> >
> >Elizabeta
> >
> >
>
collation conflict
Hi, all
I am doing testing of my application, actualy one Store Procedure at the mo
ment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in cha
r columns.
When I change them to database default setting, the stored procedure works O
K.
My question is:
how can I avoid to have collation in new copied tables, although the databas
es have it the same. I tried to copy using CREATE TABLE scripts or DTS servi
ces, copy as objects, always the same problem. Is there any setting on SQL s
erver to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the m
oment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in ch
ar columns.
>When I change them to database default setting, the stored procedure works
OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have
it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as ob
jects, always the same problem. Is there any setting on SQL server to avoid this hap
pen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "scri
pt
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
>
ening.[vbcol=seagreen]
>sqlsql
I am doing testing of my application, actualy one Store Procedure at the mo
ment.
I have development database.
I copy tables that I need for the testing.
The same queries that run on live database fail here wth the message
'cannot resolve collation conflict...'
I discovered that it is due to all copied tables have other collation in cha
r columns.
When I change them to database default setting, the stored procedure works O
K.
My question is:
how can I avoid to have collation in new copied tables, although the databas
es have it the same. I tried to copy using CREATE TABLE scripts or DTS servi
ces, copy as objects, always the same problem. Is there any setting on SQL s
erver to avoid this happeni
ng.
I am very grateful for any helpful information.
TIA
ElizabetaElizabeta,
If you script the CREATE TABLE scripts in Query Analyzer, you can go
to Tools|Options|[Script tab at far right] and check the box for "script
only 7.0 compatible features." If the collate clause is the only SQL
Server 2000 feature you are using, it might work for you. Otherwise,
assuming all the collations are the same, you can just do a search and
replace after scripting all the tables all at once from somewhere.
Steve Kass
Drew University
Elizabeta wrote:
>Hi, all
>I am doing testing of my application, actualy one Store Procedure at the m
oment.
>I have development database.
>I copy tables that I need for the testing.
>The same queries that run on live database fail here wth the message
>'cannot resolve collation conflict...'
>I discovered that it is due to all copied tables have other collation in ch
ar columns.
>When I change them to database default setting, the stored procedure works
OK.
>My question is:
>how can I avoid to have collation in new copied tables, although the databases have
it the same. I tried to copy using CREATE TABLE scripts or DTS services, copy as ob
jects, always the same problem. Is there any setting on SQL server to avoid this hap
pen
ing.
>I am very grateful for any helpful information.
>TIA
>Elizabeta
>|||Thanks, Steve,
it works from SQL query analyzer. I tick the option
'do not csript collation clause...'
Cheers
"Steve Kass" wrote:
> Elizabeta,
> If you script the CREATE TABLE scripts in Query Analyzer, you can go
> to Tools|Options|[Script tab at far right] and check the box for "scri
pt
> only 7.0 compatible features." If the collate clause is the only SQL
> Server 2000 feature you are using, it might work for you. Otherwise,
> assuming all the collations are the same, you can just do a search and
> replace after scripting all the tables all at once from somewhere.
> Steve Kass
> Drew University
> Elizabeta wrote:
>
ening.[vbcol=seagreen]
>sqlsql
Thursday, March 8, 2012
Code Profiler is executing for requested trace
Afternoon,
Is there a way in SS2K5 Profiler to see what the code looks like for the trace being executed?
And then further, is there a way to copy the code and rework it in an SP?
Thanks ALL!
J Kusch
Did you try deleting the filter in the profiler which is inserted by default in the default template ? :-) Then you will see what is executed behind the scenes.Jens K. Suessmeyer
http://www.sqlserver2005.de
code page
Can we copy a 850 code page base to a standby one with 1252 code page ?Yes, but without using dump/restore
Sunday, February 19, 2012
Clustering concepts...
We have just setup two servers running a copy of SQL 2000 on Windows 2000
server. Each of these servers is running vendor software that interrracts
with the databases. One server is primary and one is backup. Clients only
interract with the vendor process on the servers and not the SQL directly.
Some general questions on SQL 2000 high availability options...
Does Active/Passive and Active/Active refer to clustering options that
require that the servers be clustered on the OS level? Is this the only
option that keeps the databases syncronized in real time?
Is replication a good method if the failover will be done manually?
Thanks!
Karl Albrecht
Active/Active and Active/Passive are obsolete concepts from SQL 7.0 when
each SQL instance had a primary owner host node and a partner owner node.
Under SQL 2000, all nodes are interchangable in a cluster. Some people
mistakenly use teh terms to refer to single and multiple instance SQL
clustering.
Clustering involves a single data store on a 'shared' storage system (SCSI
Array, SAN, etc. NOT NAS). Shared is not exactly correct since the cluster
software arbitrates ownership so that only one host node owns the
resource(s) at a time. Therefore, you have to have a working MSCS cluster
in order to create a SQL cluster.
Replication is not a good technique for creating a warm standby server.
Replication has VERY limited ability to handle schema changes without a
total resynch. It also does not replicate stored procedures or views.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Karl Albrecht" <karlman@.pacbell.net> wrote in message
news:O8QGJUplEHA.2340@.TK2MSFTNGP11.phx.gbl...
> We have just setup two servers running a copy of SQL 2000 on Windows 2000
> server. Each of these servers is running vendor software that interrracts
> with the databases. One server is primary and one is backup. Clients only
> interract with the vendor process on the servers and not the SQL directly.
>
> Some general questions on SQL 2000 high availability options...
> Does Active/Passive and Active/Active refer to clustering options that
> require that the servers be clustered on the OS level? Is this the only
> option that keeps the databases syncronized in real time?
> Is replication a good method if the failover will be done manually?
>
> Thanks!
> Karl Albrecht
>
|||Geoff, you can replicate stored procs and views.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:u%23O18vplEHA.3712@.TK2MSFTNGP15.phx.gbl...
Active/Active and Active/Passive are obsolete concepts from SQL 7.0 when
each SQL instance had a primary owner host node and a partner owner node.
Under SQL 2000, all nodes are interchangable in a cluster. Some people
mistakenly use teh terms to refer to single and multiple instance SQL
clustering.
Clustering involves a single data store on a 'shared' storage system (SCSI
Array, SAN, etc. NOT NAS). Shared is not exactly correct since the cluster
software arbitrates ownership so that only one host node owns the
resource(s) at a time. Therefore, you have to have a working MSCS cluster
in order to create a SQL cluster.
Replication is not a good technique for creating a warm standby server.
Replication has VERY limited ability to handle schema changes without a
total resynch. It also does not replicate stored procedures or views.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Karl Albrecht" <karlman@.pacbell.net> wrote in message
news:O8QGJUplEHA.2340@.TK2MSFTNGP11.phx.gbl...
> We have just setup two servers running a copy of SQL 2000 on Windows 2000
> server. Each of these servers is running vendor software that interrracts
> with the databases. One server is primary and one is backup. Clients only
> interract with the vendor process on the servers and not the SQL directly.
>
> Some general questions on SQL 2000 high availability options...
> Does Active/Passive and Active/Active refer to clustering options that
> require that the servers be clustered on the OS level? Is this the only
> option that keeps the databases syncronized in real time?
> Is replication a good method if the failover will be done manually?
>
> Thanks!
> Karl Albrecht
>
|||> Clustering involves a single data store on a 'shared' storage system (SCSI
> Array, SAN, etc. NOT NAS).
Actually, you can cluster to a shared resource on a NAS. We have a NetApp
880 Filer and have been running SQL clusters quite nicely using Snapdrive
over Gig fiber for a couple of years using the procedures outlined at this
NetApp link:
http://www.netapp.com/tech_library/3248.html#2.
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:u%23O18vplEHA.3712@.TK2MSFTNGP15.phx.gbl...
> Active/Active and Active/Passive are obsolete concepts from SQL 7.0 when
> each SQL instance had a primary owner host node and a partner owner node.
> Under SQL 2000, all nodes are interchangable in a cluster. Some people
> mistakenly use teh terms to refer to single and multiple instance SQL
> clustering.
> Clustering involves a single data store on a 'shared' storage system (SCSI
> Array, SAN, etc. NOT NAS). Shared is not exactly correct since the
> cluster
> software arbitrates ownership so that only one host node owns the
> resource(s) at a time. Therefore, you have to have a working MSCS cluster
> in order to create a SQL cluster.
> Replication is not a good technique for creating a warm standby server.
> Replication has VERY limited ability to handle schema changes without a
> total resynch. It also does not replicate stored procedures or views.
>
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Karl Albrecht" <karlman@.pacbell.net> wrote in message
> news:O8QGJUplEHA.2340@.TK2MSFTNGP11.phx.gbl...
>
server. Each of these servers is running vendor software that interrracts
with the databases. One server is primary and one is backup. Clients only
interract with the vendor process on the servers and not the SQL directly.
Some general questions on SQL 2000 high availability options...
Does Active/Passive and Active/Active refer to clustering options that
require that the servers be clustered on the OS level? Is this the only
option that keeps the databases syncronized in real time?
Is replication a good method if the failover will be done manually?
Thanks!
Karl Albrecht
Active/Active and Active/Passive are obsolete concepts from SQL 7.0 when
each SQL instance had a primary owner host node and a partner owner node.
Under SQL 2000, all nodes are interchangable in a cluster. Some people
mistakenly use teh terms to refer to single and multiple instance SQL
clustering.
Clustering involves a single data store on a 'shared' storage system (SCSI
Array, SAN, etc. NOT NAS). Shared is not exactly correct since the cluster
software arbitrates ownership so that only one host node owns the
resource(s) at a time. Therefore, you have to have a working MSCS cluster
in order to create a SQL cluster.
Replication is not a good technique for creating a warm standby server.
Replication has VERY limited ability to handle schema changes without a
total resynch. It also does not replicate stored procedures or views.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Karl Albrecht" <karlman@.pacbell.net> wrote in message
news:O8QGJUplEHA.2340@.TK2MSFTNGP11.phx.gbl...
> We have just setup two servers running a copy of SQL 2000 on Windows 2000
> server. Each of these servers is running vendor software that interrracts
> with the databases. One server is primary and one is backup. Clients only
> interract with the vendor process on the servers and not the SQL directly.
>
> Some general questions on SQL 2000 high availability options...
> Does Active/Passive and Active/Active refer to clustering options that
> require that the servers be clustered on the OS level? Is this the only
> option that keeps the databases syncronized in real time?
> Is replication a good method if the failover will be done manually?
>
> Thanks!
> Karl Albrecht
>
|||Geoff, you can replicate stored procs and views.
Tom
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON Canada
www.pinnaclepublishing.com/sql
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:u%23O18vplEHA.3712@.TK2MSFTNGP15.phx.gbl...
Active/Active and Active/Passive are obsolete concepts from SQL 7.0 when
each SQL instance had a primary owner host node and a partner owner node.
Under SQL 2000, all nodes are interchangable in a cluster. Some people
mistakenly use teh terms to refer to single and multiple instance SQL
clustering.
Clustering involves a single data store on a 'shared' storage system (SCSI
Array, SAN, etc. NOT NAS). Shared is not exactly correct since the cluster
software arbitrates ownership so that only one host node owns the
resource(s) at a time. Therefore, you have to have a working MSCS cluster
in order to create a SQL cluster.
Replication is not a good technique for creating a warm standby server.
Replication has VERY limited ability to handle schema changes without a
total resynch. It also does not replicate stored procedures or views.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Karl Albrecht" <karlman@.pacbell.net> wrote in message
news:O8QGJUplEHA.2340@.TK2MSFTNGP11.phx.gbl...
> We have just setup two servers running a copy of SQL 2000 on Windows 2000
> server. Each of these servers is running vendor software that interrracts
> with the databases. One server is primary and one is backup. Clients only
> interract with the vendor process on the servers and not the SQL directly.
>
> Some general questions on SQL 2000 high availability options...
> Does Active/Passive and Active/Active refer to clustering options that
> require that the servers be clustered on the OS level? Is this the only
> option that keeps the databases syncronized in real time?
> Is replication a good method if the failover will be done manually?
>
> Thanks!
> Karl Albrecht
>
|||> Clustering involves a single data store on a 'shared' storage system (SCSI
> Array, SAN, etc. NOT NAS).
Actually, you can cluster to a shared resource on a NAS. We have a NetApp
880 Filer and have been running SQL clusters quite nicely using Snapdrive
over Gig fiber for a couple of years using the procedures outlined at this
NetApp link:
http://www.netapp.com/tech_library/3248.html#2.
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:u%23O18vplEHA.3712@.TK2MSFTNGP15.phx.gbl...
> Active/Active and Active/Passive are obsolete concepts from SQL 7.0 when
> each SQL instance had a primary owner host node and a partner owner node.
> Under SQL 2000, all nodes are interchangable in a cluster. Some people
> mistakenly use teh terms to refer to single and multiple instance SQL
> clustering.
> Clustering involves a single data store on a 'shared' storage system (SCSI
> Array, SAN, etc. NOT NAS). Shared is not exactly correct since the
> cluster
> software arbitrates ownership so that only one host node owns the
> resource(s) at a time. Therefore, you have to have a working MSCS cluster
> in order to create a SQL cluster.
> Replication is not a good technique for creating a warm standby server.
> Replication has VERY limited ability to handle schema changes without a
> total resynch. It also does not replicate stored procedures or views.
>
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "Karl Albrecht" <karlman@.pacbell.net> wrote in message
> news:O8QGJUplEHA.2340@.TK2MSFTNGP11.phx.gbl...
>
Subscribe to:
Posts (Atom)