Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.5K Microsoft Dynamics NAV
- 18.5K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 270 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Options
Recovery from Hotcopy
bbrown
Member Posts: 3,268
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?
Are my observations valid?
Did I have another option to recover the space?
There are no bugs - only undocumented features.
0
Comments
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.
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.
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.