Simple Settings to Help

Your AX 5Solution
Ways to Tell
toifRun
You’reFaster
Ready for
Connected Field Service

4/18/2019
 Awards Leverage the Microsoft
Global Credibility Cloud to Your
Local, Strong Skills Advantage with HSO

Foto’s van collega’s

Industry Expertise and References

Retail …

Distribution …

Manufacturing …

Services …

Public …
Presenter Introduction

Steve Walsh
Director of Managed Services
HSO North America

Technical/Developer Background

13 years w/Microsoft
MCS
Global Support Prg Mgr
Tech Acct Manager
Premier Field Engineer

7 years in Partner Channel

Managing Managed Services

Working with AX/D365 since 2005

What is Managed Services?

Client Trusted Partner

Post Go Live Consulting Technical & Functional Application Optimization

Performance Topics

➢ Factors that affect Performance

➢ Assumptions

➢ SQL Server Settings

➢ AOS Server Settings

➢ Maintenance

➢ User Features

➢ Resources
Factors that affect performance

▪ There is NO Silver Bullet for performance improvement.

▪ It is like an onion with many layers.

Factors that affect performance
▪ Hardware – Physical layer to the system; includes server box, network
bandwidth, storage devices, and client machines. Should meet the minimal
requirements stated by Microsoft.
▪ Windows Server Configuration – Operating system, firewalls, anti-virus, etc.
▪ SQL Server Configuration – Application layer to the SQL server. Overall
settings within SQL applications.
▪ Database Schema & indexes – within SQL Server; specific settings the
database has setup, the table layouts, and the indexes associated with each
table.
▪ Application Code – Kernel and application code; ISV code, Customizations, and
X++ query calls.
▪ Application Configurations – within AX; Parameters settings, sequence
numbers, and database logging
▪ Users/Business Process – Running a report or specific process multiple times;
running a specific job
Assumptions

▪ Hardware is bigger and better than recommendation from MS

installation documents.
▪ Most of this information is technical.
▪ You have access to SQL and know how to pull up settings.
▪ Information may not apply to your specific system; Consult with
your AX partner or Microsoft.

▪ Always TEST in your Test environments first.

The Process

Settings Analyze Maintain

• Proper • Performance • DB & Code
settings Assessment Tuning
• Maintenance

Today’s
Topic Repeat Continuous
Improvement
SQL Server Settings
SQL Settings

▪ Production SQL Server – Only production databases should be on the

production servers. Any Dev or Test type activity should be
separated completely.

▪ SQL Server should be configured to run as a background services

– Control Panel → Advance System Settings → Advanced Tab → Performance →Settings
→Advanced Tab → Processor scheduling → Background Services.
SQL Settings

▪ Configure max degree of parallelism set to 1

▪ Max Server Memory - Operating System needs to have some memory

available to function correctly. Either leave 4 GB or 10%, which ever is
greater.
SQL Settings

▪ TempDB
• One file per core & up to 8
• 20% of database size
• Each file should be set to same size
• Set to Simple Recover Model
• Auto growth set to 250-500MB
• Some will recommend setting to 1 Gig to start with
• When SQL is adding size to Temp files… it locks activity down.
SQL Settings

▪ Trace Flags
➢ 1117 – Enabled – This flag grows all file groups simultaneously in the case of
an auto growth event.
➢ 4199 – Enabled – This activates query optimizer fixes from several hotfixes.
➢ 4136 – Disabled – This has parameter sniffing; disabling can improve
performance.
➢ 1224 – Enabled – lock escalations based on the number of locks
➢ 2371 – Enabled – Reduces the threshold for auto-update statistics for large
tables > 25k rows.
SQL Settings

▪ Read Committed Snapshot Isolation (RCSI) – should be set to True

▪ Auto Create Stats – should be set to True

▪ Disk I/O (storage should be on a RAID system)

– Reads – Less than 10ms
– Writes – Less than 20ms
SQL Settings

▪ Maintenance:
– Periodic indexing
▪ Administration > Periodic > SQL Administration
– Statistic rebuilding
– Specific Table Sizes:
– INVENTSETTLEMENT
» Run cleanup (inventory management > Periodic > Clean Up > Inventory Settlements
– EVENTCUD
– INVENTSUMLOGTTS
– SYSTRACETABLESQL
– SYSDATABASELOG
» Administration > Setup > Database Log
– SALESPARMLINE
» Administration > Periodic> SQL Administration
AOS Settings
AOS Settings

▪ Memory - No less than 16 GB

▪ Only 1 instance per server
▪ Breakpoints – Should be disabled
▪ Max buffer size – Set between 24 to 48 (default for 2012 R2 is 48)
▪ Max No. Table to Join – Max is 30
▪ Entire table Cache size = Set to 96
▪ Global object cache elements = 100000
▪ Statement Cache = set to 450
▪ AOS Max Memory Setting = set to 80%
▪ Dedicated AOS for batch = should be 2 AOSes minimum; 1 for users; 1
for everything else. --- Greater than 3, can group batch types to
different servers
Maintenance
Kernel

▪ Check and update the Kernel from Microsoft

– Generally a performance improvement was made
– Make sure your Kernel version match
▪ Client, AOS, SQL Server and all locations
▪ Keep in mind… DEV/TEST/Production should all be the same Kernel

▪ Not necessarily dependent on the application level/version

Monthly Checks

▪ Database Log
– System setting to capture when a record is inserted/deleted/updated
– Select count(recid) from sysdatabaselog
– If >200K, query for records older than a specific date
– Transaction type tables should not have logging turned on
– Clean-up process: Use Export/Import tools to archive data.
– Clean-up too: Administration -> inquiries -> Database Log -> Clean up Log
Monthly Checks

▪ Temporary Sales Order/Purchase Order Processing Data

– Table stores temporary order lines when orders have been posted.
– Some lines hang out here and never get deleted
– SQL Query:
▪ Select Count(recid) from salesparmline
▪ Select count(recid) from purchparmline
– Clean-up Process:
▪ AR>periodic>Clean Up > Sales Update History Clean up
▪ AP>Periodic>Clean up> Purchase Update History Clean Up
– No Reason to keep data over a month
Monthly Checks

– Temporary Master Planning Data

– Table stores inventory movements caused by master planning
▪ Select count(recid) from InventSumLogtts

– Clean-up Process: AX should purge this data automatically. Should be a small

record count in the table. Check to make sure the data is for production data
versus test company data.
Quarterly Checks

▪ Sales Line
– Select count(recid) from SalesLine
– Clean Up Process: AR > Periodic > Delete Orders
– Depending on your parameter settings; SO may go to voided table
Quarterly Checks

▪ Inventory Settlement
– Stored temporary data during inventory close and other periodic adjustments
▪ Select count(recid) from inventsettlement
– If record count is > 200K, then run clean up job
▪ Inventory Mgt>Periodic>Clean Up>Inventory Settlement Clean Up.
▪ Only run cleanup on previous financial YEARs.
Batch Jobs

▪ No batch jobs with recurrence of every minute

– Will cause Jobs to get stuck in execution state
– Over lapping jobs (not just limited to 1 minute)
▪ Use the Batch Job Groups and time schedule
– Map out and track job processing length
– Be aware of similar processing and their times
▪ Which jobs are hitting Inventory at the same time?
– When does your backups run?
Reports

▪ Reports can have a big impact on the systems.

– Users will see a performance issue on data entry when someone else is
running a big report.
– Performance hits during the morning hours? Good chance someone is
running their morning reports.
▪ Daily Reports can be setup to run in batch over night.

▪ If you have a real-time backup; can you run your reports from there?
Consistency Checks

▪ System Admin > Periodic >Database > Consistency Checks

– Should run these once a quarter.
– It checks for missing data/misaligned data.
– More issues from customizations or imported data.
– If you are finding data popping up a lot, then you need to investigate
– This may cause a data query to take longer or present incorrect data set.
– If you hit the Max or a timeout, get an AX developer to help with a custom
search/dump.
Miscellaneous

▪ GUID
– Check AX Environments Unique GUID
▪ SysSQMSettings SQL Table
▪ If the same GUID is Dev/Test/Production; could have User Usage data issues
▪ Usually happens when refreshing from Prod to Dev/Test
▪ Clear the Dev/Test environments (AX will generate a new GUID)
User Features
Fact Boxes & Preview Panes

▪ Don’t use them? Turn them off!

Fact Boxes & Preview Panes
Fact Boxes & Preview Panes

▪ System Admin > Setup > System > Client Performance Options
– System wide; may not be a great option

▪ Developers can turn it off, system wide per Form

Favorites

▪ Check to see how users are access standard forms.

▪ If using a Favorite, did they create a query that might not be optimal?
User Usage Data

▪ Some Performance issues are caused by Usage Data

▪ Usually when other users can use the form or report without issues
▪ Clear our specific Usage Data components
– You can remove specific settings, if you know the form or report

▪ May lose personal preference settings

▪ Nuclear Option = Clear all of the user’s Usage Data
Resources
What else? It is still slow…

▪ Get a Performance
Assessment
– Check Indexes
– Long running queries

▪ All tests great with 100

records; how about a
few 100,000?

▪ Train your DBA on AX

Performance Tools and
Settings
Resources

▪ Storage Article:
▪ https://blogs.msdn.microsoft.com/dynamics-coe/2013/02/10/storage-
requirements-for-microsoft-dynamics-ax/

▪ Performance Page
▪ https://blogs.msdn.microsoft.com/axsupport/2015/09/28/ax-performance-
what-information-and-data-to-collect-when-you-want-to-open-a-support-
case/

▪ Microsoft Performance Team Blog

▪ https://blogs.msdn.microsoft.com/axperf/

▪ Performance Analyzer
▪ https://blogs.msdn.microsoft.com/axinthefield/cat/dynamicsperf/
Questions?
Learn More

LEARN MORE
Schedule a virtual assessment
with one of our service experts
today.

www.hso.com
(847) 348-0588
swalsh@hso.com

www.hso.com