Hi Vasudeva,
please post new questions as a new topic.
You're correct, the perm of dbc can only be increased by decreasing the size of other databases or adding new disk space (=new node).
Only a few dbc tables can actually be modified, in your case the ResUsage*, DBQL*, EventLog, SW_Event_log.
Deleting old data from those tables (and copy it to some history database) is good practice and there should be alreday a job for this.
In your case the TransientJournal is by far the biggest table indicating there is a huge transaction running, you should investigate which job was causing this.
What is the max perm space of dbc and how much is currerntly in use.
SELECT
-- assigned perm space in GB
SUM(MaxPerm) / 1024**3 (DEC(10,2)) AS MaxPermGB,
-- currently used perm space
SUM(CurrentPerm) / 1024**3 (DEC(10,2)) AS CurrentPermGB,
-- currently used perm space based on skew
MAX(CurrentPerm) * (HASHAMP()+1) / 1024**3 (DEC(10,2)) AS SkewedPermGB
FROM dbc.DiskSpaceV
WHERE DatabaseName = 'dbc'
Dieter
Hi Vasudeva,
please post new questions as a new topic.
You're correct, the perm of dbc can only be increased by decreasing the size of other databases or adding new disk space (=new node).
Only a few dbc tables can actually be modified, in your case the ResUsage*, DBQL*, EventLog, SW_Event_log.
Deleting old data from those tables (and copy it to some history database) is good practice and there should be alreday a job for this.
In your case the TransientJournal is by far the biggest table indicating there is a huge transaction running, you should investigate which job was causing this.
What is the max perm space of dbc and how much is currerntly in use.
Dieter