It worked fine with a database backup that contained about 2.5GB data.
After creating a new backup of the smaller database, it's behaving itself. I have noticed that using the backup that wasn't working, only stored procedures and tables were showing as being available to restore. In the newer backup, views are shown as well.
I've just now tried again and got it to fail again on the first server with the original database. It seems to be the CHECKSUM setting - when I turn it off, I can do OLR (and views are in the list of objects able to be restored. The 2.5GB database I used as above must've been backed up with CHECKSUM off, to save a bit of time on my slow DEV system - which threw me when OLR started working). Having all other settings the same, when I turn CHECKSUM on, views disappear from the list of recoverable objects and I get the error message reported when I try and restore any of the tables. A full restore of the database (to a different database name at least) works fine.
I tried backing up the bigger databases with CHECKSUM enabled and doing OLR. The first one I tried gave me this error: "Unable to get PFS page for page ID 1:198668" after 50% through importing schema information.
Same error (different page) for another DB I tried (that previously worked when CHECKSUM was not enabled).
Both machines are x86 Windows 2003 R2 Standard Edition with SP2. 1GB RAM, single 2.3Ghz CPU.
Both machines are running SQL Server 2005 Developer Edition with SP4.
Both are VMWare virtual machines on VMWare 5.0.
I tried with x64 SQL 2012 on x64 Windows 2008 R2 Standard Edition SP1 - I get "Unknown database compatibility version 110" error message (regardless of CHECKSUM setting).
I tried with x64 SQL Server 2008 R2 Standard Edition with SP2 on x64 Windows 2008 R2 Standard Edition (no SP). With CHECKSUM on, I got the following error: "Error reading backup objects: Couldn't locate entry for HoBT {34,1} in allocations table". With CHECKSUM off, OLR worked.
After creating a new backup of the smaller database, it's behaving itself. I have noticed that using the backup that wasn't working, only stored procedures and tables were showing as being available to restore. In the newer backup, views are shown as well.
I've just now tried again and got it to fail again on the first server with the original database. It seems to be the CHECKSUM setting - when I turn it off, I can do OLR (and views are in the list of objects able to be restored. The 2.5GB database I used as above must've been backed up with CHECKSUM off, to save a bit of time on my slow DEV system - which threw me when OLR started working). Having all other settings the same, when I turn CHECKSUM on, views disappear from the list of recoverable objects and I get the error message reported when I try and restore any of the tables. A full restore of the database (to a different database name at least) works fine.
I tried backing up the bigger databases with CHECKSUM enabled and doing OLR. The first one I tried gave me this error: "Unable to get PFS page for page ID 1:198668" after 50% through importing schema information.
Same error (different page) for another DB I tried (that previously worked when CHECKSUM was not enabled).
Both machines are x86 Windows 2003 R2 Standard Edition with SP2. 1GB RAM, single 2.3Ghz CPU.
Both machines are running SQL Server 2005 Developer Edition with SP4.
Both are VMWare virtual machines on VMWare 5.0.
I tried with x64 SQL 2012 on x64 Windows 2008 R2 Standard Edition SP1 - I get "Unknown database compatibility version 110" error message (regardless of CHECKSUM setting).
I tried with x64 SQL Server 2008 R2 Standard Edition with SP2 on x64 Windows 2008 R2 Standard Edition (no SP). With CHECKSUM on, I got the following error: "Error reading backup objects: Couldn't locate entry for HoBT {34,1} in allocations table". With CHECKSUM off, OLR worked.