TS6.5 and eventsubsystem

Valentine

How much space does eventsubsystem require using RDMS?
I hope it won't grow as fast as a flat-file DB.

I've submitted the case to support, w/o any luck. Can anybody tell me, how much space is occupied on your prod server?

foxman

There is the million dollar question. I asked the same thing of support and here is what I got. My question first then the answer,

1. What is the recommended size for events Database:

If you are using the openJMS.db (HyperSonic) it is like a flat file and will continue to grow there is no recommended size.

2. What does the size of this DB depend on ? e.g. peak number of concurrent submits ? etc.

This is based on the amount of messages that is passed to the database. These messages can be from Data Deploy or search

3. Is there a way to calculate this? (maybe based on the number of users? or content size? or submits ?)

No not really

4. What rights does the user need (does it dynamically create tables other objects etc)

There is a SQL script that you run for DB2 Oracle MySQL, and MS SQL server that will create the tables

5. What is the expected impact on space requirements as opposed to the existing file (halving; quartering, 10%)?

In what regard do you mean space requirements (to the openJMS or to a RDMS)

6. What ability is there to configure the amount of events being captured?

None the event subsystem is internal to TeamSite and the messages it passed to the DB make no sense to a user on to TeamSite

7. What is the business problem this 'new' event environment is expected to solve (ie why has interwoven included this feature and how might we
leverage it?)

For TeamSite 6.5, if you want to use the search function or use DAS in data deploy

Anyway, after wasting my breakfast time reading that, I decided to suck it and see. We set up a SQL 2000 DB on a 2gb partition and it seems fine now. I believe that the flat file grows so quickly because of a BUG in the opensource DB system that was used, and I am advised by support that the next version will drop that and go to MySQL out of the box.

I know that to tell the DBA's and Infrastructure people that when they want to calculate size, they should use the 'no not really' method PROBABLYwont cut it, (Im still shaking from the dresssing down that I got - thanks support!) but that seems to be the best way...ie: take a disk partition it, double it, divide it by your shoe size and hope like ****.

Of course, if support havce a better formula, Im all ears, but they wont return my emails now.

Andrew

Edited by foxman on 11/02/05 11:46 PM (server time).