Compact Repository model

[rupertkiwi]

Our EA repository (SQL Server) is getting quite large and performance has become quite slow.

Does anyone know how to compact a DBMS model to improve performance? Not a .eap.

Thanks,
Rupert

[qwerty]

You should ask your DBA. He should know. If he'd doesn't: fire him and hire another one.

q.

[Geert Bellekens]

Rupert,

In modern databases there is not really a linear correlation between database size and performance.
You DBA might be able to reduce the size by removing unallocated space, but I'm pretty sure that won't do anything for your performance.

One of the things you might want to look as is the auditing feature. That is known to bloat the database and cause performance issues.
Other then that, it is often more of a network issue then it is a database issue.
If you ask your DBA to monitor the performance on the database he will probably say that there is nothing wrong on the database side and that everything runs smoothly.

EA typically sends hundreds of tiny queries to the database, so you might want to ask your DBA to tune the server for this type of usage

Geert

[Nizam]

The auditing records does show down EA performance, as Geert pointed.  In one of my engagements,  the size came down from 3.6 GB to 700 MB, after clearing the audit records, and old baselines.  We saw the Oracle DB based EA performing better after that.

Also in such massive backlog, clear logs farrow didn't help and we've to clear the logs directly in the database (after backing up )
Nizam

[rupertkiwi]

Thanks everyone for you replies.

I also received a reply from SPARX support:

1. Turn off Auditing
2. Run a Project Integrity Check
3. Temporarily Disable any add-ins.

Rupert

[Nizam]

Turning Off Auditing will help, but please consider clearing your old logs using 'Clear Logs' utility.

[Uffe]

Hello Rupert,


As others have pointed out, there are some EA features which cause database bloat when used without due consideration for maintenance. To this I would like to add one which doesn't cause bloat but which can cause drastically reduced performance: model views.

A model view is like an alternative project browser which displays only a subset of what's in the project based on some query. It is possible to create auto-refreshing views and set them to refresh up to once a second, which (depending on the nature of the query) can cause the client to grind to a halt.

If you have a situation where some users experience a substantially slower client than others, this is worth a look. I've had to clobber these things in the past, from users who swear blind they haven't ever been into that menu (meaning they fiddled with it, forgot all about it, and are now too embarrassed to own up).

HTH,


/Uffe