I am not really sure what an API is and am about to do some research. However, I think the solution to my problem will include some knowledge of APIs.
I need to be able to access Outlook's contacts with my web app. Can someone point me into the right direction to instructions on how to do this?
ThanksYou could create a linked server and go from there (or use ADO/Active X script in DTS). Check this link out:
http://www.slipstick.com/dev/database.htmsql
Showing posts with label solution. Show all posts
Showing posts with label solution. Show all posts
Tuesday, March 27, 2012
Monday, March 12, 2012
High availability, VMWare and remote sites.
We are starting to look into a high availability solution to ensure
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles Deaton
Charles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
>
|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
|||Thank you for the follow up David!
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles Deaton
Charles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
>
|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
|||Thank you for the follow up David!
High availability, VMWare and remote sites.
We are starting to look into a high availability solution to ensure
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles Deaton
Charles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
>
|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
|||Thank you for the follow up David!
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles Deaton
Charles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
>
|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
|||Thank you for the follow up David!
High availability, VMWare and remote sites.
We are starting to look into a high availability solution to ensure
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles Deaton
Charles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
>
|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
|||Thank you for the follow up David!
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles Deaton
Charles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>
|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegrou ps.com...
>
|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com
|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image data.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
|||Thank you for the follow up David!
High availability, VMWare and remote sites.
We are starting to look into a high availability solution to ensure
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles DeatonCharles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/pr...oy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
>|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicatin
g
datbases with a few hundred tables, with a few of them being relatively wide
.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds t
o
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover
.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
>|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?[url]http://www.nwsu.com/0974973602.html[/u
rl]
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.co
m
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image dat
a.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our nativ
e
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image dat
a.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>|||Lines: 4
Thread-Topic: High availability, VMWare and remote sites.
thread-index: AcdZ7++LM62a2utkRBGr95GR1p67AA==
X-WBNR-Posting-Host: 206.169.226.36
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757
NNTP-Posting-Host: tk2msftsbfm01.phx.gbl 10.40.244.148
Xref: leafnode.mcse.ms microsoft.public.sqlserver.clustering:2069 microsoft.
public.sqlserver.replication:5771 microsoft.public.sqlserver.server:28202
Thank you for the follow up David!
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles DeatonCharles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/pr...oy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
>|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicatin
g
datbases with a few hundred tables, with a few of them being relatively wide
.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds t
o
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover
.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>|||answers inline.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
[vbcol=seagreen]
> Thanks,
> Michael
> "Hilary Cotter" wrote:
>|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?[url]http://www.nwsu.com/0974973602.html[/u
rl]
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.co
m
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
>
>
> Yes,
>
> Yes, but all forms of replication do not work well with text and image dat
a.
>
>
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>
>
>
>
>
>
>
>
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our nativ
e
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Yes,
>
> Yes, but all forms of replication do not work well with text and image dat
a.
> Yes, failover and failback.
>
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
>|||Lines: 4
Thread-Topic: High availability, VMWare and remote sites.
thread-index: AcdZ7++LM62a2utkRBGr95GR1p67AA==
X-WBNR-Posting-Host: 206.169.226.36
MIME-Version: 1.0
Content-Type: text/plain;
charset="Utf-8"
Content-Transfer-Encoding: 7bit
X-Newsreader: Microsoft CDO for Windows 2000
Content-Class: urn:content-classes:message
Importance: normal
Priority: normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2757
NNTP-Posting-Host: tk2msftsbfm01.phx.gbl 10.40.244.148
Xref: leafnode.mcse.ms microsoft.public.sqlserver.clustering:2069 microsoft.
public.sqlserver.replication:5771 microsoft.public.sqlserver.server:28202
Thank you for the follow up David!
High availability, VMWare and remote sites.
We are starting to look into a high availability solution to ensure
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles DeatonCharles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> > We are starting to look into a high availability solution to ensure
> > operation of our business in the event of a localized disaster
> > (i.e.. building fire). We are planning on a remote site, maybe
> > 25 miles away, that will provide virtual servers and resources via
> > VMWare. We will need, among other things, to have a warm
> > stand by MSSQL 2000 server up and running. I'm aware of the
> > common solution such as log shipping, mirroring in 2005 and
> > replication. We do not want to upgrade to 2005 so mirroring is
> > not an option. We will need to be able to fail back to the primary
> > MSSQL server with little or no intervention when the disaster
> > has been resolved so replication is not an option. Our databases
> > are used for a hybrid OLTP system with several thousand
> > transactions per second. Data loss needs to be kept to a
> > minimum. Failover and fail back should be seamless
> > (No data loss except opened transactions?).
> >
> > We are looking at DoubleTake, NeverFail, XOSoft and
> > Goldengate products. It seems like some play better with
> > VMWare than others. We have not looked closely at Symantec,
> > EMC or SteelEye but am aware of that they offer possible
> > solutions as well.
> >
> > If anyone has any hands on experience with a solution similar
> > to what we are looking into we would appreciate your comments.
> >
> > Thanks,
> > Charles Deaton
> >
>|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>|||answers inline.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
> Thanks,
> Michael
> "Hilary Cotter" wrote:
>> Use bi-directional transactional replication. Change your identity seeds
>> to
>> odd on one side, even on the other. This way you never have to worry
>> about
>> failing over or failing back and synchronization as both sides are live
>> simultaneously.
>> The only issue with this is client re-direction in the event of a
>> failover.
>> --
>> Hilary Cotter
>> Looking for a SQL Server replication book?
>> http://www.nwsu.com/0974973602.html
>> Looking for a FAQ on Indexing Services/SQL FTS
>> http://www.indexserverfaq.com
>>|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> > Hilary,
> > Will bi-directional replication work across geographical distances, the
> > WAN
> > (e.g. NorCal to Phoeix)?
> Yes,
> > Specifically for wide tables... Or for replicating
> > datbases with a few hundred tables, with a few of them being relatively
> > wide.
> Yes, but all forms of replication do not work well with text and image data.
>
> > Also, are you simply recommending odd and even identities to ease
> > failover?
> Yes, failover and failback.
> > And finally, do you have any thoughts on products like GoldenGate?
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
> > Thanks,
> > Michael
> > "Hilary Cotter" wrote:
> >> Use bi-directional transactional replication. Change your identity seeds
> >> to
> >> odd on one side, even on the other. This way you never have to worry
> >> about
> >> failing over or failing back and synchronization as both sides are live
> >> simultaneously.
> >> The only issue with this is client re-direction in the event of a
> >> failover.
> >> --
> >> Hilary Cotter
> >> Looking for a SQL Server replication book?
> >>http://www.nwsu.com/0974973602.html
> >> Looking for a FAQ on Indexing Services/SQL FTS
> >>http://www.indexserverfaq.com- Hide quoted text -
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> > Hilary,
> >
> > Will bi-directional replication work across geographical distances, the
> > WAN
> > (e.g. NorCal to Phoeix)?
> Yes,
> > Specifically for wide tables... Or for replicating
> > datbases with a few hundred tables, with a few of them being relatively
> > wide.
> Yes, but all forms of replication do not work well with text and image data.
> >
> > Also, are you simply recommending odd and even identities to ease
> > failover?
> >
> Yes, failover and failback.
> > And finally, do you have any thoughts on products like GoldenGate?
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
> >
> > Thanks,
> >
> > Michael
> >
> > "Hilary Cotter" wrote:
> >
> >> Use bi-directional transactional replication. Change your identity seeds
> >> to
> >> odd on one side, even on the other. This way you never have to worry
> >> about
> >> failing over or failing back and synchronization as both sides are live
> >> simultaneously.
> >>
> >> The only issue with this is client re-direction in the event of a
> >> failover.
> >>
> >> --
> >> Hilary Cotter
> >>
> >> Looking for a SQL Server replication book?
> >> http://www.nwsu.com/0974973602.html
> >>
> >> Looking for a FAQ on Indexing Services/SQL FTS
> >> http://www.indexserverfaq.com
> >>
> >>
>
>|||Thank you for the follow up David!
operation of our business in the event of a localized disaster
(i.e.. building fire). We are planning on a remote site, maybe
25 miles away, that will provide virtual servers and resources via
VMWare. We will need, among other things, to have a warm
stand by MSSQL 2000 server up and running. I'm aware of the
common solution such as log shipping, mirroring in 2005 and
replication. We do not want to upgrade to 2005 so mirroring is
not an option. We will need to be able to fail back to the primary
MSSQL server with little or no intervention when the disaster
has been resolved so replication is not an option. Our databases
are used for a hybrid OLTP system with several thousand
transactions per second. Data loss needs to be kept to a
minimum. Failover and fail back should be seamless
(No data loss except opened transactions?).
We are looking at DoubleTake, NeverFail, XOSoft and
Goldengate products. It seems like some play better with
VMWare than others. We have not looked closely at Symantec,
EMC or SteelEye but am aware of that they offer possible
solutions as well.
If anyone has any hands on experience with a solution similar
to what we are looking into we would appreciate your comments.
Thanks,
Charles DeatonCharles,
for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
SRDF/CE 2.2. This is a Geocluster solution.
It uses EMC SRDF/S technology to ensure all data is synchronised (to the IO
level). You can built your cluster, half of the nodes in your primary
datacenter, half of the nodes in your secondary datacenter.
It will failover your cluster to your secondary datacenter (to the
un-trained eye, it is *just* a cluster)
AND
It will failback your cluster to your primary, as simple as clicking "move
group" in Cluster Administrator, once your primary site is back up, disaster
over.
I don't think it will tie in with your VMWare limitation, but for a High
transacting db (as you mention several thousands of transactions per second)
I am not sure if a virtual server would cope with that anyway.
I have been running many SRDF/CE solutions for several years, but to be
fair: I have not ran other geocluster solutions, so my opinion is probably
biassed a bit. If your are not running EMC Symmetrix storage, then this
solution could be a bit costly, as a minimum you need two Symmetrix storage
units and obviously the FC-fabrics and FC interconnects between the two
data-centers.
rgds,
Edwin.
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||Use bi-directional transactional replication. Change your identity seeds to
odd on one side, even on the other. This way you never have to worry about
failing over or failing back and synchronization as both sides are live
simultaneously.
The only issue with this is client re-direction in the event of a failover.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Charles Deaton" <sqldba@.comcast.net> wrote in message
news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton
>|||What Edwin is referring to is termed "stretch clustering." We too have been
running Remote Disk Mirrors successfully with only bandwidth issues as the
down side.
In stretch clustering, you will need to maintain a "warm" DR site and is
built on top of remote mirroring. With remote mirroring alone, you can
maintain a "cold" site.
You could also run SRDF/A (asynchronous). This overcomes some of the disk
mirroring bottlenecks with only a minor increase in risk for data loss (it
allows 1 pending IO in the queue without remote commit instead of dual
commit associated with synchronous mode). Do not let any storage
managers/technicians sell you on the idea of Adaptive Copy. The technology
does NOT preserve the write-ordering necessary to maintain the WAL (write
ahead logging) protocol necessary to maintain database transaction ACID
properties.
You will not be able to SAN replicate if one host is real and the remote
host is virtual.
SQL Server 2000 High Availability Series
Implementing Remote Mirroring and Stretch Clustering
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/hasog05.mspx
Requirements for SQL Server 2005 and SQL Server 2000 to support remote
mirroring of user databases
http://support.microsoft.com/kb/910716
Best of luck.
Sincerely,
Anthony Thomas
"Edwin vMierlo" <EdwinvMierlo@.discussions.microsoft.com> wrote in message
news:%23IQ144ZNHHA.1252@.TK2MSFTNGP02.phx.gbl...
> Charles,
> for a "no IO lost" solution on EMC Symmetrix, I can highly recommend EMC
> SRDF/CE 2.2. This is a Geocluster solution.
> It uses EMC SRDF/S technology to ensure all data is synchronised (to the
IO
> level). You can built your cluster, half of the nodes in your primary
> datacenter, half of the nodes in your secondary datacenter.
> It will failover your cluster to your secondary datacenter (to the
> un-trained eye, it is *just* a cluster)
> AND
> It will failback your cluster to your primary, as simple as clicking "move
> group" in Cluster Administrator, once your primary site is back up,
disaster
> over.
> I don't think it will tie in with your VMWare limitation, but for a High
> transacting db (as you mention several thousands of transactions per
second)
> I am not sure if a virtual server would cope with that anyway.
> I have been running many SRDF/CE solutions for several years, but to be
> fair: I have not ran other geocluster solutions, so my opinion is probably
> biassed a bit. If your are not running EMC Symmetrix storage, then this
> solution could be a bit costly, as a minimum you need two Symmetrix
storage
> units and obviously the FC-fabrics and FC interconnects between the two
> data-centers.
> rgds,
> Edwin.
>
> "Charles Deaton" <sqldba@.comcast.net> wrote in message
> news:1168532249.017203.57740@.77g2000hsv.googlegroups.com...
> > We are starting to look into a high availability solution to ensure
> > operation of our business in the event of a localized disaster
> > (i.e.. building fire). We are planning on a remote site, maybe
> > 25 miles away, that will provide virtual servers and resources via
> > VMWare. We will need, among other things, to have a warm
> > stand by MSSQL 2000 server up and running. I'm aware of the
> > common solution such as log shipping, mirroring in 2005 and
> > replication. We do not want to upgrade to 2005 so mirroring is
> > not an option. We will need to be able to fail back to the primary
> > MSSQL server with little or no intervention when the disaster
> > has been resolved so replication is not an option. Our databases
> > are used for a hybrid OLTP system with several thousand
> > transactions per second. Data loss needs to be kept to a
> > minimum. Failover and fail back should be seamless
> > (No data loss except opened transactions?).
> >
> > We are looking at DoubleTake, NeverFail, XOSoft and
> > Goldengate products. It seems like some play better with
> > VMWare than others. We have not looked closely at Symantec,
> > EMC or SteelEye but am aware of that they offer possible
> > solutions as well.
> >
> > If anyone has any hands on experience with a solution similar
> > to what we are looking into we would appreciate your comments.
> >
> > Thanks,
> > Charles Deaton
> >
>|||SteelEye works great with Physical to Virtual clustering of SQL Server.
If you contact us, we can give you great SQL Server reference
accounts.
David A. Bermingham, MCSE, MCSA:Messaging
Senior Systems Engineer
www.steeleye.com
Charles Deaton wrote:
> We are starting to look into a high availability solution to ensure
> operation of our business in the event of a localized disaster
> (i.e.. building fire). We are planning on a remote site, maybe
> 25 miles away, that will provide virtual servers and resources via
> VMWare. We will need, among other things, to have a warm
> stand by MSSQL 2000 server up and running. I'm aware of the
> common solution such as log shipping, mirroring in 2005 and
> replication. We do not want to upgrade to 2005 so mirroring is
> not an option. We will need to be able to fail back to the primary
> MSSQL server with little or no intervention when the disaster
> has been resolved so replication is not an option. Our databases
> are used for a hybrid OLTP system with several thousand
> transactions per second. Data loss needs to be kept to a
> minimum. Failover and fail back should be seamless
> (No data loss except opened transactions?).
> We are looking at DoubleTake, NeverFail, XOSoft and
> Goldengate products. It seems like some play better with
> VMWare than others. We have not looked closely at Symantec,
> EMC or SteelEye but am aware of that they offer possible
> solutions as well.
> If anyone has any hands on experience with a solution similar
> to what we are looking into we would appreciate your comments.
> Thanks,
> Charles Deaton|||Hilary,
Will bi-directional replication work across geographical distances, the WAN
(e.g. NorCal to Phoeix)? Specifically for wide tables... Or for replicating
datbases with a few hundred tables, with a few of them being relatively wide.
Also, are you simply recommending odd and even identities to ease failover?
And finally, do you have any thoughts on products like GoldenGate?
Thanks,
Michael
"Hilary Cotter" wrote:
> Use bi-directional transactional replication. Change your identity seeds to
> odd on one side, even on the other. This way you never have to worry about
> failing over or failing back and synchronization as both sides are live
> simultaneously.
> The only issue with this is client re-direction in the event of a failover.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>|||answers inline.
--
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Batman" <Batman@.discussions.microsoft.com> wrote in message
news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> Hilary,
> Will bi-directional replication work across geographical distances, the
> WAN
> (e.g. NorCal to Phoeix)?
Yes,
> Specifically for wide tables... Or for replicating
> datbases with a few hundred tables, with a few of them being relatively
> wide.
Yes, but all forms of replication do not work well with text and image data.
> Also, are you simply recommending odd and even identities to ease
> failover?
>
Yes, failover and failback.
> And finally, do you have any thoughts on products like GoldenGate?
No, I don't. I've worked with DoubleTake and it works well.
I had some interesting discussions with David Bermingham of steeleye.com.
I'll let him weigh in here on his companies solutions.
> Thanks,
> Michael
> "Hilary Cotter" wrote:
>> Use bi-directional transactional replication. Change your identity seeds
>> to
>> odd on one side, even on the other. This way you never have to worry
>> about
>> failing over or failing back and synchronization as both sides are live
>> simultaneously.
>> The only issue with this is client re-direction in the event of a
>> failover.
>> --
>> Hilary Cotter
>> Looking for a SQL Server replication book?
>> http://www.nwsu.com/0974973602.html
>> Looking for a FAQ on Indexing Services/SQL FTS
>> http://www.indexserverfaq.com
>>|||On Feb 26, 2:21 pm, "Hilary Cotter" <hilary.cot...@.gmail.com> wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTShttp://www.indexserverfaq.com
> "Batman" <Bat...@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> > Hilary,
> > Will bi-directional replication work across geographical distances, the
> > WAN
> > (e.g. NorCal to Phoeix)?
> Yes,
> > Specifically for wide tables... Or for replicating
> > datbases with a few hundred tables, with a few of them being relatively
> > wide.
> Yes, but all forms of replication do not work well with text and image data.
>
> > Also, are you simply recommending odd and even identities to ease
> > failover?
> Yes, failover and failback.
> > And finally, do you have any thoughts on products like GoldenGate?
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
>
>
> > Thanks,
> > Michael
> > "Hilary Cotter" wrote:
> >> Use bi-directional transactional replication. Change your identity seeds
> >> to
> >> odd on one side, even on the other. This way you never have to worry
> >> about
> >> failing over or failing back and synchronization as both sides are live
> >> simultaneously.
> >> The only issue with this is client re-direction in the event of a
> >> failover.
> >> --
> >> Hilary Cotter
> >> Looking for a SQL Server replication book?
> >>http://www.nwsu.com/0974973602.html
> >> Looking for a FAQ on Indexing Services/SQL FTS
> >>http://www.indexserverfaq.com- Hide quoted text -
> - Show quoted text -
Thanks Hilary,
SteelEye Data Replication (SDR) is a host based block level replicator
that works in either async or sync mode. It is implemented as a
Windows filter driver and works below the file system. This gives us
the same type of performance as hardware based replication, with the
addition of being able to provide application level monitoring for
automatic failover, failback and client redirection. As far as
distance goes, it really depends on your rate of change. Because we
replicate block for block, we simply need you to use Perfmon to
collect disk write bytes/sec and send us the log for analysis. We
will then be able to recommend a proper WAN link.
So the key features of LifeKeeper for SQL Server with SDR are as
follows:
- Data Replication - Async or Sync across a WAN or LAN
- Data Compression - 9 levels of compression
- WAN Optimization - fully utilize existing WAN links (something
DoubleTake can not do without hardware accelerators)
- Application monitoring with local recovery and automated failover
and failback (Again, something DoubleTake does not do)
- Client redirection via DNS update or virtual IP (for spanned
subnets)
- Easily integrate 3rd party applications as well as SQL
- Runs on Standard or Enterprise Editions of the OS and SQL
- Supports VMs from MS and VMware in P2V or V2V configurations
Contact us at www.steeleye.com if you would like to request an
evaluation or talk to someone in person.
David A. Beringham, MCSE, MCSA:Messaging
Director of Product Management
www.steeleye.com|||I went to steeleye.com but I couldn't tell whether or not the solution was
byte level or transactional. Do you know which?
I have looked at Mimix/Double-Take and the draw back is that it won't give
us the Live Standby site. Overall, we want to be able to preserve our native
replication topologies on the target for the ease of failing over to a fully
functional standby site. So if we attempted this natively, we would have to
create a complex repub topology.
Overall, the reason we are looking at GoldenGate is to have a decoupled HA
solution that won't interfere with our local native replication topologies,
overall seperating our HA solution from our reporting replication topology.
Mostly preventing the metadata nightmare that happens when your distributor
crashes hard, in a major DR event.
So overall, I'm just seeing what the consensus is on WAN HA...
Thanks!
Michael
"Hilary Cotter" wrote:
> answers inline.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
>
> "Batman" <Batman@.discussions.microsoft.com> wrote in message
> news:4FE68A86-4D95-4B2C-AA87-AA36BDF0840C@.microsoft.com...
> > Hilary,
> >
> > Will bi-directional replication work across geographical distances, the
> > WAN
> > (e.g. NorCal to Phoeix)?
> Yes,
> > Specifically for wide tables... Or for replicating
> > datbases with a few hundred tables, with a few of them being relatively
> > wide.
> Yes, but all forms of replication do not work well with text and image data.
> >
> > Also, are you simply recommending odd and even identities to ease
> > failover?
> >
> Yes, failover and failback.
> > And finally, do you have any thoughts on products like GoldenGate?
> No, I don't. I've worked with DoubleTake and it works well.
> I had some interesting discussions with David Bermingham of steeleye.com.
> I'll let him weigh in here on his companies solutions.
> >
> > Thanks,
> >
> > Michael
> >
> > "Hilary Cotter" wrote:
> >
> >> Use bi-directional transactional replication. Change your identity seeds
> >> to
> >> odd on one side, even on the other. This way you never have to worry
> >> about
> >> failing over or failing back and synchronization as both sides are live
> >> simultaneously.
> >>
> >> The only issue with this is client re-direction in the event of a
> >> failover.
> >>
> >> --
> >> Hilary Cotter
> >>
> >> Looking for a SQL Server replication book?
> >> http://www.nwsu.com/0974973602.html
> >>
> >> Looking for a FAQ on Indexing Services/SQL FTS
> >> http://www.indexserverfaq.com
> >>
> >>
>
>|||Thank you for the follow up David!
Friday, March 9, 2012
high Availability cubes: During Cube metadata updates + ProClarity
Hi,
This is a kind of solution design issue.
Scenario: We have a web page that displays information from a Oracle data warehouse. We collect the required information in the page and have used AMO to create cubes and other related objects from this information. The source for the cubes in SSAS 2005 would point to Oracle. This is modelled as a web service and used within the web page. Once the Cube gets created in SSAS, we model ProClarity graphs on them.
The problem: The users can invoke the AMO web service from the web page, to add a new MeasureGroup to an existing cube. Once this is done the Cube becomes non-browsable. because we are adding a new MeasureGroup and thus modifying the cube metadata.
In detail, If the new MeasureGroup that is added, uses dimensions that are already cube-dimensions then- only the newly added MeasureGroup will be UnProcessed and the exsiting MeasureGroups will be processed. (cube is UnProcessed state).
otherwise, if the new MeasureGroup that is added, adds a new cube-dimension to the cube then- all the MeasureGroups will be in the UnProcessed state including the newly added MeasureGroup.
Now, until the user invokes a 'process' request, for the cube that is modified and the processing is complete, that paticular cube is not accesible. All the Proclarity graphs that are linked to that cube, show error messages!
How can we keep the Proclarity graphs / users pointed to a old copy of the cube, at least until the newly modified cube is processed and online?
If not, are there any other approaches to get high availability for the cubes or for the ProClarity Graphs?
Can we create a offline cube that can be used temporarily? if so how to dynamically switch between the offline cube and the online cube?
Regards
If you do all the AMO operations including creating and processing the cube within transaction, then the previous version of the cube will be available until transaction commits. After transaction commited, the new version of the cube will be immediatelly avaiable.|||Hi Mosha,
Thanks for the tip.
Since this operation is used in a J2EE web site using a AMO web service.
If I include the processing task with it then it would take a huge time for large cubes.
Currently we are using the 'Ascmd' to do the processing. This is scheduled using a scheduler.
We planned to somehow call Ascmd Asynchronously from the web page and intimate users using an email after the processing completes.
can we include the processing also in the previous transaction while using Ascmd?
Apart from this, any other mechanism that we can use like Raid/mirroring, Failover clustering. etc?
Or temporary local cubes?
:-) Just a wild shot: Probably the next version of SSAS needs to include something similary "shadow-copy-cube".
Thanks and Regards
|||Just a wild shot: Probably the next version of SSAS needs to include something similary "shadow-copy-cube".
No need to wait for the next version. SSAS2005 already supports Sync functionality, where you can build and process cube on one server and then sync it to another server.
|||You might consider using AS 2005's "synchronize database" capability. This would require (I think) two servers. The first would be the "modify and process" server (call it ServerA) while the second would be the "presentation" server (call it ServerB).
In your application, you would have the users always browsing the cube(s) on ServerB. As they make changes to the design of the cube (adding measure groups, cube dimensions, etc.), you'd direct those changes to the cube(s) on ServerA. You could then asynchronously use ascmd to reprocess part or all of a modified cube on ServerA (while they continue to use the cube on ServerB). Once the processing is complete, you could execute an XMLA script on ServerB, requesting that the database on ServerB be sychronized from ServerA. The nice thing about this is that the synchronization occurs within a transaction, so the cube on ServerB is still usable while the sychronization occurs and the updated version of the cube is then available to users immediately once it is complete.
Take a look at the following link in BOL for the XMLA element for the synchronize command:
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/xmla9/html/9401323c-feff-409a-a9da-94aee47e0563.htm
HTH,
Dave Fackler
|||Hi,
Wow!
Thanks a lot for that.
I am going to implement the "Sync Database", This will solve my problem!
although I would take some time to complete this , I will let you know when I start.
Regards
Subscribe to:
Posts (Atom)