Will star transformation be scalable?

This is rather an algorithmic question
I happen to read a post about a real-world problem.
http://groups.google.com/group/comp.databases.oracle.server/browse_thread/thread/0db61c4fab79769a?hl=en
Simple back envelope analysis shows that star transformation would be very expensive in terms of storage:
The fact table F has 750 million rows, a dimensional table D has 70k rows. Suppose I have a bitmap join index between F and D to support star transformation.
How large would the bitmap index be?
70k values, each need a bitmap vector of 750M bits. The bitmap size would be 70k x (750M/8) bytes=6.6kGb. Is that too large?
Or, I miss something? If partition can help, how?
I guess my general questions is that if the dimension table's cardinality is in the order of thousands, what solution would Oracle provide? Thanks.
T.K.

Thanks for the link. However, I do not see any metrics mentioning about bitmap compression degree.
I agree that 6.6kG join bitmap index is not in the compression form. However, in general to what degree can a bitmap be compressed? In this particular example, suppose it can be compressed by a ratio of 100. Then, we still need 6.6kG/100=66G for the bitmap join index. Decompressing it on the fly also take a lot of CPUs cycles. Adding more CPU cores would not benefit since most cores share the same L2 cache. (cache misses would be a bottleneck)
Are there any benchmark results or documents discussing bitmap compression effect and showing the practical side of a reasonable large db benefiting from Star transformation like this example?
thanks,
T.k.

Similar Messages

Why is the Star Transformation using two indexes for the same dimension?

Hi,
Recently, I have made an investigation about the Star Transformation feature. I have found a strange test case, which plays an important role in my strategy for our overall DWH architecture. Here it is:
The Strategy:
I would like to have the classical Star Transformation approach (single column Bitmap Indexes for each dimension foreign key column in the fact table), together with additional Bitmap Join Indexes for some of the dimension attributes, which would benefit from the materialization of the join (bitmap merge operation will be skipped/optimized).
The query:
select dp.brand, ds. region_name, dc.region_name
     , count(*), sum(f.extended_price)
from fact_line_item f
     , dim_part       dp
     , dim_supplier   ds
     , dim_customer   dc
where dp.mfgr        = 10                 -- dimension selectivity = 1/10 --> acttual/fact selectivity = 6/10
   and f.part_dk      = dp.dk
   and ds.region_name = 'REGION #1' -- dimension selectivity = 1/9
   and f.supplier_dk = ds.dk
   and dc.region_name = 'REGION #1' -- dimension selectivity = 1/11
   and f.customer_dk = dc.dk
group by dp.brand, ds. region_name, dc.region_name
The actual plan:
| Id | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads |
|   0 | SELECT STATEMENT                       |                             |      1 |        | 3247 (100)|      1 |00:01:42.05 |     264K|    220K|
|   1 | HASH GROUP BY                         |                             |      1 |      2 | 3247   (1)|      1 |00:01:42.05 |     264K|    220K|
|* 2 |   HASH JOIN                            |                             |      1 | 33242 | 3037   (1)|    217K|00:01:29.67 |     264K|    220K|
|* 3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      4 |
|* 4 |    HASH JOIN                           |                             |      1 | 33245 | 2934   (1)|    217K|00:01:29.10 |     264K|    220K|
|* 5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.08 |     316 |      8 |
|* 6 |     HASH JOIN                          |                             |      1 | 33248 | 2831   (1)|    217K|00:01:28.57 |     264K|    220K|
|* 7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|   8 |      PARTITION RANGE ALL               |                             |      1 | 36211 | 2827   (1)|    217K|00:01:28.01 |     264K|    220K|
|   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 | 36211 | 2827   (1)|    217K|00:01:33.85 |     264K|    220K|
| 10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:07.09 |   46980 |   3292 |
| 11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:08.33 |   46980 |   3292 |
| 12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:02.09 |    2408 |   1795 |
| 13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:04.66 |    2408 |   1795 |
| 14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
|* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:02.11 |    2402 |   1795 |
|* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:00:06.65 |     890 |    888 |
| 18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:02.78 |   16695 |    237 |
| 19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:01.56 |   16695 |    237 |
| 20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.02 |     316 |      0 |
|* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
|* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:02.07 |   16379 |    237 |
| 23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:03.65 |   26987 |    372 |
| 24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:02.23 |   26987 |    372 |
| 25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
|* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
|* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:02.74 |   26671 |    372 |
The Question:
Why is the Star Transformation using both indexes FACT_LI__P_PART_DIM_KEY_BIX and FACT_LI__P_PART_MFGR_BJX for the same dimension criteria (dp.mfgr = 10)?? The introduction of the additional Bitmap Join Index actually make Oracle to do the work twice !!!
Anybody, any idea ?!?

Dom, here it is the plan with the predicates:
| Id | Operation                              | Name                        | Starts | E-Rows | Cost (%CPU)| A-Rows |   A-Time   | Buffers | Reads |
|   0 | SELECT STATEMENT                       |                             |      1 |        | 3638 (100)|      1 |00:06:41.17 |     445K|    236K|
|   1 | HASH GROUP BY                         |                             |      1 |      2 | 3638   (1)|      1 |00:06:41.17 |     445K|    236K|
|* 2 |   HASH JOIN                            |                             |      1 | 33242 | 3429   (1)|    217K|00:08:18.02 |     445K|    236K|
|* 3 |    TABLE ACCESS FULL                   | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.03 |     319 |    313 |
|* 4 |    HASH JOIN                           |                             |      1 | 33245 | 3326   (1)|    217K|00:08:17.47 |     445K|    236K|
|* 5 |     TABLE ACCESS FULL                  | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     319 |    313 |
|* 6 |     HASH JOIN                          |                             |      1 | 33248 | 3223   (1)|    217K|00:08:16.63 |     445K|    236K|
|* 7 |      TABLE ACCESS FULL                 | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|   8 |      PARTITION RANGE ALL               |                             |      1 | 36211 | 3219   (1)|    217K|00:08:16.30 |     445K|    236K|
|   9 |       TABLE ACCESS BY LOCAL INDEX ROWID| FACT_LINE_ITEM              |      6 | 36211 | 3219   (1)|    217K|00:08:40.89 |     445K|    236K|
| 10 |        BITMAP CONVERSION TO ROWIDS     |                             |      6 |        |            |    217K|00:00:32.00 |   46919 | 19331 |
| 11 |         BITMAP AND                     |                             |      6 |        |            |     69 |00:00:34.50 |   46919 | 19331 |
| 12 |          BITMAP MERGE                  |                             |      6 |        |            |    193 |00:00:00.58 |    2353 |      1 |
| 13 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   4330 |00:00:00.10 |    2353 |      1 |
| 14 |            BUFFER SORT                 |                             |      6 |        |            |     60 |00:00:00.01 |       6 |      0 |
|* 15 |             TABLE ACCESS FULL          | DIM_PART                    |      1 |     10 |     3   (0)|     10 |00:00:00.01 |       6 |      0 |
|* 16 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_PART_DIM_KEY_BIX |     60 |        |            |   4330 |00:00:00.07 |    2347 |      1 |
|* 17 |          BITMAP INDEX SINGLE VALUE     | FACT_LI__P_PART_MFGR_BJX    |      6 |        |            |   1747 |00:01:23.64 |     882 |    565 |
| 18 |          BITMAP MERGE                  |                             |      6 |        |            |    169 |00:00:09.14 |   16697 |   7628 |
| 19 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   5460 |00:00:02.19 |   16697 |   7628 |
| 20 |            BUFFER SORT                 |                             |      6 |        |            |   5460 |00:00:00.01 |     316 |      0 |
|* 21 |             TABLE ACCESS FULL          | DIM_CUSTOMER                |      1 |    910 |   102   (0)|    910 |00:00:00.01 |     316 |      0 |
|* 22 |            BITMAP INDEX RANGE SCAN     | FACT_LI__P_CUST_DIM_KEY_BIX |   5460 |        |            |   5460 |00:00:08.78 |   16381 |   7628 |
| 23 |          BITMAP MERGE                  |                             |      6 |        |            |    170 |00:00:21.46 |   26987 | 11137 |
| 24 |           BITMAP KEY ITERATION         |                             |      6 |        |            |   6672 |00:00:10.29 |   26987 | 11137 |
| 25 |            BUFFER SORT                 |                             |      6 |        |            |   6672 |00:00:00.01 |     316 |      0 |
|* 26 |             TABLE ACCESS FULL          | DIM_SUPPLIER                |      1 |   1112 |   102   (0)|   1112 |00:00:00.01 |     316 |      0 |
|* 27 |            BITMAP INDEX RANGE SCAN     | FACT_LI__S_SUPP_DIM_KEY_BIX |   6672 |        |            |   6672 |00:00:20.94 |   26671 | 11137 |
Predicate Information (identified by operation id):
   2 - access("F"."SUPPLIER_DK"="DS"."DK")
   3 - filter("DS"."REGION_NAME"='REGION #1')
   4 - access("F"."CUSTOMER_DK"="DC"."DK")
   5 - filter("DC"."REGION_NAME"='REGION #1')
   6 - access("F"."PART_DK"="DP"."DK")
   7 - filter("DP"."MFGR"=10)
15 - filter("DP"."MFGR"=10)
16 - access("F"."PART_DK"="DP"."DK")
17 - access("F"."SYS_NC00017$"=10)
21 - filter("DC"."REGION_NAME"='REGION #1')
22 - access("F"."CUSTOMER_DK"="DC"."DK")
26 - filter("DS"."REGION_NAME"='REGION #1')
27 - access("F"."SUPPLIER_DK"="DS"."DK")
Note
   - star transformation used for this statement

Performance tuning - Is database using Star Transformation?

Reports running slow, not sure if database is using Start transformation for the Datawarehouse Database.
Used hint */+ STAR_TRANSFORMATION */, still no performance increase.
Checked database parameter -
SQL> show parameter star;
NAME                                 TYPE        VALUE
dg_broker_start                      boolean     FALSE
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     0
fast_start_parallel_rollback         string      LOW
log_archive_start                    boolean     FALSE
star_transformation_enabled          string      TRUE
Any Help is appreciated.
Thanks!

DBA_Guide wrote:
Reports running slow, not sure if database is using Start transformation for the Datawarehouse Database.
Used hint */+ STAR_TRANSFORMATION */, still no performance increase.
Checked database parameter -
SQL> show parameter star;
NAME                                 TYPE        VALUE
dg_broker_start                      boolean     FALSE
fast_start_io_target                 integer     0
fast_start_mttr_target               integer     0
fast_start_parallel_rollback         string      LOW
log_archive_start                    boolean     FALSE
star_transformation_enabled          string      TRUE
Any Help is appreciated.
Thanks!
If star transformation was not the cause of the slowness, of course it won't make it faster.
I bet you any number of other different hints will result in no change in performance.
This is like replacing gas tank on your car with a LARGER tank & filling it with more gasoline to make the car go faster.
The amount of gasoline is not a factor that limits the speed of your car.

Star transformation and Partition pruning

All experts,
I need advice on my situation -
I have data warehouse running on oracle 11.2.0.1
We are using star trnasformation. The fact table is partitioned.
However, with the star query (fact joined to dimensions with keys and filters only on dimensions), partition pruning is not happening.
I read some documents online and it seems that partition pruning is not going to happen unless I directly filter fact (which is against the best paractices of star query).
Please advice

SELECT
PTL_EDW.D_TIME.CAL_YYYYMM,
(( ( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.LABOR_COST) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.OUTSIDE_COST) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.PARTS_COST) ) )-( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_LABOR_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_OUTSIDE_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.RECOVERY_PARTS_AMOUNT) ) )+( ( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_LABOR_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_OUTSIDE_AMOUNT) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.WARRANTY_PARTS_AMOUNT) ) ) )+( sum(PTL_EDWPERF.F_JOB_OIL_COST.OIL_COST) ))
FROM
PTL_EDWPERF.F_JOB_OIL_COST,
PTL_EDW.D_LOCATION_MASTER D_LOCATION_DOMICILE,
PTL_EDW.D_VEHICLE_CAP_STATUS,
PTL_EDW.D_UNIT_MASTER,
PTL_EDW.D_ACCOUNT_CODE,
PTL_EDW.D_TIME
WHERE
( PTL_EDWPERF.F_JOB_OIL_COST.ACCOUNT_CODE_KEY = PTL_EDW.D_ACCOUNT_CODE.ACCOUNT_CODE_KEY)
AND ( PTL_EDWPERF.F_JOB_OIL_COST.VEHICLE_CAP_STATUS_KEY=PTL_EDW.D_VEHICLE_CAP_STATUS.VEHICLE_CAP_STATUS_KEY )
AND ( PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY=D_LOCATION_DOMICILE.LOCATION_MASTER_KEY )
AND (PTL_EDWPERF.F_JOB_OIL_COST.UNIT_MASTER_KEY = PTL_EDW.D_UNIT_MASTER.UNIT_MASTER_KEY)
AND (PTL_EDWPERF.F_JOB_OIL_COST.RO_ACCOUNTING_MONTH_KEY = PTL_EDW.D_TIME.TIME_KEY)
AND ( exists (select 1 from ptl_edw.s_location where s_location.ssoid = '600028988' and PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY = decode(s_location.location_master_key, -99999, PTL_EDWPERF.F_JOB_OIL_COST.CHARGING_LOCATION_KEY, s_location.location_master_key)) )
AND
--PTL_EDWPERF.F_JOB_OIL_COST.PARTITION_KEY BETWEEN 201011 AND 201104
PTL_EDW.D_TIME.CAL_YYYYMM BETWEEN 200601 AND 201104
AND
D_LOCATION_DOMICILE.CORP_CD IN ( '2000','HPTL' )
AND
( ( PTL_EDW.D_VEHICLE_CAP_STATUS.VEHICLE_CAP_STATUS ) IN ( 'ACCRUED','ACTIVE' ) )
AND
( PTL_EDW.D_UNIT_MASTER.CONTRACT_GROUP = 'P' )
AND
PTL_EDW.D_UNIT_MASTER.UNIT_CATEGORY IN ( 'TRACTOR','TRAILER','TRUCK' )
AND
PTL_EDW.D_ACCOUNT_CODE.ACCOUNT_CODE_GROUP1 IN ( 'COMMERCIAL RENTAL','CONTRACT MAINTENANCE - GUAR','CONTRACT MAINTENANCE - OTHER','CONTRACT MAINTENANCE - PEG','LEASE','TRAILER PLUS' )
GROUP BY
PTL_EDW.D_TIME.CAL_YYYYMM
-- bg4643wj2d3xn
=====================================
Elapsed: 00:39:35.08
Execution Plan
Plan hash value: 2317670688
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
| 0 | SELECT STATEMENT | | 9 | 666 | | 186K (1)| 00:43:36 | | |
| 1 | HASH GROUP BY | | 9 | 666 | | 186K (1)| 00:43:36 | | |
|* 2 | FILTER | | | | | | | | |
|* 3 | HASH JOIN | | 557K| 39M| | 186K (1)| 00:43:35 | | |
|* 4 | VIEW | index$_join$_006 | 1925 | 19250 | | 16 (7)| 00:00:01 | | |
|* 5 | HASH JOIN | | | | | | | | |
|* 6 | INDEX RANGE SCAN | D_TIME_CALYYYYMM_IDX2 | 1925 | 19250 | | 5 (20)| 00:00:01 | | |
| 7 | INDEX FAST FULL SCAN | D_TIME_TIME_KEY_PK | 1925 | 19250 | | 14 (0)| 00:00:01 | | |
|* 8 | HASH JOIN | | 557K| 34M| 32M| 186K (1)| 00:43:34 | | |
| 9 | PARTITION RANGE ALL | | 557K| 26M| | 131K (1)| 00:30:46 | 1 | 133 |
| 10 | TABLE ACCESS BY LOCAL INDEX ROWID| F_JOB_OIL_COST | 557K| 26M| | 131K (1)| 00:30:46 | 1 | 133 |
| 11 | BITMAP CONVERSION TO ROWIDS | | | | | | | | |
| 12 | BITMAP AND | | | | | | | | |
| 13 | BITMAP MERGE | | | | | | | | |
| 14 | BITMAP KEY ITERATION | | | | | | | | |
| 15 | BUFFER SORT | | | | | | | | |
|* 16 | VIEW | index$_join$_179 | 2 | 20 | | 2 (50)| 00:00:01 | | |
|* 17 | HASH JOIN | | | | | | | | |
| 18 | INLIST ITERATOR | | | | | | | | |
|* 19 | INDEX UNIQUE SCAN | D_CAPSTS_ETL_IDX | 2 | 20 | | 0 (0)| 00:00:01 | | |
| 20 | INDEX FAST FULL SCAN | D_VEHICLE_CAP_STATUS_PK | 2 | 20 | | 1 (0)| 00:00:01 | | |
|* 21 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_VEH_CAP_KY | | | | | | 1 | 133 |
| 22 | BITMAP MERGE | | | | | | | | |
| 23 | BITMAP KEY ITERATION | | | | | | | | |
| 24 | BUFFER SORT | | | | | | | | |
|* 25 | TABLE ACCESS FULL | D_TIME | 1925 | 51975 | | 19 (6)| 00:00:01 | | |
|* 26 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_CST_RO_ACC_MTH_KY | | | | | | 1 | 133 |
| 27 | BITMAP MERGE | | | | | | | | |
| 28 | BITMAP KEY ITERATION | | | | | | | | |
| 29 | BUFFER SORT | | | | | | | | |
|* 30 | TABLE ACCESS FULL | D_ACCOUNT_CODE | 11 | 165 | | 4 (0)| 00:00:01 | | |
|* 31 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_ACCT_CODE_KY | | | | | | 1 | 133 |
| 32 | BITMAP MERGE | | | | | | | | |
| 33 | BITMAP KEY ITERATION | | | | | | | | |
| 34 | BUFFER SORT | | | | | | | | |
|* 35 | VIEW | index$_join$_172 | 3136 | 28224 | | 19 (6)| 00:00:01 | | |
|* 36 | HASH JOIN | | | | | | | | |
| 37 | INLIST ITERATOR | | | | | | | | |
|* 38 | INDEX RANGE SCAN | D_LOCNMST_ETL_IDX | 3136 | 28224 | | 12 (17)| 00:00:01 | | |
| 39 | INDEX FAST FULL SCAN | LOCATION_MASTER_KEY_PK | 3136 | 28224 | | 10 (0)| 00:00:01 | | |
|* 40 | BITMAP INDEX RANGE SCAN | BIMAP_JOBOIL_COST_CHRG_LOCN_KY | | | | | | 1 | 133 |
|* 41 | TABLE ACCESS FULL | D_UNIT_MASTER | 1790K| 23M| | 51484 (2)| 00:12:01 | | |
|* 42 | TABLE ACCESS BY INDEX ROWID | S_LOCATION | 1 | 23 | | 12 (0)| 00:00:01 | | |
|* 43 | INDEX RANGE SCAN | S_LOCN_SSOID_IDX | 14 | | | 1 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - filter( EXISTS (SELECT 0 FROM "PTL_EDW"."S_LOCATION" "S_LOCATION" WHERE "S_LOCATION"."SSOID"='600028988' AND
DECODE("S_LOCATION"."LOCATION_MASTER_KEY",(-99999),:B1,"S_LOCATION"."LOCATION_MASTER_KEY")=:B2))
3 - access("F_JOB_OIL_COST"."RO_ACCOUNTING_MONTH_KEY"="D_TIME"."TIME_KEY")
4 - filter("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
5 - access(ROWID=ROWID)
6 - access("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
8 - access("F_JOB_OIL_COST"."UNIT_MASTER_KEY"="D_UNIT_MASTER"."UNIT_MASTER_KEY")
16 - filter("D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACCRUED' OR "D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACTIVE')
17 - access(ROWID=ROWID)
19 - access("D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACCRUED' OR "D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS"='ACTIVE')
21 - access("F_JOB_OIL_COST"."VEHICLE_CAP_STATUS_KEY"="D_VEHICLE_CAP_STATUS"."VEHICLE_CAP_STATUS_KEY")
25 - filter("D_TIME"."CAL_YYYYMM">=200601 AND "D_TIME"."CAL_YYYYMM"<=201104)
26 - access("F_JOB_OIL_COST"."RO_ACCOUNTING_MONTH_KEY"="D_TIME"."TIME_KEY")
30 - filter("D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='COMMERCIAL RENTAL' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT MAINTENANCE
- GUAR' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT MAINTENANCE - OTHER' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='CONTRACT
MAINTENANCE - PEG' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='LEASE' OR "D_ACCOUNT_CODE"."ACCOUNT_CODE_GROUP1"='TRAILER PLUS')
31 - access("F_JOB_OIL_COST"."ACCOUNT_CODE_KEY"="D_ACCOUNT_CODE"."ACCOUNT_CODE_KEY")
35 - filter("D_LOCATION_DOMICILE"."CORP_CD"='2000' OR "D_LOCATION_DOMICILE"."CORP_CD"='HPTL')
36 - access(ROWID=ROWID)
38 - access("D_LOCATION_DOMICILE"."CORP_CD"='2000' OR "D_LOCATION_DOMICILE"."CORP_CD"='HPTL')
40 - access("F_JOB_OIL_COST"."CHARGING_LOCATION_KEY"="D_LOCATION_DOMICILE"."LOCATION_MASTER_KEY")
41 - filter("D_UNIT_MASTER"."CONTRACT_GROUP"='P' AND ("D_UNIT_MASTER"."UNIT_CATEGORY"='TRACTOR' OR
"D_UNIT_MASTER"."UNIT_CATEGORY"='TRAILER' OR "D_UNIT_MASTER"."UNIT_CATEGORY"='TRUCK'))
42 - filter(DECODE("S_LOCATION"."LOCATION_MASTER_KEY",(-99999),:B1,"S_LOCATION"."LOCATION_MASTER_KEY")=:B2)
43 - access("S_LOCATION"."SSOID"='600028988')
Note
- star transformation used for this statement
Statistics
3034 recursive calls
0 db block gets
28519518 consistent gets
1075291 physical reads
0 redo size
2519 bytes sent via SQL*Net to client
567 bytes received via SQL*Net from client
6 SQL*Net roundtrips to/from client
4 sorts (memory)
0 sorts (disk)
64 rows processed
Partition is range on YYYYMM(numeric format)

Risky enable star transformations and trusted Query Rewrites?

Hi,
I need some advice/opinions from someone experienced with large scale
data warehousing.
I'm working on a fairly large data warehouse (around 3 TB), and we're
using Oracle 10.1.0.2.0.
So, I found out about MV's and Star Transformations, and that we're not
using them.
Naturally I decided to try them out in our test environment and I was
more than pleased (actually, I nearly wet my pants) with the potential
performance boost we could get for some of our more critical solutions.
However, I also noticed that the production environment has the
following settings:
star_transformation_enabled = false
query_rewrite_integrity = enforced
...which basically disables all the cool stuff. In the testing
environment I used the following:
star_transformation_enabled = true
query_rewrite_integrity = trusted (to make use of func. dep in
dimensions)
I would like to stand on somewhat solid grounds and increase my
understanding before aproaching our DBA's with the suggestion to change
system global settings :)
Basically, my question(s) are:
1. What are the impact of enabling Star Transformations on a system?
Is there any at all, if no previous solution has been built in a way
to
make use of star transformations?
Or could this change result in fine-tuned queries performing badly
since they
suddenly make use of star transformations?
2. Is "query_rewrite_integrity" used by Oracle for other things besides
Materialized Views?
I'm thinking, if the only thing it's used for is to resolve query
rewrites for MV's, then it's safe to change it, because there are no
such MV's.
Note that I'd like to set it to TRUSTED, in order to make real use
of the dependencies declared with CREATE DIMENSION...
I would be happy to know what you think about this.
Any thoughts, opinions are welcome since this is new grounds for me.
Best Regards
R.

Following parameters are deprecated in release 10.2.
LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
REMOTE_ARCHIVE_ENABLE
SERIAL_REUSE
SQL_TRACE
Check this in your parameter file.
As per Oracle Errors Documents.
Error : ORA-32004
Cause:     One or more obsolete and/or parameters were specified in the
     SPFILE or the PFILE on the server side.
Action:     See alert log for a list of parameters that are obsolete. or
     deprecated. Remove them from the SPFILE or the server side PFILE
Regards,
Sabdar Syed.

Hash partitions+pruning+star transformation

Hi there,
We are considering partitioning our fact table on product_id (hash) range and list not suitable for us, most queries by product.
Couple of questions
1) does oracle create the hash partitions automaticall, if say hash by quantity what happens if later decide need more partitions - keen to keep maintenance to minimum
2) Will partition pruning work
simplified structure of fact table
sales_qty
product_id
customer_id
day_id (date of sale)
simple query
select sum(sale_qty)
from sales, products, customers
where sales.product_id = product.product_id
and sales.customer_id = customer.customer_id
and product.creation_week between 200901 and 200952
all id's in the fact table are surrogate id's and are simply the dimesnion keys of the realetd dimensions, therefore users won't query omn these columns directly.
If we hash partition on product_id and database parameter star_transformation enabled will this give us query performance benefits (i.e. partition pruning).
Many Thanks

Hi there,
We are considering partitioning our fact table on product_id (hash) range and list not suitable for us, most queries by product.
Couple of questions
1) does oracle create the hash partitions automaticall, if say hash by quantity what happens if later decide need more partitions - keen to keep maintenance to minimum
2) Will partition pruning work
simplified structure of fact table
sales_qty
product_id
customer_id
day_id (date of sale)
simple query
select sum(sale_qty)
from sales, products, customers
where sales.product_id = product.product_id
and sales.customer_id = customer.customer_id
and product.creation_week between 200901 and 200952
all id's in the fact table are surrogate id's and are simply the dimesnion keys of the realetd dimensions, therefore users won't query omn these columns directly.
If we hash partition on product_id and database parameter star_transformation enabled will this give us query performance benefits (i.e. partition pruning).
Many Thanks

ORA-904 and star transformation

Hi,
We have oracle 10.2.0.4 with most recent patches.
When I run the following sql statement I got an ORA-00904: "DT"."SID_0FISCYEAR": invalid identifier
If I drop an index on /BIC/EZYEE_SDLT table on SID_0FISCPER column the sql statement run without error !
IS it an Oracle bug ?
SELECT /*+ STAR_TRANSFORMATION FACT(F) */ "S39"."COSTCENTER" AS "0COSTCENTER" ,"S40"."COMPANY" AS "0COMPANY" ,
"S41"."COMP_CODE" AS "0COMP_CODE" ,"S42"."CS_PLEVEL" AS "0CS_PLEVEL" ,"S43"."FISCPER" AS "0FISCPER" ,
LPAD("DT"."SID_0FISCPER3",000003, 0 ) AS "0FISCPER3" ,"S44"."FISCYEAR" AS "0FISCYEAR" ,
"S45"."COMPANY" AS "0PCOMPANY" ,"S46"."/BIC/ZBPSADJT" AS "ZBPSADJT" ,"S47"."/BIC/ZENT" AS "ZENT" ,
"S48"."/BIC/ZMEASURE1" AS "ZMEASURE1" ,"S49"."/BIC/ZTPBU0" AS "ZTPBU0" ,"S50"."/BIC/ZVAR_IND" AS "ZVAR _IND" ,
"S51"."/BIC/ZYEEDESC" AS "ZYEEDESC" , SUM ( "F"."AMOUNT" ) AS "0AMOUNT" , COUNT( * ) AS " 1ROWCOUNT"
FROM "/BIC/EZYEE_SDLT" "F" JOIN "/BIC/DZYEE_SDLT2" "D2" ON "F" . "KEY_ZYEE_SDLT2" = "D2"."DIMID" JOIN "/BI0/SCOSTCENTER" "S39"
ON "D2" . "SID_0COSTCENTER" = "S39" . "SID" JOIN "/BI0/SCOMPANY" "S40" ON "D2" . "SID_0COMPANY" = "S40" . "SID" JOIN "/BI0/SCOMP_CODE" "S41"
ON "D2" . "SID_0COMP_CODE" = "S41" . "SID" JOIN "/BIC/SZENT" "S47" ON "D2" . "SID_ZENT" = "S47" . "SID" JOIN "/BIC/DZYEE_SDLT6" "D6"
ON "F" . "KEY_ZYEE_SDLT6" = "D6" . "DIMID" JOIN "/BI0/SCS_PLEVEL" "S42"
ON "D6" . "SID_0CS_PLEVEL" = "S42" . "SID" JOIN "/BIC/SZBPSADJT" "S46" ON "D6" . "SID_ZBPSADJT" = "S46" . "SID" JOIN "/BIC/DZYEE_SDLTT" "DT"
ON "F" . "KEY_ZYEE_SDLTT" = "DT" . "DIMID" AND "F" . "SID_0FISCPER" = "DT" . "SID_0FISCPER" JOIN "/BI0/SFISCPER" "S43"
ON "DT" . "SID_0FISCPER" = "S43" . "SID" JOIN "/BI0/SFISCYEAR" "S44" ON "DT" . "SID_0FISCYEAR" = "S44" . "SID" JOIN "/BIC/DZYEE_SDLT1" "D1"
ON "F" . "KEY_ZYEE_SDLT1" = "D1" . "DIMID" JOIN "/BI0/SCOMPANY" "S45" ON "D1" . "SID_0PCOMPANY" = "S45" . "SID" JOIN "/BIC/SZTPBU0" "S49"
ON "D1" . "SID_ZTPBU0" = "S49" . "SID" JOIN "/BIC/DZYEE_SDLT3" "D3" ON "F" . "KEY_ZYEE_SDLT3" = "D3" . "DIMID" JOIN "/BIC/SZMEASURE1" "S48"
ON "D3" . "SID_ZMEASURE1" = "S48" . "SID" JOIN "/BIC/SZVAR_IND" "S50" ON "D3" . "SID_ZVAR_IND" = "S50" . "SID" JOIN "/BIC/SZYEEDESC" "S51"
ON "D3" . "SID_ZYEEDESC" = "S51" . "SID" JOIN "/BIC/DZYEE_SDLTP" "DP" ON "F" . "KEY_ZYEE_SDLTP" = "DP" . "DIMID" JOIN "/BIC/DZYEE_SDLTU" "DU"
ON "F" . "KEY_ZYEE_SDLTU" = "DU" . "DIMID" JOIN "/BIC/DZYEE_SDLT5" "D5" ON "F" . "KEY_ZYEE_SDLT5" = "D5" . "DIMID"
WHERE ( ( ( ( "DP"."SID_0CHNGID" = 0 ) ) AND ( ( "D2"."SID_0CO_AREA" = 3 ) ) AND ( ( "DU"."SID_0CURRENCY" = 31 ) )
AND ( ( "DP"."SID_0RECORDTP" = 0 ) ) AND ( ( "DP"."SID_0REQUID" <= 2000000250 ) ) AND ( ( "D5"."SID_0VERSION" = 1058 ) )
AND ( ( "D5"."SID_ZACTYEAR" = 20002009 ) ) AND ( ( "D5"."SID_ZSCENARIO" = 88 ) ) ) )
GROUP BY "S39"."COSTCENTER" ,"S40"."COMPANY" ,"S41"."COMP_CODE" ,"S42"."CS_PLEVEL" ,"S43"."FISCPER" ,"DT"."SID_0FISCPER3" ,"S44"."FISCYEAR" ,"S45"."COMPANY" ,"S46"."/BIC/ZBPSADJT" ,"S47"."/BIC/ZENT" ,"S48"."/BIC/ZMEASURE1" ,"S49"."/BIC/ZTPBU0" ,"S50"."/BIC/ZVAR_IND" ,"S51"."/BIC/ZYEEDESC";
Thank you for your help.
Maniss

Hi sanjay,
It not a column name problem or a typo because when I run the same sql statement after I remove the index I don't get the error
Thanks,
Maniss

Temp start transformation using "with"clause

I'm experiencing a very strange problem. I wrote the SQL below and when I execute through toad and sqlplus, oracle makes the star transformation, but when I execute it through C, it doens't makes the transformation. Any help are welcome.
WITH a AS
(SELECT /*+ materialize use_hash(c,p,c3) */
c.parent_account_no, c.package_id, c3.siebel_instance_id
FROM cmf_package c, package_definition_values p,
cmf_packages_fat3c c3
WHERE c.inactive_dt IS NULL
AND c.package_inst_id = c3.package_instance_id
AND c.package_inst_id_serv = c3.package_instance_id_serv
AND c.package_id = p.package_id
AND p.short_display IS NULL)
SELECT /*+ leading(c ) push_subq use_hash(acr,pdv,cpcp3,ciam,c) */
'PACK_VOZ_DUP', cp.parent_account_no, ciam.external_id, c.bill_period,
cp3.siebel_instance_id, cp.package_id, acr.is_business,
TO_NUMBER (NULL), 1, c.bill_state, 'SI', acr.ROWID, pdv.ROWID,
cp.ROWID, cp3.ROWID, ciam.ROWID, c.ROWID
FROM account_category_ref acr,
package_definition_values pdv,
cmf_package cp,
cmf_packages_fat3c cp3,
customer_id_acct_map ciam,
cmf c
WHERE pdv.short_display IS NULL
AND pdv.package_id = cp.package_id
AND cp.inactive_dt IS NULL
AND cp.parent_account_no = c.account_no
AND c.account_category = acr.account_category
AND c.account_no = ciam.account_no
AND ciam.external_id_type = 14
AND ciam.is_current = 1
AND cp.package_inst_id = cp3.package_instance_id
AND cp.package_inst_id_serv = cp3.package_instance_id_serv
AND cp3.siebel_instance_id IS NOT NULL
AND EXISTS (
SELECT /*+ hash_sj */
1
FROM a c3
WHERE c3.parent_account_no = cp.parent_account_no
AND c3.package_id <> cp.package_id
AND c3.siebel_instance_id = cp3.siebel_instance_id)
explain from Toad
Plan
SELECT STATEMENT CHOOSECost: 199,074 Bytes: 188 Cardinality: 1
     15 TEMP TABLE TRANSFORMATION
          14 HASH JOIN SEMI Cost: 199,074 Bytes: 188 Cardinality: 1
               11 HASH JOIN Cost: 191,234 Bytes: 111,173,166 Cardinality: 726,622
                    9 HASH JOIN Cost: 162,751 Bytes: 108,444,416 Cardinality: 847,222
                         7 HASH JOIN Cost: 159,088 Bytes: 217,362,656 Cardinality: 1,940,738
                              5 HASH JOIN Cost: 134,635 Bytes: 108,065,443 Cardinality: 1,367,917
                                   3 HASH JOIN Cost: 121,145 Bytes: 127,501,647 Cardinality: 2,712,801
                                        1 TABLE ACCESS FULL ARBOR.CMF Cost: 117,431 Bytes: 179,044,800 Cardinality: 5,425,600
                                        2 TABLE ACCESS FULL ARBOR.ACCOUNT_CATEGORY_REF Cost: 4 Bytes: 518 Cardinality: 37
                                   4 TABLE ACCESS FULL ARBOR.CUSTOMER_ID_ACCT_MAP Cost: 9,229 Bytes: 87,546,656 Cardinality: 2,735,833
                              6 TABLE ACCESS FULL ARBOR.CMF_PACKAGE Cost: 17,299 Bytes: 254,003,970 Cardinality: 7,697,090
                         8 TABLE ACCESS FULL ARBOR.PACKAGE_DEFINITION_VALUES Cost: 6 Bytes: 10,992 Cardinality: 687
                    10 TABLE ACCESS FULL TELEMAR.CMF_PACKAGES_FAT3C Cost: 17,248 Bytes: 419,471,250 Cardinality: 16,778,850
               13 VIEW ARBOR. Cost: 3,638 Bytes: 116,664,100 Cardinality: 3,333,260
                    12 TABLE ACCESS FULL SYS.SYS_TEMP_0FD9D660C_D8362B9 Cost: 3,638 Bytes: 66,665,200 Cardinality: 3,333,260
explain from C
Plan
SELECT STATEMENT CHOOSECost: 631,186,428
     19 FILTER
          11 HASH JOIN Cost: 189,620 Bytes: 5,558,643 Cardinality: 36,331
               9 HASH JOIN Cost: 189,425 Bytes: 11,401,688 Cardinality: 83,224
                    7 HASH JOIN Cost: 159,088 Bytes: 217,362,656 Cardinality: 1,940,738
                         5 HASH JOIN Cost: 134,635 Bytes: 108,065,443 Cardinality: 1,367,917
                              3 HASH JOIN Cost: 121,145 Bytes: 127,501,647 Cardinality: 2,712,801
                                   1 TABLE ACCESS FULL ARBOR.CMF Cost: 117,431 Bytes: 179,044,800 Cardinality: 5,425,600
                                   2 TABLE ACCESS FULL ARBOR.ACCOUNT_CATEGORY_REF Cost: 4 Bytes: 518 Cardinality: 37
                              4 TABLE ACCESS FULL ARBOR.CUSTOMER_ID_ACCT_MAP Cost: 9,229 Bytes: 87,546,656 Cardinality: 2,735,833
                         6 TABLE ACCESS FULL ARBOR.CMF_PACKAGE Cost: 17,299 Bytes: 254,003,970 Cardinality: 7,697,090
                    8 TABLE ACCESS FULL TELEMAR.CMF_PACKAGES_FAT3C Cost: 17,248 Bytes: 419,471,250 Cardinality: 16,778,850
               10 TABLE ACCESS FULL ARBOR.PACKAGE_DEFINITION_VALUES Cost: 6 Bytes: 10,992 Cardinality: 687
          18 HASH JOIN Cost: 17,368 Bytes: 53 Cardinality: 1
               13 TABLE ACCESS BY INDEX ROWID ARBOR.CMF_PACKAGE Cost: 5 Bytes: 312 Cardinality: 12
                    12 INDEX RANGE SCAN ARBOR.CMF_PACKAGE_XCP_ACCOUNT_NO_KEY Cost: 3 Cardinality: 1
               17 MERGE JOIN CARTESIAN Cost: 17,362 Bytes: 345,222 Cardinality: 12,786
                    14 TABLE ACCESS FULL TELEMAR.CMF_PACKAGES_FAT3C Cost: 17,248 Bytes: 342 Cardinality: 19
                    16 BUFFER SORT Cost: 114 Bytes: 6,183 Cardinality: 687
                         15 TABLE ACCESS FULL ARBOR.PACKAGE_DEFINITION_VALUES Cost: 6 Bytes: 6,183 Cardinality: 687
Thanks in advanced.

fbucco wrote:
I'm experiencing a very strange problem. I wrote the SQL below and when I execute through toad and sqlplus, oracle makes the star transformation, but when I execute it through C, it doens't makes the transformation. Any help are welcome.
Neither plan shows a "star" transformation - did you mean "temp table" transformation ?
It looks as if your C wrapper has taken out your materialize hint (among others).
Which version of Oracle are you using, by the way ? Is it the same in all cases, and is the client the same version as the server in all cases.
Regards
Jonathan Lewis
http://jonathanlewis.wordpress.com
http://www.jlcomp.demon.co.uk
To post code, statspack/AWR report, execution plans or trace files, start and end the section with the tag {noformat}{noformat} (lowercase, curly brackets, no spaces) so that the text appears in fixed format.
"Science is more than a body of knowledge; it is a way of thinking"
Carl Sagan

Conversion of Update rule to new Transformation

Hi All,
I'm using BI 7.0 SP9. I have a scenerio where in I need to load standard cube 0SD_C03 cube from the standard extractors like 2LIS_11_VAITM etc..
Based on the the thread below I have done the follwoing steps.
how to migrate old transfer rule/update rule to new transformation?
- Activated Business content cubes, update rules, infosources etc...
- Done all the required work in Source system.
- Later migrated data sources.
- Now the problem comes, Based on the above tread I have gone to the context menu and selected "Tranforamation erzeugen". It asks to create new Infosource created a new infosource and the the transformation came up. But I can see its not mapped to Source system datasource. I mean its not linked to the datasource in Source system. Its just created in BW and when i load nothing happen. I understand this is not correct process.
But when it pops up for Infosource If I select existing Infosource I dont see the old one's just because they were migrated already.
Now how do I link with the source system with out creating transformation manually. because there are lots of standard routines in update which cant be rewriten in new transformation manually.
Please let me know if there is a way to directly copy them and also correct me If i'm doing some thing wrong.
Thanks in advance,
Reagrds,
Prashanth Reddy

As Alex said delete the existing datasources and try to replicate it again as 3.x datasources. The process will work fine.
When you replicate datasources it will pop-up screen for you to replicate as 3.x datsources or as a new datasource.
Whenever you will plan to migrate from 3.x to new one, do migrate update rule, and transfer rules first. As when you migrate datasource, it deletes existing update rules/transfer rules also. For each update rule/ transfer rule it will create transformation for you after migration.
After migration your scema will look like:
datasource (new)-> transformation( replacement for transfer rule)->infosource(new)->transformation (replacement for update rules)->data target.
Anyways when you will createmodel from scratch in 2004s system, i hope you know infosource is now more mandatory in 2004s system.

Wrongly transformed the sentences of left and right paragraphs into one sentence in PDF files to txt files by Acrobat 9 Pro

I found that the when transforming PDF files into TXT files by Acrobat 9 Pro, the Acrobat will wrongly transform the sentences of the left hand side and right hand side paragraphs into one sentence, while the correct format should be the later sentence follows the former sentence in each paragraph.
An example PDF is : http://cardiovascres.oxfordjournals.org/content/cardiovascres/45/1/200.full.pdf
Is there any solution for this problem? Or should I use other software (or other version of Acrobat) to solve the problem? Thank you.

PDF is not a word processor file format.
It has no "styles", "format", "layout", "columns", "rows", "tables", etc.
PDF writers paint the content to the canvas that is the PDF page.
Depending on what was used and how it operates this painting can be like a paint by numbers affair.
ISO 32000-1:2008, the ISO standard for PDF explains it all.
So, when exporting to text from your PDF the progression is left to right, top down.
Remember, PDF has no awareness of "columns". What we see is our construct not PDF's.
What you and I see as two columns with a specific read order is our imposition.
What is on the PDF page is simply a line of text characters.
That is how it is with all versions of Acrobat. Applications can only make use of what the file format supports eh.
What to do?
Master content in a logical hierarchy in the authoring file.
Always use the build-in Headings for Headings.
Use the built-in "table" feature.
Use a PDF writer process that is compliant with the ISO standard and that supports proper output of Tagged PDF.
A well-formed Tagged PDF will export properly.
Two key design considerations for Tagged PDF are:
(1) Support Accessible PDF
(2) Support Export of PDF page content.
What constitutes a "well-formed tagged PDF?"
This would be a PDF that is ISO 14289-1, PDF/UA-1 compliant.
Be well...

Wrongly transformed the sentences of left and right paragraphs into one sentence in PDF files to txt files by Acrobat 11

I found that the when transforming PDF files into TXT files by Acrobat 11, the Acrobat will wrongly transform the sentences of the left hand side and right hand side paragraphs into one sentence, while the correct format should be the later sentence follows the former sentence in each paragraph.
An example PDF is : http://cardiovascres.oxfordjournals.org/content/cardiovascres/45/1/200.full.pdf
Is there any solution for this problem? Or should I use other software (or other version of Acrobat) to solve the problem? Thank you.

Hi Anubha,
Same problem occurred when converted into word file.
I convert the PDF into txt as I need to use the txt format for running some analyses (and I have thousands of such PDF).
However, I found the same problem even if I use the original PDF file, so I am seeking the solution.
Actually the PDF can be converted to any format if the problem can be solved! Thank you.

CS6 Free Transform ctrl drag not working properly

Anybody on this ...
When I use the free transform tool crtr-T and use the ctrl drag button, the corners do not extend properly. It extends universally as aposed to a distorted corner-pull. I uninstalled CS6 and reinstalled still getting the same result. Any help would be greatly appreciated...
Thanks

What conroy wrote convert a smart object layer to a smart object layer may seem a bit strange but he is correct. All smart object layers are not created equal they may contain many types of smart objects. An illustrator vector file placed in can most likely be reopened in illustrator by double clicking on the layers smart icon in the layers palette and transform the vector object in illustrator and when saved in illustrator the embedded smart object will be updated to reflect the changes made in illustrator. If you encapsulate a VSO into a Smart Object when you transform the resulting smart object layer it will be transformed like a raster layer using interpolation like all Smart Object layers are transformed. If you want to transform a layer that contain vector graphics using vector graphics you need to correct tools. Transform I would think would only transform Vector Shape Layer using vectors and change Text layer by changing font size all other layer types would be interpolated. An embedded smart object the contains many Photoshop layers some which are text and vector layers like a places PSD file may be transform better using Photoshop Image Size and then transforming the resulting updated smart object layer if your increasing the layers size.

Making correct use of Mappings: Transformation Step in BPE

Hi everybody,
in SAP Docu, I found the recommendation to use Transformation Step only for those kind of mappings that cannot be done in the Integration Engine (e.g. n:1 mappings)
http://help.sap.com/saphelp_nw04/helpdata/en/d5/be364296f1b26be10000000a155106/frameset.htm
Can anybody give me the rationale behind this recommendation?
regards,
Peter

Peter,
That's because u have to use BPM for n:1 or 1:n type of mappings.It can't be done through normal map programs.Hence for the better design if u have normal map then u can perform mappings either before where BPM receive step will receive transformed message or after BPM where maps source message would be fetched from BPM.
Technically BPM transform step is the part of the workflow and it communicates with Java stack for mappings.Thus I guess eliminating Transformation step in normal map would reduce this communication time and thus improves the performance of the interface.
Regards
Rajeev

What effect does a transform function have on the _parent command

Hi
I am trying to load an image onto a symbol in a symbol, that
is spinning via timeline>transform and forms a symbol called
spinner1, spinner2. etc. I want every holder to be a different
image and one use suggested using the _parent function with a
substring function. Will the transform mess this up?
I was suggested to try:
holder.loadMovie("image"+this._parent._name.substring(7)+x);
Which as I understand it tells any instance of the symbol
"holder" to load an image called "image(the seventh letter of the
parent symbol)x" So for any instance of holder in spinner1 it will
load image1x.
My images are assigned using the following:
var image10:String = "logo/jamon.gif"; etc.
"holder" is in "spinner_components"
The symbol "spinner" contains "spinner_components" spinning
using the transform function.
Therefore I also tried the code as:
holder.loadMovie("image"+this._parent._parent._parent_name.substring(7)+x);
and also
holder.loadMovie("image"+this._parent.._parent_name.substring(7)+x);
Neither worked.
Is it the transform function that is messing it all up? or
some syntax?
Thanks

x is a varibale that increase each time it loops and changes
the image displayed.
x is 0, then 1 then 2
spinner is spinner 0, spinner1, spinner2 etc.
thus images should load image00, image01, image02 etc. should
load in spinner0's holder
and images 10,11, 12 etc. in spinner1's holder.
where should this code go - at holder or spinner_components
or spinner.
You can see the final effect (I got arround this problem by
making 8 almost identical spinners)
at
http://danielfield.freewebpage.org.
only my images don't load, like they did in the flash editor.
(I've posted on this separately).
thanks.

Manual image transformation: Losing top of the image

With LR3 I often use the manual image transformations and observe an undesirable effect, which I cannot explain to myself: When changing the Vertical Perspective to a negative value, the image will be transformed to cope with the perspective as intended, but its top will be shifted out of sight as well. For example, when correcting the image of a tall building, the top of its tower shifts out of sight. An example:
After applying vertical correction -33 it looks like this:
The entire top of the tower is gone, on the bottom though we see the "out of image" area, and we cannot shift the image downward to see the top of the tower rather than the "gray" on the bottom. I found no way to avoid this, until I discovered that I can change the scaling factor (while losing the resulting image resolution :-() and than this missing part of the image will be visible again.
Once we scale to 84% the above image, we can see the top of the tower again. Of course, we can crop out the gray areas manually:
However, the pixel size of the image is really reduced proportionally to the scale factor, here 0.84.
Why is that so? I am almost convinced, its a bug.
Thomas

I would not be too worried about losing resolution etc.
If you do a lens correction like the one in the example of the "leaning tower", it is "major surgery" mo matter if you do it in LR or PS.
The top of the image gets enlarged while the bottom stays the same size.
You can think of this kind of lens correction as an image enlargement through a gradual filter that runs vertically.
As enlargements always do, it degrades image quality.
If you are concerned about retaining max image quality, in my opinion it's best to stay away from correction of lens distortion.
But I realize, sometimes we don't have that choice.
WW

Will star transformation be scalable?

Similar Messages

Maybe you are looking for