Hello everyone,We have a SQL Server 2005 SP3 (9.0.4053) configured for transactional replication (Log Reader configured for continuous). The Publisher and Distributor are on the same server.We have a job that runs once per hour that drops and recreates a table that holds approx 160M rows of data. This table is [b]NOT[/b] a published table. With the database in FULL recovery model, the execution of this procedure causes the Log Reader Agent to halt. New commands are not generated and there are several messages in the "Publisher to Distributor History" tab saying "[i]The Log Reader Agent is scanning the transaction log for commands to be replicated. Approximately X {Where x is between 1,500,000 and 5,000,000} log records have been scanned in the pass #{n},{n} of which were marked for replication, elapsed time X {where X is well over 1,000,000,000} (ms)[/i]" This command runs for approximately 6 mins. During this execution and for 3-5 minutes afterward no transactions can be processed by the Publisher to Distributor process. A tracer token initiated at the start of execution will show a 6-17 minute latency under Publisher to Distributor and no transactions on published tables are committed at the subscribers for the same 6-17 minutes.When we change the recovery model to SIMPLE this halt of Log Reader is not encountered. Log Reader Agent continues to enter other transactions to the distributor (and subsequently to subscribers) and tracer tokens initiated at the start of execution with little to no latency (max total latency is 4 seconds). Why would the recovery model have this effect? From everything I've read on-line this is not the expected behavior and the recovery model should not have this type of impact. I know that in FULL recovery model the transaction log should be backed up frequently to avoid delays in Log Reader but this issue can be seen within 60 seconds of setting the recovery model from SIMPLE to FULL. This issue presents even when this job is only activity on the server. Any advice?I appreciate any guidence,Jason----------------------------------------------Also worth noting: This can be reproduced on this server with any table having a large number of records. During diagnostics we created a test table and filled it with all the rows from sys.objects until the table had over 150M rows. Then copied the data from this test table into another test table in the same manner as the problematic procedure [code="sql"]SELECT [columnlist] INTO TestTable2 FROM TestTable1[/code]Also tried creating the table in advance and executing an INSERT INTO instead of SELECT INTO[code="sql"]INSERT INTO TestTable2 (columnlist) SELECT (columnlist) FROM TestTable1[/code]During the execution the same behavior of halting replication was seen while in FULL recovery and resolved when in SIMPLE recovery.
↧