@Alan Please check once by disabling the audit.
That server has an AUDIT on a database. If the audit is enabled, you
will get that error. If you disable the audit,query will run fine.
We are doing log backups on the principal database, and my question is what are the gotchas with doing a log backup on a mirror?
You can't do a log backup on the mirror database.
At least one full database backup from the mirror has to be completed before doing a log backup, in that case are there special options that need to be used because it is a mirror?
You can't do a full database backup on the mirror database either.
Take this for instance: I have Server1
which houses the principal database AdventureWorks2012
, and I have Server2
which contains the mirror. Here's what happens when I try to run backups on the mirror database (on Server2
):
use master;
go
backup database AdventureWorks2012
to disk = 'c:\sqlserver\AW_mirror.bak';
go
Msg 954, Level 14, State 1, Line 2
The database "AdventureWorks2012" cannot be opened. It is acting as a mirror database.
Msg 3013, Level 16, State 1, Line 2
BACKUP DATABASE is terminating abnormally.
backup log AdventureWorks2012
to disk = 'c:\sqlserver\AW_mirror.trn';
go
Msg 954, Level 14, State 1, Line 1
The database "AdventureWorks2012" cannot be opened. It is acting as a mirror database.
Msg 3013, Level 16, State 1, Line 1
BACKUP LOG is terminating abnormally.
Take a look at this Database Mirroring FAQ by Robert Davis. I will quote him regarding this operation and the mirror database transaction log maintenance:
When you backup the log on the principal, the virtual log files (individual units within the log file) are marked as re-writable. The same VLF’s are marked as re-writable in the mirror log file as well. The VLF status is mirrored on the database.
So there you have it. If you have transaction log backups on the principal then similar log reuse behavior will be mirrored to its partner database.
Best Answer
This will query the default trace for any changes to the database, which will include the addition of files (but it will also include other things that you can't differentiate, like changing a database's compatibility level). It will also only include data that is currently in the default trace files (they age away; see this answer for details, but basically, how far back the history goes depends largely on how many trace events are captured), and requires that the default trace has not been disabled.
With all those caveats out of the way, this may at least narrow down the set of logins that have made changes to your database recently, and then you can ask them directly (assuming you can map logins to humans):