Opening a Large Database

lloydsmods

I am working to upgrade a client from 3.60A native to 5.0 SQL. My next step is to upgrade the data, which is quite large (95GB). We have a copy of the database which is in 10 FDB files: Data1.fdb through Data9.fdb are 4GB each and Data10.fdb is 75GB.

When I attempt to open Data1.fdb I get the following error:

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

It recommends expanding or optimizing the database, deleting unnecessary data, or date-compressing older entries (none of which I can do since I cannot open the database).

What can be done to get past this?

bbrown

How was the copy made? It sounds like the files were copied while the NAV service was still running?

Also the varied file sizes raise some concern. When expanding a multi-file database all files should be maintain at the same size. Having a bunch of small files and 1 large one defeats the benefits.

bbrown

Why don't you just make a NAV backup of their database?

lloydsmods

Restoring 95GB could take DAYS. We figured that opening a copy might be a better solution.

I thought the file sizes was bizarre, too, but I've never worked with a database this big.

If they did not stop the NAV service, that could be the problem?

bbrown

A restore of a 95 GB database will take several hours (quite possible close to all day) but it should not take days. If it is you need to take a closer look at your hardware.

If you are going to go the copy route then yes they need to stop the service first.

lloydsmods

Thanks for the help. I don't know if my client did stop the service or not, but I doubt it. I'll ask them for another copy.

Savatage

lloydsmods wrote:

When I attempt to open Data1.fdb I get the following error:

Curious are you trying to open Just the Data1?

shouldn't it be
Data1.fdb+data2.fdb+data3.fdb....etc etc...data9.fdb

lloydsmods

Yep.

garak

uh, i hope you're 10 Files are on 10 different physical HDDs (RAID1).
The reason why you're files are different in filesize, i suppose that you are ever has exanded the file 10 and never, or at begin, the others.

I've also the problem in past with a custumer of mine. He mean the database is slow. so i checked this and it was the same like in your case. The customer has only exanded 1 file and never the others :-( .

To create a new database, i maked a fbk of the database and restore this fbk in a new database, with more files on different physical HDDs (all files the same size). For importing the fbk i used a "high" end Server with enought memory and CPU and good buses. After rebuilding the database, on my server, it was a cost of 1 workday, the database was fast and last year we could migrate this database without problems to SQL.

So your problem for a restore could only be your hardware ......