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 <[email protected]> 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 [email protected] with the body: unsubscribe spectrum [email protected]
