Troubleshooting performance issues
This topic describes the issues related to performance in Remedy Smart Reporting(Smart Reporting).
Issue symptom | Issue scope | Resolution |
---|---|---|
Accessing the Smart Reporting Console from the Mid Tier takes a long time. | The default entry page in Smart Reporting is set to Dashboards. Because loading the Dashboards takes time, launching Smart Reporting becomes slow. |
|
When IT Service Management users who are not administrators run reports in Smart Reporting, the report takes a long time to fetch the data. | A row-level security clause is added to the SQL query of the report, which causes the report to take a long time to fetch the data. | Disable the row-level security implementation as described in the following steps.
|
Smart Reporting is running very slow. The navigation from one screen to another takes a long time. The CPU and RAM usage of Smart Reporting Tomcat is very high on the server. | This behavior is observed due to the size of Smart Reporting database. For long running sessions of Smart Reporting, the size of the configuration database can increase. | The table below explains the workarounds for database tables. |
Workarounds for database tables that cause Smart Reporting to run slow
Issue symptom | Issue cause | Issue workaround |
---|---|---|
Event and Event Archive | The Event table stores all Yellowfin usage data, such as user login, running reports, and import and export information. This data is used for auditing purposes only. The Event Archive table stores the archived event data. The data from the Event table is moved in this table after a specific time period. |
Now, the Smart Reporting administrator can see the user audit trail information for the last 60 days only. The rest of the audit trail history is deleted. |
DocumentData | Stores report-related data. The table does not store the metadata, but stores the actual data such as cached report results sets. Note: Do not truncate the DocumentData table directly. | Shrink the table through the user interface by disabling report caching for each relevant report category. Alternatively, you can modify the record in the database directly by running the following query:
This setting ensures that the report cache does not increase again. You can also run the following query to identify what is stored in the table including the data count:
|
ReportInstance | Stores all the historical versions of the report. | Run the following queries to clear the table and keep all the KPI reports and cached reports intact:
These commands ensure that the records are not created in the ReportInstance and the ReportInstanceFilter table each time a report is run. |
Comments
Log in or register to comment.