ORA-34492: Analytic workspace object cubename _STORED does not exist.

Question

I am having issues accessing cube data from a user other than where the AW was built.
Following is what I have done in User-1:
1. Create two AW's in User-1 : AW-1 and AW-2.
2. Create all objects in these two AW's
3. AW-2 is dynamically attached on attaching AW-1 by using PERMIT startup programs. Please refer Attaching multiple AW's
4. Refreshed both AW's to load data
5. ALLCOMPILE - no errors.
6. Created some SQL views on User-1 which basically query the underlying cube views. I also have some queries using the olap_table option.
7. All my querries work fine in User-1. I can access data from AW-1 and AW-2.
However, we give access to the above SQL views through an abstract user: User-abs. In 10g, all we did was grant select privs to all the User-1.AW$ tables and also on all the sql views. This would let User-abs get data from the cubes in User-1.
I am not able to get User-abs to do the same in 11g. We encounter an error mentioning that the workspace object <cubename>_STORED does not exist. The cubename it is referring to exists in AW-2.
I granted select privs on all AW$ tables, dimension views, cube views and the abstracted sql views but the error persists.
I tried searching this forum but could not find any helpful leads. Any help will be greatly appreciated.
Thanks!
Database - 11.2.0.1
AWM - 11.2.0.2.0A

Answer 1

I can think of two possible problems. First, you may not be properly qualifying the owner name when you refer to the object. This can be important when refering to objects owned by other schemas. For example instead of 'my_cube_stored' you would say 'user-1.aw-2!my_cube_stored'. You should also be careful about the order in which you attach the AWs. Do you want AW-2 attached first or last? Use the LAST keyword on AW ATTACH to control this.
Another possibility is that you have added additional logic to PERMIT_READ over and above the 'aw attach' comand. I was able to recreate the error with the following code in a new AW called TEST_AW in the GLOBAL schema.
DEFINE PERMIT_READ PROGRAM BOOLEAN
PROGRAM
aw attach global.global
show global.global!units_cube_stored
return true
ENDAttaching TEST_AW in RO mode as any user gives me the following error.
ORA-34492: Analytic workspace object GLOBAL.GLOBAL!UNITS_CUBE_STORED does not
exist.
ORA-06512: at "SYS.DBMS_AW", line 93
ORA-06512: at "SYS.DBMS_AW", line 122
ORA-06512: at line 1Here is the documentation for PERMIT_READ
>
PERMIT_READ
A PERMIT_READ program is a program that you can create and that Oracle OLAP checks for by name when an AW ATTACH read-only command executes. Depending on the value returned by the program, Oracle OLAP executes the code within the program after attaching the analytic workspace. Depending on the statements in the permit_read program the user is granted or denied access to specific objects or sets of object values. Within permit_read program, you can specify PERMIT commands that grant or restrict access to individual workspace objects. All of the objects referred to in a given permit_read must exist in the same analytic workspace.
>
Note, especially, the restriction in the last sentence. This means that a PERMIT_READ program in AW1, for example, cannot refer to objects in AW2. So this is why my PERMIT_READ doesn't work. The AUTOGO does not have these restrictions, but as we know from the forum post you cited, AUTOGO is broken in 11.2.0.1. You can move forward to 11.2.0.2 where AUTOGO is fixed, but there is workaround, which is to add a PERMIT_READ program to the second AW to do the work. For example, if I add this PERMIT_READ to GLOBAL and remove the 'show' command from the PERMIT_READ in TEST_AW, then everything works as expected.
DEFINE PERMIT_READ PROGRAM BOOLEAN
PROGRAM
if aw(attached 'test_aw')
then do
show global.global!units_cube_stored
doend
return true
END