Ken, In our environment we have Spectrum 9.3.H01 on RHEL5 also. And I have two OneClick servers serving customers load balanced by F5. On monthly/by monthly basis I do maintenance of reporting database aka SRM (installed on only 1 OneClick server) and not to be confused by CABI for ad-hoc reports to be faster and also to reclaim disk space back. Below is the procedure I use. please remember that you need free disk space equal to size of the largest file (usually events table) + a little (at least 5 GB) more to run the below commands.
Remember this is for Spectrum 9.3 H01 and can take several hours to complete. **Don't forget to SHUTDOWN TOMECAT else you will CORRUPT the database** [user@server]$ ls -lh $SPECROOT/mysql/data/reporting/event.* -rw-rw---- 1 spectrum spectrum 8.7K Jul 15 19:27 mysql/data/reporting/event.frm -rw-rw---- 1 spectrum spectrum 113G Jan 2 10:54 mysql/data/reporting/event.ibd # Stop tomcat [user@server]$ $SPECROOT/tomcat/bin/stopTomcat.sh [user@server]$ cd $SPECROOT/mysql/bin [user@server]$ ./myisamchk --defaults-file=../my-spectrum.cnf -t /opt/tmp -frCSa ../data/reporting/bucketactivitylog.MYI ../data/reporting/sm_attributes.MYI ../data/reporting/sm_customermhs.MYI ../data/reporting/sm_customers.MYI ../data/reporting/sm_guaranteeoutages.MYI ../data/reporting/sm_guaranteeperiods.MYI ../data/reporting/sm_monitormaps.MYI ../data/reporting/sm_monitoroutages.MYI ../data/reporting/sm_monitors.MYI ../data/reporting/sm_periods.MYI ../data/reporting/sm_policies.MYI ../data/reporting/sm_resourcecauses.MYI ../data/reporting/sm_resourcemaps.MYI ../data/reporting/sm_resources.MYI ../data/reporting/sm_schemaversion.MYI ../data/reporting/sm_servicehealth.MYI ../data/reporting/sm_slaperiods.MYI ../data/reporting/sm_slas.MYI ../data/reporting/sm_slmagreesto.MYI ../data/reporting/sm_slmlandscapes.MYI ../data/reporting/sm_slmmonitors.MYI ../data/reporting/sm_slmowns.MYI ../data/reporting/sm_slmuses.MYI ../data/reporting/sm_usersmhs.MYI ../data/reporting/sm_users.MYI [user@server]$ ./mysql --defaults-file=../my-spectrum.cnf -uroot -proot reporting mysql> optimize table model; mysql> optimize table handleractivitylog; mysql> optimize table alarminfo; mysql> optimize table alarmactivity; mysql> optimize table interfacemodel; mysql> optimize table ncm_config_text; mysql> optimize table modeloutage; mysql> optimize table event; mysql> exit [user@server]$ ls -lh $SPECROOT/mysql/data/reporting/event.* -rw-rw---- 1 spectrum spectrum 8.7K Jan 6 09:22 mysql/data/reporting/event.frm -rw-rw---- 1 spectrum spectrum 92G Jan 6 13:28 mysql/data/reporting/event.ibd *** At this point I usually reboot the oneclick server, you can also restart tomecat, if you do not want to reboot *** Saurabh Bohra O: 860-766-0842 | M: 860-385-3597 | e-mail: saurabh.bo...@espn.com -----Original Message----- From: Kenneth Kirchner [mailto:k...@kirchners.com] Sent: Thursday, March 19, 2015 12:37 AM To: spectrum Subject: Re: [spectrum] Server Size Your memory is pretty good, Dave. That's where the lion's share of the space was being taken up. 194GB if I remember right. -Ken > On Mar 18, 2015, at 2:34 AM, David Game <david.g...@uk.logicalis.com> wrote: > > Yup have a look in $SPECROOT/mysql/data/reporting (if memory serves) > > You should have lots of MySQL tables in there, most of which are sensibly > sized, then you'll have EVENTS.MDB which will be bigger than Kanye West's ego. > > If you keep defaults set on SRM and have a particularly "noisy" network you > will find that EVENTS.MDB and the associated log/lookup index thing will > often go into several 10's of GB. If you don't keep an eye on it, it can get > really unwieldy and the only way to fix it is to run "TRUNCATE TABLE EVENTS" > on the MySQL command prompt. Which will lose your historical event data and > get you back a shed-load of disk space. You can also set SRM to record most > stuff but NOT events if you want, due to the size the tables get to which is > why there's a separate check box for events on each landscape being processed > by SRM. > > Also keep those tables in mind when you're planning major release upgrades if > there's a change in DB table format as there was recently. You'll need at > least the same amount again in free space for the conversion process to work, > and obviously the larger the tables, the longer the upgrade process takes. > For speed of deployment against historic event availability, it may be wise > to just zero out the events database before a major upgrade and take the hit. > > Dave --- To unsubscribe from spectrum, send email to lists...@unc.edu with the body: unsubscribe spectrum saurabh.bo...@espn.com --- To unsubscribe from spectrum, send email to lists...@unc.edu with the body: unsubscribe spectrum arch...@mail-archive.com
