﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 2008 / SQL Server 2008 High Availability  / High availability best practice? / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Sun, 26 May 2013 01:41:15 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>No it doesn't break the log chain. A full backup contains only enough transaction log necessary to be able to restore that database to a transactionally consistent time - the time at which the data reading portion of the full backup completed.Paul has explained this very clearly in his blog.Read the gail link above. Regards,RamaSankar,MCTS,MCITP Sql Server 2008.</description><pubDate>Wed, 12 Dec 2012 00:54:58 GMT</pubDate><dc:creator>sankar276</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>It was set up as high performance, I dont have a spare server to act as a witness at the moment . It does document management and everytime there was intense file movement and sql activity the mirror would be suspended and never be able to re-sync. The application is not mirror aware so any failover would be manual, log shipping seems the to be the path of least resistance at the moment. According to the vendor the latest version is SQL2012 compliant and mirror aware so maybe next year :-) I shall be revisiting the mirror options</description><pubDate>Mon, 10 Dec 2012 02:59:24 GMT</pubDate><dc:creator>Martin Stephenson</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>[quote][b]Martin Stephenson (12/6/2012)[/b][hr]Mirroring disconnects everytime I put the server under heavy load.[/quote]Are you setting it up as asynchronous(high-performance)?</description><pubDate>Fri, 07 Dec 2012 14:01:20 GMT</pubDate><dc:creator>scogeb</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>[quote][b]Martin Stephenson (12/6/2012)[/b][hr]If I set up log shipping, the translogs are applied to the target database, if the source gets a new full backup, doesnt that break the log chain for transaction log backups and therefore stop you applying it to the target database?[/quote]No, what it does do is to reset the differential backup chain by incrementing the differential base LSN.</description><pubDate>Fri, 07 Dec 2012 04:04:05 GMT</pubDate><dc:creator>Perry Whittle</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>I you have SANS from the same company at each site, you can do SAN replication and relieve SQL Server a bit.  That'll also work for non-SQL Server files, as well.</description><pubDate>Thu, 06 Dec 2012 23:54:21 GMT</pubDate><dc:creator>Jeff Moden</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>The only time you need to send your full to secondary is if you need a reinit. Otherwise take your fulls nightly and store locally, tran log baks will never be interrupted to secondary.Frequently take log baks, every 15min, watch sizes, e.g. during maint when we rebuild indexes those logs get big and latency backs up just a bit so this process is managed closely. Regards,Chrismssqlconsulting.com</description><pubDate>Thu, 06 Dec 2012 14:06:29 GMT</pubDate><dc:creator>Chris Becker</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>In that case I'll just go and get it setup then :-)</description><pubDate>Thu, 06 Dec 2012 10:17:25 GMT</pubDate><dc:creator>Martin Stephenson</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>[quote][b]Martin Stephenson (12/6/2012)[/b][hr]if the source gets a new full backup, doesnt that break the log chain for transaction log backups and therefore stop you applying it to the target database?[/quote]No.[url]http://www.sqlskills.com/blogs/paul/post/Misconceptions-around-the-log-and-log-backups-how-to-convince-yourself.aspx[/url]</description><pubDate>Thu, 06 Dec 2012 09:43:30 GMT</pubDate><dc:creator>GilaMonster</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>If I set up log shipping, the translogs are applied to the target database, if the source gets a new full backup, doesnt that break the log chain for transaction log backups and therefore stop you applying it to the target database?</description><pubDate>Thu, 06 Dec 2012 09:14:43 GMT</pubDate><dc:creator>Martin Stephenson</dc:creator></item><item><title>RE: High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>[quote][b]Martin Stephenson (12/6/2012)[/b][hr]Log shipping seems to be ok but I dont like being left with huge numbers of TRN files and no regular BAK files.[/quote]Log shipping does not remove the need for full backups. You need regular full backups, not for the log shipping, but for normal recovery strategies. In the case of a disaster or accidental delete, you absolutely do not want to be restoring a full backup then months of log backups.[quote] I have scripted a set of daily bak and trn routines that i can schedule to build fresh copy every day but this leaves me humping 90Gb across a WAN link everyday, which makes the Infrastructure team a little cross.[/quote]Why do you need to copy all 90 GB every day? Are you doing something odd like switching to simple recovery model before taking backups?</description><pubDate>Thu, 06 Dec 2012 09:09:39 GMT</pubDate><dc:creator>GilaMonster</dc:creator></item><item><title>High availability best practice?</title><link>http://www.sqlservercentral.com/Forums/Topic1393576-1549-1.aspx</link><description>I have a vendor supplied database driven application, I need to place a copy in another city for DR purposes, replication doesnt work because the around 30% of the tables do not have primary keys and I can't change the table schemas in case the app falls over, Mirroring disconnects everytime I put the server under heavy load. Log shipping seems to be ok but I dont like being left with huge numbers of TRN files and no regular BAK files. I have scripted a set of daily bak and trn routines that i can schedule to build fresh copy every day but this leaves me humping 90Gb across a WAN link everyday, which makes the Infrastructure team a little cross.What other options have I got and what do other people do? I am expected to provide failover to within an hour or so if it all goes wrong</description><pubDate>Thu, 06 Dec 2012 08:51:55 GMT</pubDate><dc:creator>Martin Stephenson</dc:creator></item></channel></rss>