SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post bug reports and the status of reported bugs
Post Reply
User avatar
Steve Vincent
Site Admin
Posts: 1054
Joined: Mon May 12, 2008 8:33 am
OLAP Product: TM1
Version: 10.2.2 FP1
Excel Version: 2010
Location: UK

SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post by Steve Vincent »

ViewCreate when used in a TI does not always create the view with the dimensions in the correct order. It appears to use the order as picked in the "Reorder Dimensions..." dialog and this causes the view to corrupt. When a TI tries to use the view to zero / load data, it will crash the server after consuming all it's available memory.

Initial reponse from Cognos was it's a known bug and has been fixed, awaiting reply from Engineering to confirm in which release before next steps can be discussed. That was 2 weeks ago, still awaiting...
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator.
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
User avatar
Steve Vincent
Site Admin
Posts: 1054
Joined: Mon May 12, 2008 8:33 am
OLAP Product: TM1
Version: 10.2.2 FP1
Excel Version: 2010
Location: UK

Re: SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post by Steve Vincent »

Had a call about this 10 minutes ago. Engineering believed it was one of the 9.1 releases when this got fixed. Had the usual "Can you upgrade?" conversation but we cannot do that as it'd take months to do and involves other businesses that will not do it. Surprised to be told that they would see if a hotfix for 9.0 can be created to replicate their fix for it in 9.1 :o

Stay tuned.
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator.
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
Dave
Posts: 6
Joined: Wed Jul 30, 2008 12:28 pm

Re: SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post by Dave »

After running on 9.1.3 for quite some time, we're now running into this same problem. On 9.0 we never experienced this.

We've got quite a few re-ordered cubes, and none of them gave us any problem in a new or existing TI process.

Now 1 cube, which wasn't even recently re-ordered, is causing a problem in an existing TI process. The TI uses the wrong (and modified) dimension order instead of the original order. Strange thing is that this process has been running OK for a long time, and is now unexplainable suffering from the bug described.

Awaiting feedback from the helpdesk.
Dave
Posts: 6
Joined: Wed Jul 30, 2008 12:28 pm

Re: SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post by Dave »

We have the same problem, running 9.1.3. So the fix in 9.1 apparently didn't quite happen yet ?

In the past we've done a reorder of dimensions frequently and never ran into this issue. Even better, the cube which is now showing this problem, wasn't reordered recently. It was reordered in the past, there are a lot of TI's running on it none of them showing any problem before or after the reordering.... till recently the above described problem kicked in.

I have no idea what triggered this change. But now the views are indeed taking the "reodered" dimension list instead of the original list, causing TI's to hang.

I logged it at our helpdesk, awaiting their reply.

Dave
User avatar
Steve Vincent
Site Admin
Posts: 1054
Joined: Mon May 12, 2008 8:33 am
OLAP Product: TM1
Version: 10.2.2 FP1
Excel Version: 2010
Location: UK

Re: SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post by Steve Vincent »

I've had an update from Cognos on this. Long winded but the essence is they partially recreated the issue but not the server crash. A few things were different in their test to what i had so i've made those changes and managed to recreate the crash again. I've just sent that model back and we'll see where we go from there. I would suggest if anyone has the same issue on a later version than 9.0.3 that if they log it with Cognos to quote this fault ref to avoid duplication of effort.
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator.
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
User avatar
Alan Kirk
Site Admin
Posts: 6606
Joined: Sun May 11, 2008 2:30 am
OLAP Product: TM1
Version: PA2.0.9.18 Classic NO PAW!
Excel Version: 2013 and Office 365
Location: Sydney, Australia
Contact:

Re: SR#11-81288341 - TI - TM1 9.0 SP3 182 - Corrupt ViewCreate

Post by Alan Kirk »

I'm afraid that I can't reproduce this one. The following test was done on a cube without rules; you haven't indicated whether your does or not and in any case if it is rules causing the problem there's probably no way of telling whether it's rules in general or your specific rules. (But if it does have rules I'll run a further test on a cube that has them if you'd like.)

A cube of 12 dimensions was used. My first attempt to reorder the dimensions yielded a gain of 0.2% of memory, the second 0.5%, at which time I recalled why I never bother doing it. However I selected the 0.5% one and did a data save.

I then created the following process, which was run both before and after a reboot of the server (with the relevant AsciiOutput lines commented out):

Prolog

Code: Select all

SC_CUBE = 'PNL';
SC_N_SUBSET = 'BugTest90';
SC_VIEW = 'BugTest90';

SC_VERSION_TARGET = 'Fcst Q1';

ViewDestroy ( SC_CUBE, SC_VIEW );
ViewCreate ( SC_CUBE, SC_VIEW );

ViewExtractSkipCalcsSet ( SC_CUBE, SC_VIEW, 1 );
ViewExtractSkipZeroesSet ( SC_CUBE, SC_VIEW, 1 );

l_Dim = 1;

While ( l_Dim <= 12);

    s_Dim = TabDim ( SC_CUBE, l_Dim);

#   AsciiOutput ( 'C:\Temp\PreRebootOrder_ViewCreateAndUseProlog.txt', s_Dim);
   AsciiOutput ( 'C:\Temp\PostRebootOrder_ViewCreateAndUseProlog.txt', s_Dim);

    SubsetDestroy ( s_Dim, SC_N_SUBSET);

    If ( s_Dim @= 'Version');

        SubsetCreate( s_Dim, SC_N_SUBSET);
        SubsetElementInsert( s_Dim, SC_N_SUBSET, 'Budget', 1);
        
    Else;
        SubsetCreatebyMDX( SC_N_SUBSET, '{TM1FILTERBYLEVEL( {TM1SUBSETALL( [' | s_Dim | '] )}, 0)}');
    EndIf;

    ViewSubsetAssign(  SC_CUBE, SC_VIEW, s_Dim, SC_N_SUBSET );

    l_Dim=l_Dim+1;

End;

DataSourceType='VIEW';
DatasourceCubeview = SC_VIEW;

# Not switched on again at the end to allow
# easier clearing of the data.
CubeSetLogChanges ( SC_CUBE, 0);
Data

Code: Select all

CellPutN ( Value, SC_CUBE, SC_VERSION_TARGET, {Other variables in original cube order} );
Epilog

Code: Select all

ViewDestroy ( SC_CUBE, SC_VIEW );

l_Dim = 1;

While ( l_Dim <= 12);

    s_Dim = TabDim ( SC_CUBE, l_Dim);

#   AsciiOutput ( 'C:\Temp\PreRebootOrder_ViewCreateAndUseEpilog.txt', s_Dim);
   AsciiOutput ( 'C:\Temp\PostRebootOrder_ViewCreateAndUseEpilog.txt', s_Dim);

    SubsetDestroy ( s_Dim, SC_N_SUBSET);

    l_Dim=l_Dim+1;

End;
Findings
The variables tab does indeed show the dimensions in the reordered sequence. However TabDim and CellGetN / CellPutN still generate or expect them in the original order. This is only moderately inconvenient as users do have to remember to write the Put and Get statements using the correctly ordered list; they can't simply copy and paste from the Variables tab as I for one am used to doing. However I encountered no server crashes, and although the first attempt at a copy process failed (because I hadn't noticed the reordered dimensions on the Variables tab), subsequent attempts completed normally.

(9.0 SP3 Build 9.0.3.173)
"To them, equipment failure is terrifying. To me, it’s 'Tuesday.' "
-----------
Before posting, please check the documentation, the FAQ, the Search function and FOR THE LOVE OF GLUB the Request Guidelines.
Post Reply