Background:
Pertinent Information:
System and user databases from live production machines were restored to virtual machines with identical Computer Names to those in the field (Format of {2-Letter state code}{2-Letter partner/pharmacy code}-{2 or 3-digit partner/pharmacy identifier}-{2-digit machine identifier} ).
These restoration appear to have been done with the KEEP REPLICATION option.
MSTDC session logs for these machines show sporadic attempts to contact and begin transactions with their distributors. It is not constant. Some of these virtual machines have Computer Names that do not match the local Server Name of MSSQLSERVER instance which they are ‘mimicking’. Some still do. The only log data that I could locate for these MSDTC sessions did not provide the contents of the transaction – successful or failed – so I do not know for certain whether any ‘mock’ data made its way to production, a cursory review of the SQL Server Queue Reader Agent logs from these time periods would indicate that it did not. “Spot” tests of attempting to locate test data in live production servers was also unsuccessful – but the test instances which seem to be the initial source of this problem are already overwritten. So, potentially apples and oranges. In the process of restoring a database from a computer swap, the log reader appears to have attempted to reinitialize all 103 articles for the subscription.
Investigation revealed that each publication now has five subscriptions – and the current facilities databases appear to be assigned the “most recent” of these subscriptions (the highest range of article_ids). Every article in the Publisher’s distribution database was marked as “queued for reinitialization”, this has been (ostensibly) corrected. However, for the most recent facility, the snapshot that the publisher wants to “push down” consists of only the data from the “most recent” set of articles – that is, they want to take all the data that’s there right now and replace it with data from April 16, 2014 10 AM to April 16, 2014 1 PM.
Checking the replication subsystems the repldata from the previous snapshot appears to be valid and in place already but I am having difficulty finding a way to tell it “You already have the data you need, just use that”.
Any thoughts on how we can recover from this situation?