There is always a balance. You can get close to zero data loss with the right restore strategy and none of this additional technology - which are more geared to HA than DR. I've stopped calling this a backup strategy, because the key takeaway from any such plan is that you need to test that you can restore your backups, not just that they're running successfully.
Since you can afford a day of downtime, you can take your time retrieving your full and log backups from wherever you store them and restoring them on a new server. With FULL recovery, and taking a log backup every 5 minutes, you should be able to guarantee that you will never lose more than 5 minutes of data (unless, of course, you backup to the local disk and the disk explodes - best practice is to get your backups as far away from the primary server as possible, as soon as possible). You can tighten that window up to three minutes, two minutes, one minute, etc., but backing up the log too frequently can cause a few ripple effects - most notably on your I/O subsystem, your SQL Server Agent history, and of course the complexity of restoring to point-in-time.
I also wouldn't be afraid to use mirroring in addition to a proper backup/restore methodology (but certainly not instead of), to get you as close to zero data loss as possible. Just because it's deprecated doesn't mean you have to worry about it being unavailable "soon." Deprecation announcements are typically three releases out... plenty of time in 6-9 years to come up with an alternative, even if you are staying on top of every new release, which most people don't, and even if this application is still in service, which it may not be. There are a lot of folks still running 2000 and 2005; do you think they're worried about deprecated or discontinued features in current versions?
Besides, Microsoft will most certainly have had to come up with an alternative for Standard / BI Edition customers by the time they actually remove mirroring from the product. I know they have been told loud and clear, from the moment they announced this deprecation, that they need to have a contingency plan for non-Enterprise customers. My guess, with absolutely no internal knowledge on the subject, is that at some point they will introduce some extremely limited form of Availability Groups to Standard Edition, much like they did with backup compression in 2008 R2, which was previously only available in Enterprise.
If anyone wants to increase the column width of the replicated table in SQL Server 2008, then no need to change the property of replicate_ddl=1
. Simply follow the steps as given.
- Open SSMS
- Connect to Publisher database
run command
ALTER TABLE [Table_Name] ALTER COLUMN [Column_Name] varchar(22)
- It will increase the column width from varchar(x) to varchar(22) and same change you can see on subscriber (transaction got replicated). So no need to re-initialize the replication
Hope this will help all who are looking for it.
Best Answer
Typically you would get an error message and the operation would be prevented, e.g.
However, as explained in https://blog.sqlauthority.com/2015/02/14/sql-server-msg-8152-level-16-state-14-string-or-binary-data-would-be-truncated/ that error message isn't produced after the command
SET ANSI_WARNINGS OFF
.You could have applied the command to the wrong table or column.
You could have mistaken the column sizes e.g. originally nvarchar(2555) or now nvarchar(51). Or maybe there had already been an undocumented change in the production database to make the column width 600 characters - or maybe "max" - so, again, you'd be reducing it. But you should get the error message and the change wouldn't happen.
You could have blocked someone else's transaction storing new data to the table - although I think making a varchar column longer may not even require altering the data pages. The actual storage wouldn't change. But - I don't know - SQL Server may check all of the data anyway for any ALTER TABLE ALTER COLUMN command.