Please create news group for Log Shipping
That is probably not going to happen. Microsoft has a pretty clear purpose
for each newsgroup, yet the newsgroups are broad enough to make it easy to
find what one is looking for without having to search thousands of
newsgroups for information.
If you have a question regarding log shipping it would probably fit best
within .server (or possibly .setup). Then again, many knowledgeable people
hang out in all the sqlserver groups so you are probably going to get a hit
no matter where you post.
in the meantime, check out these links:
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
news:2d08001c469c8$f0a55800$a501280a@.phx.gbl...
> Please create news group for Log Shipping
|||Hi
I already checked the documents on microsoft web sites. i
have opened a new message and looking for some kind of
workaround on that problem.
Thanks
Mayur
>--Original Message--
>That is probably not going to happen. Microsoft has a
pretty clear purpose
>for each newsgroup, yet the newsgroups are broad enough
to make it easy to
>find what one is looking for without having to search
thousands of
>newsgroups for information.
>If you have a question regarding log shipping it would
probably fit best
>within .server (or possibly .setup). Then again, many
knowledgeable people
>hang out in all the sqlserver groups so you are probably
going to get a hit
>no matter where you post.
>in the meantime, check out these links:
>314515 INF: Frequently Asked Questions - SQL Server 2000 -
Log Shipping
>http://support.microsoft.com/?id=314515
>323135 INF: Microsoft SQL Server 2000 - How to Set Up Log
Shipping (White
>Paper)
>http://support.microsoft.com/?id=323135
>325220 Support WebCast: Microsoft SQL Server 2000 Log
Shipping
>http://support.microsoft.com/?id=325220
>821786 Support WebCast: Microsoft SQL Server 2000: Using
Log Shipping
>http://support.microsoft.com/?id=821786
>321247 HOW TO: Configure Security for Log Shipping
>http://support.microsoft.com/?id=321247
>329133 INF: Troubleshooting SQL Server 2000 Log
Shipping "Out of Sync"
>Errors
>http://support.microsoft.com/?id=329133
>--
>Keith
>
>"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
>news:2d08001c469c8$f0a55800$a501280a@.phx.gbl...
>.
>
Showing posts with label shipping. Show all posts
Showing posts with label shipping. Show all posts
Friday, March 23, 2012
Please create news group for Log Shipping
Please create news group for Log ShippingThat is probably not going to happen. Microsoft has a pretty clear purpose
for each newsgroup, yet the newsgroups are broad enough to make it easy to
find what one is looking for without having to search thousands of
newsgroups for information.
If you have a question regarding log shipping it would probably fit best
within .server (or possibly .setup). Then again, many knowledgeable people
hang out in all the sqlserver groups so you are probably going to get a hit
no matter where you post.
in the meantime, check out these links:
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
news:2d08001c469c8$f0a55800$a501280a@.phx
.gbl...
> Please create news group for Log Shipping|||Hi
I already checked the documents on microsoft web sites. i
have opened a new message and looking for some kind of
workaround on that problem.
Thanks
Mayur
>--Original Message--
>That is probably not going to happen. Microsoft has a
pretty clear purpose
>for each newsgroup, yet the newsgroups are broad enough
to make it easy to
>find what one is looking for without having to search
thousands of
>newsgroups for information.
>If you have a question regarding log shipping it would
probably fit best
>within .server (or possibly .setup). Then again, many
knowledgeable people
>hang out in all the sqlserver groups so you are probably
going to get a hit
>no matter where you post.
>in the meantime, check out these links:
>314515 INF: Frequently Asked Questions - SQL Server 2000 -
Log Shipping
>http://support.microsoft.com/?id=314515
>323135 INF: Microsoft SQL Server 2000 - How to Set Up Log
Shipping (White
>Paper)
>http://support.microsoft.com/?id=323135
>325220 Support WebCast: Microsoft SQL Server 2000 Log
Shipping
>http://support.microsoft.com/?id=325220
>821786 Support WebCast: Microsoft SQL Server 2000: Using
Log Shipping
>http://support.microsoft.com/?id=821786
>321247 HOW TO: Configure Security for Log Shipping
>http://support.microsoft.com/?id=321247
>329133 INF: Troubleshooting SQL Server 2000 Log
Shipping "Out of Sync"
>Errors
>http://support.microsoft.com/?id=329133
>--
>Keith
>
>"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
> news:2d08001c469c8$f0a55800$a501280a@.phx
.gbl...
>.
>
for each newsgroup, yet the newsgroups are broad enough to make it easy to
find what one is looking for without having to search thousands of
newsgroups for information.
If you have a question regarding log shipping it would probably fit best
within .server (or possibly .setup). Then again, many knowledgeable people
hang out in all the sqlserver groups so you are probably going to get a hit
no matter where you post.
in the meantime, check out these links:
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
Keith
"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
news:2d08001c469c8$f0a55800$a501280a@.phx
.gbl...
> Please create news group for Log Shipping|||Hi
I already checked the documents on microsoft web sites. i
have opened a new message and looking for some kind of
workaround on that problem.
Thanks
Mayur
>--Original Message--
>That is probably not going to happen. Microsoft has a
pretty clear purpose
>for each newsgroup, yet the newsgroups are broad enough
to make it easy to
>find what one is looking for without having to search
thousands of
>newsgroups for information.
>If you have a question regarding log shipping it would
probably fit best
>within .server (or possibly .setup). Then again, many
knowledgeable people
>hang out in all the sqlserver groups so you are probably
going to get a hit
>no matter where you post.
>in the meantime, check out these links:
>314515 INF: Frequently Asked Questions - SQL Server 2000 -
Log Shipping
>http://support.microsoft.com/?id=314515
>323135 INF: Microsoft SQL Server 2000 - How to Set Up Log
Shipping (White
>Paper)
>http://support.microsoft.com/?id=323135
>325220 Support WebCast: Microsoft SQL Server 2000 Log
Shipping
>http://support.microsoft.com/?id=325220
>821786 Support WebCast: Microsoft SQL Server 2000: Using
Log Shipping
>http://support.microsoft.com/?id=821786
>321247 HOW TO: Configure Security for Log Shipping
>http://support.microsoft.com/?id=321247
>329133 INF: Troubleshooting SQL Server 2000 Log
Shipping "Out of Sync"
>Errors
>http://support.microsoft.com/?id=329133
>--
>Keith
>
>"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
> news:2d08001c469c8$f0a55800$a501280a@.phx
.gbl...
>.
>
Please create news group for Log Shipping
Please create news group for Log ShippingThat is probably not going to happen. Microsoft has a pretty clear purpose
for each newsgroup, yet the newsgroups are broad enough to make it easy to
find what one is looking for without having to search thousands of
newsgroups for information.
If you have a question regarding log shipping it would probably fit best
within .server (or possibly .setup). Then again, many knowledgeable people
hang out in all the sqlserver groups so you are probably going to get a hit
no matter where you post.
in the meantime, check out these links:
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
--
Keith
"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
news:2d08001c469c8$f0a55800$a501280a@.phx.gbl...
> Please create news group for Log Shipping|||Hi
I already checked the documents on microsoft web sites. i
have opened a new message and looking for some kind of
workaround on that problem.
Thanks
Mayur
>--Original Message--
>That is probably not going to happen. Microsoft has a
pretty clear purpose
>for each newsgroup, yet the newsgroups are broad enough
to make it easy to
>find what one is looking for without having to search
thousands of
>newsgroups for information.
>If you have a question regarding log shipping it would
probably fit best
>within .server (or possibly .setup). Then again, many
knowledgeable people
>hang out in all the sqlserver groups so you are probably
going to get a hit
>no matter where you post.
>in the meantime, check out these links:
>314515 INF: Frequently Asked Questions - SQL Server 2000 -
Log Shipping
>http://support.microsoft.com/?id=314515
>323135 INF: Microsoft SQL Server 2000 - How to Set Up Log
Shipping (White
>Paper)
>http://support.microsoft.com/?id=323135
>325220 Support WebCast: Microsoft SQL Server 2000 Log
Shipping
>http://support.microsoft.com/?id=325220
>821786 Support WebCast: Microsoft SQL Server 2000: Using
Log Shipping
>http://support.microsoft.com/?id=821786
>321247 HOW TO: Configure Security for Log Shipping
>http://support.microsoft.com/?id=321247
>329133 INF: Troubleshooting SQL Server 2000 Log
Shipping "Out of Sync"
>Errors
>http://support.microsoft.com/?id=329133
>--
>Keith
>
>"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
>news:2d08001c469c8$f0a55800$a501280a@.phx.gbl...
>> Please create news group for Log Shipping
>.
>
for each newsgroup, yet the newsgroups are broad enough to make it easy to
find what one is looking for without having to search thousands of
newsgroups for information.
If you have a question regarding log shipping it would probably fit best
within .server (or possibly .setup). Then again, many knowledgeable people
hang out in all the sqlserver groups so you are probably going to get a hit
no matter where you post.
in the meantime, check out these links:
314515 INF: Frequently Asked Questions - SQL Server 2000 - Log Shipping
http://support.microsoft.com/?id=314515
323135 INF: Microsoft SQL Server 2000 - How to Set Up Log Shipping (White
Paper)
http://support.microsoft.com/?id=323135
325220 Support WebCast: Microsoft SQL Server 2000 Log Shipping
http://support.microsoft.com/?id=325220
821786 Support WebCast: Microsoft SQL Server 2000: Using Log Shipping
http://support.microsoft.com/?id=821786
321247 HOW TO: Configure Security for Log Shipping
http://support.microsoft.com/?id=321247
329133 INF: Troubleshooting SQL Server 2000 Log Shipping "Out of Sync"
Errors
http://support.microsoft.com/?id=329133
--
Keith
"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
news:2d08001c469c8$f0a55800$a501280a@.phx.gbl...
> Please create news group for Log Shipping|||Hi
I already checked the documents on microsoft web sites. i
have opened a new message and looking for some kind of
workaround on that problem.
Thanks
Mayur
>--Original Message--
>That is probably not going to happen. Microsoft has a
pretty clear purpose
>for each newsgroup, yet the newsgroups are broad enough
to make it easy to
>find what one is looking for without having to search
thousands of
>newsgroups for information.
>If you have a question regarding log shipping it would
probably fit best
>within .server (or possibly .setup). Then again, many
knowledgeable people
>hang out in all the sqlserver groups so you are probably
going to get a hit
>no matter where you post.
>in the meantime, check out these links:
>314515 INF: Frequently Asked Questions - SQL Server 2000 -
Log Shipping
>http://support.microsoft.com/?id=314515
>323135 INF: Microsoft SQL Server 2000 - How to Set Up Log
Shipping (White
>Paper)
>http://support.microsoft.com/?id=323135
>325220 Support WebCast: Microsoft SQL Server 2000 Log
Shipping
>http://support.microsoft.com/?id=325220
>821786 Support WebCast: Microsoft SQL Server 2000: Using
Log Shipping
>http://support.microsoft.com/?id=821786
>321247 HOW TO: Configure Security for Log Shipping
>http://support.microsoft.com/?id=321247
>329133 INF: Troubleshooting SQL Server 2000 Log
Shipping "Out of Sync"
>Errors
>http://support.microsoft.com/?id=329133
>--
>Keith
>
>"Mayur Dhondekar" <dmny2k@.hotmail.com> wrote in message
>news:2d08001c469c8$f0a55800$a501280a@.phx.gbl...
>> Please create news group for Log Shipping
>.
>
Tuesday, March 20, 2012
Planning for Disaster Recovery in second data center..
We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
Planning for Disaster Recovery in second data center..
We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Fre
e
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Lo
g
> shipping to have the data to the remote site. We are looking at RTO and RP
O
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event o
f
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on
a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SA
N
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does
it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live wit
h
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Fre
e
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Lo
g
> shipping to have the data to the remote site. We are looking at RTO and RP
O
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event o
f
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on
a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SA
N
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does
it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live wit
h
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
Planning for Disaster Recovery in second data center..
We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.
On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.
|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html
|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>
|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>
|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> Free
> Log
> RPO
> of
>
|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi
|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
>
>
|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
Planning for Disaster Recovery in second data center..
We are planning on using Database Mirroring internally within the data
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>> We are planning on using Database Mirroring internally within the data
>> center for HA and since its used, I am left now with log shipping or
>> possibly some SAN replication.
>> I think either one will work with log shipping being very affordable..
>> Free !!!
>> Does anyone see any pros to SAN replication as the strategy compared to
>> Log shipping to have the data to the remote site. We are looking at RTO
>> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in
>> the event of a disaster.
>>
>|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>> We are planning on using Database Mirroring internally within the data
>> center for HA and since its used, I am left now with log shipping or
>> possibly some SAN replication.
>> I think either one will work with log shipping being very affordable..
> Free
>> !!!
>> Does anyone see any pros to SAN replication as the strategy compared to
> Log
>> shipping to have the data to the remote site. We are looking at RTO and
> RPO
>> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
> of
>> a disaster.
>>
>|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> > The main difference between SAN mirroring and Database Mirroring/Log
> > Shipping has to do with which machines are left online at the DR site.
> >
> > By mirroring the SAN, you can mirror the entire Data Center only need to
> > keep the remote SAN turned on, no hosts.
> >
> > In Database Mirroring/Log Shipping, you have to have the remote site fully
> > operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> > etc.
> > And, you have to perform Database Mirroring/Log Shipping on a database per
> > database configuration. If you have an installation with, say, 50 or more
> > databases, it is going to be a real pain attempting to mirror or ship logs
> > for each of them.
> >
> > If you extrapolate this for the entire Data Center, you will see that
> > mirroring the disks to remote hosts is going to be more efficient,
> > administratively at least.
> >
> > Be careful though. SAN mirroring comes in at least 3 flavors:
> > Synchronous,
> > Asynchronous, and Snap Copy. Each has its purpose and potential
> > drawbacks.
> > You need to understand how each works.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > --
> >
> > "Hassan" <hassan@.hotmail.com> wrote in message
> > news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> >> We are planning on using Database Mirroring internally within the data
> >> center for HA and since its used, I am left now with log shipping or
> >> possibly some SAN replication.
> >>
> >> I think either one will work with log shipping being very affordable..
> > Free
> >> !!!
> >>
> >> Does anyone see any pros to SAN replication as the strategy compared to
> > Log
> >> shipping to have the data to the remote site. We are looking at RTO and
> > RPO
> >> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
> > of
> >> a disaster.
> >>
> >>
> >>
> >
> >
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
>> Hari,
>> If I use mirroring or Log shipping, why would one consider storage
>> replication like EMCs SRDF ?
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
center for HA and since its used, I am left now with log shipping or
possibly some SAN replication.
I think either one will work with log shipping being very affordable.. Free
!!!
Does anyone see any pros to SAN replication as the strategy compared to Log
shipping to have the data to the remote site. We are looking at RTO and RPO
of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
a disaster.On 3 Apr, 05:04, "Hassan" <has...@.hotmail.com> wrote:
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable.. Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to Log
> shipping to have the data to the remote site. We are looking at RTO and RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event of
> a disaster.
The replication is simpler, in the sense that you have one thing to
monitor, and in theory preferrable. We went for log shipping on the
basis that we were unsure about the burden of the extra data across
the network and some reservations about knowing the state of disk
writes to the data centre. Log shipping gives certainty in the sense
that the database is written to a known transaction at a known point,
even if it may not restore to the last possible moment before failure.
And as you say, it's cheap.|||Hello Hassan,
Better approach for high availability is create a cluster in local data
center for the production SQL Server machines and for disaster recovery site
use Mirroring/Replication or Logshipping.
To plan the disaster site you should do a capasity planning on data growth,
network bandwidth...
If you have enough budget you could take a look into options like EMC's
SRDF.
http://www.emc.com/products/networking/srdf.jsp
Thanks
Hari
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>|||"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
> Free !!!
> Does anyone see any pros to SAN replication as the strategy compared to
> Log shipping to have the data to the remote site. We are looking at RTO
> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in the
> event of a disaster.
>
>
Personally in a case like this, I'd probably go with log-shipping over SAN
replication.
It's cheaper. It's also easier to ensure a consistent transactional point
in time.
And you can run log-shipping "behind" by some fixed amount of time
(basically do't update unless log is older than X minutes.)
This can save you when someone says, "oops, I just deleted this data, can we
get it back?" As long as they let you know in time, it's fairly trivial.
Then when you have a real disaster just apply the more recent logs, and
voila, you're up to date.
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html|||Hari,
If I use mirroring or Log shipping, why would one consider storage
replication like EMCs SRDF ?
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23jtZWkedHHA.4624@.TK2MSFTNGP03.phx.gbl...
> Hello Hassan,
> Better approach for high availability is create a cluster in local data
> center for the production SQL Server machines and for disaster recovery
> site use Mirroring/Replication or Logshipping.
> To plan the disaster site you should do a capasity planning on data
> growth, network bandwidth...
> If you have enough budget you could take a look into options like EMC's
> SRDF.
> http://www.emc.com/products/networking/srdf.jsp
> Thanks
> Hari
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>> We are planning on using Database Mirroring internally within the data
>> center for HA and since its used, I am left now with log shipping or
>> possibly some SAN replication.
>> I think either one will work with log shipping being very affordable..
>> Free !!!
>> Does anyone see any pros to SAN replication as the strategy compared to
>> Log shipping to have the data to the remote site. We are looking at RTO
>> and RPO of maybe 30 mins of downtime and no loss of 30 mins of data in
>> the event of a disaster.
>>
>|||The main difference between SAN mirroring and Database Mirroring/Log
Shipping has to do with which machines are left online at the DR site.
By mirroring the SAN, you can mirror the entire Data Center only need to
keep the remote SAN turned on, no hosts.
In Database Mirroring/Log Shipping, you have to have the remote site fully
operational: Domain Controllers, network, DNS servers, SAN, etc., etc., etc.
And, you have to perform Database Mirroring/Log Shipping on a database per
database configuration. If you have an installation with, say, 50 or more
databases, it is going to be a real pain attempting to mirror or ship logs
for each of them.
If you extrapolate this for the entire Data Center, you will see that
mirroring the disks to remote hosts is going to be more efficient,
administratively at least.
Be careful though. SAN mirroring comes in at least 3 flavors: Synchronous,
Asynchronous, and Snap Copy. Each has its purpose and potential drawbacks.
You need to understand how each works.
Sincerely,
Anthony Thomas
"Hassan" <hassan@.hotmail.com> wrote in message
news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> We are planning on using Database Mirroring internally within the data
> center for HA and since its used, I am left now with log shipping or
> possibly some SAN replication.
> I think either one will work with log shipping being very affordable..
Free
> !!!
> Does anyone see any pros to SAN replication as the strategy compared to
Log
> shipping to have the data to the remote site. We are looking at RTO and
RPO
> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
of
> a disaster.
>
>|||We will most likely go with Asynchronous. What are drawbacks to that other
than latency ? Would there be integrity issues ? Are there chances that when
you bring the secondary site online, some databases may be corrupt ?
Does it impact the primary site while you setup Storage replication? Does it
impact performance on the primary ?
I am no SAN expert but have heard some SAN horror stories. Care to share ?
We will use the HDS Storage.
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> The main difference between SAN mirroring and Database Mirroring/Log
> Shipping has to do with which machines are left online at the DR site.
> By mirroring the SAN, you can mirror the entire Data Center only need to
> keep the remote SAN turned on, no hosts.
> In Database Mirroring/Log Shipping, you have to have the remote site fully
> operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> etc.
> And, you have to perform Database Mirroring/Log Shipping on a database per
> database configuration. If you have an installation with, say, 50 or more
> databases, it is going to be a real pain attempting to mirror or ship logs
> for each of them.
> If you extrapolate this for the entire Data Center, you will see that
> mirroring the disks to remote hosts is going to be more efficient,
> administratively at least.
> Be careful though. SAN mirroring comes in at least 3 flavors:
> Synchronous,
> Asynchronous, and Snap Copy. Each has its purpose and potential
> drawbacks.
> You need to understand how each works.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Hassan" <hassan@.hotmail.com> wrote in message
> news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
>> We are planning on using Database Mirroring internally within the data
>> center for HA and since its used, I am left now with log shipping or
>> possibly some SAN replication.
>> I think either one will work with log shipping being very affordable..
> Free
>> !!!
>> Does anyone see any pros to SAN replication as the strategy compared to
> Log
>> shipping to have the data to the remote site. We are looking at RTO and
> RPO
>> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
> of
>> a disaster.
>>
>|||"Hassan" wrote:
> Hari,
> If I use mirroring or Log shipping, why would one consider storage
> replication like EMCs SRDF ?
This has to be looked at from the whole data center infrastructure
perspective. If you are talking about a few machines and a few databases on a
single platform, sure use database mirroring or log shipping by all means.
But if you have a large data center with a lot of servers, a lot of
databases, and different platforms, setting up and maintaining database
mirroring or log shipping for each of the databases would be very
inconvenient. So because of the expenses, nobody would go out to buy a SAN
with SRDF just for a few databases. But if you already have a significant SAN
infrastructure in place, a SRDF-like technologies become very appealing to
consider because it is at the storage level and the DBAs are freed to
concentrate on the database issues.
Imagine if you only have a few houses in a place, having individual
generators to provide power probably makes sense. But if the place starts to
get populated, it may make more sense to get a power grid in and have the
power supply managed centrally by professionals.
Linchi|||"Hassan" wrote:
> Does it impact the primary site while you setup Storage replication? Does it
> impact performance on the primary ?
> I am no SAN expert but have heard some SAN horror stories. Care to share ?
There is a performance penalty with synchronous storage replication just
like there is a performance penalty with full-safety (or synchronous)
database mirroring. I/Os (or transaction records) have to travel across the
distance, and that has inherent delay. There is no free lunch. But the issue
is whether the performance impact is too severe for the app response
requirements. Current state of the art is that most of the apps can live with
the performance penalty. For a specific app, one has to evaluate it
specifically.
This is like buying storage. You don't always go out buying the fastest
storage. You buy least expensive storage that meets your all requirements.
Linchi
> We will use the HDS Storage.
> "Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
> news:OGX2AF4dHHA.4564@.TK2MSFTNGP03.phx.gbl...
> > The main difference between SAN mirroring and Database Mirroring/Log
> > Shipping has to do with which machines are left online at the DR site.
> >
> > By mirroring the SAN, you can mirror the entire Data Center only need to
> > keep the remote SAN turned on, no hosts.
> >
> > In Database Mirroring/Log Shipping, you have to have the remote site fully
> > operational: Domain Controllers, network, DNS servers, SAN, etc., etc.,
> > etc.
> > And, you have to perform Database Mirroring/Log Shipping on a database per
> > database configuration. If you have an installation with, say, 50 or more
> > databases, it is going to be a real pain attempting to mirror or ship logs
> > for each of them.
> >
> > If you extrapolate this for the entire Data Center, you will see that
> > mirroring the disks to remote hosts is going to be more efficient,
> > administratively at least.
> >
> > Be careful though. SAN mirroring comes in at least 3 flavors:
> > Synchronous,
> > Asynchronous, and Snap Copy. Each has its purpose and potential
> > drawbacks.
> > You need to understand how each works.
> >
> > Sincerely,
> >
> >
> > Anthony Thomas
> >
> >
> > --
> >
> > "Hassan" <hassan@.hotmail.com> wrote in message
> > news:OHXNjUadHHA.2332@.TK2MSFTNGP04.phx.gbl...
> >> We are planning on using Database Mirroring internally within the data
> >> center for HA and since its used, I am left now with log shipping or
> >> possibly some SAN replication.
> >>
> >> I think either one will work with log shipping being very affordable..
> > Free
> >> !!!
> >>
> >> Does anyone see any pros to SAN replication as the strategy compared to
> > Log
> >> shipping to have the data to the remote site. We are looking at RTO and
> > RPO
> >> of maybe 30 mins of downtime and no loss of 30 mins of data in the event
> > of
> >> a disaster.
> >>
> >>
> >>
> >
> >
>
>|||"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:FFC68E76-BF64-4C98-9A42-FA5A87A7E959@.microsoft.com...
> "Hassan" wrote:
>> Hari,
>> If I use mirroring or Log shipping, why would one consider storage
>> replication like EMCs SRDF ?
> This has to be looked at from the whole data center infrastructure
> perspective. If you are talking about a few machines and a few databases
> on a
> single platform, sure use database mirroring or log shipping by all means.
> But if you have a large data center with a lot of servers, a lot of
> databases, and different platforms, setting up and maintaining database
> mirroring or log shipping for each of the databases would be very
> inconvenient. So because of the expenses, nobody would go out to buy a SAN
> with SRDF just for a few databases. But if you already have a significant
> SAN
> infrastructure in place, a SRDF-like technologies become very appealing to
> consider because it is at the storage level and the DBAs are freed to
> concentrate on the database issues.
> Imagine if you only have a few houses in a place, having individual
> generators to provide power probably makes sense. But if the place starts
> to
> get populated, it may make more sense to get a power grid in and have the
> power supply managed centrally by professionals.
Thank you for the excellent analogy.
Russ Kaufmann
MVP - Windows Server - Clustering
ClusterHelp.com, a Microsoft Certified Gold Partner
Web http://www.clusterhelp.com
Blog http://msmvps.com/clusterhelp
The next ClusterHelp class is:
April 30, 2007 - Denver
Subscribe to:
Posts (Atom)