Workaround for GAP in UPL Data

[IanStubbings]

Hi

The response by Alexander looks to be the long term solution for my issue but I'm just wondering that for a short term workaround to enable the extraction of data, that the job and program /SDF/UPL_PERIODIC_EXTRACTOR could be triggered to enable the purge of the /SDF/UPL_LOG entries.  Recently this job has been failing due an unknown variant (not sure if this was to do with the SP12 upgrade or not) and therefore I have removed the variant.

I'll check the rerun of the job tomorrow and see if my issue goes away as a result but if anyone has any thoughts on the subject in the meantime, please jump right in!

Thanks

Ian

[RiabovAleksandr]

Hello Ian,

please don't do anything to /SDF/UPL_PERIODIC_EXTRACTOR job.

This jobs takes data from raw table and stores to transparent table /SDF/UPL_LOG (so, prepares the data to be fetched by UPL extractor).

If you have done something to it - delete the job entirely and reactivate UPL.

The best way would be from SolMan. If not possible, go to CCAPPS -> UPL Control. Deactivate - Activate again.
Job wil be created again.

[IanStubbings]

Thanks for the speedy reply!

All I have done is to remove the variant that did not exist with the intention that the job will run in future as it cancels every day at the moment.

Is this job required for SP12?

[RiabovAleksandr]

Hi Ian,

let's clear things out.

this job is on managed system, right?

What is the SAP_BASIS?

How have you scheduled it?

Variants are just "purge days", so it is just a 1 number.

What is the status of UPL? try FM: /SDF/UPL_SYSTEM_STATUS (on managed system, of course)

let's strart with this first.

[IanStubbings]

Hi Alexander

Yes, on a managed system (Q system for testing purposes actually), SAP_BASIS is 731 SP5.

The job would have been scheduled previously as CCLM SP7 was configured but not really used. I was going through the process of configuring it when our SolMan system was upgraded to SP12.

Status as below - which I found interesting.

UPL is switched on and has been collecting data for the last 128 days but 14.09.2014 is missing and hence the issues I am facing.

Realistically though, it sounds as though I need to ditch this historic data and focus on the previous few days. Due to constraints on OSS note application though, it may be several weeks before the note you suggested gets applied to the QA system and therefore, I'm looking for a workaround.

Will I just have to restart UPL? Will that delete and rebuild this table?

Thanks

Ian

[RiabovAleksandr]

Hello Ian,

no, if you stop the UPL and start it again, nothing will not be deleted )

Just restart it.

then run the FM again. As soon as it shows good status, wait for extractor run.

Hope is runs fine.

I doubt it will fetch the data.

By the way, is the data available in St03n for 14.09.2014?

I think you shouldn't concentrate on 1 day.

By the way, I suppose the table is so enormous (dozens of GB). You'd better not to keep so much data. We recommend 14 days only.

[bjoern_panter]

If you stop UPL at any time of the day, the collected data for THIS day until TIME of STOP, will be deleted. As soon as you restart UPL, then it continue collection for this day.

But this is also not a real problem.

Another possibility is just use SM37, pick up the job, either

- cancel and reschedule this job, but please with the correct authorizations

or

- redefine the date parameter

14 days is enough, if Solman is attached... 🙂

[bjoern_panter]

Please start tcode SCOV

Select "consistency checks"

select check and execute (have a look unter monitor)

then try to repair.

[IanStubbings]

I've just checked the SolMan system again and noticed that the 0SM_UPL cube has been filled multiple times today. This must be because of the OSS note 2032198 which was applied this morning to address an issue with the extractor running in an endless loop.  This added code to insert a dummy entry and has had the effect below:

Notice day 14.09.2014 with the dummy entry but also for the 21.09.2014. There are also lots of others until November 2014.

Anyway, this has now extracted data up to the 14th Jan 2015 which is the limit in my /SDF/UPL_LOG table and the extractor now has not run since 10:49 this morning - two issues possibly fixed with the one note.

I'm not entirely sure why it has stopped at this date though. I'm assuming it was when the /SDF/UPL_PERIODIC_EXTRACTOR job stopped running (SM37 logs don't go that far back) so now I have removed the (non-existant) variant, I'm expecting it update the /SDF/UPL_LOG so it is up to date, and then to purge the days to 14 and ultimately for the extractor to try to extract this data. 

I'll let you know what occurs tomorrow.

Thanks for all your help.

Ian

[IanStubbings]

Ok. So the /SDF/UPL_PERIODIC_EXTRACTOR job finished successfully and has removed all UPL data, similar to the effect of me restarting UPL - not ideal but I have most of the data in Solman anyway.  Although the program has a default of 14 days built in, I guess this wasn't enacted and therefore I have now created a variant to specifically keep 14 days - as suggested previously by anyway.

The extractor is yet to run today, but I expect the data from yesterday to be picked up and the days from the 14th Jan to have dummy entries created against them. Something to watch out for when configuring in the live system.

My next issue though is already apparent as I still require the data from 0SM_UPL to be pulled into the City Model and my job - SM_CCL:LUSG* is failng due to an unknown query.

I'll create a new discussion for this.

Thanks

Ian