cancel
Showing results for 
Search instead for 
Did you mean: 

MII Database tables [XMII_DBGVARS] and [J2EE_CONFIGENTRY] Very Large!

dan_kellackey
Explorer
0 Kudos

After some DB house cleaning I now have these two table as the largest in the database.  Googling gives me no information, and I wanted to see if anyone know what purpose they server, and if it is safe to TRUNCATE them in the database.  I found old entries in other tables such as [XMII_DBGLOGS], which had old info from go-live 4-years ago.  Huge reduction in space, so wondering about these other two tables.

We have four MII instances: MII v12.2 (3), MII V14.x (1)

Here are a few example rows from each:

[XMII_DBGVARS]

TRXID         SEQNUM    STAMP                   VARNAME                        VARVALUE    VARTYPE

25181402    5066288    1409230286539    ProductionLineLoop.CurrentItem    1    integer

25181402    5066278    1409230261520    ProductionLineLoop.CurrentItem    1    integer

25181402    5066268    1409230246620    ProductionLineLoop.CurrentItem    1    integer

25181402    5066258    1409230226312    ProductionLineLoop.CurrentItem    1    integer

25181402    5066248    1409230206497    ProductionLineLoop.CurrentItem    1    integer

25181402    5066238    1409230187837    ProductionLineLoop.CurrentItem    1    integer

Only one of the four instances has data in this table, which is sitting @1.018 GB in size!   MII v12.2

[J2EE_CONFIGENTRY]

CID    NAMEHASH    ISFILE    NAME    DTYPE    VBIGINT    VDOUBLE    VSTR    VBYTES    FBLOB

-9223372036854775700    1489654279    2    CFG_MODIFICATION_TS    22    1228822109236    0    NULL    NULL    NULL

-9223372036854775699    -1731816848    0    isInUpgradeMode    25    0    0    NULL    NULL    NULL

-9223372036854775699    1489654279    2    CFG_MODIFICATION_TS    22    1228822109236    0    NULL    NULL    NULL

-9223372036854775698    1489654279    2    CFG_MODIFICATION_TS    22    1228822109236    0    NULL    NULL    NULL

All four instances have around 650 MB of data in this table. 

It had been about four years since a contractor installed the MII application and developed the initial screens/transactions.  Unfortunately, not all cleanup and set was done.  Recently we started having some disk space pressure, which prompted me to start looking at table size.  Correct, I should have been monitoring already, but DB admin only one of many hats I wear.

In the most dramatic instance of table clean up, the database size was reduced by 16 GB of useless space!  The main culprits were the tables [XMII_JCOMESSAGES] and [XMII_TRANSACTIONS], both of which I truncated, and corrected the Message and Scheduler Persistence and Logging to catch errors only.

If anyone does answer and suggest truncation, please give good reasoning and any web links to support your recommendations.

Thank,

Dan K

Accepted Solutions (1)

Accepted Solutions (1)

former_member185280
Active Contributor
0 Kudos

I think you are safe cleaning out XMII_DBGVARS. This looks like it and the other *DBG* tables store some data when you are debugging a transaction in the workbench. I did some testing on my own to confirm this. I don't think there is any data in there needed/worth keeping.

I think J2EE_CONFIGENTRY might be an important table for Netweaver. You might have to ask in the Netweaver forums about that one.

Regards,
Christian

dan_kellackey
Explorer
0 Kudos

Thank you for looking into my questions and doing a little testing, I appreciate it!  I was thinking along the same lines about these tables.  With a copy of the database, I feel comfortable truncating the XMII_DBGVARS table.  As you suggest, the XMII_CONFIGENTRY table may be important and I will leave it for now.  I will revisit if it starts to cause disk usage pressure.

BR,

Dan K

Answers (0)