2010-08-12 07:59 AM
Anyone ever come across an issue where SMSQL reports a Error Parsing Time when select the Restore option from the left hand pane in SMSQL ?
SMSQL was running for a couple of months, no problem. Then one day the Restore option stopped working.
See attached screenshot.
Ticket has been opened with support.
Scheduled snapshots work great. You just cannot restore anymore.
2010-09-29 12:59 PM
Have you had any luck in resolving this? I've been working with support to try to get this resolved for quite a while now. Of 4 SQL servers, 1 gives this error without fail. The other 3 servers work just fine and have never encountered this error. Over the past 2 months at various times, sometimes the error shows 4 consecutive times, sometimes 8, sometimes 40+ (always when attempting to restore/clone from local backup sets). It had been showing the exact same error dialog as you've attached, but since the .NET 3.5 SP1, I'm also getting a slightly different dialog (attached) in addition to the usual error. For example, earlier this week, I'd see the exact error dialog you posted 4 times, followed by the one I've attached 4 times. Right now, it just shows the error I've attached 4 times and then SMSQL crashes. Most of the time this crashes SMSQL, while other times, I am able to proceed after the last error dialog.
Restored .NET 3.5SP1 by way of repair installation as instructed by support, but that was no help. Also upgraded SMSQL several times - first to SMSQL 5.0R1, then SMSQL 5.0R1P2, then SMSQL 5.0R1P2D2; none of these have corrected the issue. Took it upon myself to delete all snapshots on the 3 volumes (LDF, MDF, Snapinfo), as support is not eager to recommend this course of action. I can somewhat understand why, but the snapshots are completely useless to me if I cannot restore/clone from them - how much worse off am I if I have no snaps versus if I have snaps but they're not usable? After deleting all snaps, I ran a scheduled backup and was able to restore/clone with no error. However, the next morning, I was getting that same error repeating once again.
Like you, our SMSQL scheduled backups on this server appear to work just fine (logs indicate all is successfully backed up). However, more often than not, we are unable to restore or clone from backup sets created on that server.
We're using OnTap 7.3.2RC1, SQL Server 2005, and SnapDrive 6.1 on Server 2003. LUNs are connected via iSCSI. Support is now recommending to upgrade to SMSQL 5.1, but I am not very confident this will resolve the problem (no dice upgrading the last 3 times...)
2010-09-29 01:05 PM
Stephen, What is your support case#?
Typically that error is nothing to worry about. It has to do with metadata in a transaction-log only backup. My understanding is that it can also happen on native SQL backups. Either way, the error itself is not a show stopper.
The bug mentioned in 145575 does not take into account that the MMC is crashing. Like Shawn's case above, the MMC is getting an unhandled exception and crashing. Perhaps we could gather some data to prove/disprove that you are seeing the same thing.
I'm not convinced that deleting snapshots will buy you anything, as the issue does not appear to be snapshot related.
2010-09-29 01:25 PM
Thanks watan, but I think this is a separate issue. I've never seen this come up as a "SystemTimeToFileTime" error. Also, I usually am not even able to get to the point where I am able to double-click on a backup set - the mmc crashes before this. I'm also not seeing anything logged in the app log at the time I recreate this issue other than event ID 1000 (Faulting application mmc.exe, version 5.2.3790.3959, faulting module msvcr80.dll, version 8.0.50727.3053, fault address 0x0001c992).
2010-09-30 12:27 PM
We have had no luck resolving this issue. The latest attempt was to make sure everything is patched the same on all of the nodes.
Mpio 3.2r1 - upgraded to 3.3.1
Snapdrive 6.0.2 - upgraded to 6.2p1
host utilities kit 4.0 - upgraded to 5.1
smsql stayed at 5.0r1p2
Ontap stayed at 7.3.2P3
Windows 2003 Enterprise Edition SP2 32bit Physical Server
SQL Server 2005
LUNs connected via Fiber Channel
Still we get the same error parsing time. We have deleted all the snapshots like you did and still the error persists. In my case the restores fail on any server that is running smsql for just one particular sql instance. We have also seen sometimes that when pressing the OK button multiple times that a window will appear saying unhandled exception occured in mmc.exe . See attachment. We even tried to enable smsql logging by flipping a registry key, however the log file did not indicate the error message either. What is interesting is that there is 0 errors in any of the event logs.
I can browse the backup images fine using the smsql cli prompt:
get-backup -server 'DB00' -ServerInstance 'DB00\SQL101' -d 'databasename' -vb
I did not attempt to perform a restore as I do not want to overwrite any of my existing production databases. I am trying to find out how to restore from cli 'databasename' to 'databasename_test'
The next step requested by support is to get Adplus and Procmon logs ftp'd to Netapp for analysis to see if we can pinpoint where it is crashing.
2010-09-30 02:20 PM
It looks like we're both at about the same point. I'll be collecting some data to send over to support tonight - already enabled SMSQL debugging, and will be running procmon and adplus this evening and sending logs over with the ONTAPWinDC output and SQL Server error logs. Will let you know how the progress goes from here.
2010-10-01 02:47 PM
The root cause of this problem is BURT 145575 (http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&
If you do get error while selecting a backup, you should still be able to do the restore with that log backup. The only problem is that you may not be able to use this log backup for point in time restore, since it does not have "BackupFinishDate" value, so SMSQL cannot determine the time range you can select for the restore.
So the issue is caused by a log backup. If you can find out which log backup caused the problem by running T-SQL restore headeronly command on all your log backups of a database (that is the database you know you will get an error message when double clicking it), you can check to see if there is a 3226 error event in SQL log during the time of the log backup described in MSFT KB http://support.microsoft.com/default.aspx?scid=kb;
Here is an example of restore headeronly output to a log backup which has the NULL column value:
(1 row(s) affected)