PR_SY_TMP table getting created automatically and holding System-locks
After 718 MLU upgrade we are observing a table called PR_SY_TEMP is getting created automatically and is holding instances whose pxobjclass is System--Locks.
Did not find any documentation on this in uprgade guide or is it present in the DDLs generated from pega media. Please let us know what is this table used for, and if its automatic creation isfine?
TABLE STRUCTURE ( taken from Oracle SQL developer)
( "PXCREATEDATETIME" DATE,
"PXCREATEOPNAME" VARCHAR2(128 BYTE),
"PXCREATEOPERATOR" VARCHAR2(128 BYTE),
"PXCREATESYSTEMID" VARCHAR2(32 BYTE),
"PXEXPIREDATETIME" DATE,
"PXINSNAME" VARCHAR2(128 BYTE),
"PXLOCKHANDLE" VARCHAR2(255 BYTE),
"PXOBJCLASS" VARCHAR2(96 BYTE),
"PXOWNERID" VARCHAR2(255 BYTE),
"PXSYSTEMNAME" VARCHAR2(64 BYTE),
"PXSYSTEMNODE" VARCHAR2(64 BYTE),
"PXUPDATEDATETIME" DATE,
"PXUPDATEOPNAME" VARCHAR2(128 BYTE),
"PXUPDATEOPERATOR" VARCHAR2(128 BYTE),
"PXUPDATESYSTEMID" VARCHAR2(32 BYTE),
"PXUSERHOST" VARCHAR2(64 BYTE),
"PYLABEL" VARCHAR2(64 BYTE),
"PZINSKEY" VARCHAR2(255 BYTE) NOT NULL ENABLE,
"PXCOMMITDATETIME" DATE,
"PXSAVEDATETIME" DATE
}
Does this have anything to do with Hazelcast, we have already disabled it in prconfig.xml
Pegasystems Inc.
US
cannot see this table in the DDL. Yes, this appears to be a copy of pr_sys_locks. Can you use Database>>Schema Change Tracking to see who created this table?
Rulesware LLC
US
Schema change tracking shows performed by MANUAL, but I doubt if we have explicitly executed the DDL.
Pegasystems Inc.
US
double check with whoever normally applying DDL in your company. I could not find any references at all to the table you mentioned here. All the schema changes from Pega should be captured in table pr_changelog table, can you find anything there?
Updated: 29 Jan 2016 19:23 EST
Rulesware LLC
US
We Checked the DDLs this TMP table is no there. However it seems to get created after we started using the appication
Pegasystems Inc.
US
It turns out this is created by the DefragSysLocksDaemon Jim Kelly has an SR for this. The db procedure that does the work is sppr_defragment_table. The Daemon is activated by default with only pr_sys_locks table is passed into the procedure. The DSS syslocks/defragEnabled is true by default but can be disabled if desired.