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.
Related
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.
I have a SQL Server 2012 database which currently used as a transactional database and reporting database. The application reads/writes into the same database and the reports are also generated against the same database.
Due to some performance issue, I have decided to maintain the two copies of the database. One will be a transactional database which will be accessed by the application. The other database will be the exact copy of the transactional database and it will only be used by the reporting service.
Following are the requirements:
The reporting database should be synched with transactional database in every one hour. That is, the reporting database can have stale data for maximum of 1 hour.
It must be read-only database.
The main intension is NOT recovery or availability.
I am not sure which strategy, transactional log shipping, mirroring or replication, will be best suited in my case. Also if I do the synch operation more frequently (say in every 10 minutes), will there be any impact on the transactional database or the reporting service?
Thanks
I strongly recommend you to use a standby database in readonly state. And every 15 minutes your sqlserveragent has a scheduled job to: a) generate a new .trn logfile within main db, and b) restore it into standby one(your reports db). The only issue is: using this technique your session will be disconnected while agent restores the .trn logfile. But if you can stop the restore job, run your reports and then reactivate it, there is no problem. Seems to be exactly what you need. Or if your reports are fast to run, probably will not be disconnected...if im not wrong restore job can also be configured to wait opened session to finish or to close it. I can check it this last doubt for you tomorrow if you don't find..
Once it is running in the same sql server instance, you don't have to worry about extra licensing...
We have a client that currently has a large busy database that they back up using database mirroring. As part of a reporting requirement we need to use some of the data stored in the database to run reports against but we cannot access the data directly.
Is it possible for us to run transaction replication on that server to get our data while it is running database mirroring at the same time?
Thanks.
Yes it's possible to run transaction log shipping at the same time you are running mirroring. It is also possible to bring the secondary server up in a "Read Only" mode rather than "Standby" for the specific purpose of allowing you to run reports on the second server.
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.