I am contemplating placing AOSes on SSD drives due to the following considerations: Dynamics AX 2009 AOS puts cache that is greater than 128k per table to a hard disk. If it is an awesomely fast SSD, then the cache update is insanely fast.
The things to consider would be is the speed of update of other AOSes, since for some types of cache, AOS must update the other AOSes too.
So the consideration needs additional planning.
Also, an enterprise-grade or an SLC drive should be considered due to high reliability.
Monday, March 12, 2012
Tuesday, March 6, 2012
Report performance of Dynamics AX
Today i've got a task to take a look at a long-running report. I came across the following useful checklist:
Include a try catch around all transactions that could result in deadlock.
Make sure the try for a deadlock is idempotent meaning no matter how many times the try is attempted, it will yield the same result.
Consider the clarity when deciding the number of return statements in a method.
Use throw instead of ttsAbort.
Avoid display methods where possible.
Set Optimistic Concurrency Control (OccEnabled) to Yes for most tables.
Do not include user interaction inside a database transaction.
Keep database transactions as short as possible.
Run code on the Application Object Server (AOS) whenever possible.
Use where clauses in select statements and in queries that align with indexes.
If method calls are used to test conditions, put the method calls after the other conditions. If the other conditions fail, then you will not incur the cost of running the method.
Minimize the size of database transactions.
Consider specifying a field list in select statements to increase performance.
Use firstonly where applicable to increase performance.
Use aggregates in the selection criteria instead of having the code do the aggregation. If aggregations are issued in the select statement rather than in code, the processing is done at the database server which is much more efficient.
Use table joins instead of nested while loops. Whenever possible use a join in the select statement rather than using a while loop and then an inner while loop on the related table. This reduces the amount of communication between the AOS and the database.
Do not include any sort of user interaction in a transaction.
Include a try catch around all transactions that could result in deadlock.
Make sure the try for a deadlock is idempotent meaning no matter how many times the try is attempted, it will yield the same result.
Consider the clarity when deciding the number of return statements in a method.
Use throw instead of ttsAbort.
Avoid display methods where possible.
Set Optimistic Concurrency Control (OccEnabled) to Yes for most tables.
Do not include user interaction inside a database transaction.
Keep database transactions as short as possible.
Run code on the Application Object Server (AOS) whenever possible.
Use where clauses in select statements and in queries that align with indexes.
If method calls are used to test conditions, put the method calls after the other conditions. If the other conditions fail, then you will not incur the cost of running the method.
Minimize the size of database transactions.
Consider specifying a field list in select statements to increase performance.
Use firstonly where applicable to increase performance.
Use aggregates in the selection criteria instead of having the code do the aggregation. If aggregations are issued in the select statement rather than in code, the processing is done at the database server which is much more efficient.
Use table joins instead of nested while loops. Whenever possible use a join in the select statement rather than using a while loop and then an inner while loop on the related table. This reduces the amount of communication between the AOS and the database.
Do not include any sort of user interaction in a transaction.
Monday, March 5, 2012
Dynamics AX: it is recommended that you cancel the recalculation
This error is caused by a situation, where either:
- Inventory closing was performed later than this recalc
- The recalculation date equals the inventory closing date and the time of the recalculation start is LESS than closing inventory start.
So what could have happened is that the inventory recalc was was launched with date to update up to a date earlier than the last inventory close. Inventory recalc gave an error, saying that it does not make sense to make this recalc, since that inventory has already been closed. Cancel the last recalc, or change the date to run up to.
Subscribe to:
Posts (Atom)