CA Service Management

How it works:

The service responsible for the purge is PslWriter. Each instance handles the agents under its responsibility.

Here the data purge procedure steps:

1. The GUI creates a request in t_purge_queue.
2. The first PslWriter instance that finds this request (it’s handled at the beginning of the cycle, so in effect, it’s the first instance that starts a new cycle) will create a list of purge agents in t_purge_agents. This is a list of all the active agents (status ‘ON’ in the system that are relevant to the purge date.
3. PSL goes over them one by one and checks if they have a state at the date you requested a purge at. Any agent that has a state is removed from the list. As long as there are agents in the list, it means that there are agents that don’t have a state at the purge line and so the purge can’t proceed.
4. Once all the agents are removed from the agents list, the request is marked ‘purge’.
5. There is an Oracle job that runs at 2 AM, which does the actual purge for requests that have that status (Set through the GUI).

Question:

Can we purge the raw data of a particular Adapter, raw data corresponding to particular resources, or raw data for a particular contract

Answer:

Either a contract can be purged or the raw data can be purged up till a certain date. There is no way of purging the 'raw data' of a specific contract, simply because the raw data does not belong to a certain contract, rather can be used (i.e. by registration) to multiple contracts.

If you are going to purge Raw Data till a certain date, please be sure that no valid data is lost. The contract may be locked to a certain date, and only once the data lock is effective, and verified that reports and dashboard are showing the information correctly, then the relevant events from the t_raw_data table may be removed up till this date.

Deleting data related to a certain adapter or resource is possible, but only running SQL delete commands to the database. It's not possible by the purge feature.

The problem with doing so is that if you have any other object within your environment (adapter/resource etc.) that this event you will get wrong results the next time a calculation is triggered due to the fact that the event type got deleted.

In order to avoid this, a full recalculation on the entire system will need to be triggered. If your environment is big, it might take some time...

Question:

I would like to archive a month (October) data but the report should display the result for that month as it displays currently, even after archiving.

 

Answer:

The reports are taking their results from the contracts calculation results, which are being stored in the database within the T_PSL% tables.

Therefore, as long as you need to see he reports results/data those tables should not be purged.

 

On the other hand, the t_raw_data table stores all the events that have been imported into BSI. The contracts calculations are done by using those events. Therefore, as long as the system is not calculated the data from this table should not be purged too.

Calculation Data Lock allows to lock calculations up till a certain date.

Since also no further recalculations will be made up till that date in this case the raw data up till that date may be purged. Detailed information on the data lock mechanism can be found in the BSI documentation.

Question:

How to keep the data of last 3 months only, but would be displaying reports for previous months too.

This is the reason why we want the data of that particular adapter/resource(linked to a particular customer) to be deleted but without affecting the reports.

Also all the objects of this customer are only used by this contract and not in any other contract. So I think there should not be any issue in deleting the data.

 

Answer:

Once you are certain that the entries being removed are not affecting any other contract then indeed the contract may be locked every month until 3 months before and only once the data lock is effective then the relevant events from the t_raw_data table may be removed up till this date. You should consider having a process of inserting the delete entries into another backup table in case something goes wrong with this process, which will require you to insert those entries again to t_raw_data.

The following delete commands delete from the raw data table all the events of a certain Adapter/Resource that their timestamp (i.e. were inserted into it) before the date specified.

Note you should change in it the ADAPTER_NAME/RESOURCE_NAME and the date and thereafter commit it.

 

delete from t_raw_data where reader_id in (select reader_id from t_readers

where reader_name = 'ADAPTER_NAME')

and time_stamp < to_date('01/01/2000', 'mm/dd/yyyy')

 

delete all raw data entries of a certain resource:

delete from t_raw_data where resource_id in (select resource_id from

t_resources where resource_name = 'RESOURCE_NAME')

and time_stamp < to_date('01/01/2000', 'mm/dd/yyyy')

Problem description: Records which exist in t_purge_agents are not calculated.

Possible reasons:

1. They’re in a separate instance that was not run. Solution: start the PSL instance where the contract/metrics are to be purged.
2. They have runtime errors. Solution: Fix the cause of the runtime error, so the engine can finish the calculation cycle, and proceed with the purge.
3. They’re suffering from starvation. Solution:
4. They’re in the process of recalculation. Solution: Wait some more time. Monitor the resources consumption for PSLWriter process.

If you can’t tell why they aren’t calculated, move them to a separate instance and force them to calculate. Once they are calculated, the purge process will move forward.

Problem description: After doing a raw data purge cannot load any data more

Solution: after changing the raw_data_pdl date backwards you should be able again to load data exactly as you can create and commit contract. Try restarting the AdapterListener.

If losing the already calculated data is acceptable, make sure that the new data is correct, with the following steps:

1. update t_rules_time_units.freeze_date_line to 1.1.2009 (the date from which you want the system to load
2. Clear all PSL