create barcode using c# Script Log Shipping in Visual C#.NET

Print EAN / UCC - 13 in Visual C#.NET Script Log Shipping

Log shipping also has the flexibility of scripting. All jobs that are run through the GUI can be generated into SQL scripts. This can help with standardizing deployments by ensuring that exactly the same script is run on all servers. When configuring log shipping, simply

27

click the Script Configuration button, and then choose where to script it to. You can select to script it to the clipboard, a new query window, or to a file.

Database mirroring and log shipping are two different technologies that can be deployed independently or together to mutually complement each other. The primary reason for using both technologies at the same time is the limitation that only one mirror server is definable per database. Hence, if your high availability strategy is in need of multiple standby databases for extra resiliency in your landscape, then you will need log shipping deployed, too. Additionally, log shipping gives you the ability to control the latency when applying a transaction log in log shipping, which cannot be controlled with mirroring. A typical landscape for this configuration can be seen in Figure 27-13. On the left, the landscape is up and running properly. On the right, the principal has failed, and the mirror has become the new principal and is now the log shipping.

Arguably the most important concept that is often not performed is practice recoveries. Many times DBAs configure log shipping but don t actually test it. For example, you recover the database but do not have the user logins to sync, or the sync script does not work as expected. Now, you have a database, but users cannot log into it. Or, as in the above not just a database, the failover is a bit more sophisticated. A secondary database is converted to a primary database and then is repointed to another secondary database. This is not difficult, but it needs to be documented and tested thoroughly. The bottom line is that at least once a year, if not more frequently, recoveries should be tested.

In a very indirect way, log shipping tests the validity of your transaction log files. For example, if you cannot restore a transaction log file in log shipping, chances are good that the file was corrupted, perhaps via a controller error or a bad block on the disk. Needless to say, this provides an early warning mechanism that it s time to do a full backup of your primary database due to the breaking of the log chain. Please note that this is not a substitute for testing your backups. SQL Server s development team mantra is You are only as good as your last restore. They will not guarantee future restores. The simple reason is that backup media can go bad. In addition, tapes should be rotated and tested. This is covered in detail in 14, Backup Fundamentals, and 15, Restoring Data.

You can log ship a corrupted database. I have experienced a customer who had a very robust high availability solution which included clustering and log shipping to two remote sites and a SAN with triple mirroring. The problem was that the SAN firmware corrupted the database and log shipped the corruption to the remote locations. Additionally, they also backed up the corruption onto tape and overwrote their last good backup. The only element missing in their solution was running DBCC CHECKDB on their database, which would have caught the issue. Log shipping and mirroring do not protect you against such failures. A RESTORE command does not check the validity of the data structures on the restored pages.