on 01-08-2016 6:25 PM
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
User | Count |
---|---|
11 | |
6 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.