Backup and restore full and transaction log in nonrecovery mode failed due to LSN

Question

In SQL 2012 SP1 enterprise, when taking a full backup and followed up a transaction log backup immediately, the transaction log backup starts with an earlier LSN than the ending LSN of the full backup. As a result, I cannot restore
the transaction log backup after the full backup both as nonrecovery on another machine. I was trying to make the two machine in sync for mirroring purpose. An example is as follows.
full backup:       first 1121000022679500037, last 1121000022681200001
transaction log: first 1121000022679000001, last 1121000022682000001
--- SQL Scripts used  
BACKUP DATABASE xxx  TO DISK = xxx WITH FORMAT
go
backup log  xxx to disk = xxx
--- When restore, I tried the
restore log BarraOneArchive  from disk=xxx  WITH STOPATMARK  = 'lsn:1121000022682000001', NORECOVERY
Also tried StopBeforeMark, did not work either. Complained about the LSN too early to apply to the database

Answer 1

I think that what I am saying is correct .I said in sync mirroring ( i was not talking about witness) if network goes for few minutes or some longer time may be 20 mins ( more than that is reare scenario IS team has backup for that) logs on Principal will
continue to grow as they wont be able to commit because there connection with mirror is gone so commit from mirror is not coming.After network comes online Mirror will replay all logs and will soon try to come up with principal
Books Online says this: This is achieved by waiting to commit a transaction on the principal database, until the principal server receives a message from the mirror server stating that it has hardened the transaction's log to disk. That is,
if the remote server would go away in a way so that the primary does not notice, transactions would not commit and the primary would also be stalled.
In practice it does not work that way. When a timeout expires, the principal will consider the mirror to be gone, and Books Online says about this case
If the mirror server instance goes down, the principal server instance is unaffected and runs exposed (that is without mirroring the data). In this section, BOL does not discussion transaction logs, but it appear reasonable that the log records are
retained so that the mirror can resync once it is back.
In Async Mirroring Transaction log is sent to Mirror but it does not waits for Acknowledgement from mirror and commits the transaction.
But I would expect that the principal still gets acknowledgement that the log records have been consumed, or else your mirroring could start failing f you backup the log too frequently. That is, I would not expect any major difference between sync and async
mirroring in this regard. (Where it matters is when you fail over. With async mirroring, you are prepared to accept some data loss in case of a failover.)
These are theories that could be fairly easily tested if you have a mirroring environment set up in a lab, but I don't.
Erland Sommarskog, SQL Server MVP, [email protected]