how to add an oracle database hint to a physical table in OBI; but they all stop short of showing how they can be added to an Alias Object. There is a section at the end of the blog addressing this.
Database Hints allow us to change suboptimal SQL Execution Plans; they simply allow us to provide more information to the optimizer and influence the plan executed. A database hint will take the form as below.
SELECT
/*+ index(T222,PK) */
‘ROW_WID’ as c1
FROM
W_CUSTOMER_D T222
OBIEE Query Hints
In OBIEE we can add a database hint to a table object in the physical layer; whenever this table is referenced in a query the hint will be applied. Importantly, a hint should use the table alias whenever a query specifies an alias for a table; the table itself should not be used. If you look at the underlying SQL of an OIBEE query, via the Obiee view log, you will notice OBIEE will always use an alias for a table in the generated SQL; an alias taking the form such as T222 above.
The first step to adding our hint to a table is to determine the alias that OBIEE will use in the generated SQL. Select to Query Repository from the Tools Menu of the Administration Tool. The Query Repository Tool will open, as in the image below. Enter the Name of the table in the Name textbox and select Physical Table from the Type menu; click query to run the tool. Notice the use of the wildcard character, *.
In this example you can see we have a physical table in the database, W_CUSTOMER_D, and that I have created an Alias ojbect based on that table of Dim_W_CUSTOMER_D. In the ID column the two objects have IDs of 3001:111 and 3001:222 respectively. If we were using the table in our query, we can deduce we will use an alias of T111. Actually we used the Alias object and the database alias generated would be T222. You can see it is the latter segment of the ID that is used.
We can now add the hint; a hint can not be added to an OBIEE Alias object, only to an underlying Table object. We open the properties for the table object and add the hint to the text box as below.
You can see that the hint is applied to the OBIEE Alias object, T222; but we are creating that definition on the underlying Table object. If there were no Alias object and the table itself were used in the query then we would need to use the SQL generated alias of T111.
Hinting an Alias Object
But what do we do if we have multiple Alias’ objects sharing the same underlying Table object; this happens all the time.
We can’t apply the hint to the Alias object itself; instead we apply it to physical joinsto and from the Alias object. The screenshot below shows where we apply the hint for the Alias table above.
You can see that we’ve populated the hint textbox referencing the SQL alias T222. Whenever this join is used the hint will be added to the query.
Database Hints allow us to change suboptimal SQL Execution Plans; they simply allow us to provide more information to the optimizer and influence the plan executed. A database hint will take the form as below.
SELECT
/*+ index(T222,PK) */
‘ROW_WID’ as c1
FROM
W_CUSTOMER_D T222
OBIEE Query Hints
In OBIEE we can add a database hint to a table object in the physical layer; whenever this table is referenced in a query the hint will be applied. Importantly, a hint should use the table alias whenever a query specifies an alias for a table; the table itself should not be used. If you look at the underlying SQL of an OIBEE query, via the Obiee view log, you will notice OBIEE will always use an alias for a table in the generated SQL; an alias taking the form such as T222 above.
The first step to adding our hint to a table is to determine the alias that OBIEE will use in the generated SQL. Select to Query Repository from the Tools Menu of the Administration Tool. The Query Repository Tool will open, as in the image below. Enter the Name of the table in the Name textbox and select Physical Table from the Type menu; click query to run the tool. Notice the use of the wildcard character, *.
In this example you can see we have a physical table in the database, W_CUSTOMER_D, and that I have created an Alias ojbect based on that table of Dim_W_CUSTOMER_D. In the ID column the two objects have IDs of 3001:111 and 3001:222 respectively. If we were using the table in our query, we can deduce we will use an alias of T111. Actually we used the Alias object and the database alias generated would be T222. You can see it is the latter segment of the ID that is used.
We can now add the hint; a hint can not be added to an OBIEE Alias object, only to an underlying Table object. We open the properties for the table object and add the hint to the text box as below.
You can see that the hint is applied to the OBIEE Alias object, T222; but we are creating that definition on the underlying Table object. If there were no Alias object and the table itself were used in the query then we would need to use the SQL generated alias of T111.
Hinting an Alias Object
But what do we do if we have multiple Alias’ objects sharing the same underlying Table object; this happens all the time.
We can’t apply the hint to the Alias object itself; instead we apply it to physical joinsto and from the Alias object. The screenshot below shows where we apply the hint for the Alias table above.
You can see that we’ve populated the hint textbox referencing the SQL alias T222. Whenever this join is used the hint will be added to the query.
0 comments:
Post a Comment