2.60 Databse CRash - no available space

Have a Navision 2.60 C/Side database reporting :

"Other concurrent activities have reused the available space in the database that contained your snapshot of data. This can occur with time consuming tasks such as printing or making backups. Wait until there are fewer concurrent updates of the database and try again.

If this occurs often, you should create more available space in the database. ........."

Normally this would be, should be, a simple problem solved easily by expanding the database by increasing the size of the .dbf file(s) or adding more .dbf segments.

Not in this case - even direct connection from a client to the primary .dbf file with dbreadonly=Yes set fails !

My conclusion is that internal pointers inside the .dbf files have been corrupted ?

My question - has anyone seen this one before, or better still has anyone been able to recover a database in this state before ?

Do you get the error message immediately upon entering the database? If not, I suggest you try a Backup / Restore sequence to rebuild the database with refreshed, validated key files and other database control information.

Hi,

I saw this problem few times and it was relatively easy to fix.

First you should find corrupted table. (As common it is only one Table).

You should run database test. It will crash on the currupted Table.

Second you should delete corrupted records. (The lagest number i had was about 20. Not so many).

Normally I open table and scrolling down antil it crushed. You need to find primary keys for corrupted table. (It can take some time if it is entry table, but as common it is in last 90% of data)

When you found you have to delete corrupted records. Write and run codeunit;

Table.Key := 'Value';
Table.Delete;

After you delete all such records you have to insert deleted records manually.

Hi. You propably have a corrupted key. If it's the primary key You're in trouble. Otherwise You can do as Valentin says.

Afterwards You should upgrade Your C/SIDE to at least 3.01B where this has been fixed.

Unfortunately in this case the error occurs immediately any attempt is made to open the database regardless of the open method - client / server, client direct or client direct in read only mode.

Update - what the users did NOT tell us !

The corruption is actually the result of a 'Blue Screen of Death' on the host NT server. The Navision database service runs with both data and commit cache turned on.

So the database file set did not run out of space. The database is actually corrupt as a result of cached data not posted back to physical disk.

I had this problem a few weeks ago and came to the same conclusion. Both data and Commit cache on. I could only open the database in Readonly mode. The database had 3 Companies, one of which had a corrupt Purchase Line table. All I could so was backup the clean Companies, create a new database, restore the backup, then restore the corrupt Company from the previous nights backup.

Thanks.

Basically confirms our belief. Unfortunately in our case we cannot open the database in read-only mode.

We have the best of the Navision techos in this country on the job and a copy in trasit to Denmark, but at this stage the prognosis is not good.

Update - Database has been recovered by Navision technical specialist after a few days work. Only the last few transactions done in the period just before the Windows server 'blue screened' were lost.

Useful information ? if you are desperate enough Navision do have some tools and a few technical specialists around the world who can recover seemingly dead databases !

This is on ongoing issue. The recovery program C/DART = Cside DAta Recovery Tool, is great. But why can't we have access to it [:(!].

By the way the particular error you mention, (where a particular record continually expands to use all available space), is quite rare. A simple corrupt record is quite common.

That error I have only ever seen on 2.00b and 2.50a. Which version of 2.60 executables are you running?

The Navision version is 2.60E.

Note this time the problem is not Navision ! The problem this time was Windows 2000 'Blue Screen of Death' which naturally took out the Navision Server cache before it could be posted to physical disk.

For what is worth I find the general Navision policy on user access to high level tools to be less than acceptable and this is yet another example.

Hi Peter,

A Blue Screen of Death should not take out the Navision database. That is what the Version Principle is all about. You have a problem, and you need to fix it.

The only time any hardware crash should cause this level of corruption is during the actual database expansion it self. Now... if the blue screen of death occured whilst you were expanding, then yes, it should have destroyed the database. But as we all know we always make a backup immediately before expanding right [;)].

The normal error that we all see from time to time, is the one Val was talking about, where you have a few records corrupted, and the corruption hits the primary key. Your two options to fix, are C/DART or the method that Valentin mentions. Of the times I have seen this error, it has always been caused by either a/ A baddly configured, or faulty SCSI disk controller, or b/ a faulty net card. Interestingly, in 12 years with Navision I have never seen the error caused by an actuall disk error, odd that. But in just about every case, I have heard everyone blame it on disks.

In your case Peter, I think the problem is simpler. At a guess, I would think you have a problem with your disk configuration. My first guess, would be to say that you are using RAID 5, but everyone knows RAID 5 and Navision do not mix, and I could not imagine that you are using this[}:)]. If you are, then the error is identified, and can be easily fixed by going to RAID 1.

The next possibility is that you have a cached hard disk controller. If so, then either turn off the cache, or find a new controller card. The problem with cache, is that Navision can not predict the sequence that data is written to the physical drive, and it screws up the Versioning.

The next possibility is a Net Card failure, but I don't think that this is the problem, unless it was the net card that caused the blue screen of death. In your case, I seem to believe your original prognosis that the Blue Screen of Death caused the problem, not the other way around. Also errors due to net cards are normally on the client, I am assuming this was a server crash.

Beyond this, there are many more things to check, but start here.

ONE WORD OF WARNING. Don't just assume that the problem is fixed. You really don't want this problem again.

Good luck, and let us know how it goes.

today we've had the same error message :


___________________________________

"Other concurrent activities have reused the available space in the database that contained your snapshot of data. This can occur with time consuming tasks such as printing or making backups. Wait until there are fewer concurrent updates of the database and try again.

If this occurs often, you should create more available space in the database. ........."
___________________________________




I get this error message and I cannot even open the bleeding Database [xx(]

Also restoring yesterdays backup is an issue [:(!]
The restore hangs without giving any errors.

Our version of Navision Financials 2.60

Tarek

I had totally forgotten about this post ! Unfortunately the problem was an internal corruption of the data structures within the database .FDB and there are no user tools that will fix the problem.

Navision have tools available only to Navision support offices and we had to send the .FDB to Navision in Sydney who then extracted the table data and used this to rebuild a database for us. This is a not a simple process and there is only 1 person in Australia who has the skills. We were told there are only a small number of people in the world who have the training to perform this recovery process.

I believe the problem is a bug in the database engine, but I have not documentary evidence. It was interesting that Navision Australia did not seem surprised at the problem as if they rather expect to see a few cases of this problem.

Our backup problem was simple - the IT people were backing up the .FDB segments directly as opposed to using Navision to do a dump to flat file thus the backup was potentially inconsistent, but we will never know as they had added new .FDB segments over time and NOT included these new file sets in the backup file list thus the backup was incomplete as well.

The whole recovery process took a week.

This IS a bug in the DBMS. It was fixed in 3.01B and the fix is documented in the change log