Problem in Planning Cube Requests

[former_member212742]

HI All,

In the Planning Cube when ever we save data, some new requests are being created without turning the old requests to green.

This considerably increase the number of requests as we save the data in the cube.

Kindly let me know if any one has encountered the same issue and suggest any feasible solution.

regards.

Shafi.

[Former Member · Accepted solution]

Hi ,

When you enter plan data ( less than 50000 records )from report, A request will be added to your cube and this will be in yellow status by default.U wil hv to make it to green manually.

If you enter more than 50000, request will turn to green automatically.

Thanks

Satya

[former_member212742]

Yeah i can understand that it only turns green after specified no. of records.

But the problem is first i am saving 5000 records to the cube. So it creates a request with a yellow sign. Then i post amother 10000 records. for this it will be added in the existing prev request right. But instead it creates a new request with a yellow sign. Totally there are 2 requests now in the cube though the records are only 15000 which is less that 50000.

if i again save it another set of 5000 request a third req is added and so on ...

Kindly help me in this issue.

[Former Member]

Hi,

Whenever the data is loaded into cube a new request ID is generated, as per your above query for all 5000, 10000 data loaded in to cube two seperate request ID will be created. (if you load both the data records at one stretch ie 15000 then it will be one request ID)

If you load 50000 records at one stretch it will be taken as one request ID. If you load 75000 records it will be treated as two request ID. one with 50000 and other 25000.

Hope it is helpful.

[Former Member]

hi Saif,

What Vinay said was obsolutely right.. this might answer your doubt

Thanks

Satya

[Former Member]

Hi,

I have a doubt on this. Isnt it supposed to write the data in the same request?

Ideally, data requests in transactional cubes stay open until the number of records in the data request exceeds 50,000. When an application is writing data into the request and the limit of 50,000 records is exceeded, the data is stored and the request is closed. (Thus a request can actually contain more than 50,000 records.

Example: If a request already contains 49,900 records, and someone is using a BPS layout to store 500 records at once, then all the records are into the same request of this InfoCube so that the request contains 50,400 records). As soon as the number of records in this data request exceeds 50,000, this request is closed and the request can be rolled up into defined aggregates if any exist (in asynchronous mode).

Physically, the design of these InfoCubes may differ with respect to indexing and partitioning (depending on database). For an Oracle DBMS this means, for example: no bitmap indexes on the F fact table and no partitioning of the F fact table by packet dimension (initiated by the BW). Rollup and definition of aggregates, compressing, and so on, is still possible.