Large Database on C/Side

pang · 2007-02-27

We have a client has very big database (100G). Their live system is on SQL. Now they want to have a test database on C/Side server.

In the beginning, when they try to expand the database during restore, they got error message 'The database cache is too small it must be a minimum of 0.012% of the size of the database.' We told them to change the Cache to 16000 from default 8000, then they are able to create the database.

So everything looks fine when they try to connect the database from the local server. But they got the same error when they try connect from a workstation. Now the cache has been changed to maximum 768,000. They're still getting the same error.

Does this mean they have to use SQL as the C/Side doesn't support big database like that?

Any suggestion will be appriciated.

Savatage · 2007-02-27

from this post I assuumed 128gb
http://www.mibuso.com/forum/viewtopic.php?t=2044

But our license permits us to go to 65gb
So I guess it depends on the license :-k

this might have changed for ver 4 & 5 tho

pang · 2007-02-27

Their license allow for size of 131,072. And they are installing on version 4.0SP3.

Savatage · 2007-02-27

So I guess you answered your own question then. If they are allowed 131 and it's only 100 it should be fine.

-Note if this database is not on sql then need to use fin.exe not finsql.exe.

I'm guessing this copy of the database is installed on a diff server or on someone's workstation?

kine · 2007-02-28

And do not forgot to split the DB into more files. Native Server don't like big files.

Kowa · 2007-02-28

Upon special request you can get a license for the native server for 256 GB. We have some of our retail customers running with such a license.

Savatage · 2007-02-28

what's required for this "Special Request"???

DenSter · 2007-02-28

What is required is that the NAV version that you have in production is still supported. I don't think they will cut new licenses for 3.7 and older. It's worth a try though, I'd go through your solution center.

Savatage · 2007-02-28

So I guess when you reach your limit - you're forced to upgrade if you're on a older version. :bug:

If you switch to SQL does the database size on the license no longer matter?

Captain_DX4 · 2007-02-28

If they've been able to write a database file that big, then their license supports it. What I'm wondering is if the fin.exe client doesn't like to support a huge cache on its own. Have you setup the database to read directly to the FDB file, or are you setting it up under a server? My suggestion would be to attempt to set it up under a server.

Has the client peformed the restore into the C/SIDE database already, or are you working towards that step still?

Captain_DX4 · 2007-02-28

Savatage wrote:

So I guess when you reach your limit - you're forced to upgrade if you're on a older version. :bug:

If you switch to SQL does the database size on the license no longer matter?

I believe when you cut-over to SQL, the size on the license is no longer required.

However, licenses issued under new versions can still run older executibles/databases.

Savatage · 2007-02-28

That's what I thought thanks for verifing. But my DB needs to triple before I have to worry about greasing some palms 8)

Captain_DX4 · 2007-02-28

You make it sound so dirty! *lol* Really, it's not that bad.

Kowa · 2007-03-01

Savatage wrote:

So I guess when you reach your limit - you're forced to upgrade if you're on a older version. :bug:

The first 256 GB License we used was for a 2.6 Database, technically upgraded to 4.0. It is possible and, in our experience , absolutely reliable, but the MS document where this was announced declared it as "unofficial size limit "and the official statement nowadays is usually "Switch to SQL Server".

It is Granule 1,370 Database Extension by 1GB x 192 (+ 64 GB Standard)

DenSter · 2007-03-01

Kowa wrote:

the official statement nowadays is usually "Switch to SQL Server"

That makes sense coming from the company that sells SQL Server right

kriki · 2007-03-02

Savatage wrote:

If you switch to SQL does the database size on the license no longer matter?

This is the reason at a certain point, Navision decided not to charge anymore per MB of DB-space.

kriki · 2007-03-02

kine wrote:

And do not forgot to split the DB into more files. Native Server don't like big files.

Do you know what is the upper-limit (for performance-reasons) of a DB-file?
I know once there was a limit of 2GB per DB-file, but now this is not the case anymore. But I never found out the limit to use. Apart max 16 DB-files.

DenSter · 2007-03-02

I seem to remember 256GB max, but I'm not sure.

kriki · 2007-03-02

DenSter wrote:

I seem to remember 256GB max, but I'm not sure.

I meant : per DB-file but not limited by the license, but rather limited by reasons to keep a good performance.

DenSter · 2007-03-02

That would then be 16GB. 16 files of 16GB totals 256GB.

kriki · 2007-03-02

DenSter wrote:

That would then be 16GB. 16 files of 16GB totals 256GB.

Yes, but which setup is the most performant?
-1 X 16 GB
-2 X 8 GB
-3 X +-5.3 GB
-4 X 4 GB
-5 X +-3.3 GB
-...
-16 X 1 GB

DenSter · 2007-03-02

Always use equal size for all of the files, to spread the load evenly. I think if you need to add files, you should recreate the database altogether, or you'll get an uneven load into the new (empty) file, and your performance is still bad. I don't think there is such a thing as "5x12 is better than 10x4", it all depends on the usage.

kriki · 2007-03-02

DenSter wrote:

Always use equal size for all of the files, to spread the load evenly. I think if you need to add files, you should recreate the database altogether, or you'll get an uneven load into the new (empty) file, and your performance is still bad.

Or create a new file with the same size of the others.
I know all that, but my question basically is:
Once a DB-file gets over a certain size, the performance decreases. BUT what is that "certain size"?

DenSter · 2007-03-02

Depends on:
- system usage
- cpu
- storage
- network

I doubt that you will find anything more helpful than that

David_Singleton · 2007-03-02

kriki wrote:

DenSter wrote:

Always use equal size for all of the files, to spread the load evenly. I think if you need to add files, you should recreate the database altogether, or you'll get an uneven load into the new (empty) file, and your performance is still bad.

Or create a new file with the same size of the others.
I know all that, but my question basically is:
Once a DB-file gets over a certain size, the performance decreases. BUT what is that "certain size"?

Personally I feel that with modern hardware, its around 10gig per db part. But that is just my opinion.

But as Daniel says, it depends on a lot of things, most importantly how many concurrent users writing to the same tables. If its a background posting routine at night generating all the date as a single user, then its not really an issue. If you have 100 concurrent users entering sales order lines iwth 3 dimensions per line, then I would not go over 4gig.

Waldo · 2007-03-04

kriki wrote:

DenSter wrote:

Always use equal size for all of the files, to spread the load evenly. I think if you need to add files, you should recreate the database altogether, or you'll get an uneven load into the new (empty) file, and your performance is still bad.

Or create a new file with the same size of the others.
I know all that, but my question basically is:
Once a DB-file gets over a certain size, the performance decreases. BUT what is that "certain size"?

Well, once I heared that microsoft recommended a maximum file size of 2 Gb... . But that's just something I heared. Nothing "official" to find there... .

But I agree ... it all depends on the usage and the hardware, which is still getting more and more powerful.

bbrown · 2007-03-04

A recommendation I got from Navision on time (pre-MS), was to split the database and place each file in its own RAID 10 array.

Waldo · 2007-03-04

bbrown wrote:

A recommendation I got from Navision on time (pre-MS), was to split the database and place each file in its own RAID 10 array.

I heared this as well ... but don't you think times has changed, and this is not necessary anymore?

bbrown · 2007-03-04

Never said it was necessary only recommended. Considering that the Navision Server really has not changed, in all these years, it is probably still a valid approach. It depends on whether the bottleneck is the Navision disk service, or the physical disk system.

Similar approaches are taken in very large SQL databases.

kriki · 2007-03-05

Waldo wrote:

bbrown wrote:

A recommendation I got from Navision on time (pre-MS), was to split the database and place each file in its own RAID 10 array.

I heared this as well ... but don't you think times has changed, and this is not necessary anymore?

Indeed, you can still use this approach:
How about a 1 GB-DB divided in 16 DB-files with a 6-disk RAID10 per DB-file :!:

If this goes slow, I want to know the programmer who programmed everything!

DenSter · 2007-03-05

Yes that system should have your order posted before you even click the button

Large Database on C/Side

Comments

Categories