Recovery from Hotcopy

bbrown
bbrown Member Posts: 3,268
edited 2012-01-12 in Navision Attain
Last night I had to recover a client database from Hotcopy. After moving the DB files back and logging in, I found the database to be at 100% used. I suspect that this was caused by user activity when the hotcopy was made. My solution is a backup, new DB , restore to recover the free space. That is currently running.

Are my observations valid?

Did I have another option to recover the space?
There are no bugs - only undocumented features.

Comments

  • David_Singleton
    David_Singleton Member Posts: 5,479
    bbrown wrote:
    Last night I had to recover a client database from Hotcopy. After moving the DB files back and logging in, I found the database to be at 100% used. I suspect that this was caused by user activity when the hotcopy was made. My solution is a backup, new DB , restore to recover the free space. That is currently running.

    Are my observations valid?

    Did I have another option to recover the space?

    In all the cases where I saw the 100% thing, it was a bad network. I know that the UPS thing really makes it look like hard drives, but I wouldn't be surprised if there was a network issue also. Generally when there is a drive failure like this, it gives a corrupt database, that can then be recovered with C/DART.

    Are they on TCP or TCPS?

    As to recovering, an FBK restore is the only solution I ever found to work.
    David Singleton
  • bbrown
    bbrown Member Posts: 3,268
    I'm going to disagree with you here. I'm fairly confident that the lastest failure of the live copy was a direct result of the disk issue.

    viewtopic.php?f=14&t=51134

    Consider the following:

    1. NAV is running normally and using the database "free space" to maintain various versions related to user activity.

    2. Under normal conditions, the NAV database engine knows the difference between real data and this "temp data". When a user process completes the "Temp Data" is removed freeing the space.

    3. However, in the event of the failure, NAV and the disk loose communicatiions. The system comes back up, but WIndows doesn't know the difference between real and temp data. It's just all data. Hence the full disk.

    I see this no different, then if you yank power to your computer. You get back on and find a bunch of temp files that got orphaned.
    There are no bugs - only undocumented features.
  • David_Singleton
    David_Singleton Member Posts: 5,479
    bbrown wrote:
    I'm going to disagree with you here. I'm fairly confident that the lastest failure of the live copy was a direct result of the disk issue.

    Yes I agree that the current issue has a very high probability of being caused by the disk failure. But it doesn't explain the first crash, though that could also be because maybe the same thing happened before.

    What I am saying is that since it happened again, the issue was not resolved the first time. Navision's version principle should not ever allow this to happen, therefor there is an issue that needs to be resolved, and I think its more than just the disks. I found when a client had this issue, then the only way to get it completely working again was to upgrade the executable, restore a clean FBK into a brand new Database, AND do a thorough check of all the hardware.

    Your best bet is to push the SQL upgrade as soon as possible.
    David Singleton

Categories