We have a sandbox SQL Server that we use mostly for playing around with reporting data; basically stuff like running an analysis that might be pretty intensive, we do it there to avoid putting stress on the production servers.
Anyway, the other day the powers that be decided to make this server virtual. The hardware is way more than we need for what we were doing, so it was decided that we'd pull everything off, make it virtual, and then put everything back again.
Since there was a LOT of data and not a whole lot of time, we decided to detach the databases, physically move the .mdf files to an external drive, and then move them from there to the new server; the idea being to just attach them on that server. The external drive is attached to a workstation.
I've done this before without any problems. Not so this time.
The first one I tried to attach on the new box was for our Red Gate Monitor, using this code:
CREATE DATABASE Blah ON
(FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\Blah.mdf')
I got the following error:Message
SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:14825728; actual 0:0). It occurred during a read of page (1:14825728) in database ID 7 at offset 0x00001c47200000 in file 'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\RedGateMonitor.mdf'. Additional messages in the SQL Server error log or system event log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
After some research, I saw a few suggestions that it may have been corrupted during the copy. So I made a copy to the workstation that's physically connected to the external drive. It attached without a hitch. I then detached it, copied both the .mdf and .ldf to the new server, and attached it there; it worked perfectly.
So I tried another database. This time, it restored without any problem on the server but failed on the local workstation. Another database worked fine on both; others won't attach on either. The error is always like the one above when it fails.
So my question is, what is really causing this? Why would the same file fail to attach on one machine and not the other; and why is it not even consistent which machine that fails? It seems strange that we'd be seeing this much corruption from a network copy. Any ideas would be appreciated.
Fortunately, none of the databases in question are really critical; the majority of them are only around for historical purposes, and we've got live copies of them on another server. I'm just curious about what is actually happening here.