I am currently setting up log shipping for a client and have a question.
The process of setting up the log shipping is pretty straight forward but I do not see much information about failing over to that secondary server event of DR.
The secondary database is in Standby (Recovering). Do I simply restore the back up again?
Using Google or Bing to search the phrase "Microsoft SQL Server Log Shipping Failover" should give you some articles that would be helpful. One of them is called "Fail Over to a Log Shipping Secondary (SQL Server)" and another is "Change Roles Between Primary and Secondary Log Shipping Servers (SQL Server)". These provide detailed steps and considerations when performing the failover.
The very high-level idea is to:
1 - Perform any transaction log backups you can on the Primary database(s)
2 - Apply all available tran log backups (including the one from the step above) to the Secondary database(s)
3 - Make Secondary databases available
Your question of whether to "simply restore the back up again" may have been more geared to how to get Log Shipping started again when you've run into some issue. If the configuration is correct and you've resolved any outstanding issues, you should be able to restore a recent full database backup on the Secondary in NORECOVERY mode and it will begin applying the log backups from the Primary database again without further intervention. If going this route, it's best to perform a database backup of the Primary using the "WITH COPY_ONLY" clause so you don't introduce complications into your recovery chain. Using that clause tells SQL Server you just want to make a database backup "on the side" that you want to be able to toss away when you're finished.
Hope this helps.
Related
Have a production server and a report server.
What I have been reading is that the database on the report server has to be in a state where it can't be used.
Is there a way to have transaction log shipping while still allowing applications to query/create temp tables on the report server to generate reports or is there some other setup that can allow this?
MSSQL 2008 R2
You can do a "restore … with standby" on the secondary which will recover the database but allow the recovery to be undone. Keep in mind that no logs from log shipping can be applied until you unto the recovery.
If I had these requirements, I'd use something like transactional replication off of the primary to create an always readable secondary.
I am new to sql server .I have a sql server and I have 2nd sql server(backupserver).I want to copy data from sql server to 2nd one and all my transactions create update delete must be reflected in the 2nd server immediately in real time.I have very large data in my table assuming million of rows.How can I achieve this.I dont have previalge to use third party tools.
You specify that you need data to be reflected on the second server immediately, in real time.
This requirement will add latency to every transaction that occurs on your primary server, since every action will need to be committed on the secondary server before it can be committed on your primary server.
In addition to the latency, this requirement will also likely reduce your availability. If the secondary server is no longer able to successfully commit transactions from the primary, then the primary can no longer commit transactions either, and your system is down.
For more information about these constraints, refer to the extensive discussion around this topic(CAP theorem).
If you're OK with these restrictions, you might consider using Synchronous Database Mirroring (High-Safety Mode).
If you're not OK with these restrictions, please adjust / clarify your requirements.
You may try to get some help from these two references:
Replication in MS SQL Server
SQL Server Replication
On a side note an important thing you should need to plan before doing replication is the Replication model which you will use for your replication.
There is a list of Replication model which you can use:-
Peer-to-peer model
Central publisher model
Central publisher with remote distributor model
Central subscriber model
Publishing subscriber model
Each one of the above has its own advantages. Check them as per your need.
Also to add to it there are three types of Replication:-
Transactional replication
Merge replication
Snapshot replication
Check out this tutorial on SQL Server 2008 replication:
Tutorial: Replicating Data Between Continuously Connected Servers
Since you said "... reflected in the 2nd server immediately in real time", that means you want to use Transactional Replication. You still may only choose to replicate certain tables.
Does the "millions of rows" represent some kind of history? If so, consider the risks that Michael mentioned... and whether you need all the history in the 2nd server, or just current / recent activity. If it's just current/recent, it may be safer and less of a system drain, to write something in T-SQL or SSIS, for a job to execute that loops, reads, and copies the data.
That could be done with linked servers and triggers... but the risks Michael mentions, about preventing the primary server from committing transactions, are as much or more a concern with triggers... that you can avoid with your own T-SQL/SSIS + job.
Hope that helps...
By mistake I have updated data on production database. Is there any way to rollback those transactions.
I have executed the update statement from management studio and the script does not have in
Begin Trans/rollback/commit.
Thanks
Here is what I would do in this case:
Restore backup in separate database and compare these databases to recover rows that exist in backup?
If your database is in full recovery mode try reading transaction log to recover the remaining rows.
In order to read transaction log you can use a third party tool such as ApexSQL Log or try to do this yourself through fn_dblog function (here is an example but it’s quite complex).
Here are other posts on this topic:
Read the log file (*.LDF) in SQL Server 2008
How can I rollback an UPDATE query in SQL server 2005?
Without transaction (or indeed even with a committed transaction), there is no easy way to revert the changes made.
Transaction are mostly useful to ensure that a series of changes to the database are performed as a single unit, i.e. so that either all of these changes get performed [in the order prescribed] or that none of them get performed at all (or more precisely that the database server rolls-back whatever changes readily done would there be a problem before all changes are completed normaly).
Depending on the recovery model associated with your database, the SQL log file may be of help in one of two ways:
If you have a backup and if the log file was started right after this backup, the logfile may help "roll forward" the database to the point that preceded the unfortunate changes mentioned in the question. (aka point-in-time restore)
If no such backup is avaiable, the log file may be suitable to reverse the unfortunate changes
Both of these approaches imply that the SQL log was indeed maintained as some of the recovery models, are such that the log file get truncated (its data lost) after each successful batch/transaction. And neither of these approaches is easy, the latter in particular probably require third party software (or a lenghty procedure) etc.
Depending on how your backups are set up, you may be able to do a point in time restore. Talk to your DBA. You may also want to take the DB offline ASAP to prevent more changes that would eventually be lost when you do the restore.
We have set up a logshipping scenairo on 2 Sql Server 2005 machines. The secondary database is in STANDBY mode.
We want to use this secondary server for reporting purposes, as the report viewers will query this STANDBY database according to their given execute rights. So we need multiple users on this secondary server, having different execute rights on the STANDBY database.
The problem is, after seting up log shipping, we can't grant the necessary permissions to the standby database as it is read-only.
Do you have any suggestions ?
Thanks,
Umut
For some reason, till we setup a better reporting system, we need to use the Standby server for reporting purposes.
And there is a way to create new users and give necessary sp execute rights to that user on the standby server.
The simple solution is, to create a login on the primary server and Select its SID from master table. Then with "sp_addlogin" create the same login with the same SID on the Standby database.
Then, on the primary server give required rights to the user on the database. With the restored transaction logs, the execute rights will ship to standby server. Passwords don't need to be the same on two servers, so the standby report viewer user can't access the primary server with the same credentials.
Sadly, you need to look into something other than log shipping.
Log shipping works by keeping up-to-date copies of your logs in a 'continually' restoring/recovery state on the secondary server. As such, the database there is never actually 'active' or live - as it's always just applying more and more logs and waiting for the command that will make it go active.
In other words, log shipping is ONLY for high-availability - it does NOT support duplication of your data in USABLE form.
To learn more about what purpose logging serves, check out this video:
http://www.sqlservervideos.com/video/logging-essentials/
And if you really need a secondary server for reporting purposes, then I'd suggest using something like transactional replication. (It's NOT suitable for high-availability solutions because of some of the schema changes and limitations you'd have to make... but it does work well as a way to 'publish' multiple copies of your database to different servers/locations for reporting purposes.)
I'm interested in hearing people's thoughts about the pros and cons of database mirroring vs. log shipping in this scenario: we need to setup a database backup situation wherein there is exactly one secondary server that need not automatically pick up when the primary fails. Recovering and starting with the secondary should not have to take too long though.
Mirroring
Database mirroring is limited to only two servers.
Mirroring with a Witness Server allows for High Availability and automatic fail over.
You can configure your DSN string to have both mirrored servers in it so that when they switch you notice nothing.
While mirrored, your Mirrored Database cannot be accessed. It is in Synchronizing/Restoring mode.
Mirroring with SQL Server 2005 standard edition is not good for load balancing (see sentence above)
Log Shipping
You can log ship to multiple servers.
Log shipping is only as current as how often the job runs. If you ship logs every 15 minutes, the secondary server could be as far as 15 minutes. Making it more of a Warm Standby.
You can leave the database in read only mode while it is being updated. Good for reporting servers.
Good for disaster recovery
For backup purposes I would recommend Mirroring: it keeps an always up-to-date copy of your database with no hassle.. If you don't need automatic fail-over you need just two servers/instances. Note that High Performance mode is only available in the Enterprice (sp) edition!
Switching to the secondary database does take longer with log shipping, but it's not too bad. You'll have to manually copy any uncopied backup files, apply the transaction log backups to the secondary database, recover the secondary database, and change its role to primary. If the old primary databases accessible, you should back up its transaction log before beginning. Failing over with mirroring is somewhat simpler, and can be done automatically if you are using High Availability mode. Even when using High Performance mode, it's still a one statement operation.