new implementation

NavStudent

Hello.
We are implementing a new project. The transaction volume is really high. 10K to 15K orders per day. It's 1-2 items per order.
Can navision handle such high volume transactions?
We are already thinking about batch post the orders.
Any advise/experience are welcome.
They are using new sql 2005.
Should we contact MS to help us with sql?

Thank you.

Alex_Chow

We have a client that's processing the same amount of transactions per day using EDI. The performance is very good.

NavStudent

hello Alex
Thank you for the information. How long have they been live? How many items, customers, vendors, do they have?
How big is the db? How fast is it growing daily?
What kind of hardware do they have?

kriki

You also need some SQL-tuning of the indexes. This is best done by a specialist.

Alex_Chow

NavStudent wrote:

hello Alex
Thank you for the information. How long have they been live? How many items, customers, vendors, do they have?
How big is the db? How fast is it growing daily?
What kind of hardware do they have?

They've been live since 2003. They have about 15,000 items using the standard Navision DB.

The database is growing rapidly, they're at 40GB now. We're looking into the option of converting them to a SQL database.

nunomaia

One of the issues you will have with such high volume transactions is to optimize or disable SHIFT Tables.

Standard DB has designed natively to support Sum index fields. In SQL is “simulated” with tables, so will have to make tunning in such tables and indexes in posting.

NavStudent

Thank you for the info.
So far I see only native db handling that number of transactions.
Anybody else has come even close to 15K orders per day?

We are going to implement it on 5.0, which has already optimization for sql. We will do additional optimizations.

kine

NavStudent wrote:

We are going to implement it on 5.0, which has already optimization for sql.

This is too strong... :-) I would say "which has some optimalization for sql"...

8)

kriki

kine wrote:

NavStudent wrote:

We are going to implement it on 5.0, which has already optimization for sql.

This is too strong... :-) I would say "which has some optimalization for sql"...

8)

I checked the beta.
Some tables are quiet good but others are completely wrong for SQL-optimization.
But even for the good tables:you need to control it anyway,because the best optimalization depends on the data in the table.

NavStudent

kriki wrote:

I checked the beta.
Some tables are quiet good but others are completely wrong for SQL-optimization.
But even for the good tables:you need to control it anyway,because the best optimalization depends on the data in the table.

could you tell me which tables and which keys? I'm curious.
Thank you.

kriki

-T17:nothing I noticed.
-T21,25:some SQLIndex that is different from the Navision Key but I think they don't make much sense. Some SIFTLevels on date (only year and month but I would rather take only day)
-T32:there is something, but it can be a lot better.
-T36,37,38,39:these are definitly optimized and I think they did quite a good job (you can still optimize some things given a certain customer with his DB). For example they create a new index "Document No.,Line No.,Document Type".

Nobody

Have you partner check out Microsoft BSA Services they do hardware and infrastructure assessments and recommendations for large volume customer tailored tothe customers needs for all product lines including NAV. I know there is a charge for this service. It might be worth a shot.

Here is a link to the partnersource page discussing Microsoft BSA services

https://mbs.microsoft.com/partnersource ... page=false

NavStudent

I don't know. I heard that MS sometimes advises the customer to use Axapta.

nunomaia

Navision can handle 10K to 15K orders per day. If your SQL Server can handle that volume, Navision can be optimized to handle that volume.

First you have to simulate in your hardware the expected volume, and based in those results you have to optimize.

If you will post invoices using batch, probably you are posting the invoices during the night. It’s not better to optimize tasks that users perform during the day?

NavStudent

kriki wrote:

-T17:nothing I noticed.
-T21,25:some SQLIndex that is different from the Navision Key but I think they don't make much sense. Some SIFTLevels on date (only year and month but I would rather take only day)
-T32:there is something, but it can be a lot better.
-T36,37,38,39:these are definitly optimized and I think they did quite a good job (you can still optimize some things given a certain customer with his DB). For example they create a new index "Document No.,Line No.,Document Type".

I saw that they have changed the keys, main reason sql performance. I'm sure they have done the improvement for a reason, It can be still optimized further based no customer data. But it's alot better than 4.0.

David_Singleton

Just an FYI, the first performance tuning job I did on the Windows version, was on version 1.3. the client averaged 53,000 sales order lines per day, so about three times your volume. they initially were running on a NT 3.51 with a 486, and 32 Hard drives. They had huge performance issues (28 hours to post one days orders !!!) there were some bad programming mistakes, the hardware was configured badly, the users were badly trained etc. But with some tunning work, a lot of user training, and rebuilding the server, the system got to run fine.

Of course there were no dimensions, or reservations or detail ledgers or value entries, but still, Navision can handle these volumes, if though is given to the whole process. And don't search for a magic bullet, there isn't one. Start with a good server, think through the business processes, train the users well, and tune the system one step at a time. And just to emphasis, training!!! Its the cheapest performance gain you can get. Teach the users how to sort search and filter, don't just let them hit F7 on any field.

By the way, that system had 100 computers in a huge room set up for order entry. In todays version, you would probably have to remove dimensions and reservations for that to work.