This document contains official content from the BMC Software Knowledge Base. It is automatically updated when the knowledge article is modified.
Remedy AR System Server
Smart Reporting Remedy
Smart Reporting All versions
Smart Reporting performance issues are observed. Navigation is very slow in Smart Reporting Console.
Reproducing the Issue:
Cross Launch to Smart Reporting from Midtier/Smart IT takes longer time than expected.
Smart Reporting navigation is very slow.
Smart Reporting DB is full due to cache
As loading the Dashboards will take time, slowness is observed while launching smart reporting. To fix this, change the default home page to either ‘Timeline’ or ‘Browse’.
For a user who has never accessed Smart Reporting – get entry page as ‘Browse’
For a user who has accessed Smart Reporting without making any changes, for Entry Page, in Settings – get entry page as ‘Browse’.
For a user who accessed the Smart Reporting and changed the Entry Page, in Settings – get entry page as set in the display settings by user.
If the user changes the personal display preferences, then the global settings do not apply to the user. To update the default entry page for all the users, use the below query in the smart reporting database:
UPDATE Configuration SET ConfigData ='Browse' WHERE ConfigCode = 'DEFAULTENTRYPAGE'
AND IpOrg = 1
Note IPOrg 1 is for default org, change the iporg value while updating this for cient orgs. Each client org will unique Ip Org value.
Restart the Smart Reporting service and Default entry page = ‘Browse’ will be applied globally to all the users.
- If Navigation is Slow in the Smart Reporting Console, then check the below steps:
- Apply the tomcat tuning following the below:
- Check the size of Event, Event Archive and DocumentData tables in the Smart Reporting database.
Event table:This table stores all YF usage data, such as ; User logins, Running reports, Imports/exports. This data is all used for auditing only.
EventArchive table: This table stores all of the archived event data, so the data here is simply data that was moved from the 'Event' table after a specified period.
There is a possibility that Event and Event Archive tables count might go to some millions of rows. We can straight away truncate both the tables.
Truncate table Event;
Truncate table Eventarchive;
Apply the below tuning to keep the number of records in the Event and EventArchive tables under control, this is good practice because these tables can get quite big as they record many different types of Yellowfin events.
The way to create these 2 jobs and configure the number of days is by running the following 2 queries, keeping in mind that the last value of each INSERT query represents the number of days.
1. Archive tasks from the EVENT table, the job runs every day, searches for events older than xnumber of days ( eg. 30 days).
INSERT INTO Configuration
VALUES (1, ‘SYSTEM’, ‘EVENTMAXDAYS’, 30)
2. Delete records from the EVENTARCHIVE table older than x number of days ( eg. 60 days).
INSERT INTO Configuration
VALUES (1, ‘SYSTEM’, ‘EVENTARCHIVEMAXDAYS’, 60)
Again, value 1 is for default org, change the value to Ip org of the tenant.
DocumentData table: This table stores a lot of report related data. Not meta-data, actual data. Such as; Cached report result sets. There are a set of delete queries to shrink this table. I have attached it here. Do not Truncate Document Data table Directly.
Once the document data is cleared, set the report folders option “Keep the latest result set”.
This has to be done for all the folders manually or with the below sql we can apply this setting for all the folders:
UPDATE ContentManagement SET VersionHistoryRequiredFlag=false;
This setting will make sure the report cache does not grow again. With the above configuration, smart reporting performance should definitely improve.
If the Slowness is observed while refreshing the reports, disable the RLS implementation and increase the API timeout following the attached.