Troubleshooting is a crucial skill for Maximo administrators, as it involves diagnosing and resolving issues to keep the system stable and efficient.
Log files are one of the most important resources for identifying and fixing issues in Maximo. Maximo generates various logs that record detailed information about system operations, errors, and user actions.
Understanding Log Types: Maximo provides different types of logs, such as application logs, system logs, and database logs. Each type of log contains specific information that can help you pinpoint issues. For example:
Configuring Log Levels: Log levels determine how much detail is captured in the logs. Common log levels include:
By setting the appropriate log level, you can control how much data is captured, balancing detail with system performance.
Analyzing Logs: When an issue occurs, reviewing relevant logs can reveal clues about what went wrong. For example, an error message in the application log might indicate a database connectivity issue. You can use log analysis tools to filter and search logs, making it easier to find relevant entries.
Key Takeaways:
Certain errors are more common in Maximo, and learning to recognize and address these can save significant time and prevent system downtime.
Database Connection Failures: This is a frequent issue where Maximo cannot connect to its database. This can be caused by network issues, database server downtime, or incorrect configuration. Checking the database server status and connection settings is often the first step in troubleshooting.
Insufficient Memory Errors: Maximo may run out of memory if it’s handling too many tasks or if the server’s resources are limited. Increasing the server’s RAM allocation or optimizing memory usage in the JVM (Java Virtual Machine) settings can help resolve this.
Application Server Crashes: If the application server (such as WebSphere or WebLogic) crashes, Maximo will be unavailable. Common causes include excessive load, improper configuration, or JVM errors. Restarting the server and analyzing server logs are the first steps in addressing this issue.
Other Common Errors: Maximo administrators often encounter issues like slow performance, user login failures, or data synchronization problems. Familiarity with these errors and their causes helps you respond quickly.
Key Takeaways:
Performance bottlenecks can slow down Maximo, making it harder for users to complete tasks. Analyzing system performance can help you identify and address these bottlenecks.
CPU Usage Analysis: High CPU usage can indicate that Maximo is handling more requests than the server can manage, or that certain processes are consuming excessive resources. Monitoring CPU usage lets you see if specific actions (like report generation or large data imports) are causing slowdowns.
Memory Usage Monitoring: Insufficient memory can lead to system crashes or slowdowns. Monitoring memory usage and adjusting JVM heap settings can help prevent memory-related issues. You can also adjust garbage collection settings to free up memory more efficiently.
Database Usage: Maximo’s performance depends heavily on database response times. Analyzing database usage helps identify if certain queries are slowing down the system. For example, large or complex queries can cause delays if they aren’t optimized.
Using Profiling Tools: Tools like IBM Tivoli Performance Analyzer or external profilers can provide detailed insights into how Maximo uses system resources. Profiling can help you pinpoint the exact process or query causing the bottleneck, allowing you to optimize those areas specifically.
Key Takeaways:
The database is central to Maximo, and many issues can stem from database problems. Database debugging involves analyzing queries, optimizing indexes, and resolving locks or deadlocks that can slow down Maximo.
Understanding Maximo’s Database Structure: Familiarize yourself with how Maximo organizes its database tables, as this knowledge helps you diagnose data-related issues more effectively. For example, tables for work orders, assets, and inventory items are frequently accessed and may require special attention.
Query Optimization: SQL queries can sometimes take longer to execute due to complexity or large data volumes. Optimizing queries (e.g., by adding indexes) can improve database response times. For instance, adding indexes to fields like “Work Order ID” or “Asset Tag” can make data retrieval faster.
Table Locks and Deadlocks: When multiple users or processes try to access the same data, a lock or deadlock can occur, preventing users from accessing records. Debugging these locks and understanding their causes can help you prevent them from happening in the future.
Database Logs: Reviewing database logs provides information on slow queries, connection issues, and error messages, helping you quickly identify database-related problems.
Key Takeaways:
Maximo relies on application servers like WebSphere or WebLogic, and tuning these servers can significantly impact system stability and performance.
JVM Heap Memory Configuration: The JVM (Java Virtual Machine) runs the Maximo application within the server, and configuring its heap memory correctly is essential. The heap memory should be large enough to handle Maximo’s workload but not so large that it impacts system performance. Setting initial and maximum heap sizes ensures the JVM has the memory it needs for efficient operation.
Thread Pool Configuration: Thread pools allow the application server to handle multiple requests simultaneously. Properly configuring thread pools helps the server respond to user requests without overloading. Too few threads can lead to delays, while too many can overload the server.
Garbage Collection Tuning: The JVM uses garbage collection to free up memory by removing unneeded data. Optimizing garbage collection settings can help improve memory management, reducing pauses and improving overall performance. You can use tools to monitor garbage collection performance and adjust settings based on Maximo’s demands.
Regular Maintenance Checks: Performing regular maintenance on your application server, like applying patches and monitoring performance, can help prevent issues from arising. Checking server logs regularly also helps you spot issues early.
Key Takeaways:
Effective troubleshooting in Maximo involves identifying and resolving issues quickly to maintain system stability. Here’s a summary of the main tasks involved:
By mastering these troubleshooting skills, you’ll be able to maintain a stable and responsive Maximo environment, ensuring smooth operations and minimal downtime.
Maximo includes the Integrity Checker, a tool for identifying database inconsistencies and data integrity issues.
To execute Integrity Checker, use the following command from the Maximo application server:
integritychecker.bat -action check
For Linux:
./integritychecker.sh -action check
This generates a report highlighting database anomalies.
| Issue | Example | Resolution |
|---|---|---|
| Missing Work Order Links | Work order references a deleted asset | Rebuild asset relationships |
| Invalid Inventory Records | Inventory stock doesn’t match purchase receipts | Run stock reconciliation |
| Orphaned User Data | User no longer exists but is still assigned work orders | Delete or reassign records |
Maximo Escalations provide a way to detect system issues and trigger corrective actions automatically.
| Scenario | Escalation Action |
|---|---|
| Work Order Delayed > 48 hours | Notify Manager via email |
| Inventory Below Safety Stock | Auto-Create Purchase Request |
| Unresolved Database Lock > 30 minutes | Automatically Release Lock |
Go to: System Configuration → Platform Configuration → Escalations.
Define an Escalation Condition:
workorder.status = 'INPROG' AND workorder.reportdate < current_date - 2
Example: Fixing Duplicate Work Orders Automatically
from psdi.mbo import MboConstants
if mbo.getInt("WONUM") in duplicate_list:
mbo.delete()
This script deletes duplicate work orders automatically when triggered by an escalation.
The Task Performance Monitor is a built-in Maximo tool for identifying performance bottlenecks related to slow queries and high-resource tasks.
System Configuration → Platform Configuration → Task Performance Monitor.| Issue | Detected By | Solution |
|---|---|---|
| Slow SQL Queries | High execution time in Task Monitor | Optimize query indexes |
| High CPU Usage by Cron Task | Cron jobs exceeding limits | Adjust frequency or split workload |
| Excessive JVM Garbage Collection | Slow response times in WebSphere | Increase heap size and optimize memory settings |
Maximo's System Properties allow administrators to fine-tune system performance and resource utilization.
| Property | Purpose | Recommended Optimization |
|---|---|---|
mxe.db.fetchResultLogLimit |
Limits the number of database query results to avoid memory overload | Set to 5000 for large databases |
mxe.mbocount |
Restricts the number of MBO objects loaded into memory | Reduce value if experiencing memory leaks |
mxe.report.birt.disableReportSecurity |
Disables report security checks for faster report generation | Set to 1 for internal-only environments |
System Configuration → Platform Configuration → System Properties.mxe.db.fetchResultLogLimit).| Scenario | Optimized Setting |
|---|---|
| SQL Queries Taking Too Long | Reduce mxe.db.fetchResultLogLimit to limit query size |
| WebSphere Memory Overload | Lower mxe.mbocount to reduce in-memory objects |
| Slow BIRT Report Loading | Disable report security using mxe.report.birt.disableReportSecurity=1 |
To ensure efficient troubleshooting in Maximo, administrators must master:
mxe.db.fetchResultLogLimit, mxe.mbocount) to enhance performance.After adding a new attribute to an object, the field does not appear in the application. What is the most likely cause?
The most likely cause is that Database Configuration has not been applied.
In Maximo, adding a new attribute in Database Configuration does not immediately make it available in the live database. The change remains only in configuration metadata until the database update process is executed. After that, the field may still need to be added to the application through Application Designer. Exam questions often test this sequence: first create the attribute, then apply Database Configuration, then expose it in the UI. A common mistake is assuming that creating the attribute alone is enough. If the attribute exists in configuration but is not physically applied, users will not see or use it in the application.
Demand Score: 84
Exam Relevance Score: 92
Users cannot access an application even though it exists in the system. What should be checked first?
Check the user's Security Group application permissions first.
In Maximo, application access is controlled through Security Groups, not directly through the existence of the application itself. Even if the application is configured correctly and available in the environment, users will not be able to open it unless their security group grants access. The administrator should verify whether the application is authorized for the group and whether the user belongs to that group. This is a common exam scenario because it tests the difference between system configuration and access control. The key clue is usually: “the application exists, but the user cannot access it.” That points first to Security Groups rather than database or UI issues.
Demand Score: 81
Exam Relevance Score: 88
An escalation is configured correctly but never executes. What should be checked first?
Check whether the Escalation Cron Task is active.
Escalations in Maximo depend on Cron Tasks to run on a schedule. Even if the escalation condition, action, and communication template are configured correctly, nothing will happen unless the related Cron Task is enabled and running. This makes Cron Task status one of the first things to verify during troubleshooting. In exam questions, this issue is often presented as “configuration looks correct, but nothing triggers.” That usually indicates the scheduler is inactive or misconfigured. The best troubleshooting approach is to verify the Cron Task instance, schedule, and activation state before reviewing deeper escalation logic.
Demand Score: 83
Exam Relevance Score: 90
A field was added to Maximo, but users still cannot see it in the application. What is another likely reason besides missing Database Configuration?
The field may not have been added to the application layout in Application Designer.
Even after the database change is successfully applied, a field will not automatically appear on the user interface. Administrators must place the field into the correct application tab, section, or screen using Application Designer. This is a common source of confusion because database structure and application presentation are separate layers in Maximo. Exam questions often test whether the issue is database-related or UI-related. If the field exists technically but is not visible to users, Application Designer is the next place to check. Another clue is when the field exists in the object definition but is missing only from the screen layout.
Demand Score: 80
Exam Relevance Score: 87