Has anyone else noticed this as a problem?
I have 2 customers, one with a brand new 184.108.40.206 install and one with an upgraded one.
They both have CABI 3.3 SP1 with hotfix 1 installed.
One customer runs scheduled availability reports and these "seem" to be unaffected.
But as part of a check I run every week I have noticed that since the upgrade, if I run a TopN Alarms Report (Top10) that they are nearly all "Unknown Alarms".
I have queried the reporting database and the alarm Title is indeed "Unknown".
I have a CA ticket open for this which is currently being worked but I am curious to know if anyone else who is running Spectrum 220.127.116.11 and CABI 3,3 SP1 + hotfix 1 might be having the same problem but just hasn't noticed yet?
If you could run a report to test and let me know the results that could be quite useful.
Ouch ... thanks for the hint. I will check some installations and report back.
From the description i see that you are seeing the alarm title as "Unknown" in the report. If this is the case follow these steps on 18.104.22.168
1) Go to mysql prompt and truncate the below tables in reporting database:
2) truncate table alarmtitles;
3) truncate table pcause;
4) stop tomcat
5) reinitialize reporting database on all landscapes
6) start tomcat
After following the above steps, you will be able to see correct titles in alarm reports.
Thank you for responding.
Could you be more specific about what you mean by "reinitialize reporting database on all landscapes"
The reporting db is not per landscape - it resides on the One-Click with SRM. (as I understand it : SPECHOME/mysql/data/reporting)
What I want to avoid is deleting all content from BOXI as my customer has many business critical scheduled reports - and we don't want to have to recreate these again!!
If you have installed reporting Manager specific to each SpectroSERVER (in Distributed Environment), you need to reintialize Reporting DB on each Reporting Manager server. Usually we install reporting manager along with Oneclick server, so it resides on oneclick server as mentioned by you.
If you have one Oneclick server (with reporting manager - SRM), then it is enough to reinitialize the reporting DB on that particular server. (Refer Database Management guide for steps).
BOXI (CABI) database is different from Reporting Manager Database. CABI fetches data from reporting DB. Reinitializing Reporting DB will not effect CABI Database.
Hope this helps...
I have since been directed to this Tech Bulletin by Support.
Rather suprisng that this issue seems to have been around since 9.3
I'll report back when I've tested this.
Why does everyone keep addressing me as Pearson when I sign my threads/discussions with my first name Lesley?
I don't mind but I do find it rather bewildering....!
I followed the steps in the Tech Bulletin but I a) forgot to initialise the SRM reporting db and b) hadn't noticed your addition which includes truncating the pcause tables
At this point, I checked the alarmtitle table and everything looked good - it was starting to be populated.
To be thorough, I went through the steps again but did all of the steps including the reinit of the reporting db and the truncating of the pcause table.
Having started the tomcat service nearly an hour ago...I see nothing in either of those tables - and that concerns me.
How long should I be waiting before I start to see something because perhaps I'm being impatient - but I would have expected to see something/anything after that much time.
I've removed the servers from being monitored (Spectrum Status page in One-Click Administration > Report Manager) and then re-added them.
I then saw the pcause and alarmtitle tables start to be populated...even though the Last Event Time still shows as no events processed.
I'll leave it overnight and see how it looks in the morning.
DId you ran the rpmgr initialize like this
RpmgrInitializeLandscape.sh root root -initHist 90 -all --> This will fetch last 90 days of data from ddmdb incase your ddmdb stored 90 days of data
Incase you ran like this
RpmgrInitializeLandscape.sh root root -all ---> It will not fetch any previous data from ddmdb.
Incase you ran the first one and still see no events processed i suggest looking for any exceptions in stdout.log.
Thanks for the all the help on this one.
Yes, I had run the report db init (and correctly), it's just that Spectrum gives no indication that it is actually doing anything.
The status page had shown no events processed for over an hour.
After leaving it to do it's own thing overnight, I ran reports the next day and the data had re-populated with the correct alarm title and pcause information
I have suggested to CA Support that they may want to update this tech bulletin to include checking the pcause table
Many thanks for your help resolving this issue.