>From (old) memory storage: Transaction replication records the transactions that were applied in the order that they a) were initiated, or b) completed
FULL Log shipping should include all accesses including failed ones and the actions of tables in the order they actually Happened rather than that in which the transactions were processed, and it should also log the actions of imbedded processes such as cascade deletes – or the failure of such action attempts. As well as the (sudden inexplicable) absence of such triggered processes. Considering the rebuilding of the DB – Hopefully there are the creation scripts that build tables from flat files, and the associated scripts to export the tables as flat files. Definitely worth keeping checked and available – if for nothing more than migration to a different DBMS. JimB From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Lundy Sent: Monday, August 11, 2014 3:12 PM To: [email protected] Subject: Re: [NTSysADM] Semi OT: SQL log shipping The client wanted log shipping basically because it is old, tried and true. They have limited DBA, so didn't want anything more complex (complex relative to their knowledge). On Sat, Aug 9, 2014 at 8:30 AM, Ken Schaefer <[email protected]> wrote: Whether you reseed all 100GB depends on your connection (how quickly you can replicate everything vs. how quickly you’re restoring your primary DB). Restoring your primary means you need to re-replicate everything. That said, do you need to use Log Shipping? It’s a pretty old technology, and depending on what your requirements are (and your SQL Server versions), there’s availability groups, mirroring, transactional replication etc. Cheers Ken From: [email protected] [mailto:[email protected]] On Behalf Of Kevin Lundy Sent: Saturday, 9 August 2014 7:35 AM To: [email protected] Subject: [NTSysADM] Semi OT: SQL log shipping Hi all, I'm (unfortunately) the DBA for a client. I'm only an accidental DBA. We are setting up log shipping for a soon to be critical database. All seems to be working fine. During the pre go-live testing, we will be refreshing the test data in the db several times. The database is about 100G. When we refresh (in other words I will be restoring the database), should we just let all 100 G replicate as transactions through the log shipping? Or break shipping, restore, reseed shipping? Or does it matter? Actually I think I'm just over analyzing, but would be interested in your thoughts.
