In our environment on log shipping is configured but there are some jobs in primary servers the jobs are with SSIS packages with dependency on some files/folders also. Now how can I move the jobs to secondary server so that it can be enabled in time of DR replication.
we have about 4 different SQL Servers (sql 2000 standard) where each server has about 7 databases. We wanted to have a disaster recovery plan where there will be a single sql2000 standard server as a standby server. we wanted to have all other sqlserver databases (about 7x4) replicated or logshipped to the remote standby server.
We thought about to have all the databases logshipped to the standby server. But since the sql server we have are Standard servers, we thought about using Simple Logshipping tool in the resource kit.
Each server databases are having full backup in the morining and there will be transaction log backup every hour. and then it will be overwritten on the following morings full backup and then the transaction log.
1) the problem we have now is if we go with the Stand by server, we need to modify the daily backup plan to have just one full backup and then the incremental transaction log backup(otherwise standby won't be syncronized). we need to have the backups done as per the backup plan we currently have. Can you please advice me on how can we achive this?
2) If you think the replication is the better one, please direct me on which replication is best and can you also please advice me if we do replication how hard it is to administer replication as well as other adminitration task???
I am little bit hesistant to go with replication as it might create more problem when there is any other problems. (Note: these servers are all Prductions servers)
As a finger in the air generalisation would log shipping or replication provide the least impact on a network?
We are moving some servers from our local LAN to a remote location on the other side of an MPLS cloud (anyone understand those network guys?!) and the replication that is currently running will need to move or be replaced. Obviously this traffic is going to have to fit in amongst the general office to internet traffic now where previously it was only on the LAN so we want to reduce the traffic as much as possible.
Many thanks for any thoughts that you might have ...
Are there any articles on the pro's and con's for creating a warm stand-by using log shipping vs. replication? Other than the obvious latency issues, is one better than the other?
I recently devised a way to implement Log Shipping on my standby server. It presently working well. We are however a 24x7 shop, and since we backup nightly, we have about a 5 hour window of vulnerabilty (2 hours backup of Prod, followed by about 3 hours Restore on Standby - then apply logs every hour) It has been suggested to only back up once weekly, but that makes me very uncomfortable, even though we have to standby up to date. Now, the debate is whether Replication for a standby is a better method. I'm not so sure. Isn't it really more for distributed data, OLAP, etc, rather than a reliable method of disaster recovery? And also, doesn't replication have more overhead cost on the server than log shipping (even if dist db is remote) Seems to me there is more chance and places of failure with REPL than LOG SHIPPING. Any experience or input is greatly appreciated. Thank you.
We are researching various ways to create an offsite disaster recovery solution. We are talking about either Transactional Replication or Log Shipping. Which would you use?
Using: SQL2000
Down time max of 4 hours.
My concerns are once a failure occurs and we are running production at the offsite facility how quickly could we get back to the primary cluster?
We currently have a production box that log ships several databases to multiple servers. One of these servers acts as our "reporting" server. One of the things that I'm not satisfied with is the fact that if we need to make a change to any underlying stored procedure that is used for reporting, we need to deploy that stored procedure to our production database and then wait for it to be log shipped to our reporting server.
Because of this, we have a ton of stored procedures in production that are never actually used for production.
I'd like to implement replication to get data from production to our reporting box. This way we can update stored procedures as necessary.
Is anyone aware of any gotch's / caveats / issues with having replication and log shipping configured on the same "publisher"? Also, if I recall correctly, now with SQL2K5, any DDL is automatically replicated to any and all subscribers...
I need to implement a dirt cheap replication method for some dirtcheap servers. We are using the SQL Server workgroup license. Isthere anything in this that prevents using log shipping forreplication in Workgroup versus Enterprise?ThanksTravis
Can anybody tell me the differences, advantages and disadvantages between these three solutions? When do I may use one or another? Could you recommend me any documentation?
I need to move my database servers from one location to another. The issue is that I have over 200 databases to move and my clients can't afford a downtime. The collective volume of all the databases is over 2.5 TB and growing.
I am thinking to copy these databases in batches over the WAN to the new location and replicate them using Transactional replication till I have all the databases moved and synchronized.
Will it be wise enough to use replication for synchronizing 200 databases or is there a better approach which I can use to move these databases with minimum downtime and compromise on performance of applications.
Note: Migration is from SQL Server 2000 to SQL Server 2005.
I need to move my database servers from one location to another. The issue is that I have over 200 databases to move and my clients can't afford a downtime. The collective volume of all the databases is over 2.5 TB and growing.
I am thinking to copy these databases in batches over the WAN to the new location and replicate them using Transactional replication till I have all the databases moved and synchronized.
Will it be wise enough to use replication for synchronizing 200 databases or is there a better approach which I can use to move these databases with minimum downtime and compromise on performance of applications.
Note: Migration is from SQL Server 2000 to SQL Server 2005.
I am having trouble finding any documentation on how linked servers are set-up under SQL 2005 for log-shipping and replication. Under SQL 2000, the only linked servers "visible" were ones that were user-defined. Under SQL 2005, it seems when you set-up log-shipping or replication, you get these new linked servers which are automatically defined. I would like to understand them and in particular, how security is maintained. We recently had a production issue where after some problem with a server which resulted in having to restart SQL Server, and shrink msdb, log-shipping started to fail authentication when trying to run alert jobs. Only after rebooting the server, and also the log-ship target server, and waiting 9 hours, did the authentication correct itself. I would like to know how it resolved itself and what took so long?
Up to now we have gotten by without having any local DR copies of servers (if a sql server goes down we are usually able to get it back in less than 3 hours). But I want more now. I want to trim the "down" window to no more than 5 or 10 minutes. (Immedate failover would be nice but is not an essential requirement. The essential requirement is to loose no data!)
I have a spec of knowledge in these areas:
SQL 2005 Clustering (requires approved hardware, quorum disk, etc. involved)
SQL 2005 Replicaiton
SQL 2005 Log Shipping.
SQL 2005 Database mirroring. ( needs three servers)
Which approach do you think is the most straightforward, sparing of hardware, yet reliable way to get us back up and running after a sql server failure.
I want to move table from one database to another database in same instance, table should migrated with complete data,with same column data type, all constraints like PK,FK unique key, check, identity, permissions has to be there.. which is the right way to achieve this.
My company is moving to a SQL Server-based packaged application early next year. We€™re planning our SQL Server architecture but have some questions that I can€™t readily find answers for. I€™m hoping someone here can point me in the right direction.
We have three servers, I€™ll call them A, B, and C. We want to duplicate all changes to certain databases on server A to server B, then duplicate changes to selected databases and tables on server B to server C.
Ideally we€™d run SQL Server 2005 Enterprise Edition on all three servers, but the packaged application vendor does not support SQL Server 2005 yet, only SQL Server 2000. Our license agreement with them does not allow us to use replication on server A. We€™re free to do whatever we want on our other SQL Servers, but server A must sit alone, untouched, like a monolith on a far-away moon. (I€™m lobbying to have the server named Tycho, or TMA2.) Stranger still, they€™re OK with log shipping from server A to other servers. We€™ve tried to explain that replication and log shipping are both core function built into SQL Server, and that if one is acceptable, then both should be. Their fear is that replication could cause performance and stability problems, and to eliminate this possibility they€™re ruling out replication on server A.
Given these constraints we€™re resigned to using SQL Server 2000 Enterprise Edition on servers A and B, and SQL Server 2005 Enterprise Edition on server C. We plan on periodically shipping logs from server A to server B and applying them at server B.
We€™d like to know if it is possible to also use transactional replication on server B to duplicate changes from server B to server C. I€™ve used log shipping and replication in the past, but never at the same time. My understanding is that a database goes into recovery mode while a transaction log is being applied and that any user changes to the database after the log has been applied will cause later log applications to fail. The scripts I€™ve seen that are used to apply the transaction logs put the database into single user mode after the log has been applied to prevent this.
This raises a few questions:
If we try to RESTORE a log to a database being used as a source for transactional replication articles, will the RESTORE fail? Or will the RESTORE start and break the transactional replication? I€™ll test this on my own, but it€™d be nice to know if anyone has already experienced this.
Is it possible for us to have a database in read-only mode serve as the source for transactional replication articles? (I can€™t imagine why not, ever though it seems counter-intuitive - why would you want to replicate transactions from a database that has no transactions?)
If the answer to number two is yes, can we suspend transactional replication on a database, RESTORE a log to the database, put the database into read-only mode after the RESTORE, and restart the replication on the database? Thanks in advance for sharing your wisdom, everyone!
We are going away from a 2003 Windows Server OS with SQL Server 2008 R2 to a 2012 Windows Server with 2012 SQL Server. Both the distributor and subscriber resides on 2003 Windows Server and the focus will be to migrate those databases to the 2012 SQL Server.
 We would also like to avoid sending down a new snapshot due to logic in the replication process (major headache to clean up data).  what's the best approach in moving the distributor and subscriber databases without having to run a snapshot? Â
In theory and needs testing:
1. Work with business users to get downtime
2. Stop sql apply so no new changes are going to the Oracle publisher database
3. Remove subscription, publication and distributor from current replication
4. Oracle DBA to clear out replication related objects - fresh clean slate
5. Use log shipping to apply last t-log and restore db with Keep_Replication
6. Set up new distribution, publication (keep existing object unchanged), and subscriber (without initialization) Will this work?
I could not able to find Forums in regards to 'Log Shipping' thats why posting this question in here. Appriciate if someone can provide me answers depends on their experience.
Can we switch database recovery model when log shipping is turned on ?
We want to switch from Full Recovery to Bulk Logged Recovery to make sure Bulk Insert operations during the after hours load process will have some performance gain.
I 'm sure I am missing something obvious, hopefully someone could point it out. After a failover log shipping, I want to fail back to my inital Primary server database; however, my database is marked as loading. How can I mark it as normal?
I did the failover as follow:
I did a failover log shipping from the 2 server Sv1 (Primary) and Sv2 (Secondary) by doing the following
1) Stop the primary database by using sp_change_primary_role (Sv1)
2) Change the 2nd server to primary server by running sp_change_secondary_role (Sv2)
3) Change the monitor role by running sp-change_monitor_role (Sv2)
4) Resolve the log ins - (Sv2)
5) Now I want to fail back - I copy the TRN files to Sv1 - use SQL Ent to restore the database at point in time. The task is done; however, the database is still mark as loading. I could not use sp_dboption.
I need to create a RO copy of a production DB owned by an outside company. We are connectd via a WAN link, but cannot use replication. They are proposing using an initial load via tape, and sending us a text file nightly with the days changes to the DB. We will then need to load that data using BCP, DTS or some other method. Does any one have any ideas on using log shipping instead of the text file. It would only be practical to get a fresh load of the entire DB once a quarter or once a month at most. It is a 40+ GB database and we are expecting 100 to 200 MB of logs per night. For business reasons, we are limited to some type of file transfer mechanism for the data transfer, and cannot really change their backup schedule which is nightly fullbackups and tlogs every 30 minutes.
I am using SQL 2k EP Editions with SP2 on Win 2k Advance servers. Since more than week or so I am trying to establish log shipping between two servers. But its not working.
I am using database maintainence plan wizard to set up log shipping. Every thing works fine as far as wizard is concern, it creats plan for log shipping. But my log shipping is not working. The plan to back up log on source database is working fine. I can see the job history and the log files in the backup folder. But I have found that the job on the standby server to copy log file on network folder is failing and so the job to restore log on stand by server. I get the following message
"sqlmaint.exe failed with error state....."
Little reaserch on the standby server found that sql server is using maintainence plan to copy and restore log files, but i do not see any database maintainence plans on standby server as well as I have checked that there is no plan id in sysjobs table on either server.
I have sa rights. The account used by sql service and sql agent have admin rights and they do have rights to access the network folder for both the servers. So there is no rights problem.
I have followed all steps published in white paper for setting up log shipping on microsoft web site.
I have searched microsoft KB but it is of no use for sqlmaint.exe.
This might end up being fairly lengthy...I'm in the midst of implementing log shipping as a "warm stand-by" solution at my company. All the components appear to be in place: I'm using cmd shell to copy the backup device file to a remote server and then execute a RESTORE stored procedure on the remote server. The copy and restore work just fine. The problem I'm having is with the transaction log dumps and restores. We normally dump transaction logs (and then truncate) every hour. With the log shipping being implemented, we're going to want to do separate log dumps every ten or fifteen minutes, copy that dump over to the remote server, and then apply that log to the database. Here's the question: for the log ship portion, I don't truncate the log. But after the "normal" log dump occurs, things get tossed out of whack. When you try to apply a log, I get the message "database has not been rolled forward enough....". Has anyone encountered this type of issue and if so, how did you work around it? I'm assuming it's a simple of issue of certain options you set on your dumps and scheduling.... I'd appreciate any help.... Thanks!!!
We are considering implementing log shipping. Do the sql server logs keep track of the logs that are shipped and applied through log shipping? Or is there some other way to make sure that all logs have been shipped and applied?
I have been successful in getting log shipping working but still have some nagging questions that I cannot find answers to.
1. I had a situation where the copy for one TranLog took much longer than the 15 minute interval I have it setup for. It seemed to get stuck on that copy. Is that how it is supposed to behave.
2. Related to the question above, weekly, I have jobs that reorganize, check integity, recalc statistics. Would these jobs create very large log files? If so, how do others deal with this?
3. Is there any documents available that discuss testing converting your secondary server/database to your primary and back again?
4. Is there a way to setup Email notification to report out-of-sync conditions?
While configuring log shipping, if i choose the "allow database to assume primary role" then the "ceate and initialise new database " option is selected by default..Does this happen all the time or am i missing something.What if i have already initialised the destination database.
I am testing my log - shipping strategy. I have tried with northwind database and it was successfully created and is operating. However in order to test I have created a new Test Table in the primary database to see whether it is working. From now on database shows that it has been loading and I cannot see any tables it is grayed and it says loading. What would be the problem? When I checked the logs it has been copying to the secondary database and it doesn't show any error in the log-shipping monitor. It seem everything is cool accept this loading part. If some one help me I really appreciate it.
I am using SQL 2k EP Editions with SP2 on Win 2k Advance servers. Since more than week or so I am trying to establish log shipping between two servers. But its not working.
I am using database maintainence plan wizard to set up log shipping. Every thing works fine as far as wizard is concern, it creats plan for log shipping. But my log shipping is not working. The plan to back up log on source database is working fine. I can see the job history and the log files in the backup folder. But I have found that the job on the standby server to copy log file on network folder is failing and so the job to restore log on stand by server. I get the following message
"sqlmaint.exe failed with error state....."
Little reaserch on the standby server found that sql server is using maintainence plan to copy and restore log files, but i do not see any database maintainence plans on standby server as well as I have checked that there is no plan id in sysjobs table on either server.
I have sa rights. The account used by sql service and sql agent have admin rights and they do have rights to access the network folder for both the servers. So there is no rights problem.
I have followed all steps published in white paper for setting up log shipping on microsoft web site.
I have searched microsoft KB but it is of no use for sqlmaint.exe.
I failed to configure the Logshipping in SQLServer2000, through database maintenance plan wizard, at last step I got the following error.
Microsoft SQL-DMO(ODBC SQLState:42000) Error 50007:xp_repl_encrypt:Error executing srv_paramsetoutput
I am running SQLServer2000 Enterprise Edition with Servicepack2, and Windows2000AdvancedServer with Servicepack2 on both machines and bothe machines are in the domain, both SQLServerservices are running under Domain account.
Is there any effect on taking full backups on Primary Server while log Shipping is in place? If we take a full backup is that applied to the secondary server?