Dondon22 Respected Contributor.
Respected Contributor.
1063 views

OO 10.70 - Is it safe to Truncate OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS table

Jump to solution

OO 10.70 - I want to know if it safe to TRUNCATE these two tables OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS because they consume a lot of tablespace... I am using Oracle DB.

Thanks in advance...

In IT there is no Magic, just Logic ^_^
0 Likes
1 Solution

Accepted Solutions
AndreiTruta Outstanding Contributor.
Outstanding Contributor.

Re: OO 10.70 - Is it safe to Truncate OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS table

Jump to solution

The first link basically says the below:

(OO) Support Tip: Purge scripts not cleaning all data

In 10.x there are several types of data stored.  The purge scripts clean the execution data.

To clean remote Debug data or audit data there are operation/flows.

 There are also flows to purge execution data but we do not recommend them over the purge scripts becuase they are multiple layers of abstraction and DB calls.  The purge scripts will be much more efficient

This post focuses on Debug data from Remote debugging sessions.

The action of Studio remote debug will create data in the OO_DEBUGGER_EVENTS table. A graphical ilustration is also available in the OO Central Database Health tab in later versions of OO 10.x. With multiple authors creating and debugging flows, this data will continue to grow unless purged periodically. To maintain the database and purge this data, OO recommends to run the flow: 
/HPE Solutions [1.x.y]/Library/Integrations/Hewlett-Packard/Operations Orchestration/10.x/Database/Purge Debug Events

However this flow is time consuming for large data.  If this has not been done on a regular basis one way to manage it is to run SQL commands to remove the data and then setup the flow to run in a scheduled manner in the future.

SQL Command:

TRUNCATE TABLE OO_DEBUGGER_EVENTS;

The data in that table is not used after a debug run ends. So performing the above command is fast and safe. Make sure OO Central Service is stopped while interacting directly with the database.

Andrei Vasile Truta
5 Replies
Dondon22 Respected Contributor.
Respected Contributor.

Re: OO 10.70 - Is it safe to Truncate OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS table

Jump to solution
Thank you Andrei but I cannot open the first URL... says invalid URL param... can u upload the content in PDF... it will be a BIG HELP for me...
Thanks in advance... appreciate the support 🙂
In IT there is no Magic, just Logic ^_^
0 Likes
Micro Focus Expert
Micro Focus Expert

Re: OO 10.70 - Is it safe to Truncate OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS table

Jump to solution

Hi,

As long as there are no running executions  it is safe to truncate oo_step_log_bindings and as long as there are no active remote debugs it is safe to do so with oo_debugger_events.

That being said do note that by truncating oo_step_log_bindings you will lose ALL of the historical data regarding inputs and outputs of completed flows and as such the drilldown will not show any data for all executions. 

My advice is that before you start deleting data left and right try to have support look at your environment. If there is a problem  it is easyer to identify before part of the data has been deleted.

Hope this helps,

Vlad

AndreiTruta Outstanding Contributor.
Outstanding Contributor.

Re: OO 10.70 - Is it safe to Truncate OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS table

Jump to solution

The first link basically says the below:

(OO) Support Tip: Purge scripts not cleaning all data

In 10.x there are several types of data stored.  The purge scripts clean the execution data.

To clean remote Debug data or audit data there are operation/flows.

 There are also flows to purge execution data but we do not recommend them over the purge scripts becuase they are multiple layers of abstraction and DB calls.  The purge scripts will be much more efficient

This post focuses on Debug data from Remote debugging sessions.

The action of Studio remote debug will create data in the OO_DEBUGGER_EVENTS table. A graphical ilustration is also available in the OO Central Database Health tab in later versions of OO 10.x. With multiple authors creating and debugging flows, this data will continue to grow unless purged periodically. To maintain the database and purge this data, OO recommends to run the flow: 
/HPE Solutions [1.x.y]/Library/Integrations/Hewlett-Packard/Operations Orchestration/10.x/Database/Purge Debug Events

However this flow is time consuming for large data.  If this has not been done on a regular basis one way to manage it is to run SQL commands to remove the data and then setup the flow to run in a scheduled manner in the future.

SQL Command:

TRUNCATE TABLE OO_DEBUGGER_EVENTS;

The data in that table is not used after a debug run ends. So performing the above command is fast and safe. Make sure OO Central Service is stopped while interacting directly with the database.

Andrei Vasile Truta
Highlighted
Dennis Handly Acclaimed Contributor.
Acclaimed Contributor.

Re: OO 10.70 - Is it safe to Truncate OO_STEP_LOG_BINDINGS and OO_DEBUGGER_EVENTS table

Jump to solution

> I cannot open the first URL

 

The URL contains junk chars on the end.  The author can fix it by using post options > Edit Reply and use the hyperlink menu.  BTW it is to the Support forum and you'll need a SAID.

https://community.softwaregrp.com/t5/Operations-Orchestration-Support/OO-Support-Tip-Purge-scripts-not-cleaning-all-data/m-p/807249

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.