Replies:

Hi Kyle,

O.K. so I'm nearly 3 years replying to this post but none the less......

I agree that tune tables is a very necessary and useful tool in order to improve query performance.

Where it does fail in my opinion, much to my disappointment is that the tune table data is stored within the actual class rather than elsewhere. This causes a major tune table flaw for classes that are mapped over 2 or more namespaces as the tuning needs for one namespace could and often is completely different for the tuning needs of the other namespace.

Are you aware of any ways to get around this problem please?

Hi,

It would seem that your REGINUS database expansion size has been set to 1000, this can be checked via the SMP using System->Configuration->Local Databases and clicking on the relevant database link.

I would hazard a guess that your cachetemp database has an expansion size of 0 which is the system default hence why it is growing at a lesser rate.

If you run ^%GSIZE in the relevant namespaces then you will be able to see which globals are taking up so much space.

There is of course the possibility that you had work objects/globals being created that have since been deleted and therefore you could have a lot of empty space in your database. This can be resolved using both Database Compact and Truncate. These options can be found in the SMP under System->Databases and clicking on the relevant database link.


 

I personally would dismount and then take a duplicate copy of the relevant IRIS.dat or Cache.dat at an OS level, then mount them both as separate databases.

I would then delete the globals from 1 and then the the routines/classes from the other.

Then remove any inapropriate namespace mappings if necessary.

Followers:
Steve has no followers yet.
Following:
Steve has not followed anybody yet.
Global Masters badges:
Steve has no Global Masters badges yet.