OBM postgresql DB grow a lot due to pg_largeobject

Idea ID 2743415

OBM postgresql DB grow a lot due to pg_largeobject

Hi,

OBM use postgres large object. Why not, but when rows are deleted large objects are not removed and our DB grow and grow a lot.

These tables use Large Objects.

c000_consrv_certificates
c000_resource_entry
c001_consrv_certificates
c001_resource_entry
cfg_instrumentation
cfg_pkg_deplbin
cfg_templatefile
event_sync_buffer
holdstore_event
marble_persist_1
marble_persist_2
marble_persist_garbage
pmi_dashboards
pmi_service_dashboard
pmi_template_details
pmi_uistate_details
premigration_backup_files
prevsyncdata
server_key_store
simple_blob
sis_profileinfo
syncpackages

Is it possible to manage that at OBM Level

BR

Thomas

 

 

Tags (1)
6 Comments
Honored Contributor.. Honored Contributor..
Honored Contributor..

I create case for this - MF report that this is not a MF problem 😀

https://softwaresupport.softwaregrp.com/doc/KM02170167

Workaround - use vacuumlo utility to clean DB.

Super Contributor.
Super Contributor.

not a postgres problem either , as it is  documented how to deal with large objects,isn' it  ?

Respected Contributor.
Respected Contributor.

 

Yeah, we got the same problem. A shame that microfocus refuses to address this bug.

In fact, a very simple work around would be to use bytea instead of large object in postgresql, but this must be done in the product.

Honored Contributor.
Honored Contributor.

Hi all,

26 millions of LO in 4 months and 60 GB of data locked.

We will try to understand what is really contained in these LO.

BR

Thomas

 

Acclaimed Contributor.. Acclaimed Contributor..
Acclaimed Contributor..

my customer run regulary vacuumlo so DB stays small.

here a snip of the script:

 

export PATH=$PATH:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/opt/OV/bin:/opt/OV/bin/OpC:/opt/perf/bin:/opt/HP/BSM/opr/bin


# directory
WORKDIR=/opt/TYB/OMi_Postgrestools
cd $WORKDIR

# Logfile
LOG=$WORKDIR/OMi_Postgrestools.log
TIMESTAMP="+%Y-%m-%d_%H:%M:%S"
DAYOFWEEK="+%A"

 

# start
echo `date $TIMESTAMP` $0 started >> $LOG

echo `date $TIMESTAMP` $PSQLBINDIR/vacuumlo ${PARMS} event >> $LOG
$PSQLBINDIR/vacuumlo ${PARMS} event 2>&1 >> $LOG
RC=$(( $RC + $? ))

echo `date $TIMESTAMP` $PSQLBINDIR/vacuumlo ${PARMS} rtsm >> $LOG
$PSQLBINDIR/vacuumlo ${PARMS} rtsm 2>&1 >> $LOG
RC=$(( $RC + $? ))


echo `date $TIMESTAMP` $PQLBINDIR/vacuumdb --all --full --analyze ${PARMS} >> $LOG
$PSQLBINDIR/vacuumdb --all --full --analyze ${PARMS} 2>&1 >> $LOG
RC=$(( $RC + $? ))

echo `date $TIMESTAMP` $PSQLBINDIR/reindexdb ${PARMS} -d event >> $LOG
$PSQLBINDIR/reindexdb ${PARMS} -d event 2>&1 >> $LOG
RC=$(( $RC + $? ))

echo `date $TIMESTAMP` $PSQLBINDIR/reindexdb ${PARMS} -d rtsm >> $LOG
$PSQLBINDIR/reindexdb ${PARMS} -d rtsm 2>&1 >> $LOG
RC=$(( $RC + $? ))

echo `date $TIMESTAMP` $PSQLBINDIR/reindexdb ${PARMS} -d mgmt >> $LOG
$PSQLBINDIR/reindexdb ${PARMS} -d mgmt 2>&1 >> $LOG
RC=$(( $RC + $? ))

 

# recreate indexes
echo `date $TIMESTAMP` /opt/HP/BSM//opr/support/checkIndices.sh --create >> $LOG
/opt/HP/BSM//opr/support/checkIndices.sh --create 2>&1 >> $LOG
RC=$(( $RC + $? ))

Micro Focus Expert
Micro Focus Expert
Status changed to: Waiting for Votes
 
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.