RE: issue with report generation issue

All:

Just as a follow up to the mail I sent yesterday, what I found out this morning is that all reports generation based on
the 1st cub processing are successful, after I moved the cube processing time back to 2:30 AM. This probably tells
us that we need to leave enough time between the last scraping and the cube processing, although what caused
the blow-up yesterday is still mysterious. The lesson is when it is working, do not make changes, or it may break.

There are still a few format issues I need to fix.

Yan
-----Original Message-----
From: Wang, Yan
Sent: Monday, April 30, 2001 10:37 AM
To: Gaskill, Chris; Reitmeyer, Jay; Smith, Matt; Piazze, Tara; Tonks, Colin; Hyde, Chris; Dronet, David; Zhang, Eddie
Cc: Alexander, Kim D; Hylton, Angela; Chiu, Lindon
Subject: issue with report generation issue

All:

As you all noticed that on many of our morning reports today "NA" were put there as today's data,
that means at the time those reports were generated today's data were not in the cube, so the report
engine put "NA" there. However, by looking at the Retrieved_DTM field in the Meter_Usage_Stat
table in our database it showed that the scrapings were successful for all west pipelines as of
11 PM last night. When I checked the history log of cube processing, the cube were processed
successfully both times at 11:59 PM last night and 6:30 AM this morning, respectively.

We process cube twice in the morning, the purpose of second processing is to grab those manual entry data.
Reports generated after second processing (CIG_WIC, SoCal, and Rockies Production) were all successful.
Only those reports generated after first processing are problematic. So only two possibilities I can thick of can
explain this: 1) Although processing log showed success, it did not actually grab newly entered data to the cube with
the first procssing. 2) Those data were not in the database table at the time of first processing.

I believe the true reason has to be one of the above. But my investigation so far can not give me any clue as what
could have caused one of above. Because if 1) was true, we'll need ask Microsoft on the consistency of cube processing,
cube processing has never failed us before. If 2) was true, it could not explain why in the Retrieved_DTM column of
Meter_Usage_Stat table showed us that before the first processing the data were already in the database.

My intention to move the first processing time from 2:30 AM to 11:59 PM was to have more time between the two processing
to take care of the growing number of reports we are generating. I thought 1 hour difference between the last scraping and
cube processing should be enough. That was the only change I made last week and we had not experience such a problem
before this change.

So without knowing the true cause of the problem, what I am going to do is to move the 1st cube processing
time back to 2:30 AM to see if it corrects the problem. I'll try to be here early tomorrow morning to make sure
all the reports run fine.

I welcome your suggestions and comments on the possible cause of the problem to suggestions on how to prevent this from
happening again.

Thanks

Yan x33228